Halting game till init is finished?

[ZNorQ 0]

Is there a way to make sure the game doesn't start till the init script is finished?

[loyalguard 15]

ZNorQ-

What do you mean by "start" exactly? Do you mean players cannot move or do anything until the init finishes? Or do mean nothing else "loads" until the init.sqf is finished executing?

If it is the former you can disableUserInput and titleText or cutText to black out the screen until everything is ready (after a certain amount of time).

If it is the latter, unfortunately, some things load before the init.sqf even launches so it depends?

What exactly are you trying to accomplish?

[ZNorQ 0]

What exactly are you trying to accomplish?

I wanted to make sure that all scripts executed by init.sqf is completed before the game starts..

For example, I've used waitUntil {scriptDone hPlyrSetup}; as the last line in the init.sqf, but it seems to be ignoring that..

(hPlyrSetup is the script handle returned from execVM which sets up the players.)

ZNorQ

[ZNorQ 0]

Maybe I should use another example;

init.sqf;

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

waitUntil {bTest};

hint "Continued...";

When I preview the mission, it starts up - it doesn't wait till the init.sqf is completed.

ZNorQ

(Urk, not sure if that helped anything at all...)

[loyalguard 15]

Quote[/b] ]I wanted to make sure that all scripts executed by init.sqf is completed before the game starts..

Hmmm...I think the long and the short of the matter is that the mission will always start "before" the init.sqf finishes (or at least depending on the complexity of either the mission.sqm or init.sqf). I think the best we can do is prevent other commands performed in the init.sqf (including executing other scripts) from occurring until we are ready for them to occur (via waitUntil, scriptDone, booleans, etc).

If something is happening before you want it to (say a unit being created via the editor) you could try to create that unit via a script launched from the init.sqf instead of in the editor.

Does that help it all?...I am sorry I cannot shed more light!

[ZNorQ 0]

Well, you gave me the idea of disable player input and use a black screen till everything has reported back ok, I guess. Think I'll have a look into that possibility.

I do wish that the game wouldn't start before the init.sqf was completed though...

So, you did give me some ideas, so thanks for the help, loyalguard.

ZNorQ

[Synide 0]

try in your init.sqf to do 'calls' to your first layer of scripts out the init... don't spawn or execVM them...

then the called scripts will be inline and the init.sqf will not complete till all the inlined scripts complete... also, try to have 'finishMissionInit' at the bottom of your init.sqf...

I got bored with doing analysis on the foilbles of the scripting runtime 6 months ago, but i'm sure what you want is achieveable...

[ZNorQ 0]

try in your init.sqf to do 'calls' to your first layer of scripts out the init... don't spawn or execVM them...

then the called scripts will be inline and the init.sqf will not complete till all the inlined scripts complete... also, try to have 'finishMissionInit' at the bottom of your init.sqf...

I got bored with doing analysis on the foilbles of the scripting runtime 6 months ago, but i'm sure what you want is achieveable...

This is exactly what I'm after! But, As I use waitUntil {scriptDone <handlevariable>}; for all my execVMs in the init.sqf, and finishMissionInit at the end of the script, shouldn't converting to call functions be unecessary?

Thanks, Synide.

ZNorQ

[Synide 0]

hmmm... true... in theory... lol, sorry mate as i said i've sorta moved away from doing hard core scripting...

somewhere in the anals on my mind i seem to recall waitUntil not being valid in the 'init' phase...

i do however remember quite clearly that if you 'inline' the calls to the subordinate scripts then they will run one after the other... meaning your 'init' phase will slow down quite alot...

[ZNorQ 0]

hmmm... true... in theory... lol, sorry mate as i said i've sorta moved away from doing hard core scripting...

somewhere in the anals on my mind i seem to recall waitUntil not being valid in the 'init' phase...

i do however remember quite clearly that if you 'inline' the calls to the subordinate scripts then they will run one after the other... meaning your 'init' phase will slow down quite alot...

Moving away from scripting; Hehe, and I'm drawn more and more into the depts of heavy coding, and its a nightmare in MP coding, especially if you're gonna get JIP to work as well... I see now what I have done...

