Init.sqs – Talk
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)
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)
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)