Welcome to the ZDoom Forums!

[quote="GooberMan"]What, there nothing else to discuss so you have to try to derail a finished thread?[/quote]
There's no such thing as a "finished thread." Except for a locked one.

(I'm not intending this to be a cue, but it might be one anyway. :P )

What, there nothing else to discuss so you have to try to derail a finished thread?

PM me if you have a problem with how I've acted in this thread or report it to a mod.

[quote="GooberMan"]Still. The "Not Needed" resolution is perfectly valid if you don't want to spend more than five minutes doing the feature. Which is quite clearly the case with Graf.[/quote]
Because insulting everyone else when they don't agree with your ideas is a good idea, right?

Well, all specials get activated by something. Cleaning up activators has more far-reaching implications than just linedefs. A "decorate" activation reason, for example, is just as applicable to everything I wrote above.

Still. The "Not Needed" resolution is perfectly valid if you don't want to spend more than five minutes doing the feature. Which is quite clearly the case with Graf. Chalk it up to another feature I'll do myself when I get the time/clearance (which, to be quite honest, I've started posting feature requests so that I can do them myself if no one else has the time before I get to them).

I don't see how the issue of gameplay mods applies here, since we're talking about linedef activation, which is not something that's generally added to a gameplay mod. :P

This would be a perfectly useless setup for non-map mods so I really do not care.

[quote="Graf Zahl"]The suggested feature is quite a bit of work just to avoid some minor inconvenience (OMG! Two lines of code per script that needs to be checked. The world must be coming to an end!)[/quote]You're forgetting that projectile-activation requires a particular MapInfo flag, which:[list=1]
[*]Is not mod-portable, because it has to be enabled in specific maps.
[*]More importantly, changes activation rules for everything else in the map, which is even less mod-portable.[/list]

Maps+Scripts and Actors+Scripts do not always go together any more.

[quote="edward850"]
That's quite a bit of work, maintenance and such for one function, don't you think? Especially if a solution which already works has already been presented, despite the fact that you don't like it for what ever reason.[/quote]



Here's the issue I have with it.
The suggested feature is quite a bit of work just to avoid some minor inconvenience (OMG! Two lines of code per script that needs to be checked. The world must be coming to an end!)

Sorry, this will get filed under 'not needed'.

[quote="Xaser"]I can't seem to read this as anything other than "It's not a hack if I write the code myself,"[/quote]
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.

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?

[quote="GooberMan"]I have no immediate use for this, so it's a "nice to have" thing.[/quote]
So this has been a needlessly long discussion.

I'm not sold on the original feature suggestion myself from a general architectural perspective, because it's indeed a highly-specialized function that's only useful in a subset of cases that could probably be solved by introducing a more general-purpose (but still easy-to-use) function instead.

I'm rather fond of the Originator idea, and the [i]simplest[/i] way to kill two birds with one stone is make it so that when the MissilesActivateImpactLines MAPINFO flag is set, the Originator flag is defined as the player that activated the script; this way you can refer to Activator to get the projectile and Originator to get the player. Though I suppose some folks may constitute the semantic meaning change of Originator when the flag is set to be a "hack" as well, but so long as it's a documented feature of the flag (which is changing how activator behavior works anyway), I personally wouldn't complain. Thoughts on this?

I suppose it wouldn't smooth over the problem of having to use the SetActivator* functions to do certain things in some cases, though (e.g. have the script in question require checking both the projectile and the player for something), but that's a different issue altogether, I think (though one which bothers me greatly still). It'd be nice if there was some sort of script-level analogue to actor pointers that could be dropped into any place where actor pointers are expected as arguments (i.e. AAPTR_ACTIVATOR and AAPTR_ORIGINATOR, or some name variant thereof), which would at least allow for a subset of functions to be executed without swapping around the activator. But now we might be encroaching into WFDS territory. :P

I also realize I'm probably being heinously pedantic, but I still can't grasp the meaning of this particular quote:
[quote="GooberMan"]I don't exactly get what point you're trying to make by telling a coder that a change to an [i]open source project[/i] is a hack when I'm perfectly capable of looking through the code and seeing what is required. That's a pretty big hint that I actually have done so.[/quote]
I can't seem to read this as anything other than "It's not a hack if I write the code myself," which doesn't make a whole lot of sense because it's certainly possible to produce technically-well-written but architecturally-horrible code. I'm certain that's not what you meant to convey here, but it comes across wrong IMO.

Again, probably-useless pedantry, but I have to ask. :P

How is that script - which again you'll need to copy and paste in to every script where you want the functionality or write your own function to work around the limitations - contributing to clean system design? How does that solve the problem where line settings are pointless?

By the time you get in to a script, you shouldn't need to worry about whether it's a player or not because [i]that's what line triggers are for[/i]. Even thing specials have that built in to some degree - ones that require to be used are implicitly player only, for example. Specials being activated on thing destroy should be the only basic-use valid case where you actually need to check for a player from a script because that's the one thing you don't have control of from the editor.

[size=60]And no, that doesn't mean I'm discounting the need to check for players for more advanced cases. Changing activators just to get the information you need? Complete hack.[/size]

Honestly though, there's no reason [i]both[/i] CheckActivatorProjectileClass and SetActivatorToOriginal couldn't be implemented if the Originator pointer is implemented. At which point, this suggestion is an even-more valid bit of cleaning up that can be done.

script "Plasma_Trigger" (void)
{
	//We could do this without checking if it works, as the next step would fail regardless 
	//if we weren't still a PlasmaBall, but this is a code example and I like doing this for completeness.
	if(!SetActivatorToOriginator()) terminate;

	//Only "PlasmaBall" may run the script
	if(!CheckActorClass (0, "PlasmaBall")) terminate;
   
	//Set the activator to the projectile's target. If that works, and it's a player, do stuff
	if(SetActivatorToTarget(0) && (ClassifyActor(0) & ACTOR_PLAYER))
	{
		/*
		The stuff
		*/
	}
}

If your issue is "maintenance hell", then perhaps a more flexible suggestion would be the better option? Create a new pointer to track known as "Originator", and a new function to co-exist, "SetActivatorToOriginator()", which in this case is used to track the object that triggers a script, rather then what the ownership happens to get transferred to down the line, either in the scripts life or Doom methodology quirks. This way, there is something to expand upon, and already has uses outside of just checking one specific thing in one specific scenario.
Then all one would need to do is adapt the above script like so, without needing to apply MissilesActivateImpactLines:
[code]script "Plasma_Trigger" (void)
{
//We could do this without checking if it works, as the next step would fail regardless
//if we weren't still a PlasmaBall, but this is a code example and I like doing this for completeness.
if(!SetActivatorToOriginator()) terminate;

//Only "PlasmaBall" may run the script
if(!CheckActorClass (0, "PlasmaBall")) terminate;

//Set the activator to the projectile's target. If that works, and it's a player, do stuff
if(SetActivatorToTarget(0) && (ClassifyActor(0) & ACTOR_PLAYER))
{
/*
The stuff
*/
}
}[/code]

I'm going to go ahead and quote Graf here from the Feature Suggestions Guideline thread.

[quote="Graf Zahl"]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.[/quote]
Your solution requires remembering to [i]change the activator yourself in every single script that requires it[/i] after you've already changed a setting in GAMEINFO that [i]changes the activator behaviour completely for projectiles[/i].

I'm suggesting the code gets cleaned up to provide feature completeness (as I've laid out) so that such entirely massive workarounds aren't necessary. It means more work for a programmer up front, and then it's done. Once and forever.

How is cleaning things up a hack exactly? I'm all ears. Convince me.

It's a hack because what you want to do doesn't fit in with everything else, not because it will not work at all.
You want to add a feature that has a projectile guess that's going to be executing a script, add its classname into some sort of arbitrary string that gets passed down to the ACS VM, which then needs to track alongside every script that can/will ever be executed regardless if it has anything to do with this one function that you want implemented, just so you can have this one function implemented.

That's quite a bit of work, maintenance and such for one function, don't you think? Especially if a solution which already works has already been presented, despite the fact that you don't like it for what ever reason.

[quote="Graf Zahl"]What you propose would mean even more hacks in the engine itself.[/quote]
I think you've confused the term "refactor" with the term "hack".

I don't exactly get what point you're trying to make by telling a coder that a change to an [i]open source project[/i] is a hack when I'm perfectly capable of looking through the code and seeing what is required. That's a pretty big hint that I actually have done so.