XR57

physics notes

Recommended Posts

stuff I write down that I decided to make public; will be updated, possibly

 

 

SPEED AND VELOCITY

 

Top speed, as in redline, is determined by the lowest of all speed limits as well as encumbrance.

The first limit comes from your cabin; it may be multiplied by an engine, or increased additively by a codriver; the former will multiply the latter (getting conflicting answers on this). Time taken to accelerate to this speed is represented by the acceleration stat, so by raising this you gain some true-acceleration as well.

The second limit(s) comes from your movement parts; these limits may be raised by either the golden eagle engine or steppe spider cabin, if applicable. Does not alter acceleration.

Wheels have no limit themselves, but with them, cabins will have an additional, unmodifiable limit in reverse. (Seems to vary by wheel actually? High enough power consumption might create a terminal reverse velocity.)

Lastly, you will also be limited if your weight crosses max tonnage—continually so up until you cross your mass limit, at which point you will travel at around 1/2 kmph.

The speedometer and travel counters simply deduce via RPMs rather than tracking your true velocity or travel distance; you can fly through the air at "0" kmph, etc.

Increasing wheel circumference will not gear your vehicle any differently, though bigfoot wheels speed up the travel counter.

Combining forward or backward movement with strafing will increase neither your current nor maximum speed. However, RPMs from rotation stack with translation independently.

Traveling through water will neither decrease nor limit your speed.

Even subtle collisions at 240kmph will result in instant death.

 

Example:

A trucker, below tonnage, on augers, with a golden eagle engine and +5kmph codriver, will have its 60kmph cabin speed raise to 65 and then increased by 8% for 70.2 kmph, and then its 60kmph movement part speed raised by 10 for 70, with 70 being the lower of the two limits and thus the actual speed.

Ideally these limits ought to be as close as possible, but this kind of optimization is typically not a priority.

 

FORCE, MASS, AND ACCELERATION

 

Increasing your mass will decrease your acceleration.

Increasing your power will increase your acceleration, per unit of mass.

Increasing your tonnage or mass limit will NOT increase your acceleration UNLESS you were already OVER your tonnage limit. An easy, controlled way to test this is to compare steering wheels to regular ones, which differ only in their tonnage support (provided you’re driving in a straight line). Raising these limits will have no effect on acceleration: they merely give you permission to add more mass, which lowers it. A heavier wheel with more “net tonnage” will still impede upon your acceleration more than a lighter one with less would, and so on, assuming you were already below the line.

As with speed, your acceleration will be penalized if your weight crosses max tonnage—continually so up until you pass your mass limit, at which point you will travel at around 1/2 kmph. Also like speed, bonuses to mass limit and tonnage from engines should affect codriver bonuses (getting conflicting answers on this).

Your RPMs face a kind of drag force, such that the higher your current wheel velocity is, the less well it can be raised further. At least in real life, drag force is typically proportional to some fraction of the velocity squared, such that the fraction is initially smaller, but eventually grows to match the current acceleration due to the squaring of the velocity, thus creating a terminal velocity and so on. However, this is NOT the limit which your vehicle speed is determining; increasing your max velocity will NOT increase your acceleration/diminish drag force. Actually yeah, this works for some reason. The acceleration-stat dictates your time to max speed, so by raising your max speed without altering the acceleration-stat, you actually gain true acceleration despite the stat not changing. This is based specifically off cabin speed though.

This drag force is applied, specifically, just to RPMs; your car is otherwise treated as a projectile in space. This can be tested by breaking traction and going into several doughnuts; per each loop, the net force on your car should come out to zero, hence why you should pivot about one point—however, if traction is broken, each doughnut will nonetheless translate some fixed amount to the side, making a continual line of doughnuts, neverending so long as you remain on a flat surface. Or other words, your vehicle is object in motion which remains in motion, due only to inertia and not the continual application force which would be required if there were air resistance. Note that traction is easier/harder to break on certain surfaces; formerly this was dependent on wheel type as well I think. There is also still a recoverable static friction.

Water impedes acceleration, but still just on RPMs. Impacting water will not decelerate you as colliding with a denser atmosphere would realistically.

Given the lack of atmospheric resistances, there’s likely no way to produce airfoil-type lift force either. However, force from weapon recoil or boosters is more than enough to sustain flight.

