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 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.
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.
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.
Add 'useowncoloradd_{top,mid,bottom}' sidedef properties to the UDMF
spec
Only use side's additive colors if 'useowncoloradd_(top|mid|bottom)' is
set.
Rename UseOwnColors flag to UseOwnSpecialColors
Add UseOwnAdditiveColor flag to side_t::part
Add EnableAdditiveColor to side_t
Add Side.EnableAdditiveColor to ZScript API
Sector.SetAdditiveColor actually called Sector.SetSpecialColor
Add use boolean property, used to determine whether or not to override the sector's additive wall colour with the side's additive colour.
The new specification is more flexible, and allows assigning additive
colors to individual parts of a sector (walls, sprites, flats) and even
individual parts of a side (top, middle, bottom)
Add AdditiveColors arrays to sector_t and side_t::part
Initialize AdditiveColors arrays to 0
Export AdditiveColors to ZScript
Save AdditiveColors in saved game files
Use colors from AdditiveColors arrays when setting the additive color
for the render state
Add code to parse the new UDMF additive color properties
Remove additive color slot from sector color/part enum
Add SetAdditiveColor to sector_t and side_t
Add GetAdditiveColor to side_t
Export new methods and additive color arrays to ZScript
Rename ColorAdd to AddColor
Add AddColor to FRenderState
Tweak SpecialColors array in ZScript to include the additive color
Add uAddColor to the shader compiler
Add uAddColor to the texel
- 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.
This was done to make reviewing easier, again because it is virtually impossible to search for the operators in the code.
Going through this revealed quite a few places where texture animations were on but shouldn't and even more places that did not check PASLVERS, although they were preparing some paletted rendering.
Considering that the physical texture size should be abstracted away from modding this needs to be done differently.
Doing any calculations with physical texture sizes on the mod side is only going to cause errors so this had been changed to always return scaled size.
- disallow bool as a return value for direct native calls because it only sets the lowest 8 bits of the return register.
- changed return type for several functions from bool to int where the return type was the only thing blocking use as direct native call.
This was the last bit of code standing in the way of making AInventory a fully scripted class.
All that's left to sort out is some variable accesses - the vast majority of them in SBARINFO.
- moved the ALTHUDCF parser PClass::StaticInit, so that it gets done right after creating the actor definitions.
All left to do is not to reallocate the AltHud object for each frame but store it in a better suited place.
Instead of overriding the Massacre method it is preferable to clear the flags causing the bad behavior, most notably ISMONSTER.
# Conflicts:
# src/g_inventory/a_pickups.cpp
# src/g_inventory/a_pickups.h
Now a child type can decide for itself how to treat 'amount'.
The scripting interfaces to this function in ACS and FraggleScript have been consolidated and also scriptified.
- offloaded key list generation for alternative HUD to non-UI parts.
This change also revealed a problem with handling empty sprites in the key list so this got fixed, too.
Overriding this would make the engine vulnerable to badly behaving mods. Intercepting this and altering the behavior can render the entire game inoperable, especially if more internal code gets scriptified later. So even at the risk of breaking some carelsss mods this must be blocked.
This was by far the largest block of native virtuals, and they were only native to be able to allow checking if the event was implemented for the current handler. This can easily be done by looking at the byte code, just like VMCall also does but in turn it removes more than half of the existing native virtuals from the interface.
It has been like this initially but was changed when ZDoom gained an overly complicated polymorphic class descriptor object that required a lot of support code. All these complications have long been removed but these methods remained. Since they prevent a class from being moved to the script side entirely they had to be removed.
This was the last major blocker to make Weapon a purely scripted class, the only remaining native method is Serialize which is of no concern for the coming work.
This stuff is now kept locally in the bot code so that it doesn't infest the rest of the engine.
And please don't read the new botsupp.txt file as some new means to configure bots! This was merely done to get this data out of the way.
The bots are still broken beyond repair and virtually unusable, even if proper data is provided for all weapons.
In both cases, having this flag on will render the monster-backing-off-check for melee attacks ineffective because it would misinterpret these weapons as close range only - which they aren't. Even for the PhoenixRod the range is longer than what gets checked here.
As a consequence, the bot's check for missile shooting melee weapons has also become pointless because no such weapon is defined anymore.
