Tackling the Physics of Battlezone II

[Zero Angel]

This post will address changes to 1.3 physics which reduce overall maneuverability and player enjoyement. Through this topic, I will explain problems and seek advice on how to address these problems.

CHALLENGE 1: Reduced lateral (sideways) acceleration when moving forward.

I have noticed that in 1.3 when forward thrusters are active on a scout, the ability to move sideways decreases. I have tested this using bridge segments which have clearly defined middles and edges. The first set of tests was carried out from the bridge's center:

||-----[^]---->||

When in a resting position (center of the bridge) and engaging sideways thrusters, the scout hits the side of the bridge in 3 seconds. When thrusting forward and engaging sideways thrusters, the scout hits the side of the bridge in 4 seconds. So lets look at another test case where the user is on one side of the bridge and wants to strafe to the other side:

||[^]----|---->||

From resting, and then strafing, the scout will hit the side of the bridge in 4 seconds. When moving forward and strafing, the scout hits the side in 5 seconds.

This leads me to believe that when moving forward, the *acceleration* (not velocity) of the side vector is decreased.

Such a problem is most noticable on the DM scout "Thunderbolt" (ivscoutdm.odf) which possess very slow lateral acceleration when moving forward and thus inability to dodge effectively while advancing on its target. I believe this change is triggered by the velocity ODF changes from the "Default ISDF" (ivscout.odf) (where velocForward is increased) and not just because velocStrafe has been reduced from 20 to 15.

The degree at which is done is directly tied into the velocForward value, conversely the higher that the velocReverse value is, the more affected the thruster responsiveness when the user is attempting to dodge while backing up.

This makes it difficult for aggressive (advancing) and defensive (backing up) postures since his acceleration is more sluggish when doing so.

EDIT: This looks like a fundamental physics change that was implemented by Ken prior to the release of PB1. I couldn't find anything in the changelogs that makes this tweakable.

CHALLENGE 2: Getting stuck on hills

Another issue that I see is that a hover unit's maneuverability gets reduced when they are on steep-ish hills (~>45 degree), particularly when backing into one, being pulled up it, and trying to execute a strafe maneuver -- the thrust controls on the unit appear to go dead.

I would like to know if anyone knows of a setting that can be tweaked to reduce this effect.

EDIT: Solved, partially. Reducing LIFT_DAMP from its default value of 6.25 also reduces the 'pulling' effect of terrain but does not eliminate it -- reducing it too much reduces the 'traction' units have on cliff faces which may be desired. The effect cannot be completely removed, but it can be somewhat mitigated. LIFT_SPRING should be reduced accordingly to preserve the 'feel' of ships.

[Zero Angel]

Did some digging through the changelogs and found some interesting constants that were exposed and made into variables.

Code: Select all

[HoverCraftClass]
OverLandVelocFrontMult = 1.0f;
OverLandVelocSideMult = 1.0f;
OverLandThrottleMult = 1.0f;
OverWaterVelocFrontMult = 0.75f;
OverWaterVelocSideMult = 0.75f;
OverWaterThrottleMult = 0.8f;
AirborneVelocFrontMult = 1.0f;
AirborneVelocSideMult = 1.0f;
AirborneThrottleMult = 1.0f;
AirborneMinHeightRatio = 2.0f;
AirborneMaxHeightRatio = 5.0f;

By upping the AirborneVeloc settings, It should be possible to get players to use the terrain to gain additional speed which is interesting and certainly something that will be appreciated by strat players.

[MrTwosheds]

These are to define general velocity for hover vehicles over ground/water/airborne, these are used to slow down vehicles while over water, I'm not sure its really what your looking for, increasing the airborne multiplier, would allow a unit to go faster while off the ground. I don't know how AirborneVelocSideMult = 1.1f; for example, would actually effect airborne maneuverability. I suspect it will not do what you really want it to, they are the default settings, airborne is 1, the same as ground, It is the underlying physics code that makes a "ground effect" hovercraft vehicle fly as they do when the ground effect is no longer having any effect.

