Apparently, you have to read() before you check status bits. Who woulda thunk.
This never manifested because all the files we ever embedded this way ended in a newline. I needed a report from someone who uses a text editor that doesn't ensure this.
Ignoring broken pipes led to libcurl crashing when connections were dropped, rather than re-attempting. Now, libcurl is not set to ignore broken pipes. Closes#823.
Repurposing the comment I added because I'm lazy: pavg[1] used to be saved as a u16, which PressureInTmp3 elements then treated as an i16. tmp3 is now saved as a u32, or as a u16 if it's small enough. PressureInTmp3 elements will never use the upper 16 bits, and should still treat the lower 16 bits as an i16, so they need sign extension.
The code that was originally responsible for this somehow got lost in the tmp3/tmp4 migration.
Also add GameSave::PressureInTmp3 to check for elements with pressure memory and fix TUNG not sampling pressure on creation. This does not in itself fix#822 because tmp3 and tmp4 are still saved in 16 bits each, so full ctypes still don't fit in tmp3.
This fixes a crash with water equalization on, with loop mode enabled, when there are high velocity particles near the edges. This can be occasionally reproduced with id:2800901
The water was moved to a new position and pmap updated, but the movement code continued, assuming water was at its old position. pmap for the WATR's old position won't be cleared once it moves, leaving a stale entry. If a particle then looks up the water in that location and tries to swap positions, this can cause a crash at the end of try_move
lua_close wasn't being called at all before due to the delete commandInterface being missing. With it there, the lua gc could delete the LuaComponent before the LuaWindow. Make sure if that happens, it tells the parent LuaWindow it's already been gced
Becuase *of course* whether it succeds or not depends on whether you've rebuilt menus.
With all seriousness, the real culprit here is GameModel::GetToolFromIdentifier, which looks for tools in the menu section tool lists, plus another list with tools that aren't in any menu section. This is absolutely blaphemous, but I don't feel like refactoring this right now. It also wouldn't be a problem in itself, but allocating an element also doesn't rebuild these lists, only changing the MenuSection property and a few other obscure operations do. This makes allocating elements also rebuild these lists.