Locality

[misinformed 0]

Couldn't find anything on this in my searches so here we go.

Ive got an sqs that i want run server side only. Ie clients being told to exit the script.

So in essence it would be the opposite of this

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

?!local server:goto "exit"

exit

Anyone know what that might be?

Also ive done a bit of searching and in BIS's Cameldogfight MP mission the server side score counter is exec'd using:

Condition: Local AL in the trigger.

On Act: AL exec "PlanesServerE.sqs";

Thats specifying the server right? How exactly does that work?

Thx in advance.

[whisper 0]

use the new command isServer instead.

It returns true if the local computer is the server, false otherwise.

So if you want a script to run only on a server, at the beginning of the script exclude all clients :<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if !(isServer) exitWith {true};

[misinformed 0]

Brilliant will try that out.

[Taurus 20]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">isServer is indeed a nifty function added in arma.

The (.sqs)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?!local server:goto "exit"

or for .sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if !(local server) exitWith{"OMG not the server !"}; is just a check whether or not server is local.

(obviously)

BUT, server is a game logic placed in the map, and can be named anything

like

having a game logic named misinformed

and doing

(sqs)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?!local misinformed:goto "exit"

or (.sqf)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if !(local misinformed) exitWith{"OMG not the server this time either! :("};

Will be the same thing as checking "!(local server)"

Hope this clarifies things

[misinformed 0]

Wondered exactly how it worked. I was after something to sync the server time with new JIP clients. Piss easy once you know that.

All ready got a nice little synced server to client dynamic weather script down and working on the dedicated, going to be great having everyone with the right lighting as well.

[mr.Flea 0]

_axel = "Mi17" createvehicle _someposition

? Local _axel AND NOT IsNull player: hint "This is a Server"

? Local _axel AND IsNull player : hint "This is a Dedicaded Server"

? Not Local _axel  : hint "This is a Client"

deletevehicle _axel

exit

Any problems?

[sickboy 13]

All a bunch and load of old OFP-habbits that are not needed anymore; why teach someone depricated code?

Another thing is that a vehicle doesn't always have to be local to the server, it can also be local to a client

As already been mentioned before:

<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

{

hint "this is a dedicated server";

}else{

hint "this is a server-client";

};

}else{

hint "this is a client-only";

};There is an extra consideration for JIP but I guess thats unimportant atm.

The whole local server stuff is obsolete.

Locality checks of a vehicle or unit can of course still be interesting to know if you should take action/execute a script on the vehicle yes/no.

[Taurus 20]

<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

{

hint "this is a dedicated server";

}else{

hint "this is a server-client";

};

}else{

hint "this is a client-only";

};

Nifty indeed

There is an extra consideration for JIP but I guess thats unimportant atm.

It might, post example?

Locality checks of a vehicle or unit can of course still be interesting to know if you should take action/execute a script on the vehicle yes/no.

Such as? elaborate please?

[misinformed 0]

Quote[/b] ]

Another thing is that a vehicle doesn't always have to be local to the server, it can also be local to a client

My understanding is that a vehicle is local to its driver, so understandably yea. Its only local to the server when its empty, i think. However a turret is local to its occupier as well, etc.

Anyway ive got the line i was after, quick service, good answers, great job.

[whisper 0]

There is an extra consideration for JIP but I guess thats unimportant atm.

It might, post example?

Thanks to Synide, in the Biki init.sqs discussion page :

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">/*

Synide

11/6/2007

v1.0

Things to note...

If you are there at mission launch from that point on your 'Context'

will always be 'MP_CLIENT' and will stay as such even when you respawn.

If you are an 'MP_CLIENT' then you 'disconnect' from a continuing mission

and select a new playable character or the same playable character you will

become a 'JIP_CLIENT'.

If you join an inprogress mission you will be a 'JIP_CLIENT' from that

point till the mission ends.

*/

//init.sqf

debug=false;

common = compile preprocessfile "scripts\common\init.sqf";

mp_server = compile preprocessfile "scripts\mp_server\init.sqf";

sp_server = compile preprocessfile "scripts\sp_server\init.sqf";

