Revert "Makes the emergency shuttle and status display process timed to the second" #36980
Conversation
…to the s…" This reverts commit 29536e3.
|
To be fair, figuring that out pre-merge would have required some industrial levels of stress testing, but yeah the displays should probably be updated independantly. |
|
could not reproduce this with spawning copies of a clothed mob to be crushed by the shuttle as it docks |
|
Folks are thinking it has to do with moving the shuttle dock as well, but the cause is clear: the shuttle fails to move before the next shuttle process() is called. Messing with the shuttle timings created mustard gas. I talked with several others and the general take is that this method (speeding up the shuttle subsystems and linking them to the displays) isn't worth it for the status screens, which have their own pile of glitches on top of this. I had two bugs reported to me with these as I was typing this... why can't they make bug reports... |
i wish they did because i have no idea what they mean by this |
Reverts #36388 due to a bug where the escape shuttle will immediately leave BEFORE arriving at the station if it takes too long to dock, usually due to shuttle crushing a mob or two. Speeding up the subsystem was a bad idea with unforseen consequences...
This should probably be reimplemented by putting the displays on their own, faster subsystem, and call the dedicated
/datum/emergency_shuttle/proc/timeleft()function to get the true timeleft and implement a similar solution with shuttles in general.Why it's good
Admins don't have to deal with the game state breaking anymore. Closes #36886.
How it was tested
The PR this is reverting was tested, but it wasn't stress tested enough.