The way this was done was a major headache inducer, requiring reconstruction of the function each time the value was changed and in general made actor damage a major hassle.
There was a DECORATE wrapper to mimic the original behavior but this looked quite broken because it completely ignored the different semantics of both damage calculation types.
It also made it impossible to determine if damage was a function or a value.
This accessor has been reverted to what it should be, only returning the constant, which now is -1 for a damage function. I am sorry if this may break the odd mod out but a quick look over some DECORATE-heavy stuff showed that this was never combined in any of them so that accessing 'damage' in DECORATE code depended on an actual damage function.
To get proper damage, a future commit will add a DECORATE function which calls AActor::GetMissileDamage.
int SetActorFlag(int tid, str flagname, bool value);
- Mimics DECORATE's A_ChangeFlag
- Returns number of actors affected (number of things with the flag)
- Affects activator if TID is 0
# Conflicts:
# src/p_acs.cpp
It acts as a simple wrapper around P_DamageMobj which can damage a
single actor, but can also set the actor inflicting the damage. It
returns the amount of damage actually done, or -1 if the damaging was
cancelled.
bool CheckActorState(int tid, str statename, bool exact = false);
- Same parameter order as SetActorState
- Returns true if actor has the state; else returns false
SPF_NOTIMEFREEZE processes particles with this flag regardless of time freeze. The endsize parameter changes the scale of the particle to that size throughout its lifetime linearly.
- If the two strings compared both point to the same location in memory,
then we know they are the same string without having to bother actually
comparing their contents. Note that the opposite is not neccessarily
true: If they point to two different locations, they could still match a
case-sensitive comparison because there are still two ACS string tables:
the one that belongs to the map's script and the one that belongs to
everything else.
In some places, P_UndoPlayerMorph was called with the 'force' argument placed in the 'unmorphflag' parameter, so that 'forced' unmorphs would be not completely forceful.
I hope no mod relied on this weirdness...
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
- Since DECORATE already allows reading all declared variables in a class,
where's the utility in keeping this restriction in ACS?
- Variables must still be numeric types.
- SetUserVariable is still restricted to user variables only.
