It was more of a challenge to see what he thinks makes it a hack. I can certainly think of the wrong way to implement it right off the top of my head. It's also the easiest way to implement it.Xaser wrote:I can't seem to read this as anything other than "It's not a hack if I write the code myself,"
But moving on.
There's only one thing with the originator - you still need to change the entire activation behaviour for projectiles to get this information. I keep on bringing up lines because everyone is looking at it in explicit scripting terms here. There's basic systems in place - since the day Doom was released no less - for determing what activated a special.
Activators exist in the code as a concept, but are only represented by a single actor pointer. Without that MissilesActivateImpactLines set, that's either a player or a "monster". This is quite limiting, and results in such situations as actor pointers which requires familiarity with ACS and at least intermediate knowledge.
It's ludicrous to suggest that something that's so easily set up in an editor via the basic systems of Doom maps introduced almost 20 years ago should be locked off to people with an intermediate knowledge of a scripting language bolted on several years after those basics were created.
Refactoring activators in code to be more than just an actor starts introducing very powerful basic concepts. All it needs is a struct that can contain that activating actor. What else? How about an enumeration to stipulate the activation reason? Use, bump, walk, projectile. Those are the basic reasons. An ActivationReason() function suddenly becomes a possibility. Can you picture a switch that gets destroyed if you shoot it but is functional up to that point? Completely possible with a script operating on the results of that function without elaborate scripts to back it up. And it doesn't require intermediate knowledge such as actor pointers.
Projectiles are the odd one out of those basic reasons. They're the only activation reason that requires knowledge of another actor. So put the actor in the activator struct. It's quite obviously already possible to obtain those projectile actors because otherwise MissilesActivateImpactLines wouldn't exist. Information functions for querying that projectile are then required.
The barrier for entry due to a code refactor like that is lowered. You don't need to set a flag somewhere else to access what should be basic information. This also doesn't exclude more intermediate concepts such as Originator actor pointers - which, to be clear, is just as "highly-specialized" and "only useful in a subset of cases" as including projectile information at a basic level. What behaviour does it have when MissilesActivateImpactLines isn't set? What is an originator in that case? An originator is only a useful concept with that flag on, and what percentage of released ZDoom mods do that?
So this has been a needlessly long discussion.GooberMan wrote:I have no immediate use for this, so it's a "nice to have" thing.
