[ACS] Continuous script - fork

[doomista]

If I understand the ACS properly, all global variables are server side (and thus I need an array of variables for tracking stuff globally for each player). And when I call ACS_ExecuteAlways, it will behave like a linux fork/thread, not a standard C function? I mean does scriptA calling execalways on scriptB run in parallel or does it wait for scriptB to terminate?
And can I have a script unique for each player constantly checking for an event (like a too far from certain item, kill the player)?

[Sean]

No. The difference between a script called with ACS_Execute and ACS_ExecuteAlways is that ACS_Execute will not work if the script is currently running. ACS_ExecuteAlways will run the script even if it is running. None of them are asynchronous, as there is no async in ZDoom.

And can I have a script unique for each player constantly checking for an event (like a too far from certain item, kill the player)?

I believe you're looking for looping ENTER scripts.

[doomista]

No. The difference between a script called with ACS_Execute and ACS_ExecuteAlways is that ACS_Execute will not work if the script is currently running. ACS_ExecuteAlways will run the script even if it is running. None of them are asynchronous, as there is no async in ZDoom.

And can I have a script unique for each player constantly checking for an event (like a too far from certain item, kill the player)?

I believe you're looking for looping ENTER scripts.

Technically... yes, I just was wondering whether is possible to call another script from inside ENTER and don't care about when exactly it was run. Since it is not asynchronous, then I'll have to be careful where to put that loop. Thanks

[doomista]

Also, is there a way to set a fade or a fog not to a certain sector but in circle around some point or I have to create fake fog actors?

[SwordGrunt]

I don't think you can make non-sector fogs, no. You'd need to make circular sectors around the point you want.

[ZZYZX]

If I understand the ACS properly, all global variables are server side (and thus I need an array of variables for tracking stuff globally for each player). And when I call ACS_ExecuteAlways, it will behave like a linux fork/thread, not a standard C function? I mean does scriptA calling execalways on scriptB run in parallel or does it wait for scriptB to terminate?
And can I have a script unique for each player constantly checking for an event (like a too far from certain item, kill the player)?

1. Yes, all variables are serverside.
2. When you call ACS_ExecuteAlways, yes, it behaves like a fork. You can also use ACS_ExecuteWithResult for this.
The difference between ACS_ExecuteAlways and ACS_ExecuteWithResult is that ExecuteAlways will execute the script on next tic, while ExecuteWithResult will do it in current at the time of being called (at least until first Delay() in called script).
Both will do it even if the script is already running.
3. When you use ACS_Execute (the single instance one), you can use ScriptWait to wait until child instance finishes, thus acting like a function call.
4. You cannot wait until a nonblocking instance finishes. Nonblocking instance will detach on first Delay() or any other wait function called. Before that, it's possible to use SetResultValue though.
5. If you need to have a script unique for each player constantly checking for an event, you need to make a serverside ENTER script like this (note: Zandronum 3.0! for 2.1.2 find replacement for VectorLength)

Code: Select all

#define ITEMTID 1
script "killiftoofar" ENTER
{
  if (VectorLength(VectorLength(GetActorX(0)-GetActorX(ITEMTID), GetActorY(0)-GetActorY(ITEMTID)), GetActorZ(0)-GetActorZ(ITEMTID)) > 1024.0)
    DamageThing(1000000, MOD_UNKNOWN);
  Delay(1);
  restart;
}

Also note that creating fake fog actors might cause severe slowdowns due to actor creation being resource intensive. It's okay if you don't create the fog actors every time though (like reusing existing fog actors on each "spawned" cloud).

[doomista]

5. If you need to have a script unique for each player constantly checking for an event, you need to make a serverside ENTER script like this (note: Zandronum 3.0! for 2.1.2 find replacement for VectorLength)

Code: Select all

#define ITEMTID 1
script "killiftoofar" ENTER
{
  if (VectorLength(VectorLength(GetActorX(0)-GetActorX(ITEMTID), GetActorY(0)-GetActorY(ITEMTID)), GetActorZ(0)-GetActorZ(ITEMTID)) > 1024.0)
    DamageThing(1000000, MOD_UNKNOWN);
  Delay(1);
  restart;
}

Yup, I already have that, maybe there will be a problém when I'll start playing with OPEN script

Also note that creating fake fog actors might cause severe slowdowns due to actor creation being resource intensive. It's okay if you don't create the fog actors every time though (like reusing existing fog actors on each "spawned" cloud).

I thought so. To be clear what I want to achieve - I am trying to make a tornado which has an eye with a static centre, but also a constantly lowering radius. "Collisions" can be dealth with using ENTER scripts and comparing player distance from the centre, but the actual visualisation of the tornado will be real pain in the ass. I actually thought about two different approaches:
1) Spawn 360 fakefog actors (once per MP match) and then after each T ticks move all of them closer to center (basically change their position, the actors wouldn't be able to move on their own). I can imagine it would be real slow.
2) Spawn let's say 8 or 16 fakefog actors and give them a movement vector (hope that works in Zandro 2.1, in last few days I've encountered so many things from zdoom2.8.1, that I need and cannot use :( ) and after each T tics adjust their vector in a way that fog will be orbiting on the spiral.

[SwordGrunt]

I don't understand why you want to refresh actors and/or move them with ACS. Why not control their movement via Decorate? You'd achieve practically the same results and spare bandwidth usage.

[doomista]

I don't understand why you want to refresh actors and/or move them with ACS. Why not control their movement via Decorate? You'd achieve practically the same results and spare bandwidth usage.

