Off-by-one in 4c2c95c72bcb. This would cause the most recently added element in any specific version of the game between versions 78.1 and 96.0 to be reported as missing in saves made with that version of the game.
So it would always sample in K. For example, sampling something with a temp of 20C would sample the string "295.15" without specifying a scale, which would then translate to 295.15C once OK'd.
Point arguments are supposed to look like "x,y", but if you gave it anything after y, it would crash. The comma split data is stored by reference, but the String it was referencing goes out of scope and is potentially destructed. Fix it by expliticly keeping a String object in scope until we're done.
An old hack got deleted that converted values for "temp" to StringType, to force it down the string conversion flow which handles temperature scales. I added that code back.
CAUS will convert multiple nearby GAS to RFRG when this reaction triggers. Perhaps it should have been a 1:1 conversion, but it's been like this from the start and nerfing the conversion rate could break reactors that don't input enough CAUS
This fact that this was missing was overlooked in 7e9d9686dda4 because the gravity mask had not been stored in Snapshots even then, ever since edad8f46af6c.
Specifically, either at the UI rendering rate or the FPS cap, whichever is lower, or simply at the UI rendering rate if there is no FPS cap.
Also, always render the UI at the screen refresh rate; importantly, even when the simulation is unpaused. Unpausing the simulation would lower the UI rendering rate to the FPS cap to prevent rendering from being too out of sync with the simulation, but this is now impossible.
Also stop displaying 0 FPS when the simulation is paused. This now closely matches the way FPS used to be displayed, i.e. display simulation tick rate when the simulation is unpaused, display renderer tick rate when it's paused, and don't display SDL tick rate anywhere.
Client wouldn't get ticked if the simulation was paused >_> Also fix some old bugs that would allow weird delay values to be derived when tick schedule was given weird target FPS values.
It's really annoying when a stable workflow fails because nextVersion didn't get updated, whereas we actively seek out this variable when planning a new version between stables.
And have ui.fpsCap set only GameView's fps cap. This is the closest we'll be getting to the fps cap being true to its name (i.e. actually controlling frames per second, rather than ticks per second) with this iteration of the user interface. Also disable SRT if the sim is paused. Together, these changes fix some old problems such as non-sim user interfaces burning CPU for no reason when the fps cap is removed.
This was ill-designed: "vsync" should be a draw cap limit, if anything. We can't currently think of a way to allow both vsync and a different arbitrary fps limit without banishing the simulation to another thread, so this gets shelved now.
So now user interface ticks (event processing, animation, etc) happen in tandem with drawing the user interface. This happens to solve some weird lag issues on linux with ibus, and who knows how many other similar performance problems we're not aware of.
Namely, the ones caused by element numbers already invalid at the time of saving. This makes it impossible to intentionally have invalid element numbers in the low bits of properties listed in CarriesTypeIn, but these bits are considered to be under TPT's control anyway, so this is ok.
