Talk:Init.sqs

An init.sqf file may be used instead of the init.sqs. Not sure if the article should be moved or just added to. --pyro05x 07:59, 7 February 2007 (CET)

Add it, as the init.sqs is still working. :) --raedor 15:24, 7 February 2007 (CET)

And if there're both sqs&sqf what happens ? What is executed first ? --bdfy

I don't know, test it :P --raedor 23:35, 7 February 2007 (CET)

Just tried it and it seems SQF is executed first. ++Str 15:17, 8 February 2007 (CET)

First or only? --Ceeeb

First. Executed are both of them. ++Str 16:13, 8 February 2007 (CET)

so the execution of the init.sqs is delayed until init.sqf is done? --pyro05x 01:33, 13 February 2007 (CET)

Hmm, seems to execute for each player that joins, as oppose to once at the beginning of the mission... --BarmyArmy, 09:32, 14 April 2007

Unless something has changed recently, it shouldn't. --Kronzky 17:17, 14 April 2007 (CEST)

I also noticed that the init is executed for every player that joins. Probably it is the mission start for him. --T_D 14:36, 15 April 2007 (CEST)

I believe Suma was mistaken in what he wrote there. Executing init for JIP players is much better from a mission editing POV anyway. I sent him a message about it a while ago and he said he'd investigate but heard nothing back so hopefully the current behaviour is here to stay. --Salisan 19:25, 15 April 2007 (CEST)

JIP and INIT.SQS/F

_InitState="NONE"; execVM "init_common.sqf"; if ( local server ) then { _InitState="SERVER"; if ( isnull player ) then { _InitState="MP-SERVER"; } else { _InitState="SP-SERVER+CLIENT/EDITOR"; [] execVM "init_client.sqf"; }; [] execVM "init_server.sqf"; } else { _InitState="CLIENT"; if ( isnull player ) then { // no server and no client - we must be JIP _InitState="JIP"; [] execVM "init_jip.sqf"; } else { _InitState="MP-CLIENT"; [] execVM "init_client.sqf"; }; };

Apologies for everyone who posted replies to my orignal and factually incorrect post. init.sqf is run even for JIP clients, the above code currently correctly detects SP,MPClient,MPServer and JIP-Clients. BarmyArmy

If I recall correctly, the init.sqs is never run on any other machine than the server. -- Manny 01:43, 7 May 2007 (CEST)

Init.sqf/sqs runs on all machines during mission initialization. --Ceeeb 06:18, 7 May 2007 (CEST)

My bad, sorry, I usually don't use init.sqs for client initialization :). You could however seperate the init.sqs into init.sqs (which only runs server related stuff, or stuff that should only on one machine and once, using the good old ?!local server:exit) and init_client.sqf for clients, which are run once by a trigger with condition alive player. Furthermore, push variables across the net again with publicVariable in an onPlayerConnected event handler, in case this is required.

I'll try to address issues like this in a seperate article about multiplayer locality somewhen this month. -- Manny 15:06, 7 May 2007 (CEST)

I'm getting the opposite result (running beta 5143, dedicated server). A JIP player's client executes init.sqf?! --Ceeeb 08:29, 8 May 2007 (CEST)

Finally, do we have a definite answer on this? Is init.sqs/sqf run on a client who connects after the game has started and has passed the mission briefing step? I can't test it atm :( --Whisper 14:37, 16 May 2007 (CEST)

My tests said that the init.sqf is also executed for JIP Players. Didn't test the init.sqs but I doubt that there is a difference --T_D 15:29, 16 May 2007 (CEST)

From my experience init.sqf is executed on JIP. You should use something like that to get scripts working as they should for JIP'ed players:

if (!isServer && player != player) then { waitUntil {player == player}; player setVehicleInit format ["hint 'new player: %1'", player]; processInitCommands; };

OK, init.sqf launched for eveyone. Great. (well, in fact absolutely NOT great, but nevermind...) Tested, the (player != player) trick doesn't work fine for me. So HOW, now, can I detect a JiP situation? With a JiP NOT triggering init.sqf, it would have been really easy, simply using a trigger with a "true" condition would do the trick, but now I'm stuck unable to differentiate JiP from non-JiP players... I don't see the improvement in having init.sqf running for everyone. --Whisper 18:03, 14 June 2007 (CEST)

I set up a dedicated server then ran a client on the same machine and connected to it to test my mission. No briefing is shown when I JIP and the init.sqf and .sqs are NOT run (this is on a JIP). So... I don't know why this is but perhaps having client & server on same machine creates a weird environment? --Doolittle 08:09, 2 August 2007 (CEST)

lol, well all i can say is I have the exact same setup, and init.sqf IS run - you must be doing something not quite right. and, it's been tested on a remote dedi-server as well, init.sqs AND init.sqf are both run - JIP players of course do not get spamed with the breifing on connect - a briefing display could be initiated from a jip script if required however.--Sy 09:08, 2 August 2007 (CEST)

---

This works for me it correctly identifies the context within which any of your scripts may run. --Sy 01:33, 15 June 2007 (CEST)

init.sqf - You then can test for context == 'blah' from any of your scripts. I prefer to have all scripts split into different folders depending on the 'context' rather than having a generic script that runs for any 'context' and decides which/where it is running at runtime. I beleive it's better to decide at 'login' time what type of 'user' is interacting with this mission. /* 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; 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";}; }; call compile preProcessFile "scripts\common\init.sqf"; call compile preProcessFile format["scripts\%1\init.sqf",Context]; processInitCommands; finishMissionInit;

That's great Sy... but could someone explain why we have JIP client (why the distinction?)? Why would a client that is joining after the mission starts have a null 'player'? And is it the same to use 'isnull player' and 'local player'? --Doolittle 19:32, 16 June 2007 (CEST)

---

Amended, the above example init.sqf as per a post by Sickboy in the forums. @Doolittle... Why the distinction? Because often a mission maker keeps variables local to a particular computer (whether they are a client or the server). Or, one might want to run 'cathup' type scripts on the JIP client. Yes indeed, for a 'short' period of time that a 'JIP_CLIENT' is transitioning from 'User+Player=null' to 'User+Player=User' the 'inull player' is true and the 'local player' should return false. So, you're right to point out they should be the same. But i haven't tested that. --Sy 20:57, 20 June 2007 (CEST) Amended again... --Sy 04:28, 21 June 2007 (CEST)

---