Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SafariJohn]

I was idly testing very high acceleration/deceleration values and decided to see how big of numbers I could use. I was not able to test thoroughly, however, I was able to determine a few things.


Bugs:
 - Extremely high values (confirmed at 100,000) in both acceleration and deceleration causes a bug that affects diagonal movement (only tested using turn to cursor): forward/backward speed (but not left/right speed) drops to a very low number. Forward/backward and left/right strafe movement alone still work as they should. Testing at various values between 40,000 and 50,000 seems to indicate the cutoff value is in that range, however, I was not able to find an exact value.

 - My testing may have been interfered with by a possible bug with diagonal movement: either diagonal movement is not at a 45 degree angle, changing the acceleration/deceleration values can affect the angle, or (now that I think about it) the 16:9 aspect ratio of my screen was affecting my perception. More rigorous testing should be able to hammer this out, although it probably requires significantly better measurement tools than my good ol' Mk 1 Eyeball (D).

 - The action Decelerate (default "C") cannot handle large deceleration values (such as 30,000); it overcompensates, unable to get to zero. The value of acceleration has no effect.


Findings:
 - Nearly imperceptibly fast (effectively instantaneous) direction change is accomplishable by setting acceleration and deceleration to 30,000 (should be bug-free, excluding directly above bug). When testing a Hound only a flicker of the ones place on the speedometer was visible when changing back and forth from forwards to reverse or strafe left to strafe right. When testing a Lasher traveling at 600 (modded 500 base + AE + 0-Flux Bonus) the changing numbers were more noticeable, but still only a brief flicker. 60 fps, of course.

 - Forward and strafing acceleration are controlled by the acceleration value, but reverse acceleration is controlled by the deceleration value. This means you cannot create a ship that can accelerate quickly forwards but not side to side, as far as I can tell.

 - Deceleration set to 0 is read as 1. Presumably acceleration defaults the same way.


 - I also messed with turning acceleration. Setting it to a high value with turn to cursor movement causes the ship to flicker back and forth, overcompensating in a similar way to the Decelerate action as it tries to face the desired direction.


More testing would easily (given time, of course ) find all the unknown cutoff values that create the above anomalous behaviors, but I found enough to do what I was interested in, so I'm not messing with this further. Hope this helps somebody else.

[Tartiflette]

The ship's top speed is capped at 600 I believe. Accelerating at 60 x the speed would be instantaneous so 36000 should be the maximum acceleration usable by the game engine. That could explain the bugs, and why it's probably not necessary to correct them. The values could be capped though.

[LB]

Coming back to this - on a semi-related topic, I'm interested in details of stats on weapon rotation speed. For example, what sort of variables control the slowed rotation of weapons during bursts? What's the max rotation speed like? Can it be literally instant including during bursts?

[xenoargh]

I don't think there is an upper limit on turret speeds in the sense of being a major ceiling, and they can certainly reach instant turning to an angle.  That's really not that high of a value; we're talking 10800, for true, one-frame instant turns (although that would look pretty weird, in practice, at least with anything on auto-fire).

The only place where that's not true is the way that Beam sources are locked positionally after they've finished a "burst"; this is working by design, to prevent a minor visual glitch, but it's always been a little wonky.