Tackling the Physics of Battlezone II

[Zero Angel]

LIFT_DAMP's duty is to equalize the craft's previous altitude with the setaltitude of the terrain it is encountering, including the natural resistance of the terrain for out of the setAltitude through use of accelJump. If you set LIFT_DAMP high on a torpedo, and then make that torpedo scale a 20m cliff, when it reaches the top of the cliff face, it will be 20m high in the air and have to fall down by 20m. This 'invisible wall' effect also affects scouts which try to fly over a cliff, in that case the LIFT_DAMP impedes them from passing through the invisible wall.

[Red Devil]

good luck implementing that or anything; fixed the Scion Gunship a few years back by adjusting that and uploading it for testing, but it was never tested/added. okay, a lot of the fixes i uploaded were never tested, so they were never added/implemented.

[Zero Angel]

good luck implementing that or anything; fixed the Scion Gunship a few years back by adjusting that and uploading it for testing, but it was never tested/added. okay, a lot of the fixes i uploaded were never tested, so they were never added/implemented.

Burns Fighter 2?

[Commando]

Wow, that's all I can say. Would be funny if someone made a Mega Maid.

[Commando]

With changing stock assets, you are going to have a harder time getting them approved or tested. I made the GreenHeart and Commando Recycler Variants for that reason. It's hard enough to get 1.2 players to play due to the physics changes. When you go screwing with assets, that creates a potential for more complaints. Unless there is a very good reason to change a stock asset, I tend to not try them out.

[Zero Angel]

I just tested MIN_BOUNCE_VEL, and have to say that increasing this setting is most critical for reducing bounce on crafts that have characteristics that cause bounce -- probably moreso than the other elasticity settings.

[MrTwosheds]

I would certainly be in favour of a tweak that reduced the invisible wall at the top of cliffs effect, I do find that very annoying sometimes. Best put this on a list of things to consider, while current implementations are being worked on.

[Zero Angel]

I have used this setting for non-moreLike12Physics ships with good effect

LIFT_DAMP = 4.125 // *6.25

It reduces the effect enough so that it's not so annoying, but introduces craft bounce (which requires an increase in MIN_BOUNCE_VEL to compensate) as well as when craft fall from a high height and hit water, they will go into the water and surface right away -- I don't think it could be worked around without raising LIFT_DAMP up to its default value but the going under water thing is a lot less annoying than getting snagged on cliffs.

[Zax]

I would certainly be in favour of a tweak that reduced the invisible wall at the top of cliffs effect, I do find that very annoying sometimes. Best put this on a list of things to consider, while current implementations are being worked on.

That's a leftover from BZ1 phsyics. More subtle in bz2 but very annoying. I would like more aircraft-class type terrain interaction as far as altitude goes with hover craft.

[Zero Angel]

A few more notes for anyone who's interested:

PitchPitch affects the magnitude of user induced pitch to a craft. Setting PitchPitch high will allow the user to pitch the nose of their craft more quickly, but if it is too high then it can allow the craft to overcome the leveling force of the terrain and nose up and down completely even when on the ground. This can lead to a secondary effect of having the accelJump provide additional acceleration to the craft nosing down to the point where a craft moves at an extremely high speed.

PitchThrust, despite the comment that says 'nose down', only affects how much the nose pitches when the craft goes from neutral to forward, or neutral to backwards. Set to 0 to make the craft remain completely level when accelerating or decelerating.

AlphaTrack does as it says and controls the speed that the craft 'rights' itself when landing on the terrain from a rolled or pitched orientation. It also globally affects the reactiveness of rolling and pitching maneuvers.

AlphaDamp resists changes of the pitch (and roll) orientation of the craft. AlphaDamp works directly against natural forces (like terrain) and ODF settings to smooth the pitching and rolling vectors of the craft. It may be a good idea to increase this if the handling of the craft is unstable.

RollStrafe obviously controls the maximum roll of the craft when it strafes;If this is combined with a high accelJump, it can be used to provide additional sideways acceleration when the craft rolls.

[Red Devil]

good work on analyzing all of the odf settings.

[Zero Angel]

After a little more analysis of alphaTrack, I have determined that it not only affect the leveling setting, but also the acceleration (alpha) of rolling and pitching maneuvers (even while airborne) -- higher alphaTrack will mean that a craft will react more quickly to forces that affect its roll and pitch such as natural terrain correction and ODF settings like pitchPitch and rollStrafe.

AlphaDamp, on the other hand, damps the 'momentum' vector of rolling and pitching maneuvers. If the alphaDamp is too low than the craft will not properly level out, pitching and rolling uncontrollably when even the slightest forces are applied to it. I will update the previous posts which explain the alphaDamp and alphaTrack settings.

[Zero Angel]

Does anyone else think that the LIFT_DAMP setting is similar to a sine wave? The higher the LIFT_DAMP, the higher the frequency of the sine wave that affects lift forces relative to the terrain/setAltitude. It might explain why craft with a low LIFT_DAMP 'pierce' the height of water more readily -- the craft's vertical acceleration differs greatly from the damping forces that seek to level it out to it's setAltitude.

[Zero Angel]

Okay, here's a precise explanation of what LIFT_DAMP is.

Hovercraft have a set altitude that they are supposed to be at. It is the job of LIFT_DAMP to enforce that altitude close to the ground. Think of how a magnet works. The magnet has a certain effective range, anything inside of that range of the magnet will be pulled in. Well, the LIFT_DAMP is a lot like a variable that determines the 'strength' of that magnet -- but it only affects the pull within that certain effective range. We will assume that the center of the force lies at the craft's setAltitude (ie: for the scout, it would be 1 meter off of the ground) and that the amplitude is also equivalent to the setAltitude (so the effective range of the force would be 0 meters to 2 meters high).

The reason why having an insanely high LIFT_DAMP is problematic is because when the craft is accelerating at the top end of the 'magnetic floor region' that liftDamp affects, is that the craft's downwards acceleration is increased because the magnetic pull to the central height of the magnetic plane is greater than the craft's downwards velocity, causing the craft to accelerate downwards even faster and slam into the ground. The upwards velocity generated from the bounce from terrain combined with the upwards magnetic pull from LIFT_DAMP causes the craft to accelerate upwards even faster than normal and break out of the bounds of the force.

On the other hand, a very low liftDamp will result in more bounce on crafts since the magnetic effect of LIFT_DAMP is not strong enough to decelerate the craft and it will collide with the ground.

[Zero Angel]

I am happy to report that I have found out additional information about MIN_BOUNCE_VEL, and some of it very useful.

MIN_BOUNCE_VEL, while it can be used to reduce terrain bounce when the LIFT_DAMP setting is lowered, can also introduce undesirable effects with hover unit collisions. Raising this value will cause collisions with other units to cause the craft with the raised MIN_BOUNCE_VEL to bounce off of the other craft more.

HOWEVER! When raising the MIN_BOUNCE_VEL on treaded units to 10 or more, it starts to fix collision problems between treaded units (like Scavengers) and buildings -- it also creates a weak resistive barrier for the units but they can still phase through each other.