[Nielk1]

Both cases lead me to believe that the acceleration magnitude is limited but not specifically to a given vector direction.

[Zero Angel]

These are to define general velocity for hover vehicles over ground/water/airborne, these are used to slow down vehicles while over water, I'm not sure its really what your looking for, increasing the airborne multiplier, would allow a unit to go faster while off the ground. I don't know how AirborneVelocSideMult = 1.1f; for example, would actually effect airborne maneuverability. I suspect it will not do what you really want it to, they are the default settings, airborne is 1, the same as ground, It is the underlying physics code that makes a "ground effect" hovercraft vehicle fly as they do when the ground effect is no longer having any effect.

The mults do not increase maneuverability in air, but they do allow for crafts which are using terrain to go faster when airborne.

These are my current settings

Code: Select all

airborneVelocFrontMult = 1.1 // *1.0
airborneVelocSideMult = 1.1 // *1.0
airborneThrottleMult = 1.5 // *1.0
airborneMinHeightRatio = 1.5 // *2.0
airborneMaxHeightRatio = 4.0 // *5.0

The 'throttle' setting reduces the effects of friction/drag acting against the craft. In other words, it accelerates better even when traversing things that would otherwise slow down its acceleration (like sharp slopes), kind of like giving a truck more horsepower -- while the top speed and acceleration on flat terrain doesn't necessarily increase, it will accelerate more capably up slopes and when bearing load.

The air speed boost, while nice -- doesnt resolve any of the first two problems I presented.

[Zero Angel]

I have found a way to reduce adverse effects of moreLike12Physics on ivscout12.odf by using these settings

Code: Select all

[CraftClass]
MIN_BOUNCE_VEL = 1.0 // *0.5
OBJECT_ELASTICITY = 0.0125 // *0.125
GROUND_ELASTICITY = 0.003125 // *0.03125

Basically, I doubled the MIN_BOUNCE_VEL value, and reduced the elasticity settings to 10% of their stock 1.3 values.

The result is that the physics code that increases the gravity of the ship over time when airborne still works like GSH intended, but the drawback of having ships bounce off the terrain like rubber balls is also greatly reduced and so these types of ships are much more usable.

[Zero Angel]

After some experimentation, I decided to tweak a setting that never really caught my interest before.

accelJump

I have to say now that accelJump is *such* underrated setting when it comes to craft handling. By increasing it, I noticed that it affects speed/acceleration when nose-downing, and even helps to traverse hills as well as maintain air speed when performing a rainbow attack.

In fact, when I combined a higher accelJump with the airborne* settings, I noticed that overall air speed increased much more than I would have liked -- causing me to have to tone down the airborneVeloc and airborneThrottle settings a bit more to accomodate the extra velocity provided by the jump thruster, while still coming out with a result that felt organic.

I applied this knowledge to the Sentry's ODF combining it with a high-ish rollStrafe setting, by strafing and using the jump thruster -- the sentry could perform a 'slide' maneuver to perform a wide flank on its target because the accelJump combined with its amount of sideways roll would allow it to accelerate sideways to a greater magnitude than when its jump thrusters are disengaged (but at the cost of slower deceleration). Doing this makes the sentry feel much more dynamic.

[Red Devil]

dude, you're a little late to the party

you should also adjust these values when adjusting that value:

LIFT_DAMP = 4.25
LIFT_SPRING = 10.0

[Zero Angel]

dude, you're a little late to the party

keep your cheeky comments to yourself. I never seen you make a thread trying to make sense of physics in 1.3 -- hence why my post about this is so 'late'.

[Red Devil]

no, i don't that think i will... talking about all these settings like they were just discovered and the effect that they have is amusing. it's even more amusing when someone with tons of experience using them and tweaking them is rebuffed when he offers some advice...

[Zero Angel]

It's not your advice i'm rebuffing, just your condescending tone. Excuse me if I don't kiss your butt cheeks in gratitude this time.