Simply because I need them to stop in certain distance from the center. I have no idea what type of function in decorate I should look for.

[doomista]

Code: Select all

int x = GetActorX(0) >> 16;
int y = GetActorY(0) >> 16;
int d1 = sqrt(x*x + y*y);
int d2 = VectorLenght(x, y);

Is there ANY practical reason why both d1 and d2 are always zero, no matter where I stand? X, Y coordinates are correct (bitshifted to be proper decimals).

[ZZYZX]

I don't understand why you want to refresh actors and/or move them with ACS. Why not control their movement via Decorate? You'd achieve practically the same results and spare bandwidth usage.

Fog actor should be +CLIENTSIDEONLY anyway............... (and controlled with clientside script too);
And then damage should be dealt based on player distance from the center (Zandronum 3.0, A_RadiusGive) instead of collisions with actors (that doesn't use excessive actor count and doesn't require the client to know anything pixel-perfect).
That way bandwidth usage is minimal and ACS is maximal.

*ACS intensifies*

Code: Select all

int x = GetActorX(0) >> 16;
int y = GetActorY(0) >> 16;
int d1 = sqrt(x*x + y*y);
int d2 = VectorLenght(x, y);

Is there ANY practical reason why both d1 and d2 are always zero, no matter where I stand? X, Y coordinates are correct (bitshifted to be proper decimals).

Zandronum 2.1.2 doesn't support VectorLength and silently returns 0. Probably same for sqrt.

[StrikerMan780]

Actually, not all global variables need to be serverside.

You can define a global variable, and manipulate that variable in a clientside script. That clientside script could also check if it's running on the consoleplayer first before allowing it to execute, that way each player has their own value stored in that variable on the client side.

for example:

Code: Select all

#include "zcommon.acs"

int current_player_class = 0;

script 1 ENTER CLIENTSIDE
{
	if(playernumber() != consoleplayer.. can't remember the exact syntax atm.)
	{
		return;
	}
	
	current_player_class = playerclass(playernumber());
}

If different people are playing as different classes, each client's stored value of current_player_class will be different. On the server, it'll always be 0.

[doomista]

I don't understand why you want to refresh actors and/or move them with ACS. Why not control their movement via Decorate? You'd achieve practically the same results and spare bandwidth usage.

Fog actor should be +CLIENTSIDEONLY anyway............... (and controlled with clientside script too);

Ok, I'll try that

And then damage should be dealt based on player distance from the center (Zandronum 3.0, A_RadiusGive) instead of collisions with actors (that doesn't use excessive actor count and doesn't require the client to know anything pixel-perfect).
That way bandwidth usage is minimal and ACS is maximal.

*ACS intensifies*

Yup, I already do that (as is apparent from my problems with VectorLenght, I hope).

Code: Select all

int x = GetActorX(0) >> 16;
int y = GetActorY(0) >> 16;
int d1 = sqrt(x*x + y*y);
int d2 = VectorLenght(x, y);

Is there ANY practical reason why both d1 and d2 are always zero, no matter where I stand? X, Y coordinates are correct (bitshifted to be proper decimals).

Zandronum 2.1.2 doesn't support VectorLength and silently returns 0. Probably same for sqrt.

Thanks for info, you've saved me a lot of headaches. I guess I'll copy some distance function definitions from zdoom wiki or come up with some even faster approximation. After all we're talking tornadoes.

[doomista]

I don't understand why you want to refresh actors and/or move them with ACS. Why not control their movement via Decorate? You'd achieve practically the same results and spare bandwidth usage.

Fog actor should be +CLIENTSIDEONLY anyway............... (and controlled with clientside script too);

Ok, I tried.. and it seems like a no-go. Spawning things with SpawnForced does not work at the clienside, not even in singleplayer, not even with the +CLIENTSIDEONLY flag in decorate. Plus, unless I put in serverside OPEN one redundant loop, I need to have a variable defined globally and shared alongside server and all of it's clients and the script that works with this variable, changing it's value, is supposed to be clientside and thus its value would be modified multiple times, which is bad. Also, computing player distance from the center and killing him should be done on the serverside ENTER to prevent desync or possible abuse.

But I currently have this algorithm working (all is serverside)

Code: Select all

1) ENTER script loops NOP till the tornado is spawned
2) OPEN script loops NOP till the tornado spawn is triggered
----
2) Players are killing each other and together they are activating the tornado spawn trigger
3) tornado spawn is triggered, OPEN script tells all players that tornado is being spawned and creates N fakefog(or tornado) actors. Actors are spawned "distance" far from the center
----
4) OPEN script lowers the "distance" and moves all actors to their new XY; loop
5) ENTER scripts computes player distance from the center and compares it with "distance", killing player when he's too far; loop

I am not moving actors in every frame, there's a tiny delay (about 3 tics). I have currently no means to test the mod at the full server capacity (8 players), and I did not even try to test it outside my home network, but I'll rather get this working now and optimize it later, when it will be clear it's necessary.

[SwordGrunt]

I believe SpawnForced is also a ZDoom 2.6+ function (not supported by Zandronum's current official version).

[doomista]

I believe SpawnForced is also a ZDoom 2.6+ function (not supported by Zandronum's current official version).

SpawnForced is supported in zandro. If it wouldn't, it would be totally impossible to create that tornado, because Spawn works only for places where the thing can be placed without any risk (and thus it does not work at all on complex maps). If you want, there's a vid from the almost newest version of the mod, a "tornado" can be seen couple of times.

[spoiler]

phpBB [media]

[/spoiler]