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)

Are you sure, Sy? You understand the setup I am describing is... I start up Arma in one window and Arma dedicated server in another window, and then connect to my machine from the Arma client. It doesn't run init.sqs. Very strange. What am I doing wrong? Perhaps my way of testing if the init.sqs was run (by having just player sidechat "I am init.sqs" in the init.sqs is the wrong way to see if it's activated?? Do I need to put a time delay in there? --Doolittle 18:33, 2 August 2007 (CEST)

Yes, your way of testing is most likely wrong. I posted somewhere else about it a long time ago. 'player' is not set when init.sq[s|f] is run in JIP, you need to waitUntil or sleep until player has been set before you do your sidechat. Salisan

I figured out why waitUntil and sleep and all (like player being null) don't work inside an init.sqf at times... because it's executed instantly. Like when I try to JIP my own dedicated server running on the same machine. --Doolittle 06:00, 3 August 2007 (CEST)

I use the init.sqf below and subsequent scripts initiated from jip on a dedicated server on the same machine as the game I'm running - it all work flawlessly 'everytime'. --Sy 09:26, 3 August 2007 (CEST) PS. Doolittle - you seem to be quite keen on MP scripting etc. I suggest you make yourself a MP debugger for running from the UI while you are in 'host' mode or as a client on a dedi. - then you can 'see', alter and create all scripts, variables etc. directly from the UI while in-game. It'll help you alot.

Thanks... yes, it occurred to me if I (as client) send a publicVar to the dedicated server prompting it to create a vehicle and run processInitCommands that I could see what the result was for the currently connected client (me). --Doolittle 16:04, 3 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)

---