Very similar in nature to the problem fixed by 0fcad65d. Again, it'd be massive help if we didn't destroy the Lua state explicitly in LSI's dtor. But this is not worth refactoring LSI for.
All these smart pointers have to be cleared before the Lua state is closed. Ordinarily, we'd have a smart pointer to the Lua state defined earlier in LSI than these smart pointers, which would take care of destruction in the correct order, but tfw technical debt.
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