waitUntil not being valid in init.sqf; But ofcourse! Why make it easy for us?? But then again, as you said, call should be the solution to overcome that problem... Back to the drawing board... DOOOH!

If this works, then this is what I need. Thank you, Synide.

ZNorQ

[Synide 0]

hey, don't hold me too that i'm might be completely wrong - but good luck...

[sickboy 13]

If you ask me, waitUntil works just fine in Init.sqf

The problem is that waitUntil in init.sqf does not stop the game from loading.

Actually, if the condition in the waitUntil is not true at the first cycle, waitUntil will halt the init script running until after the mission has started,

and then checks the condition every few milliseconds again until it's true, and then it will continue the rest of the init script.

If you want certain things initialized before the player "sees" or "is able to play in" the gameworld, you could add a black-out and disableUserInput before the waitUntil.

And re-enable userinput and black-in after the waitUntil.

This should basicly give the wanted result, if I understand your wish correctly.

Calling scripts instead of spawn or execVM, could be an option. But it depends on what kinds of scripts and functions you will call.

If the functions or scripts will contain waitUntil or sleep, you will get the same result again; the scripts will run 1 cycle until sleep (or the sleep induced by waitUntil),

and then continue running again after the mission has started

Also, JIP is childsplay, in init.sqf:

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

t_Jip = false;

t_Server = false;

if ( isServer ) then

{

  t_Server = true;

  if (!(isNull player)) then { t_Client = true };

} else {

  t_Client = true;

  if (isNull player) then { t_Jip = true };

};(there are many possible variants of the above of course)

basicly:

[*] Server Only: (t_Server && ! t_Client)

[*] Server Client: (t_Server && t_Client)

[*] Client Only: (t_Client && ! t_Server && ! t_Jip)

[*] JIP Client: (t_Jip)

From here on out you can work with the following functions:

onPlayerConnected

onPlayerDisconnected

publicVariable

addPublicVariableEventHandler

setVehicleInit

processInitCommands

(all docs available at http://community.bistudio.com)

[ZNorQ 0]

If you ask me, waitUntil works just fine in Init.sqf. The problem is that waitUntil in init.sqf does not stop the game from loading.

Yep, and that was my problem. I wanted to make sure the game didn't start until all scripts (including init.sqf) had been completed. I noticed this first time when my character changed weapon configuration at the start of the game. This is what I want to prevent.

Actually, if the condition in the waitUntil is not true at the first cycle, waitUntil will halt the init script running until after the mission has started, and then checks the condition every few milliseconds again until it's true, and then it will continue the rest of the init script.

Sounds correct. Initially (along time ago, back in the ofp days), I thought the init.sqf was always finished before the game started, and have for a long time been under that impression.

If you want certain things initialized before the player "sees" or "is able to play in" the gameworld, you could add a black-out and disableUserInput before the waitUntil. And re-enable userinput and black-in after the waitUntil.

Yes, as Loyalguard explained to me earlier, and hopefully that with the combination of finishMissionInit at the end of init.sqf, things should problably become the solution I was looking for. Unfortunatly, it doesn't seem to work, as I put a sleep of 30 seconds before the finishMissionInit, and a hint text after the finishMissionInit - and it didn't work. The game started, and around 30 seconds thereafter, the message appeared... But I guess the use of disableUserInput and black-out as you described it should be sufficient.

Calling scripts instead of spawn or execVM, could be an option. But it depends on what kinds of scripts and functions you will call. If the functions or scripts will contain waitUntil or sleep, you will get the same result again; the scripts will run 1 cycle until sleep (or the sleep induced by waitUntil), and then continue running again after the mission has started.

Ok, I'll be sure to take that in consideration when I'm programming init.sqf and related statup scripts.

Also, JIP is childsplay, in init.sqf:

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

t_Jip = false;

t_Server = false;

if ( isServer ) then

{

  t_Server = true;

  if (!(isNull player)) then { t_Client = true };

} else {

  t_Client = true;

  if (isNull player) then { t_Jip = true };

};

(there are many possible variants of the above of course)

basicly:

[*] Server Only: (t_Server && ! t_Client)

[*] Server Client: (t_Server && t_Client)

[*] Client Only: (t_Client && ! t_Server && ! t_Jip)

[*] JIP Client: (t_Jip)

Question regarding t_jip; I'm not quite sure when this would be true. When the player is in the player selection screen?

From here on out you can work with the following functions:

onPlayerConnected

onPlayerDisconnected

publicVariable

addPublicVariableEventHandler

setVehicleInit

processInitCommands

There is a few functions there I wasn't aware of, like onPlayerConnect / onPlayerDisconnect .. I noticed that this applies when the game starts up the first time, which should be taken in consideration when utilizing these functions. I was hoping they only triggered when players connected/disconnected to games already in progress (JIP'ing)...

