When player is picked up item that does morph, the corresponding toucher actor is changed in process
Previously, morhing item was removed from original actor leaving player's inventory in inconsistent state
https://forum.zdoom.org/viewtopic.php?t=63124
Unlike the other classes, the places where variables from this class were accessed were quite scattered so there isn't much scriptified code. Instead, most of these places are now using the script variable access methods.
This was the last remaining subclass of AActor, meaning that class Actor can now be opened for user-side extensions.
This should be less of a drag on the playsim than having each light a separate actor. A quick check with ZDCMP2 showed that the light processing time was reduced to 1/3rd from 0.5 ms to 0.17 ms per tic.
It's also one native actor class less.
# Conflicts:
# src/g_shared/a_dynlight.cpp
# src/g_shared/a_dynlight.h
# src/hwrenderer/dynlights/hw_dynlightdata.cpp
# src/hwrenderer/dynlights/hw_dynlightdata.h
# src/hwrenderer/scene/hw_renderhacks.cpp
# src/namedef.h
# src/scripting/thingdef_data.cpp
# src/swrenderer/line/r_walldraw.cpp
# Conflicts:
# src/d_main.cpp
# src/g_levellocals.h
# src/g_shared/a_dynlight.cpp
# src/g_shared/a_dynlight.h
# src/gl/dynlights/gl_dynlight.h
# src/gl/dynlights/gl_dynlight1.cpp
# src/gl/scene/gl_spritelight.cpp
# src/gl/scene/gl_walls.cpp
# src/hwrenderer/dynlights/hw_shadowmap.cpp
# src/hwrenderer/dynlights/hw_shadowmap.h
# src/hwrenderer/scene/hw_flats.cpp
# src/p_setup.cpp
Actors get initialized from their defaults so anything done in the constructor or some explicit member initialization will be overwritten.
They must use their properties for setting up configurable fields and do the rest in BeginPlay.
Only the class definition itself remains and needs to be taken care of.
# Conflicts:
# src/g_statusbar/sbarinfo_commands.cpp
# src/hu_scores.cpp
# src/scripting/thingdef_data.cpp
# Conflicts:
# src/actorinlines.h
# src/hu_scores.cpp
This was the only code using the ViewBob member variable.
This also moves the range check for this variable to its application, because a badly behaved mod can just as easily change it at run time instead of just setting an absurdly large value in the class definition.
The current behaviour offsets to the front of the actor rather than the side, due to an oversight in the code, which oddly is not present in the A_FireBullets equivalent.
The loop never checked if the item was still valid and would continue to try to use it, even after it was removed from the inventory and destroyed.
As native code this just failed silently, but with the VM it needs to be explicitly checked.
- TriggerPainChance(Name mod, bool forcedPain)
- One exception: PainThrehold is only checked in ReactToDamage, since this function does not require checking damage amount.
Unlike everything else from the IWADs this had to use the 'light' keyword in ZScript because this is merely a base class for many others and the light definitions here need to be inheritable.
Many uses of random() & value have been turned into random(0, value).
This is not only more efficient, it also ensures better random distribution because the parameter-less variant only returns values between 0 and 255.
