JIP Script Handling

[MrZig 0]

Does anyone know how script handling is done with join in progress? When you join, does the init.sqs run specifically for you, and all the other scripts in the edtor restart for you? And if you quit, then rejoin, does it save scripts at all? (I seriosuly doubt this one). This information would be helpful for designing a complex mission (ala RTS, CTI etc). Sorry if it's already been discussed.

[crashdome 3]

I assumed scripts were depreciated.

Isn't it all Functions (and the new FSM model) now?

[kronzky 5]

Both still work.

Even in the official missions scripts are still used.

[crashdome 3]

Both still work.

Even in the official missions scripts are still used.

Well, I knew they worked. However, with the new sleep command and other such features added. Scripts are fast becoming the "bad way" to accomplish a task. I say that not to be negative about scripts... they have good purpose especially in cutscenes where other choices are to tedious for short results. However, if you are trying to set weather, give a group some patrol behavior, create an airburst effect, control air support, etc.. etc.. functions are going to give the highest performance and become the cleanest code. After having written alot of scripts (check how many complex scripts are in the SoW code and how many functions) I can easily say that scripts should be the last resort.

[UNN 0]

There are still scripts (*.sqs). But Scripts now use the same syntax as OFP's functions. Semi colons e.t.c However they still behave like the original OFP scripts. Same goes for functions (*.sqf), they behave the same way they did in OFP.

Check out the wiki for more detailed info:

Scripts

Functions

I'm going to stick with the *.sqs and *.sqf extensions, and refer to them as scripts and functions. It makes life easier when trying to determine how each file is supposed to be executed by Arma.

The only thing thats changed is the format of traditional "scripts" and the commands used to call them. Thier functionality and use remain the same.

[KaRRiLLioN 0]

Back to the original question, I would like to know.

I've ported RWS (Real War Simulator) from OFP.  It's similar to RTS and, of course there are lots of global vars floating around.

To save time, I've left everything as regular scripts.  When I re-do it from the ground up, I'll use SQF scripts.

Anyway, from testing RWS last night, here's what happened.  Those of us who were present from the start of the game had things go smoothly.  When you take a territory, a global var is sent out.

For those who JIP'd, everything was still at initial status.  They didn't see captured territories.

The commander also assigns roles, i.e. tanker, pilot, infantry.  This is done with a global var which is then detected by a looping script that assigns the role to the appropriate person locally.  If someone dropped from the game and came back, they would not still have the role.  This is unavoidable since the script did it locally and reset the global var once used.

So, what I've determined is that if global vars have changed from the time a JIP'er joins, they need to have the current state of the global vars transmitted to them.

Obviously, the onPlayerConnected script sounds like the perfect candidate.  But is it capturable by the server during a game, or is it part of a built in script like onPlayerKilled is?

I assume the onPlayerConnected is global when the player connects.  The server could detect this, pause for a moment to allow the player to run init.sqs, and then broadcast the relevant global var states to bring the person up to speed.  It could also transmit the time, etc. to synchronize the player.

Has anyone tested this script and can verify my assumptions?  I plan on testing it as well, but if someone can save me some time...

Another thing came to mind. I could put a boolean in init.sqs called NewPlayer. When a person runs init.sqs, it then publicVariables NewPlayer and the server knows to run the script that declares all global vars. That might work even better.

Perhaps put a small pause at the end of init.sqs before the boolean to give the player time to synch properly, then hand them the info.