Locality

[[aps]gnat 29]

Thought I read that now with 1.08 the PLAYER variable is now initilized straight away, no lag .......

[UNN 0]

Quote[/b] ]This feature is intrinsic to the architecture of BIS's client-server design. While a JIP player is sitting at the 'lobby' screen deciding on which 'slot' they are going to jump into they are not and never will be a 'player'.

it's only when they hit the 'go' button that the client computer requests the server that this 'user' be equated to the playable character selected and the server sends the 'game-state' for that playable character and the rest of the 'stuff' going on currently with the mission.

so the player has hit 'go' on there end and there game starts running the 'init' phase of the mission. while it's waiting for the gamestate to arrive there User/Character/Identity on their own computer is null this 'feature' is unavoidable in the given ArmA context i would think.

btw... i haven't confirmed every single aspect of the above... but i'd imagine they'd be reasonably accurate assumptions but ya never know... could be just all rubbish.

Yeah, that’s pretty much the way I've seen it work to. Until a player actually joins a game, they are considered to be part of and local to the Server. While it sorts out all the Groups and Sides e.t.c

So far, launching the init events and scripts is essential for a JIP client. Again as far as my own experience goes, if I design my mission correctly I don't have to make any special consideration for JIP. JIP does have it's limits and restrictions, but once you understand them, they can be avoided.

Not sure if anyone else is interested, but since JIP was introduced. The whole Mp initialise sequence appeared to get much more complicated. So I started making an attempt to map it across the Client, Server and JIP client. I came up with this:

It's not as bad as it looks. The numbers across Vertical column represent the various different init events launched during startup:

0 - 5: Functions and scripts launched from an addons config Init event

6 - 11: Functions and scripts launched from Init.sqf

12 - 17: Functions and scripts launched from Init.sqs

18 - 23: Functions and scripts launched from the init field of an object placed in the mission editor.

In each of the four stages I tested the same test script. The script performs six different tests, from launching a function through to launching a script that lanches another script via ProcessInitCommands. So for a config init event the numbers are:

0 : Call a function

1 : ExecVM a script

2 : Call a function to ProcessInit a function

3 : Call a script to ProcessInit a function

4 : Call a function to ProcessInit a script

5 : Call a script to ProcessInit a script

The same six test are repeated for each of the four init stages. The horizontal axis is the sequence of events in chronological order.

Not done as much testing as I would like, still need to map out the commands that work or don't work for each stage.

[norrin 9]

Gnat @ June 21 2007,12:26)]Thought I read that now with 1.08 the PLAYER variable is now initilized straight away, no lag .......

You're right Raedor said this in my revive thread

Today I found that it looks like the player var is init'ed instantly for JIP'ed players since 1.08...

As far as the init.sqf is concerned this seems to be true in most cases, however, I've found that when the server is taxed in 1.08, and maybe under other conditions as well, this may not always be the case.  For instance, when I use an int.sqf script that starts with the waitUntil {player == player} code it can take up to a second for the init script to run under these conditions.

@Sy thanks for clearly explaining what's going on with the player variable.

[whisper 0]

Gnat @ June 21 2007,12:26)]Thought I read that now with 1.08 the PLAYER variable is now initilized straight away, no lag .......

You're right Raedor said this in my revive thread

Today I found that it looks like the player var is init'ed instantly for JIP'ed players since 1.08...

Which means that Synide's method doesn't work anymore?

Great...

Well, time to push up in my crusade, then

[UNN 0]

Well I just ran a check for the Player in my MP test mission.

On a client starting a mission:

Inits 0,1,3,18,19,21 returned the player as null.

On a client starting as a JIP they all returned the Player as Null.

You can do a simple test to confirm if this is the case. Run the following from a client that starts a mission. I used a Radio trigger and and a game logic with this line:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">GameLogic01 SetVehicleInit "Hint Format [""Player=%1"",Player]"; ProcessInitCommands

If you quit out and JIP back into the mission. The Hint reports the Player as Null. Now I'm not running this on a proper (remote) dedicated server. Just Arma_server.exe being run on my client.

[sickboy 14]

I would suggest simply testing with the hint line in init.sqf, though that leaves less flexibility if you want to test the player object "on the run", though I would not see any real application of being able to test the Player object past the init, as at the moment you are able to operate ur radio, the player object is known

[UNN 0]

Quote[/b] ]I would suggest simply testing with the hint line in init.sqf, though that leaves less flexibility if you want to test the player object "on the run"

I would certainly like to hear if the same thing happens on a proper remote server. For myself I tested all 23 variations on the init events and scripts for JIP. For all 23 of them, Player was returned as null.

Quote[/b] ]as at the moment you are able to operate ur radio, the player object is known

I'm not sure I understand what you mean. If the Player was known then the hint should not return a null object? But it does return null, at least in my tests.

But if you notice, a processed init command gets executed quite early on in the JIP init sequence. At that early stage, Player appears to be unkown.

[Synide 0]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if (isServer) then

{

  if (isnull player) then {Context = "mp_server";}else{Context = "sp_server";};

}else{

  if (isnull player) then {Context = "jip_client";}else{Context = "mp_client";};

};

I can confirm that the above code in an int.sqf is still valid in v1.08.

I ran 2 client instances on my computer both connected to a remote Dedicated Server.

Once in the mission I checked the 'Context' variable on each - 1 had a value of 'mp_client' and the other had a value of 'jip_client'.

Sorry, I should point out that the 'jip_client' one joined the mission after it had started.

[Synide 0]

Slightly on the topic but a little different

Is there a way to tell what client the object is local to? I am curious if we can detect who is creating objects.

Was this question regarding vehicles? Or, just objects in general?

[UNN 0]

Quote[/b] ] can confirm that the above code in an int.sqf is still valid in v1.08.

I ran 2 client instances on my computer both connected to a remote Dedicated Server.

Cheers

BTW For anyone who does not want the init scripts running when a JIP joins, just add this at the top of init.sqf:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">If (!IsServer and (IsNull Player)) ExitWith {}

At least this way we have the choice of executing init.sqf with a JIP.

Quote[/b] ]Is there a way to tell what client the object is local to? I am curious if we can detect who is creating objects.

If your using CreateVehicle, then the object will always be local to the server until a player, or a member of the players group gets in as driver. Or in case of a infantry guy, it joins a players group or vehicle.

As for which client called the CreateVehicle command, that would depend on how it was called. A trigger would be called by everyone, a user action or dialog would be called local by a specific client.

If your thinking of cheat prevention, then no you can't tell who the cheat is. All you could do is identify an object that should not be in a mission and delete it.