World version of RETURN script

[Nash]

Pull requests:

ZDoom: https://github.com/rheit/zdoom/pull/784
ACC: https://github.com/rheit/acc/pull/60


Original post:

---

The RETURN script gets activated by every player upon returning to the map; which mean there's a possibility that something can be activated MAXPLAYERS number of times upon returning to the map, without any sort of scripted safeguard, and with the inconvenience that using 0 in your script's TIDs would target the respective player.

Can there be a world-exclusive version of RETURN that's only activated by the world instead? For level-only stuff. I'm basically asking for a repeatable version of the OPEN script upon every map return.

[RaveYard]

You can set the activator as world by using SetActivator that fails. It's mentioned under "return value" here: http://zdoom.org/wiki/SetActivator

So you can substitute that by:
1. Terminating scripts that don't belong to player with the lowest player number - but you have to check what is the lowest player number...
2. Checking if there is running script via variable - but you have to make sure to reset it and it's generally messy...
3. Executing another script using ACS_Execute - but that delays execution by a tick...
4. Executing an UNLOAD script with a delay(1) - this one is executed by the world already, so it's probably the best solution...

Well...

Anyway... how about calling it "REOPEN"?

[NeuralStunner]

Anyway... how about calling it "REOPEN"?

That works, I think.

[Nash]

Less hacks/workarounds and a proper in-engine solution would be nice, thank you!

[RaveYard]

Less hacks/workarounds and a proper in-engine solution would be nice, thank you!

Indeed, that would be nice...

Here is a though that is bugging me: is it worth adding such thing, even if there is practically no difference in performance and memory usage?

Code: Select all

script "something" UNLOADING
{
      delay(1);
      //Write code here
}

vs.

Code: Select all

script "something" REOPEN
{
      //Write code here
}

On the other hand, if the UNLOADING script contains some nasty big arrays, you don't want that garbage.
But if I remember correctly, ACS arrays are allocated only when actually used...?

[ZzZombo]

You can set the activator as world by using SetActivator that fails. It's mentioned under "return value" here: http://zdoom.org/wiki/SetActivator

So you can substitute that by:
1. Terminating scripts that don't belong to player with the lowest player number - but you have to check what is the lowest player number...
2. Checking if there is running script via variable - but you have to make sure to reset it and it's generally messy...
3. Executing another script using ACS_Execute - but that delays execution by a tick...
4. Executing an UNLOAD script with a delay(1) - this one is executed by the world already, so it's probably the best solution...

Well...

Anyway... how about calling it "REOPEN"?

SetActivator(0), nothing to substitute it is required.

[RaveYard]

SetActivator(0), nothing to substitute it is required.

When I was "talking" about substituting, I was referring to a substitution for the world-exclusive version of RETURN script.

I kinda left that part out...

[ZzZombo]

I can't make sense of your suggestions then. For example, UNLOADING scripts shouldn't have any delays by design, or be called manually.

To the OP: just clear the activator using my first post's code here in a RETURN script, using a flag in an ACS variable to execute code only once per return.

[Nash]

I wouldn't add this to the first post but it needs to be said here, too:

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.

[RaveYard]

I can't make sense of your suggestions then. For example, UNLOADING scripts shouldn't have any delays by design, or be called manually.

Again, sorry for my inability to properly explain what the substitutions are

Here are the first three writen in ACS:

---

The first one is: "use RETURN script and terminate the running instances for each player except the one with lowest player number of all players.":

Code: Select all

script 1 RETURN
{
	int i;
	for(i = 0; i < MAXPLAYERS; i++) {
		if(PlayerInGame(i)) {	
			if(i != PlayerNumber()) {
				terminate;
			}
			break;
		}	
	}
	SetActivator(0);

	//Code goes here
}

The second, is probably the exact suggestion you had for OP:

Code: Select all

int reopen_executed = 0;
script 1 RETURN
{
	if(reopen_executed)
	{
		terminate;
	}
	reopen_executed = 1;
	SetActivator(0);
	
	//Code goes here
}

The third one is to use ACS_Execute which allows to run only one instance. However the script will start running after a tick passes.

Code: Select all

script 1 RETURN
{
	ACS_Execute(2, 0, 0, 0, 0);
}

script 2 (void)
{
	SetActivator(0);

	//Code goes here
}

But I recommend the fourth.
I am suggesting that OP should use UNLOADING type script with one tick delay, because the running instance of that script will immediately resume once you return to the map.

Code: Select all

script 1 UNLOADING
{
	delay(1);

	//Code goes here
}

In another words:

• Runs only one instance? Yes!
• Is activated by world? Yes!
• How many extra lines of ACS code does it add? One!
• How much extra memory does that consume? Somewhere between 100 to 300 bytes per map. For comparison: single actor uses between 800 and 1200 bytes... and actors are used for effects like blood, bullet casing, rain, snow and other stuff that HUB will remember, unless you make sure it gets removed. Estimations are extremely rough and may be off in hundreds of bytes.
• How much think time / CPU usage does it cause? Practically unmeasurable amount.

@OP: I honestly think that this "REOPEN" script type should have been implemented already, because it makes sense. However I believe that it will not make much difference if it is, or if it isn't added.
Or is there something that I am missing?

[ZzZombo]

snip

Unless proven otherwise, I see this as uncalled for, as I do believe what it does matches exactly your stated needs and goals.

[NeuralStunner]

An in-engine solution rather than hacks/workarounds was a stated goal, so no.

"Can we get an elevator? I don't want to keep hauling things up and down the stairs."
"We don't need an elevator. We already have stairs."

A RETURN script runs once for each player. Yes, you can "just" use a map variable to track whether the script has already run, but that variable is still going to be set the net time you reopen the map. Okay, "just" unset it via an UNDLOADING script. But you now have one more variable and script than you should need for such a simple operation.

Also, a delay()ed UNLOADING script does have the problem that it's going to resume 1 tic after the map (re)loads. Yes, for some things, 1 tic of delay can be problematic.

[RaveYard]

Also, a delay()ed UNLOADING script does have the problem that it's going to resume 1 tic after the map (re)loads. Yes, for some things, 1 tic of delay can be problematic.

Last time I did this, there was no delay. It runs before autosave is made.

[Xaser]

Unless proven otherwise, I see this as uncalled for, as I do believe what it does matches exactly your stated needs and goals.

Posts like yours in this thread are exactly why the post Nash quoted exists. In fact, you in particular have a seriously bad habit of violating this guideline repeatedly. Kindly cease this behavior or otherwise stop posting in the Development boards entirely.

[InsanityBringer]

ok to be completely honest, even if it is sort of possible already (through means I consider sketchy and possibly not future proof), is there actually any harm in adding a feature like this? I can't imagine it will be very hard to do, and wham, suddenly you have an entirely future proof (well, you still have to be somewhat careful, just like anything) way of doing things that results in ultimately cleaner and easier to read code.

Is there something wrong with this?