I really don't like how the only way to return with an error from ParseFloatProperty is via an exception >_>
Also do a range check on airTemp only if isValid is true, otherwise it's uninitialized.
This website API was created to enable TPTMP to prove the identity of connecting users, and while TPTMP works fine without explicit support for this from the game, it has to resort to parsing powder.pref. This is not only ugly but also likely to be disallowed by the next version of the script manager. This new script manager will probably come after 97.0, so it's okay for it to rely on a game feature that won't be available until 97.0.
get_normal_interp is given a PHOT and scans a line section starting from the PHOT, extended in the direction of its velocity, to determine the surface normal of the surface that is reflecting the PHOT. It uses is_boundary to detect "boundaries" on this line section, defined as one "blocking" cell with at least one "non-blocking" non-diagonal neighbour. It never actually makes sure the position it passes to is_boundary is within the simulation area, so I assume is_boundary is expected to handle this correctly.
Plot twist: it does not. It delegates checking whether a cell is "blocking" (defined as something PHOT would normally fail to move into as per eval_move, but GLAS and BLGA are handled specially) to is_blocking. is_blocking returns true for cells beyond the simulation area (as eval_move returns "no move" for such cells). Once is_boundary sees that the cell it's been given is blocking, it then proceeds to check whether any of its non-diagonal neighbours might be non-blocking. In most cases, non-diagonal neighbours of an out-of-bounds cell are also out of bounds and are thus blocking, but if the cell is_boundary is given is in the innermost layer of out-of-bounds cells, just beyond the simulation area, then it has a neighbour that is in bounds, and that one may not block PHOT. The takeaway is that out of bounds cells can indeed be boundaries, as far as is_boundary is concerned.
This is a problem because get_normal_interp's line section can easily reach beyond the simulation area if the PHOT's velocity is high enough, and if it finds a boundary along this line section, it immediately stops looking and passes its position to photoelectric_effect, which then uses this potentially out-of-bounds position to index pmap. A position with y = -1 causes photoelectric_effect to read from the last few slots of parts data that it then interprets as pmap entries, which then may direct it to particles to spark that are beyond parts. This eventually crashes.
This commit doesn't fix is_boundary's definition of boundaries, but it stops get_normal_interp looking at cells beyond the simulation area.
The crash is difficult to reproduce because there have to be many particles in the simulation for the very last slots of parts to be in use, and for them to point to memory that isn't accessible. PHOT also has to survive a try_move beyond the simulation area first (otherwise the reflection code isn't even run), which requires it to start from EHOLE. I have no idea why this is so. Reproduce the out of bounds read in photoelectric_effect with
break Simulation.cpp:2934 if nx < 0
in gdb and executing the following Lua code:
sim.clearSim()
tpt.set_wallmap(55, 44, 12)
local i = sim.partCreate(-1, 223, 178, 31)
sim.partProperty(i, "vx", -300)
sim.partProperty(i, "vy", 0)
sim.framerender(1)
This is how we'll handle systems where the cert bundle and cert directory is stored where mbedtls doesn't expect it.
Also update tpt-libs to get new curl and mbedtls.
Also Factor out app constants that mods might change into Meson options and clean up format::URLEncode in the process, convert app and document icon data in arrays to actual images, actualize AppStream data for possible future packaging, add alternative command line format for opening filesystem saves and ptsave URLs, fix a memory leak in Platform::GetCwd, and add format::URLDecode.
This made it possible to get rid of two GameSave constructors.
Also clean up Client::LoadSaveFile, Client::ReadFile, and Client::WriteFile in the process, and remove unused SaveRenderer::Render
Also restructure meson.build and the ghactions workflow a bit, and enable -ffunction-sections and -fdata-sections.
Note that starcatcher uploads have not been tested and most likely don't work.
Also fix a few bugs and other weirdness in Platform::DirectorySearch. Empty string paths would crash and filenames with 4 or fewer characters wouldn't register.
This fixes bugs like "type\0hello mom" being a property name sim.partProperty accepts and half-fixes bugs like text formatting codes making gfx.drawText exit prematurely.
Currently it detects presence of v incorrectly (via if (ID(type))) and thus rewrites v = 0 to v = -1, even if 0 is actually what you want. Especially problematic if you're trying to spawn GOL (so LIFE(ctype=0)).
Also fix the first mouse click not being detected on windows with sdl 2.0.20. Apparenlty, we need SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH set to 1 for it to be detected.
If the built-in update function is allowed to run, it can change the particle's type. The code path assumes that there is a Lua update function to call on the particle, but this type change may break this assumption and cause the code to call the update function of an element that doesn't even have one, producing a weird error message with no line number.
Empty stamps are those whose block width or height is 0. While they are technically valid and certain parts of the game are prepared to handle them, others aren't, so it's safest to just adjust the definition of valid stamps to exclude empty ones.
Also clear SaveRenderer graphics cache along with the main Renderer's when needed, and revert to built-in element callbacks rather than nothing at all when assigning nil to a callback slot in Lua.
Rather than hacking velocity, do it directly through can_move. Add a special case to make it slowly float upwards, rather than immediate like most weight differences in TPT.
This is a follow up to this crash fix - 0ed8d0a0be
This may possibly fix other crashes users occasionally experience, especially in the case of high velocity particles with loop edge mode on. Even so, there are other bugs at play, as a crash here can't be triggered if pmap is in a correct state
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.
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.
The underlying problem was that the spreading step in SimulateGOL would record activity concerning a cell to builtinGol even if said cell already housed a non-GOL particle. The culling step handles these records and purges them once it's done (thus builtinGol only ever has non-zero values inside SimulateGOL), except in this case, it saw the non-GOL particle and skipped the cell without purging the corresponding records. This would later let GOL spread seemingly out of nowhere.
LITH: show .tmp2 in HUD, remove outdated comment
SLCN: update description
ROCK: form under pressure from both normal LAVA and LAVA(STNE), as these are basically the same thing
Summary of migrated files will be shown to user in a popup, and a log file with every moved file will be left in the original directory
stamps, saves, scripts, screenshots, and powder.pref will be migrated. Recordings are not.