Wheels and the like WILL apply counter torque to the cabin, while gun swivels will NOT. You CANNOT twist your gun into the floor to prop your car up, nor can you rotate a turret against someone to push them around, etc.

Unlike high speed, no amount of instantaneous acceleration has been shown to cause death, despite that unlike high speed, this actually can kill you in real life.

The penalties/benefits to power from wheels/engines are summed affectively, such that eight -10% wheels will have the same effect as four -20's, barring mass etc. However, the sum itself is not scaled linearly, so a net subtraction of 100% will not remove 100% of your power.

Edited by XR57
  • Thanks 2
  • Confused 1
  • Upvote 2

Share this post


Link to post
Share on other sites

i think 255'ish ( there is a specific number for this ) is maximum speed, ive build a flyer and when it reaches 350+ it just exploded even without floor contact!

Share this post


Link to post
Share on other sites

Might as well get some additional info i've gathered over the time while designing my race vehicles out there. I was going to make this into a guide but never managed to simplify their explanation enough for your average player, or cover all possible scenarios.

 

  • Wheels use a static physical collider to handle self-destruction collisions and collisions with other players, while "normal" use uses raycasting. This collider is smaller than the wheel visually appears, and doesn't change with suspension travel.
  • Wheels also use an internal velocity counter which can be unrelated to the vehicle's actual velocity. This is most noticeable under two circumstances: moderate braking and booster use without throttle.
  • Steering wheels also use an internal turning angle counter which does not seem to actually match the visually reported turning angle on some wheels(although appears to be proportional to it).
  • There are 3 wheel forces: longitudinal force, lateral force, and drag.
    • Longitudinal grip is applied on braking(for rolling wheels), and throttle(for all wheels, as long as the internal velocity counter is higher than the vehicle's (forward?) velocity).
    • Lateral grip is applied proportionally to slip angle and forward velocity on rolling wheels.
    • Drag forces are always applied against the vehicle's velocity vector.
  • There are 4 wheel states: rolling, sliding, locked, and parked.
    • Rolling wheels visually appear as rolling. In this state, lateral forces are applied, along with a low amount of drag.
    • Sliding wheels visually appear as rolling and also have a low amount of drag, but don't apply lateral forces. This state happens if treating the wheel as rolling would cause too much force to be applied.
    • Locked wheels visually appear and behave as rolling or sliding as long as no braking is applied. When braking is applied, they visually lock up, stop applying lateral forces, and have increased drag.
    • Parked wheels visually appear as locked even without braking applied, have a high amount of drag and don't respond to lateral forces whatsoever.
    • The main difference between a parked wheel and a locked up wheel is releasing brakes will cause a locked wheel to resume rolling, while a parked wheel will not.
    • A rolling or locked wheel below a certain forward-axis-relative vehicle velocity threshold(~0.5 m/s) not under throttle changes to a parked state.
    • A rolling wheel transitions to a locked state when their internal velocity counter reaches 0.
    • You can still park wheels in a moving vehicle, by having it reach an angle of attack close to 90 degrees.
    • The locked-up wheel state was only introduced somewhat recently(though i can't specify which patch). Before, any locked wheels behaved as parked, and they could spontaneously park if you were moving by only using boosters for a while.
  • The self-destruction-on-collision-with-terrain threshold is exactly 240km/h. There were previous updates where self-destructions happening due to collisions in test drive had their speed logged, and i've done several hundred tests to identify it at the time. This logging was eventually removed, but the threshold velocity didn't change.
  • Boosters apply their forces on where they were at the previous physics simulation step. This results in torque being applied to a moving vehicle even if its center of mass was perfectly aligned with the vehicle standing still, as seen here. I have been actively using this for a long time to control vehicle direction during flight.
  • The physics simulation time delta between steps is locked to the game client's frame rate in test drive, and to 30 Hz on game servers(used in pretty much everything else). This ruins test drive's suitability for physically-demanding-vehicle testing, especially on powerful computers running high refresh rate monitors or without frame rate limiters in use.

I'm still not exactly sure on the hover physics model, but a lot of it appears to rely on raycasting and relative terrain velocity. This can be exploited in race designs to produce not only lift from ground effect(up to a point where one or more hovers loses said ground effect then suddenly gains it back, typically with catasthropic results), but also can be used to provide downforce. There are limited circumstances where i can take advantage of this, but i'm pretty sure one of the main things making me a fast hover racer is being able to avoid creating sudden accidental lift changes while in race conditions - at least most of the time.

 

  • Thanks 2
  • Upvote 1

Share this post


Link to post
Share on other sites
12 hours ago, RA2lover said:

The physics simulation time delta between steps is locked to the game client's frame rate in test drive, and to 30 Hz on game servers(used in pretty much everything else). This ruins test drive's suitability for physically-demanding-vehicle testing, especially on powerful computers running high refresh rate monitors or without frame rate limiters in use.

Is this the reason why sometimes when I test a car in test drive and do sharp turns, I might conclude the craft doesn't tip over? Yet when I take the car onto battle, suddenly I'm having tipping issues on sharp turns?

 

Thanks for the additions, great read!

  • Upvote 1

Share this post


Link to post
Share on other sites

Usually not - the main effects this change has on vehicle dynamics are on booster use and to a lesser extent terrain collision probability.

  • Upvote 1

Share this post


Link to post
Share on other sites

@RA2lover so random quarry, I notice packet loss can result in weird collision issues, tracks or BF (etc) sinking into terrain, any idea on how to document/prove this for bug report purposes, 

Share this post


Link to post
Share on other sites

I'm pretty sure the game's match servers run an authoritative physics simulation for their matches, with the only things sent by players being their inputs and look direction. There seems to be some client-sided interpolation involved(which could be causing these issues to visually happen to a client), but the closest thing i can think of in terms of tracking down what is causing it is essentially recording all packets transmitted/received by all players(and the game server, which would require developer intervention) in a match, reproducing said visual behavior in the match, and comparing what happens between the viewpoints of the server and involved clients, down to individual server ticks.

It's not something you'd be able to submit directly to the developers, and this would likely require a networked debugging environment(and potentially a few hundred to a few dozen thousand lines of custom code, depending on whether they're already recording match replays and how organized their codebase is) to analyze properly.

Edited by RA2lover

Share this post


Link to post
Share on other sites

Well the fact our input latency is dependent on the ping already proves the client pretty much just sends input data over to the server, the server does the heavy lifting, sends it back to client and lets the client render it in front of our eyes. If the "server fps" is 30 and physics calculations are run at that fps, that's pretty much decisive evidence it's the server that runs the physics, not the client.

Share this post


Link to post
Share on other sites

thanks for that

dev's saying it's not My ISP (lol :P) is unlikely.

theres 2 cases i have seen personally & happen to others, both have more than Visual outcomes, 

  1. Bigfoots (may happen to others -easy to see on BFs) sink down to hubs, visual yes, except that it stops the build, or significantly slows it or throws it in some direction (in race this is obvious due to lack of other normal action) 
  2. tracks or wheels "trapped in terrain/scenery - (this is pretty rare now as most maps/gear has improved) - except for BF's, armoured, goliath & meat-grinders, which seem to skim surface (visible or not) - saw a build recently go backward off a "cliff" while firing & get stuck with tracks half in the ground, cannons stuck firing straight up, no flip counter (or screenshots - did it happen?) & dies quick because of it, i've had meat-grinders do this when wedged by tusk rocket

 

Share this post


Link to post
Share on other sites
On 6/10/2019 at 9:48 PM, RA2lover said:

 

Could you explain where you got most of this from? I'll take your word for it on the 240 SD logs.

Also, in what way is the second point different from IRL wheels/speedometer? For example, spinning your wheels "50 kmph" in an upside-down, stationary car shows 50 on the speedometer, as it does in crossout. It sounded like you were saying something more.

Share this post


Link to post
Share on other sites
On 5/19/2019 at 2:07 AM, Cathy_Toshlyra said:

i think 255'ish ( there is a specific number for this ) is maximum speed, ive build a flyer and when it reaches 350+ it just exploded even without floor contact!

It did hit the ground or an invisible wall. Wheeled racing cars can reach really high speed on flat ground and survive. I've reached 600 km/h and managed to brake and survive, and I know I'm not the first or best one. The racers I talk with go past 1000 kmh on the Adventure highway. With wheels.

Edited by Clebardman

Share this post


Link to post
Share on other sites

Can we talk about how slightly scrapping the ground shouldn't make you do this:

tumblr_o31jxi8u3W1safv0do1_400.gif

But this:

tumblr_nr904njl581qz7otto3_540.gif

Edited by lucashc90

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.