Welcome to the ZDoom Forums!

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.

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.

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.

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.

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

Like this?

No, like this:

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.

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

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.

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