[Zero Angel]

Okay, i've explored LIFT_DAMP and LIFT_SPRING and here are my findings:

[HoverCraftClass]
LIFT_SPRING = 25 // hardcoded default value for hovercrafts
LIFT_DAMP = 6.25 // hardcoded default value for hovercrafts

LIFT_SPRING affects the magnitude of rising/falling of the craft. For crafts which use MoreLike12Physics, the default value is too high and is partially responsible for the fast/hard bouncing that the crafts experience, I would advise a value of 12.5-15 for these crafts to reduce the magnitude of AGOT (accumulated gravity over time) and bouncing that these craft experience when they are eventually pulled to the ground. Setting the value too low makes height transitions feel more 'muddy' and setting it too high makes them too severe.

LIFT_DAMP is used to 'smooth' changes to the height vector relative to the terrain that the craft is over. In other words, it allows the craft to 'hug' the terrain more when going over hills and bumps. Interestingly enough this setting may be partially responsible for the effect which causes crafts to run into an 'invisible wall' and get sucked down when trying to pass over cliffs. Setting LIFT_DAMP to 0 allows for completely smooth flight over cliff faces. On MoreLike12Physics craft, I prefer to set this to 1.25 to reduce the effects of terrain on flight while not eliminating the 'terrain hugging' which makes the craft feel like it has actual weight.

Another thing to note, is that lowering LIFT_DAMP to something even as low a 3.125 will cause even normal crafts to 'dip' into water when landing on it from a high height -- however this setting will reduce cases where the user is unable to escape the 'pull' of a cliff face.

In the case of TorpedoClass units, it may be advisable to set this LIFT_DAMP fairly low (ie: 10) to prevent it from ramping too high off of terrain, while setting the LIFT_SPRING fairly high (ie: 40) to allow the torpedo to fall quickly.

So thanks, RD, for bringing those things to my attention. And thanks, GSH, for making these values tweakable.

[Commando]

I don't fully understand what each does.

LIFT_Spring. Does that determine the speed a ship will snap to it's over altitude, if pre-placed on a map at an altitude of 0?

It appears to be the amount of upward force applied to a ship when it's altitude is below that of it's Hover Altitude. Only applying an upward force on the object.

LIFT_DAMP. Does this reduces or increases ascending and descending of a craft based on whether it is going up a hill or down one?

I'm at a loss as to what exactly LIFT_DAMP does. I set it to 200, and the ship bounced indefinitely. It didn't bounce in place, it ascended indefinitely. It would settle at a specific altitude, then would bounce upward, then would settle only to repeat. But it would settle at a higher elevation than it's previous altitude. LIFT_DAMP definitely applies an upward force since setting it insanely high causes a unit to ascend indefinitely. I'm not sure if this setting is only applied while the unit is bobbing up and down prior to settling at it's hover altitude or how this setting works.

[Commando]

I'm not a physics person, so my understand of the settings is limited. The following is what I observed.

Think of BZ2 ships interacting with the terrain as if there is a spring between the ship and the terrain. The ship's setAltitude, specified in the ship's ODF, is the spring's natural position. When the ship's altitude drops below the specified setAltitude, the spring is compressed and therefore an upward force is applied to the ship in order to return the ship to its natural position or the setAltitude[/b\. This upward force is called LIFT_SPRING.

Once forced upward, by the LIFT_SPRING, the object will oscillate up and down until it settles to it's setAltitude. In theory, LIFT_DAMP reduces the oscillation that occurs until the ship returns to it's setAltitude.

In actuality, LIFT_DAMP seems to do more than absorb energy. If set too high, the unit will oscillate indefinitely, gaining altitude as it does so. I'm not sure of the math as to why this happens.

[Red Devil]

It's not your advice i'm rebuffing, just your condescending tone. Excuse me if I don't kiss your butt cheeks in gratitude this time.

in that case, i see your tone and call.