So, we've got these fancy actor pointer things now, but the whole feature seems incomplete because almost nothing uses them yet. The most serious gap, ATM, is that there's no way to reference an actor in ACS via pointer (without doing hacky stuff with TIDs).
A version of GetActorProperty and SetActorProperty that work with these could help with the trouble a bit, since you can traverse the masters-minions and projectiles-originator link in scenarios where TIDs are inappropriate (e.g. non-map-spawned things). The closest we have right now is SetActivator, but that's a one-way street that shuts out a lot of use since you lose the reference to the original actor.
Actor Pointer support for GetActorProperty/SetActorProperty
Moderator: GZDoom Developers
Re: Actor Pointer support for GetActorProperty/SetActorPrope
I think you could use UniqueTID to assign a tid to actor and save reference to it, then use SetActivator to change script's activator
Re: Actor Pointer support for GetActorProperty/SetActorPrope
Would fully support this if it could make it possible to do things like this:
GetActorProperty(AAPTR_PLAYER_GETTARGET, APROP_HEALTH)
GetActorProperty(AAPTR_PLAYER_GETTARGET, APROP_HEALTH)
Re: Actor Pointer support for GetActorProperty/SetActorPrope
How would you know which TID is the calling actor's target, tracer or master, doing that?cybermind wrote:I think you could use UniqueTID to assign a tid to actor and save reference to it, then use SetActivator to change script's activator
Re: Actor Pointer support for GetActorProperty/SetActorPrope
Extended GetActorProperty would be: int GetActorProperty (int tid, int property, int pointer)
Extended SetActorProperty would be: void SetActorProperty (int tid, int property, int value, int pointer)
Actor is chosen by TID, as usual. TID can be 0 as usual. If pointer is non 0 (AAPTR_DEFAULT) then the pointer is applied from the chosen actor. (This is the same logic that applies to SetActivator)
One thing I'm not sure of: Can SetActorProperty affect multiple actors with the same TID?
If so, SetActorProperty with non-0 tid and a pointer should go through all the actors at the given tid, and from each of them use the pointer to get the chosen actor for the function. This should be uncomplicated most of the time. The possibility of setting the same actor's value several times per call would exist, because different actors can have pointers to the same actors, but usually the number of times a value has been set is not relevant. (If assignment immediately triggers a repeatable effect, it might matter.)
Since I'm posting I'll also mention two workarounds. One is messy, the other bloody.
Extended SetActorProperty would be: void SetActorProperty (int tid, int property, int value, int pointer)
Actor is chosen by TID, as usual. TID can be 0 as usual. If pointer is non 0 (AAPTR_DEFAULT) then the pointer is applied from the chosen actor. (This is the same logic that applies to SetActivator)
One thing I'm not sure of: Can SetActorProperty affect multiple actors with the same TID?
If so, SetActorProperty with non-0 tid and a pointer should go through all the actors at the given tid, and from each of them use the pointer to get the chosen actor for the function. This should be uncomplicated most of the time. The possibility of setting the same actor's value several times per call would exist, because different actors can have pointers to the same actors, but usually the number of times a value has been set is not relevant. (If assignment immediately triggers a repeatable effect, it might matter.)
Since I'm posting I'll also mention two workarounds. One is messy, the other bloody.
Spoiler: Messy
Spoiler: Bloody?The workarounds can apply immediately to any acs function, unlike the patches that must be created specifically for each function. Still, they have some limitations, require extra management and might reduce compatibility between mods (since otherwise compatible mods might contain overlapping & conflicting workarounds).
Re: Actor Pointer support for GetActorProperty/SetActorPrope
With all due respect, cybermind... there was this discussion a while ago and the consensus was basically, "if someone suggests something, it's generally not a good idea to counter it with "you can do X with a workaround" because having something implemented properly is better than using hacks"... I'm sure you meant well with your post but I just thought I'd let you know on the discussion that the community took part in. :) You're a brilliant coder and I know you can come up with sick stuff but I support proper ways to do things over hacks or workarounds... no hard feelings man!
To add to the current suggestion being discussed... I agree fully! There have been many times where I'd like to get away from the "intermediate TID" solutions I've been using!
To add to the current suggestion being discussed... I agree fully! There have been many times where I'd like to get away from the "intermediate TID" solutions I've been using!