mp_client = compile preprocessfile "scripts\mp_client\init.sqf";

jip_client = compile preprocessfile "scripts\jip_client\init.sqf";

if (isServer) then

{

Context = "SP_SERVER";

if (isnull player) then {Context = "MP_SERVER";};

}

else

{

Context = "MP_CLIENT";

if (isnull player) then {Context = "JIP_CLIENT";};

};

call common;

switch (Context) do

{

case "MP_SERVER": {call mp_server;};

case "SP_SERVER": {call sp_server;};

case "MP_CLIENT": {call mp_client;};

case "JIP_CLIENT": {call jip_client;};

};

processInitCommands;

finishMissionInit;

With this, you then just need to populate the scripts corresponding to the situation (common for all to runthe commands, server, client, JiP client, ...) as defined in the first preprocess commands

[vipermaul 246]

This is an excellent script. We use something very very similar.

Bravo for using CASE statements. It is far easier to read than a complex If statement.

However, I see something I need the veteran scriptors to help me understand.

I see that the variable Context is a global variable. Now I guess that is ok since we are not doing a publicvariable command on Context. But technically this should be a _Context a local variable right?

Now that I think about it, at this point in the execution of a new client connection since the variable is not PUBLIC (ie. publicvariable "Context") then this code is perfectly safe and will operate in all situations. Right?

[sickboy 13]

Nice set of code altough I would leave out the case and global variable PreProcessFiles parts:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//init.sqf

debug=false;

if (isServer) then

{

Context = "SP_SERVER";

if (isnull player) then {Context = "MP_SERVER";};

}else{

Context = "MP_CLIENT";

if (isnull player) then {Context = "JIP_CLIENT";};

};

call compile preProcessFile "scripts\common\init.sqf";

call compile preProcessFile format["scripts\%1\init.sqf",Context];

processInitCommands;

finishMissionInit;

Reason for the case removal; preference

Reason for the global variable preProcessFile parts removal; Loading those scripts in a variable is a waste, because under usual circimstances, the scripts only gets loaded once per session, even when you stay ingame and switch character/jip.

[Nutty_101 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.

[Synide 0]

@Sickboy... both true points... good'o i have amended my standard mission template init... it's always good to have 'clean' code.... thanks chap.

@ViperMaul... I made the 'Context' variable 'global' to the particular computer as it was useful in other scripts running on the given 'client' as opposed to 'private' to the init.sqf...

Too answer your question? Yes, the 'context' variable stays as set on any given comp. It's not published across the network with publicVariable.

PS. reminds of of Keygetys post the other day... Mr Peanut asked 'why was there no xor in ArmA' after numerous replys Keg's chimed in with a most elegant solution

[Doolittle 0]

Quote[/b] ]if (isServer) then

{

Context = "SP_SERVER";

if (isnull player) then {Context = "MP_SERVER";};

}else{

Context = "MP_CLIENT";

if (isnull player) then {Context = "JIP_CLIENT";};

};

I do not understand why a joining client would have their player object be null!!?

[sickboy 13]

Quote[/b] ]if (isServer) then

{

Context = "SP_SERVER";

if (isnull player) then {Context = "MP_SERVER";};

}else{

Context = "MP_CLIENT";

if (isnull player) then {Context = "JIP_CLIENT";};

};

I do not understand why a joining client would have their player object be null!!?

ArmA issue When the player jip's the player object is still null, until after a frame or so into the mission... while the init.sqf script runs before that moment, hence to get the side of a jip player or any other info, you would need to add a:

waitUntil{player==player};

or

waitUntil{isPlayer player};

Before you would perform tasks on the player inside a JIP script.

PS, nitpicking, altough not tested, the script-snippet I edited earlier could also be:

<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";};

};

[Synide 0]

lol, i wouldn't call it nick picking... cheers.

[whisper 0]

Quote[/b] ]if (isServer) then

{

Context = "SP_SERVER";

if (isnull player) then {Context = "MP_SERVER";};

}else{

Context = "MP_CLIENT";

if (isnull player) then {Context = "JIP_CLIENT";};

};

