EmptyEpsilon
EmptyEpsilon copied to clipboard
daid
[Bug] Inacurate jump time
As engineering increases power to the jump subsystem, the timer jumps between integers goes faster in the helms, single pilot and tactical position.
While that can look a bit odd, the question is, what would be the alternative? Recalculating and changing the numbers could potentially be even more confusing. I think it works the way it is now if you don't see the number as seconds, but literally as a count down. You can also see the speeding up as a side effect of the folding of spacetime :-)
Perhaps adding a charge bar like the charging animation with a clear end marker could make it less quantitative while making it intuitive?
That might work, although I once ran a game were the crew liked to chant every single countdown, so they would probably miss it :-)
Right now on legacy/2024.12.08, the SpaceShip jump_delay variable is used not only for the countdown display but also to gauge the jump itself, and also as a hardware controller value for jump feedback and in CPUShip AI. It counts down as a tick * jump system effectiveness rather than just the tick, which causes the speed-up (and also, reduced power or system damage also makes the countdown slower than 1 per second).
The behavior is generally the same in ECS, with delay now being the runtime value in the JumpDrive component, the default delay set at 10.0 as activation_delay in the component, and the tick * effectiveness countdown occurring in JumpSystem::update.
The jump delay is independent of jump drive charge capacity; as long as the charge is full and system effectiveness is 100%, it takes a default 10 seconds to jump regardless of the set or maximum distance.
We'd have to detach jump progress from the displayed timer value and define it as a rate independent of the countdown, which should also let us display and update the expected time-to-jump in the jump control before starting the jump. We also likely should do this without breaking hardware feedback compatibility, and should test that CPUShips still jump as expected.
