Set victim as tracer?

[cybermind]

I have found a way to achieve special effects when a monster is being hit without interrupting its actions, though, it will work same regardless of what hit the monster.
Instead of accessing monster from projectile itself, we will modify the actor's blood. The PUFFGETSOWNER flag works differently for blood actors - it sets blood's target field to bleeding actor. That's exactly what we need!
So define a new blood for monster using BloodType property. Remember that blood actors have special logic for their first states, so just place a few empty states in Spawn block with no duration. After that, you can call ACS script from blood actor. In the script, use SetActivator(0, AAPTR_TARGET) - this will set the monster as the activator of the script. That's all, dowhateveryouwant from this script.

So, to make different reactions for different weapons, ZDoom should support different blood types for different damage types. That's pretty easy to implement, I think.

An example which is included in attachment shows zombieman's health on screen, when something hits it (I've increased zombieman's health to 200, to clearly show the effect, because zombiemans die very quickly)

[Nightfall]

That is a very ugly hack. Blood actors are visual effects and shouldn't have any impact on the gameplay. What about +NOBLOOD or non-shootable actors?

[Ghastly]

That is also really unrelated to this thread.

[cybermind]

You can use blood actor to give or take items from projectile's target, as it was described in the link of the thread's first post. The only problem is that this method is only applicable for all projectiles, not the specific ones. But I think that this method is more convenient, rather than using homing projectiles with SCREENSEEKER flag

[edward850]

And this would be more convenient to, say implementing a version suggested feature so that gratuitous guesswork isn't actually needed at all? Why do people keep ignoring the stickied guidelines thread?

If you want to suggest a workaround for a requested feature please think first if your workaround meets the suggester's needs. I have seen it too many times that some people post stuff that completely ignores the original post's motivation or suggests some laborious things that would be more an annoyance than anything else to do repeatedly. Often these things come equipped with the word 'just' as if it was the most normal thing to do repeated cumbersome routines.

Such posts tend to create tension because the OP might feel ignored on purpose by that. Here's a good example of this kind of behavior which I really don't want to see anymore on the Feature Suggestions forum.

[Major Cooke]

That could work, but it'd need a pointer "flag" and relevant functions. I think Tracer was chosen because that stuff is already there.

Edit:
I put some options in order from best to worst (as I see them):

1. A new pointer. ("victim" works.) Open it for access and assignent.
2. Use a pointer that projectiles don't normally use. (E.G. lastenemy.) Also needs to be opened up for use.
3. Use tracer or master. (Least work involved as far as access, but cuts into future uses for these.)
4. Bad Decorate/ACS hacks!

#1 and #2 I support. However, if we are forced down to #3, +TRACERIMPACT could allow for this to happen. Maintains compatibility too.

[Fishytza]

How about instead of a flag or having it hardcoded to a specific pointer (like lastenemy) we make a new actor property instead?

It would be like Activation where you can specify via flag which pointer you want the store the victim to. (And by "flag" I mean like Activation's THINGSPEC_TriggerActs and not an actor flag. Just to clear up any confusion.)

For example, if you wanted a projectile that stores its victim into both tracer and master (for some odd reason) you would specify:

Code: Select all

SaveVictimTo    AAPTR_TRACER|AAPTR_MASTER

This ought to be flexible enough and shouldn't break any existing compatibility.

Then again, this might be more work than it's worth?

[Gez]

If you add a new actor property for that, the simplest approach is to make this new property a pointer to the victim, rather than a gizmo where you choose which pointer gets the victim.

[Fishytza]

In that case it might as well be just another actor flag (TRACERONIMPACT or whatever). Just one thing I'm curious about...

...rather than a gizmo where you choose which pointer gets the victim.

Why is that a bad thing?

[edward850]

Because one requires More Flags™, even though there is no pre-existing behaviour to change and the alternative is a pointer reference. I myself would rather add a new pointer reference.

[Gez]

The entire point of using an existing pointer like lastenemy is that you avoid bloating the actor class even more than it already is with a new field that'll be used in maybe 0.0013% of ZDoom game sessions. If you're going to add a new field anyway, you can as well make it do the thing you want to do in the first place. That way, it'll be larger, instead of larger and more complex.

[edward850]

I'm not sure how well lastenemy will work out, as it's already used by projectiles. The Hexen lightning projectile to be precised. And a lot. Then again, maybe none of it will be affected by setting a tracer on death. Maybe. I'll test it out later if I get the chance.

[NeuralStunner]

Then again, maybe none of it will be affected by setting a tracer on death. Maybe. I'll test it out later if I get the chance.

The only case i can find is, for whatever reason, a modder wanting to know what actor a seeker missile was tracking (even if it hit something else).

Also of note: Setting the pointer even for "non-interactive" actors like lamps or statues, since one might want them to react to certain specialty projectiles.

[Fishytza]

I'm not sure how well lastenemy will work out, as it's already used by projectiles. The Hexen lightning projectile to be precised.

IMO it shouldn't be an issue as long as it's not standard behavior, i.e. only store whatever it hits to lastenemy if the specific actor flag is set.

[Graf Zahl]

This is never, ever, EVER going to work if it's implemented as a hack. Frankly, the whole thing is in despeate need of being cleaned up, unfortunately that will break lots of existing mods.
Really, the only solution I see is to add a few new pointers with completely unambiguous semantics and NO WRITE ACCESS from DECORATE at all!