Separate names with a comma.
Discussion in 'Ideas and Suggestions' started by Eli_Audi, Jul 25, 2016.
Maybe they could have a tertiary wheel in the center all ways on to act as a gyroscope?
Gyroscopes? I did not think of that. Good job.
You could call it mechanic gyroscope, it's using a high weight node located under the ground (without having collision of course) keeping it stable at low speeds. It wouldn't be required above 30km/h though, centrifugal forces of the wheels are high enough then.
I guess it's the same as with a bicycle, riding hands free at low speeds requires a lot balancing by yourself, the faster you go the easier it get's.
Physics based game? F**k physics! Gyroscope under the ground FTW! You did not think of that, Newton, did you?
I'm looking forward to drive it, looks really promising. And I would really appreciate if you teamed up with creator of hovercar (if you guys aren't the same person) and add this feature so it would be, I don't know, driveable maybe?
I'm that guy, I tryed the underground thing, but it's even more wiredly moving with that. But maybe the centrifugal forces might work .
For any of you interested, this is the old way we used to do it...
"Old way"... haha, it still works
The only difference is that BeamNG lets you run custom Lua code, so more advanced controllers can be used rather than just proportional control, currently I'm messing with a predictive model.
I did it again in BeamNG a few weeks ago with a simple PD controller, above 40mph it is has rock solid control.
Bad quality video, but you get the idea:
Now that's what I like to see! Old ways never die!
Edit: That thing is actually incredibly well controlled. Nice job. Looks like it handles almost as good as my real bike! (all be it a bit more flexible)
What are all the blue lines being displayed? Are those the forces being generated that the LUA is keeping track of?
The blue lines are just the aero. forces debug which I left enabled. All the Lua does is control the steering angle of the front forks, in the same way a rider would steer the bars etc. No fake forces or anything like that, it is literally just a few lines of code.
The flex comes from the low weight of the nodes limiting the spring values I can assign the the beams, the entire bike is on the limit of stability. A future version would use fewer but heavier nodes to create a very simple stiff frame, then hang the fairings and parts from that.
The other thing that actually induces the wobbles is the fact the cross section of the wheels are 'square', and so leaning the bike means it isn't as smooth as a rounded profile. (Watch the scrapheap challenge episode when they make bikes but use car parts and wheels and how much of a handful they are to control.)
Ok, I understand that entirely. And I did't even know we had an aero debug... shows how much I have been paying attention.
As far as the tires go... short of getting the devs in here and programming in an entirely new breed of tire for the game... could we possibly "make" a rounded contact patch tire?
Basically using the standard tire as the furthest edges of the tire and then creating the inner/rounded tread out of extra attached nodes and beams. While I am sure it would work, I have no idea how heavy you would have to take the structure to let the physics be able to handle all the extra nodes and beams. Perhaps I should go looking through my old computer for a spread sheet I made way back in the day that enabled perfect settings calculations to get a vehicle down to realistic weight in RoR. I had a representation of my Suzuki LT 125 atv I had made (for funnzies) that had over 300+ nodes (because I was a detail freak) but it weighed under 150KG which was practically unheard of. I really wonder if I still have that thing.
If I can't find it, the way that I did it was to use a Taguchi array with the Set_Beam_Defaults numbers. I would pick some numbers, run the game, see what happened, and then enter them into the array, pick some more numbers, and repeat. There was a lot of crashing and weird squishy vehicles, but after enough data was collected, the spread sheet would spit out almost perfect settings that would still allow the game to run. Was it perfect? No... sometimes it would just give you even worse crashes. But most of the time it was like magic. I really hope I can find that because it took me forever to make. But that computer is almost 15 years old now and its been in my basement for the last 6... so I am not even sure if it will start.
This is what I'm using for the monowheel, all nodes are high weight:
It's only riding on the middle row of nodes, it is a bit wobbly though, but I'm still improving.
Well, that proves that it is at least doable!
Edit: Well, my computer wouldn't start, but I did happen to find some of my old college homework, so I attempted to update it with some better Excel coding.
This is an Excel Taguchi Array. This particular one has 4 input variables, and you can take it to either 3 or 4 levels. The 4 level sheet is the one that I updated and reworked to be more friendly. Although, if need be, I can rework the 3 level one as well for the sake of saving time. Reason being is because on the 3 level sheet you only need to run 9 tests while on the 4 level sheet you need to run 16... so it will take much longer to attain that much data... but it is worth it if this thing works as good as I remember them doing.
On the top of the sheet you can type in your 4 variables... say spring, damp, weight, and deform (just for instance) and then for each level give them a reasonable number that will allow the truck to work. Then start running your tests and iterating the levels for each variable in the specified order in the array for that test number. Once done you then record your performance data at the end of the array in the column marked Performance. For suspension setups I used to run lap times and just enter negative values for seconds.
Once all of your tests are done and your data collected and entered, just scroll down the page and retrieve your optimal numbers. If even more precise values are required, then you can run the whole thing again gauging off of these numbers.
And since I am apparently not allowed to share excel files on here, I will share it like this.
cool. my idea was creating a 2 wheel vehicle but have small invisible wheels attached to invisible stabilizers that work like suspension, the more you turn, the more it leans into the turn. crude but should be effective.
I am sure that motorcycles in the sense to replicate how their physics works IRL is very possible, although hard.
Its not so much about making them, as much as it is having to code the balance with bikes from the ground up. Would love the idea tho, but it would look terrible without stigs/drivers.
Not knowing anything about modding, I feel like once again reviving the whole jbeamed-rider thing. First because of looks, and second because with something as light as a motorcycle the weight of the rider is a significant enough part of the overall package.
Wow, a lot of anger in this thread. Are people not allowed to suggest things in the suggestion part of the forum? Saying "This isn't possible, it would be crazy to try" makes zero sense. The game is supposed to be physics based.
how do you balance you don't sit on a controller and move your body weight? it would be very hard to replicate that with a controller. or almost imposable with a key board! im not mad or angry im just putting this out there sorry if this came across wrong
--- Post updated ---
if done right it should work
Did you guys just totally miss Davded's post or something? He just showed a fully functional self balancing prototype and you guys seem to be still discussing if its even possible?
Ideally you wouldn't lean it yourself, it would lean on its own.
No. You would lean it yourself. The point of leaning in a bike is that it allows you to turn harder without having the G forces of high speed throw you off. That's why you dont usually lean on low speed turning.