publicVariable have been frequently used by me since the early days of OFP, and now that v1.09b have been released, it supports all types - finally!

The new addPublicVariableEventHandler is something I have been missing since back in the old OFP days, and its finally here. Haven't made use of it quite yet, but I know it will come in handy.

Regarding the processInitCommands, I'm abit sceptical, since it seem to be executing all object's inits, and that could become a really messy situation..? I'm thinking initializations of variables that will change during the game, and that new players would get the 'old' settings...

(all docs available at http://community.bistudio.com)

.. And I use it frequently, but it is not always easy to find the information one is after..

I really appreciate your feedback, Sickboy, it have helped me immensly. Keep up the good work!

ZNorQ

[loyalguard 15]

There is a few functions there I wasn't aware of, like onPlayerConnect / onPlayerDisconnect .. I noticed that this applies when the game starts up the first time, which should be taken in consideration when utilizing these functions. I was hoping they only triggered when players connected/disconnected to games already in progress (JIP'ing)...

Just to be clear, onPlayerConnected and ...Disconnected apply when ALL players connect/disconnect, at misson start AND join in progress.

However, even though they apply universally, if you only want them to execute code when JIP players connect that should be fairly easy to do using time or even other variables as conditions. e.g:

init.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">onPlayerConnected "[_id, _name]execVM ""PlayerConnected.sqf""";

PlayerConnected.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if (time > 60) exitwith{}; // If more then 60 seconds has elapsed since mission "started" then exit with JIP Update else continue.

publicVariable "someVarJIPPlayerNeeds";

[zaphod 0]

store your "scripts" into functions ... after that you can just precompile the script holding your functions on top of init.sqf to declare functions into global variables ... after that the content of the whole script is loaded and you can just go on calling/spawning your client/server functions ...

[ZNorQ 0]

There is a few functions there I wasn't aware of, like onPlayerConnect / onPlayerDisconnect .. I noticed that this applies when the game starts up the first time, which should be taken in consideration when utilizing these functions. I was hoping they only triggered when players connected/disconnected to games already in progress (JIP'ing)...

Just to be clear, onPlayerConnected and ...Disconnected apply when ALL players connect/disconnect, at misson start AND join in progress.

However, even though they apply universally, if you only want them to execute code when JIP players connect that should be fairly easy to do using time or even other variables as conditions. e.g:

init.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">onPlayerConnected "[_id, _name]execVM ""PlayerConnected.sqf""";

PlayerConnected.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if (time > 60) exitwith{}; // If more then 60 seconds has elapsed since mission "started" then exit with JIP Update else continue.

publicVariable "someVarJIPPlayerNeeds";

Loyal,

Ok, I see your point, sounds logical - but I have another pressing issue with the JIP function.

