Welcome to the ZDoom Forums!

Request made. But all it is, is just three flags. Better than nothing at least.

I just dug through the source, and apparently the only way a projectile can use the lastenemy pointer is with the native and not-very-customizable MWeapLightning functions. Everything else is monster behavior. The only other existing pointer I can think to use is maybe goal, if we don't make a new pointer.

Ryan_Cordell posted a patch preview on the first page for a flag that worked in testing. Some of the work is done already (though for the p_railattack one, I'd've put it in the if(spawnpuff) part at about line 4062). Ripping projectiles are an interesting subject, though, as is the ability to check if the pointer in question is the same actor as the projectile's tracer, as was brought up earlier.

A real scripting language can do that easily. DECORATE, on the other hand is ill equipped for that.

It would still need a dedicated action function, since "pointer selectors" are just arbitrary bitfield values (classy!) and nothing like actual pointers.

Working with actual (or "virtual") actor pointers would be one of the best features for ZScript.

No, like this:

Ghastly_dragon wrote:After this, we would need A_JumpIfNullPointer, though.

Like this?

Okay, yeah, I can see that.

The "NO write access from Decorate" made me a little nervous, but as long as it would be useful in all the same functions such as A_GiveToTarget, A_Warp and etc., then I don't see a problem. After this, we would need A_JumpIfNullPointer, though.

Graf Zahl wrote:...and NO WRITE ACCESS from DECORATE at all!

"Write" access? You mean things like A_RearrangePointers and the likes?

XutaWoo wrote:There are the scenarios where you want to check if the projectile hit its intended target or not.

Just for reference, if that wants to be put up for consideration.

I can foresee ripper missiles being one of them. But I could imagine a special projectile seeking after its tracer, and having the ability to immediately change to ripping another monster it touches in its place.

Ghastly_dragon wrote:In the meantime, how does TracerOnHit itself sound? Considering the projectile has already hit something, I don't think we would necessarily care about our original tracer in that case.

There are the scenarios where you want to check if the projectile hit its intended target or not.

Just for reference, if that wants to be put up for consideration.

In the meantime, how does TracerOnHit itself sound? Considering the projectile has already hit something, I don't think we would necessarily care about our original tracer in that case.

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!

edward850 wrote: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.

edward850 wrote: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.

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.

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.