Locality of setVehicleInit, clearVehicleInit and processInitCommands

[ceeeb]

G'day peoples,
 
 I'm continuing to fill in the missing command locality details in the BI wiki. In my testing have come to a conclusion that contradicts the information that's already in there. I'm MP-stupid, and don't want to step on toes of those who aren't, so if anybody is knowledgable on the topic please let me know what's what? At the moment I'm not interested in how to use the commands, just exactly what they do. Cheers 

Biki currently says:
setVehicleInit - global effect
clearVehicleInit - (no locality info)
processInitCommands - local effect

My findings :
setVehicleInit - local effect
clearVehicleInit - local effect
processInitCommands - global effect

The clients/server each keep a local initialization string for each object. Executing proccessInitCommands on any client/server executes that clients/server version of the string, upon every client/server. No changes are made to any clients/servers version of the init string. Using clearVehicleInit will clear the local init string for an object. I've only taken a brief look at JIP effects, but it seems that JIP clients recieve the effect of processInitCommands that were executed on the server itself only, client executed effects are not passed on. I'll do some more testing...

FWIW, i'm testing using multiple clients and a dedicated server running on a single PC.

[Rommel92]

Interesting question.

Code: [Select]

vehicle_1 setvehicleinit "this setfuel 0";
processinitcommands;

vehicle_2 setvehicleinit "this setfuel 0";
Lets presume this script is run on the server with no execution parameters.

The client would see vehicle_1 with 0 fuel; and vehicle_2 with 1 fuel.
The server would see vehicle_1 with 0 fuel; and vehicle_2 with 1 fuel.

From what I know processinitcommands runs the setvehicleinit string that has been set locally, globally; however next time processinitcommands is run (on the server) vehicle_2 will have 0 fuel.

[Worldeater]

...however next time processinitcommands is run...

...probably nothing will happen if the BIKI article is correct:

The statements will only be executed once even if processInitCommands is called multiple times.

 

[Rommel92]

No, thats just mis-read information.

When 'processinitcommands' is run, this means that all the vehicleinits that have been 'set' will execute. And they are then reset to ""; so if you processinitcommands again, it is executing "".

If you say did the following:

Code: [Select]

for "_i" from 0 to 10 do {
    Vehicle_1 setvehicleinit format["player sidechat '%1'",_i];
    processinitcommands;
};
Will display

0,
1,
2,
3,
4,
5,
6,
7,
8,
9,
10

Unless my counting was off, that will work.

But this won't work.

Code: [Select]

Vehicle_1 setvehicleinit format["player sidechat '%1'",_i];
processinitcommands;

processinitcommands; //EXECUTES "" (NIL)


[Worldeater]

Hmmm, I don't think I misread anything. The article simply fails to mention that anything is reset by this command. Anyway, thanks for making it clear! I will change the article accordingly and try to find a non-misleading example for clearVehicleInit.

But there is still one odd thing:

Code: (init.sqf) [Select]

player setVehicleInit "this sidechat 'foo'";
processInitCommands;
This will display "foo" two times. How can this be? 

[Spooner]

This is explained better by saying that processInitCommands unsets the "run" flag on the vehicle after it is run. Since JIPers get the init command being run when the object is created on their machine, this implies that the text is not being removed, rather it is being marked as having run, so it will be be re-run on future processInitCommands. This also fits in with the clear command, which would have no meaning if processing the commands also cleared the code string (thus, clearing the string only has an effect for players that join after the command is cleared).

I imagine that the reason you are seeing your "foo" message twice is because the init.sqf is being run once on the server (running once on every machine via objNull, which is the player object on the server) and also once on each local machine (running the code once on every machine via the local player object). If someone else joined, I'd expect to see the message repeated 3, then 4, etc, times. Could be wrong on that, but sounds right.

[Worldeater]

I failed to mention several things: the example was run from the SP Editor and there was a "sleep 0.02;" at the top if the init.sqf. So a better test case is this:

Code: (init.sqf) [Select]

counter = 0;
player setVehicleInit "counter = counter + 1";
player setVehicleInit "counter = counter + 1";
processInitCommands;

...and then have a trigger to display the value of "counter" (which is 2).

[Rommel92]

Interesting, so I guess that would mean that the vehicle init has been stacked to the following:

Code: [Select]

player setVehicleInit "counter = counter + 1; counter = counter + 1";

[Spooner]

Hmm, I'd assume from this empirical evidence that setVehicleInit sets and runs the code locally and immediately and that processInitCommands then runs the code globally. However, that doesn't seem to be the case! From other tests, it does seem that setVehicleInit is non-destructive and just adds the new init to the old one. However, it does seem to be reset to "" in processInitCommands, since

Code: [Select]

counter = 0;
player setVehicleInit "counter = counter + 1";
processInitCommands;
// <-- A sleep here doesn't affect anything.
player setVehicleInit "counter = counter + 1";
processInitCommands;
hint str counter;
Gives the result as 2.

I think the issue here is that it is so standard to add init to an object and then immediately process that init, so this behaviour has not been noticed before. I'm not sure what use this behaviour can actually be for us, but I'm sure someone can find some use for it.

Personally, I never find use for setVehicleInit any more, though I used to rely on it, since public variable event handlers allow you to do similar things and allows you to pass any data, not just those that can be safely formatted into a string. Still, I probably should reassess its usefulness (I've got very lazy in my scripting and don't do as much experimentation like this as I used to do)...

[Rommel92]

Code: [Select]

counter = 0;
player setVehicleInit "counter = counter + 1";
processInitCommands;

player setVehicleInit "counter = counter + 1";
processInitCommands;counter == 2

Code: [Select]

counter = 0;
player setVehicleInit "counter = counter + 1";
player setVehicleInit "counter = counter + 1";
processInitCommands;counter == 2

Code: [Select]

counter = 0;
player setVehicleInit "counter = counter + 1";
processInitCommands;
processInitCommands;counter == 1

Code: [Select]

counter = 0;
player setVehicleInit "counter = counter + 1";
player setVehicleInit "counter = counter + 1";counter == 0


----------

Does seem rather strange however, that if the processInitCommands doesn't reset 'setvehicleinit' to "", then how does it stop the init from re-executing (twice). Maybe clearvehicleinit was purely designed for changing what may have been added by other scripts that you may be unawares. 

[Spooner]

There just has to be a hidden "This code has been run, so don't run it again on processInitCommands but do still run it for JIP players" flag Can't assume that we can see all game-state information using existing commands!

[Mandoble]

If we have already any clear conclusion about the behaviour of these two commands, please modify and/or add the corresponding comments here.

In my experience setVehicleInit command is not executed locally and it requires a processInitCommands execution, unless it is executed before the standard initialization of the units. In that case, setVehicle init "might" be added to the set of commands in the init fields of existing units.

[Rommel92]

unless it is executed before the standard initialization of the units In that case, setVehicle init "might" be added to the set of commands in the init fields of existing units..

Only way that could be possible is if you somehow add it within the mission.sqm, or something that initialises before the mission.sqm which would mean the unit wouldn't exist anyhow?.