Replaced explicit save of configuration file, which doesn't work after recent backend refactoring, with passing of CVARs we need to store to a new GZDoom process
https://forum.zdoom.org/viewtopic.php?t=69790
It's not obvious where we can reset blocking line in a more generic way, and whether it's possible at all, because this member is exposed to scripting
https://forum.zdoom.org/viewtopic.php?t=69747
src\common\audio\sound\s_sound.cpp(556,27): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
src\scripting\vmthunks.cpp(2678,13): warning C4244: 'return': conversion from 'time_t' to 'int', possible loss of data
src/console/c_cmds.cpp:690:11: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
src/scripting/vmthunks.cpp:2698:21: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
* Added ViewAngle/Pitch/Roll properties to actors.
- These are offsets for camera angles that allow turning the camera without affecting aim or movement direction.
- Added A_SetView<Angle/Pitch/Roll>, which will set the view direction.
- Added ABSVIEWANGLES flag, used to make the view absolute instead of an offset.
* Converted functions to be direct-native.
* Simplified some stuff, made up-to-date
* Dealt with DST problems
* Made SystemTime.Format clearscope, as there is no reason for this function to be limited to the ui
- If the actor passed into the function has THRUACTORS, PIT_CheckThing won't be called anymore.
- Moved THRUACTORS check to just under the self clipping check in PIT_CheckThing.
Bogus pointers and offsets were serialized silently
This will to find other cases of dangling pointers, and protect from loading of broken saved games
https://forum.zdoom.org/viewtopic.php?t=67494
Inventory items had dangling floor and ceiling sector pointers after transition to a new level
This could cause random issues with serialization
https://forum.zdoom.org/viewtopic.php?t=67494
This is a quick fix for an error in which Animated Doors crash the game by trying to check "actor->player" when "actor" itself is NULL. Deleting the check entirely also worked, but I worried it might be there for some higher-level scripting reason. This just puts in a check to make sure actor isn't NULL before checking actor->player, and keeps the behavior in that case the same.
I think this was happening because I had doors being opened by projectiles (like in Metroid) which were being despawned into NULL pointers when they hit the doors, as this was an issue when initially programming said doors..
- 1: The missile will continue moving through the actor, and it's down to the modder to handle bouncing.
- 0: The missile will explode.
- Any other value will process a bouncing actor as normally done in the engine.