I do not understand why a joining client would have their player object be null!!?

ArmA issue When the player jip's the player object is still null, until after a frame or so into the mission... while the init.sqf script runs before that moment, hence to get the side of a jip player or any other info, you would need to add a:

waitUntil{player==player};

or

waitUntil{isPlayer player};

Before you would perform tasks on the player inside a JIP script.

Which is exactly why I find the decision to run init.sqs on every client pretty stupid, we must rely on a "ArmA issue" (with all the side-effect it can have) to detect a JiP condition.

If, like stated initially, init.sqs would be run only on client present at mission start, then you could put a simple "noJIP = true" in the init.sqs and then, through a trigger, detect if noJip == true and if not, do what you need to do for JiP clients.

That would be easy and logical.

Nothing against the script by itself (thks Synide for sharing it in Biki), but I find relying on a side-effect for important matter really really itching, and stupid, to say the least.

Why BI changed their mind? They were right

[sickboy 13]

Why BI changed their mind? They were right

BI changed their mind?

As long as I can remember since version 1.0 the init.sqs and sqf run on a JIP client mate? Since when would you say this was changed?

[whisper 0]

It was stated in Biki as not being run for JiP clients back in summer 2006. This information must have come from somewhere

EDIT : errr...

After check maybe not...

* trying to remember where I did hear that *

EDIT 2 : there is this comment from Suma in BT (from Biki bug list, so the date is BT is not good, it's the BT import one. Suma wrote that way before) :

Quote[/b] ]This is by design. Init script is launched only when the mission starts. If the player is not present at that time, it would be a bug to launch it for him. If the script left anything in the game state which is important for the joining player, he should receive this using the game world state update.

Anyway, it's not a good thing to do, for the reasons mentionned above

[sickboy 13]

Anyway, it's not a good thing to do, for the reasons mentionned above

Hmm maybe somehow he was refering to init lines (altough im not sure if they run yes/no ), though he really says "Init Scripts"

I think it's a good thing that the init script runs on both because it leaves the power in your hands to do with it as you please.

I must say I agree, a init.sqf and a JIPinit.sqf would of course been a ton times cooler

[whisper 0]

the power is in our hand whatever the case

trigger condition true => runInitScript , and you're set.

It has not been encountered before, I guess, but by relying on an engine side-effect ("there is a slight moment in JiP where client has no player character"), you're bound for it to fail at some odd occasion.

[sickboy 13]

the power is in our hand whatever the case

trigger condition true => runInitScript , and you're set.

It has not been encountered before, I guess, but by relying on an engine side-effect ("there is a slight moment in JiP where client has no player character"), you're bound for it to fail at some odd occasion.

I agree with you on the bad condition...

Still, placing triggers inside missions is not my thing, at least, not through the editor. Creating a trigger happens locally when done in a script, so in this case we could make a solution that uses the onPlayerConnected function on the server so that when a JIP client joins, we can either use a setVehicleInit or whatsoever to work out a runInitScript.

Still I would simply prefer that there would be a check for a initJIP.sqf

[Synide 0]

but the JIP client being a 'null' player during initilization phase of them joining an in-progress mission is not really a 'side-effect' (probably used the wrong terminology there).

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.

So you see making use of the fact that for a short time on a client's end of the equation there 'player' object is 'null' so as one can do some nifty stuff to there version of the game once the game-state has arrived with them can be of benefit and i think this 'feature' will never go away.

unless of course BIS change the way the client-server initialization phase happens... and even if they do... well it's not really an issue now is it... i mean they change functionality all the time and one just adapts to what they give us.

so i don't think it's a concern or bad to make use of this 'feature'. (i ramble alot sometimes btw, and some of it is cr#p too...)

[sickboy 13]

(i ramble alot sometimes btw, and some of it is cr#p too...)

No worries, I like it!

It's nice to discuss these things, and it's especially nice that there are persons left on this world that "Accept" other opinions, ideas and possibly improvements :-)

There's a whole bunch out there that doesn't and is very stubborn lol :P