It seems in my mp mission, when someone disconnects - and reconnects, there is a new instance of that player created (it doesn't 'take over' the player object he/she disconnected from), with an identical ID (vehicleVarName)!! This is not supposed to be possible!

Anyone else experienced this?

EDIT: Maybe this should be brought up as a separate issue...

ZNorQ

[ZNorQ 0]

store your "scripts" into functions ... after that you can just precompile the script holding your functions on top of init.sqf to declare functions into global variables ... after that the content of the whole script is loaded and you can just go on calling/spawning your client/server functions ...

Yepp, was thinking of the same approach.

[loyalguard 15]

It seems in my mp mission, when someone disconnects - and reconnects, there is a new instance of that player created (it doesn't 'take over' the player object he/she disconnected from), with an identical ID (vehicleVarName)!! This is not supposed to be possible!

I am only vaguely familiar with vehicleVarName and never used it unfortunately so I can't comment too much on that aspect, but what you describe is my understanding of how disc/reconnect works. I don't think it possible for a re-connecting player to assume the same player object that existed before they disconnected.

The only method I am aware of "resuming" the same "player" (on a persistent server) I think is to store whatever information makes that player unique (weapons and equipment, score, rank, etc.) as a series of public variables, or packed as a public string (or in 1.09 beta as a public array ) and then retrieve that information on recconect and use that to reconstitute the "player" with addWeapon, AddScore, etc. and/or resetting other applicable variables to their previous values and such.

[Rommel 2]

Maybe I read BIS's wiki wrong, as I am currently getting my head around functions and their differences to normal scripts in ArmA anyway (thank you BIS )

Quote[/b] ]Unlike scripts, functions halt all other game engine processes until the function has completed its instructions. This means functions run faster than scripts, and the result of functions is immediate and unambiguous. It can also mean that if a function takes too long to run it will have an adverse effect on game play - large functions or CPU intensive functions can cause the game to seize up until it completes. When creating a functions you want the function to be short and sweet to achieve the best results.

[sickboy 13]

@ZNorQ:

Np mate, glad to be of help.

About disconnecting and reconnecting. This is only a problem in missions that either:

[*] Have respawn for player: Instant, Base

[*] Have disabledAI = 1; in the description.ext

In other situations, when a player disconnects, his object remains as an AI. When he or anyone else reconnects into that slot, he takes over that object again, incl. everything (weapons, etc).

PlayerConnected.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if (time > 60) exitwith{}; // If more then 60 seconds has elapsed since mission "started" then exit with JIP Update else continue.

publicVariable "someVarJIPPlayerNeeds";

FYI: You only would need to use it (onPlayerConnected and publicVariable, in this sense), when the variable you want to send, might've been updated since the last time you publicVariabled it.

What im trying to say is; When a player JIP's, all variables and values that were 'publicVariabled' before in the mission, will automaticly be synchronized to the JIP client.

However, if the value for that variable has changed, after it was publicVariabled... then indeed you must 're-publicVariable' it at the connect of the new player.

f.i: for synchronizing time, you should probably use your method

f.i: for sharing a common setting which got set somewhere at the start, you would not need to use your method because the variable is already synchronized at join

[loyalguard 15]

...What im trying to say is; When a player JIP's, all variables and values that were 'publicVariabled' before in the mission, will automaticly be synchronized to the JIP client....

That is something I did not know! Thanks much SB!

[Doolittle 0]

I have found that init stuff, be it in init.sqf or a vehicle's init... does not let you pause in any way. No sleep or waitUntil. All that is just rolled right over.

[sickboy 13]

I have found that init stuff, be it in init.sqf or a vehicle's init... does not let you pause in any way. No sleep or waitUntil. All that is just rolled right over.

Indeed, Init's of objects in editor, execution from dialogs or from within eventHandlers do not support sleep or waitUntil. You will have to spawn or execVM from there. In the spawned/execVMed script you can use it again.

Init.sqf does, but it will mean that the processing of the init.sqf halts at the sleep or waitUntil, and continues after the mission has started. At least, thats how I remember it

Basicly, everything that supports sleep and waitUntil, will hold at the position of sleep or waitUntil, until after the mission is started. After that it will work as it should.

UNLESS the waitUntil condition is true at first execution cycle, in this case it will go past the waitUntil without waiting until after mission has started.

Probably because the waitUntil function works like this:

a) check condition

b) if false, sleep 0.3, return to a)

the sleep happens after the condition is checked, and is only executed when the condition was false.