Clientside player TIDs for newly connected clients

[RaveYard]

When client joins, I want to make sure that on his (client's) side each player has a tid of "playerNumber() + 1000".

Sure, I do this:

Code: Select all

script "clientside_init" enter clientside //Zandro 3.0
{
   thing_changeTid(0, playerNumber() + 1000);
}

But as far as my knowledge goes... for a newly connected client, this script won't run.

So far I have solution which involves server executing clientside scripts with players being the activators such as this:

Code: Select all

...
for(int i = 0; i < 64; i++)
{
   if(setActivator(i + 1000))
   {
     acs_executeAlways(70, 0, 0, 0, 0); //Named clientside scripts executed serverside fail in Zandronum 3.0
     delay(1);
   }
}
...

Code: Select all

script 70 enter clientside
{
   thing_changeTid(0, playerNumber() + 1000);
}

But that is too silly.


Could I take advantage of setActivator on client's side using AAPTR_PLAYER1 to 8? How can I do that with more than 8 players with this method?

[SwordGrunt]

You can't assign a TID to spectators. If you're not talking about spectators, why wouldn't the enter script run?

And why must the TIDs be clientsided? Why would serverside TIDs for players not work?

[RaveYard]

You can't assign a TID to spectators. If you're not talking about spectators, why wouldn't the enter script run?

And why must the TIDs be clientsided? Why would serverside TIDs for players not work?

I am not trying to assign a TID to spectators, but to players.

To avoid useless traffic, I do most of the things clientsided and some of the scripts need to work with players. So I need to give every single player a TID on client's side.

The problem is that enter scripts run only on players that entered the game and not on the ones that have been already in the game.

[SwordGrunt]

You can't assign a TID to spectators. If you're not talking about spectators, why wouldn't the enter script run?

And why must the TIDs be clientsided? Why would serverside TIDs for players not work?

I am not trying to assign a TID to spectators, but to players.

To avoid useless traffic, I do most of the things clientsided and some of the scripts need to work with players. So I need to give every single player a TID on client's side.

The problem is that enter scripts run only on players that entered the game and not on the ones that have been already in the game.

I am not a skilled programmer, and I honestly do not know much about ZDoom's source nor do I know anything about Zandronum's netcode. But I assure you that even if you were to assign every player a random TID during every single tic (approximately 35 times a second) it would not come even close to generating any noticeable traffic for the server.

Your clientside script will assign the entering player a TID, but since it is not receiving information from the server from this script regarding any other players, it will never know their TID was changed for them as well.

Even if every one of your scripts depending on player TIDs is also clientsided, I would avoid using that for anything that is not exclusively decorative. Desyncs can and likely will happen if you use clientside recklessly.

[RaveYard]

Alright, I suppose the traffic isn't really noticeable.
Still, avoiding it altogether would be nice.

Even if every one of your scripts depending on player TIDs is also clientsided, I would avoid using that for anything that is not exclusively decorative. Desyncs can and likely will happen if you use clientside recklessly.

Don't worry, I know what I am doing

[Torr Samaho]

When client joins, I want to make sure that on his (client's) side each player has a tid of "playerNumber() + 1000".

An actor's TID is a synced property, i.e. the server will inform the client of the TID of all actors when the client initially joins the server. The server should also inform the clients of TID changes and of TID's of actors when they are spawned (I'm not sure though how thoroughly tested this is, some syncing may still be missing, but will be fixed if problems with this are reported). Having a client locally desync the TID is not supported and shouldn't be done.

[Leonard]

Still, avoiding it altogether would be nice.

I had to make something like that a while ago for a jumpmaze wad.
Basically since as already said changing TIDs on the client is bad, I based it on having one instance of a script run for each player ingame with themselves as the activator.
The only way I could think of to make everyone run the script including people already ingame was to use the GiveInventory trick: if you use GiveIventory in an acs script with the world as the activator (SetActivator(-1)) it will automatically run it on each player ingame.
The actor that was given was just a dummy custominventory that runs an acs script on pickup.

I wish zandronum had the static pointers (AAPTR_PLAYER#) extended to the 64 limit but last time I checked that wasn't the case. It would have made the whole thing a lot easier.

[RaveYard]

An actor's TID is a synced property, i.e. the server will inform the client of the TID of all actors when the client initially joins the server. The server should also inform the clients of TID changes and of TID's of actors when they are spawned (I'm not sure though how thoroughly tested this is, some syncing may still be missing, but will be fixed if problems with this are reported). Having a client locally desync the TID is not supported and shouldn't be done.

Wait, really?

Wow, it does work... but not all the time.
Were the TIDs supposed to be synchronized even in skulltag or is this a recent change?

The only way I could think of to make everyone run the script including people already ingame was to use the GiveInventory trick: if you use GiveIventory in an acs script with the world as the activator (SetActivator(-1)) it will automatically run it on each player ingame.
The actor that was given was just a dummy custominventory that runs an acs script on pickup.

Wow, neat!

[Torr Samaho]

Wow, it does work... but not all the time.
Were the TIDs supposed to be synchronized even in skulltag or is this a recent change?

I started to introduce the TID synchronization many years ago in Skulltag to fix problems with InterpolationPoint and PathFollower. I only fixed reported problems with the TID synchronization though, so it's more than possible that the syncing is still not complete yet even though it has been in for so many years now. If the syncing doesn't work for you, please open a tracker ticket and we'll discuss how to fix this there.