Investigation: Initialisation of units/objects/waypoints/triggers

[Chris Death]

Yesterday i've made a couple of tests which i must say should have been
done right from beginning of mission editing in ofp.

Before a few words about how i got inspired to start these tests:

Until a few weeks ago i've been in the meaning that init fields of units become
executed in order of first unit being placed = first init field being executed.

Then i found out that this is not true by trying to initialise an array from the
first unit's init field i've placed onto the map (a West unit) and adding other
units by their init fields to this array (West and East units).
Now the result was that the East units weren't added to the array which made
me stunning.

After a little bit of playing around i figured out that East unit's init fields become
executed before West unit's init fields.

Then yesterday i found a thread by UNN at official forums where he was
also posting about initialisation of units or vehicles but from the config
point of view. I shared my experiences to him.

So i started thinking about testing what gets executed when at missionstart;


Initialisation test:


The following events i've taken into consideration when starting my tests:

• East unit's Init field
• West unit's init field
• Resistance unit's init field
• Civilian unit's init field
• Empty Object's init field
• Gamelogic's init field
• Trigger (with condition: true)
• Init.sqs
• Script (started from init field of a unit)
• Script (started from init.sqs)
• Script (started by waypoint scripted)
  :note - wp scripted scripts execute once a unit's next waypoint is the wp type scripted.
  Therefore i've made the very first waypoint of a unit type scripted.
• Script (started by normal waypoint placed right on top)
• OnActivation field of a waypoint

Point of the test was:

In which order these aspects become executed.
This is an important information when it comes to initialise variables/arrays/scripts or
any other important events when mission starts.

Here are the results of the tests in ascendending order (most top gets executed first and
most bottom gets executed last):

- East unit's init field
- West unit's init field
- Resistance unit's init field
- Civilian unit's init field
- Gamelogic's init field
- Empty Object's init field
- Script (started from init field)
- Init.sqs
- Script (started from init.sqs)
- Trigger (condition true)
- Script (started by waypoint scripted)
- OnActivation field of a waypoint (placed on top of unit)
- Script (started from onActivation field of a waypoint)

Now something weird occured too;

Two times the trigger became executed last.
The only thing i can say about it is:
It happened after changing something in editor
e.g: delete a waypoint or a group here and/or add a waypoint
or group there.

I could not recreate the triggers execution at the end by
intension but i can confirm that it was not just a imagination
(i thought that first), because it happened twice (though not twice in a row).

Now i've also tried to test same type of waypoints on several
groups which ended in the result that: first group being placed, first waypoint being executed,
but still along those results shown above - East first then West, then Resistance,
followed by Civilian and at last Gamelogic's waypoints.

----------------------------------------------------------------------------------------------------------------------
                                                        end of initialisation tests
----------------------------------------------------------------------------------------------------------------------

Now part two of my tests:

Trigger list:

As you all know, a trigger with a radius features a list of units which do match with the
trigger's activation condition.

This means: a trigger of size: 300/300 / activation: WEST / present / once or repeatedly (doesn't matter)
features a list of all west units inside the trigger area whenever you use the command: thislist from within
the trigger, or list triggername.

My tests were about how this trigger list is built up at mission start with units already inside.

Therefore i've made a trigger: 550/550 activation: anybody/present

First try:
player (west)
east soldier
resistance soldier
civilian
gamelogic

The result was along the initialisation results as stated above:

- West
- East
- Resistance
- Civilian
- Gamelogic

Now i enhanced the tests by adding another East unit and placed it
far away from the others.

This i did because i figured out that in the config the units are defined
that way:

#define TEast 0
#define TWest 1
#define TGuerrila 2
#define TCivilian 3
#define TSideUnknown 4
#define TEnemy 5
#define TFriendly 6
#define TLogic 7

This made some sense in combination with the results i got
from the initialisation testing and how the trigger list was built.

Now i thought about the aspect: SideUnknown

So i thought that the East unit being placed far from
trigger's center AND out of sight of player could receive
the status: SideUnknown.

The result was:

- West
- East
- Resistance
- Civilian
- Gamelogic
- East (the unit being placed far away)

Now to confirm that i exchanged the two east units
locations and the result was:

- West
- East (the one which was formerly far away and now close to the center)
- Resistance
- Civilian
- Gamelogic
- East (the one which was formerly close and now far away from the center)

I later found out that moving units around and changing
positions in relation to the player and/or the trigger's
center everytime has taken some influence on how the
trigger's list was built up.

At the end i couldn't find out why or how the trigger's list
was built up that way but i will not give up finding out - *hint* here's
the point i would like others to join my tests to find that out too,
since this is making me get headache a little bit. 

~S~ CD

[h-]

Just thought I'd ask whether you tried changing the side of the player while doing those trigger tests?
It may be a factor..

[Chris Death]

Good point mate - will add that to the trigger investigation.

I didn't think about it yet because of the so different results i got
until now when changing positions of the units.

Although the results are very confusing and it might be very complex
to find a key rule of how the list is built, but player's side is for
sure an aspect i'm gonna have to investigate too. 

To everybody who would like to join the testing - i forgot to mention
the method i was using ('cause it's not that hard and even the not
so good scripters can do this).

Trigger: 500/500
Activation: Anybody / present / once or repeatedly (doesn't matter)
Name: TriggerA
Condition: this

Trigger: 0/0
Activation: Radio-Alpha / once or repeatedly (doesn't matter)
Condition: this
onActivation: hint format ["%1",list triggerA]

Now start placing units E/W/R/C/Gamelogic inside the first trigger's
range and preview the mission.

Hitting Radio-Alpha will show you the list of triggerA in ascendending order.

When moving around the units like i described above you should notice
soon that the organisation of triggerA's list will be different by that.

~S~  CD

[Mandoble]

Quite interesint 

And now what about init fields of empty objects? 

Lets say you have three of them, a house, a table and a computer. You want the table inside the house and the computer above the table. If you use init fields with setPos of each object related to other object pos, while everything might be ok from the editor's preview, in most cases it is a disaster from exported mission. I also suspect the stack of objects within the editor changes each time you edit one of them and click ok. In the very first second of the missions I experienced so many weird effects when using init fields of units/objects using data of other ones that I ended up using one of two: a gamelogic with a single waypoint with a wait of 1 second, and initilizing things in its activation field or in the init.sqs after a ~1.

[Chris Death]

And now what about init fields of empty objects?

Well, each cathegory gets executed by the FPFE method in itself. (Firs Placed First Executed)

Let's say: 5 east units and 5 west units

The 5 east unit's init fields get executed before the 5 west unit's init fields.
Which east unit's init field get executed first depends on the order in which
they were placed. The first east unit being placed gets executed first and the
fifth east unit is number five when it comes to execution.

The same goes for empty objects - first empty object being placed gets executed
first.
Now you can figure out on your own, why there are sometimes weird results, when
setposs'ing objects by using getpos information of other objects. 

The stack of objects in editor doesn't change about initialisation - if you delete a unit
and add a new one, the new one will be last in the list.
If you change something on the unit, it will still be in the same position of the execution
order.

~S~ CD

[Mr.Peanut]

Just posting to emphasize that these effects are not necessarily the same in MP. In MP, the init.sqs is most definitely executed first, and units' init fields after the game begins.

Another thought. Try exporting the mission to SP and see if the results are the same.  My experience has been that the preview does not behave the same as the actual mission.

[Chris Death]

Just posting to emphasize that these effects are not necessarily the same in MP. In MP, the init.sqs is most definitely executed first, and units' init fields after the game begins.

I don't think so because:

Until a few weeks ago i've been in the meaning that init fields of units become
executed in order of first unit being placed = first init field being executed.

Then i found out that this is not true by trying to initialise an array from the
first unit's init field i've placed onto the map (a West unit) and adding other
units by their init fields to this array (West and East units).
Now the result was that the East units weren't added to the array which made
me stunning.

When i encountered this i was helping a guy with his money script problems and this
was for multiplayer. This was a multiplayer mission and because of respawn i was
working in mp aswell on that. The init.sqs was executed after the unit's init fields
in this case.

First i did suggest to initialise his player array in init.sqs and add the units to the array
by init field. This didn't work because the array got initialised afterwards and thus
the units didn't get added as the array didn't exist when init fields were executed.

Another thought. Try exporting the mission to SP and see if the results are the same.  My experience has been that the preview does not behave the same as the actual mission.

That's a good point. 

Gonna have to setup a more complex mission to test so that i only need to export it
once and not everytime i want to find out the next candidate of the list.

~S~ CD

[Mandoble]

My experience has been that the preview does not behave the same as the actual mission.

And mine.

[Chris Death]

Well, that's why this post exists now.

Actually everything is based upon some experiences without going deeper
inside to find the reason me thinks.

I noticed very often that when having a problem ppl tend to try it on another
way and if that works the initial way is forgotten or considered to be buggy.

Maybe your/our experiences with the differences were based on other circumstances
which nobody explored in detail.

As i said, i will test the initialisation behaviour in exported missions to as i will do
it again in multiplayer (preview and exported / ded. server and non ded. server).

I would not mind if someone else starts testing too *hint* to double or counter
my test results - four eyes often can see more than two. 

It's not difficoult tho - you just use a numeric variable which you will give a different
value from each initialisation method - in mission you display the value of the variable
by hint format and voilla - the value which returns points you to the last executed
method. Then you write this one down and remove it to see who's the next one. 

~S~ CD

[Mandoble]

I'll do your test later, now I'm too far away of any computer with OFP. Meanwhile, and if you have OFP ready, you may try the following:

A single mission with four units, one per side, named u1, u2, u3, u4.

Code: [Select]

;init.sqs
rating = 1000
rating = 2000
rating = 3000
rating = 4000
rating = 5000
rating = 6000
rating = 7000
rating = 8000
rating = 9000
rating = 10000
rating = 11000
rating = 12000
rating = 13000
rating = 14000
rating = 15000
rating = 16000
rating = 17000
rating = 18000
rating = 19000
rating = 20000
exit

init field of each unit:
this addRating rating

Then a single gamelogic with a single waypoint with a delay of 1 second, in its activation field:

Code: [Select]

hint format["%1 %2 %3 %4", rating u1, rating u1, rating u3, rating u4]

This is what I suspect,
init.sqs is executed as a anyother script once the mission is loaded in memory. After launching init.sqs, everything else is initialized in the mission. But init.sqs needs to loaded from disk and then executed like a thread, its first statements would be executed at or near the same time of anyother init field of present units. But these statements are executed one after another, so some init fields of some units may be executed before some statements of init.sqs.

So, perhaps you will get different ratings per each of these units in the test.

[Chris Death]

This is what I suspect,
init.sqs is executed as a anyother script once the mission is loaded in memory. After launching init.sqs, everything else is initialized in the mission. But init.sqs needs to loaded from disk and then executed like a thread, its first statements would be executed at or near the same time of anyother init field of present units. But these statements are executed one after another, so some init fields of some units may be executed before some statements of init.sqs.

May i remind you on my first post? 

Initialisation test:


The following events i've taken into consideration when starting my tests:


East unit's Init field
West unit's init field
Resistance unit's init field
Civilian unit's init field
Empty Object's init field
Gamelogic's init field
Trigger (with condition: true)
Init.sqs
Script (started from init field of a unit)
Script (started from init.sqs)
Script (started by waypoint scripted)
:note - wp scripted scripts execute once a unit's next waypoint is the wp type scripted.
Therefore i've made the very first waypoint of a unit type scripted.
Script (started by normal waypoint placed right on top)
OnActivation field of a waypoint

Point of the test was:

In which order these aspects become executed.
This is an important information when it comes to initialise variables/arrays/scripts or
any other important events when mission starts.

Here are the results of the tests in ascendending order (most top gets executed first and
most bottom gets executed last):

- East unit's init field
- West unit's init field
- Resistance unit's init field
- Civilian unit's init field
- Gamelogic's init field
- Empty Object's init field
- Script (started from init field)
- Init.sqs
- Script (started from init.sqs)
- Trigger (condition true)
- Script (started by waypoint scripted)
- OnActivation field of a waypoint (placed on top of unit)
- Script (started from onActivation field of a waypoint)

See yourself, when init.sqs gets executed and think about your idea once more. 
:note - btw - maybe i made a mistake when saying it's in ascendending order because
it's in posted descendending order. 

The most top event (East unit's init field) gets executed first and the most
bottom one (Script started from onActivation field of a waypoint) gets executed
last.

:edit - btw - thanks for your offer to start testing on your own too - mucho appreciated. 

~S~ CD

[Mandoble]

Did your test and did mine, your conclusions seems to be right in both cases 

[DeanosBeano]

 whilst your on this subject ,i found something weird too about init.

  if i place an object in the editor and setpos it using the init field everything is fine.
 but if i try to edit the mission .sqm and copy and paste the setpos there.
 altho it does setpos the object on the map .
 1 it dosent show the code in the initfield in the editor when clicked on
 2 it always returns the height of the object as 0 when i try to retreive its x,y,z co-ords

 weird huh ?

[h-]

You obviously did something wrong there because when I tried it it worked just fine..

1. Put a soldier (player) and two ammo crates on the map
2. Wrote this setPos [(position this select 0),(position this select 1),10] in the other ones init field -> saved the mission
3. Preview -> the crate was placed in the air
4. Opened the mission.sqm and copy pasted the init from the first crate to the second and altered the z value a bit -> saved the document
5. loaded the mission in the editor; both crates had the inputs in their init fields and when previewed both were set up in the air
Step 5 is essential because OFP doesn't check if the mission.sqm has been updated so when you edit the sqm outside OFP you need to 'realod' it before the changes take effect..


The mission.sqm (from the relevant parts)

Code: [Select]

class Mission
{
randomSeed=4695555;
class Intel
{
};
class Groups
{
items=1;
class Item0
{
side="WEST";
class Vehicles
{
items=1;
class Item0
{
position[]={9956.440430,26.730000,3905.439697};
id=0;
side="WEST";
vehicle="SoldierWB";
player="PLAYER COMMANDER";
leader=1;
skill=0.600000;
};
};
};
};
class Vehicles
{
items=2;
class Item0
{
position[]={9952.804688,26.730000,3929.259033};
id=1;
side="EMPTY";
vehicle="ReammoBoxWest";
skill=0.600000;
init="this setPos [(position this select 0),(position this select 1),10]";
};
class Item1
{
position[]={9968.294922,26.730000,3929.259033};
id=2;
side="EMPTY";
vehicle="ReammoBoxWest";
skill=0.600000;
init="this setPos [(position this select 0),(position this select 1),15]";
};
};
};

EDIT:
As for the init.sqs not being executed first, to me that is obvious...
How else would you execute all kinds of list my_trigger etc. things from the init.sqs if it was executed before the trigger and units placed on the map are initialised..

[DeanosBeano]

 hmm how very stange.

 here is my sqm init that i pasted
 

Code: [Select]

init="this addeventhandler [""Hit"", {_this exec ""hole.sqs""}];this setpos [(getpos this select 0 , getpos this select 1,3.9)];"; only thing i see different is the brackets where your height is set outside the last  )

 now ya freaked me out lol. ofcourse you also answered my question. because you have managed to get your code to appear in editor init and i havent , then it would appear the mission sqm dosent pass that info on after the init , but the init field in the object does ?

 i have reloaded the mission each time, like i say all works well, but it dosent show the event handler or setpos in the objects init field ,altho it works and the height is set .

  have you done a hint format x,y,z on both crates and does it return all correct ? i would predume yours does cause its in your init field :9.

 i think your right i done something really weird.

 ah i got it .pls ignore me i am talkin sh.t as usual, i remembered now that i setit by changing the middle figure of the pos in some of the objects, not by setpos code thats why theres nothing in the init also i put some with killed eventhandler so thats why the height is 0 .
 foolish man i am.

  v.sorry

 

 

[Chris Death]

As for the init.sqs not being executed first, to me that is obvious...
How else would you execute all kinds of list my_trigger etc. things from the init.sqs if it was executed before the trigger and units placed on the map are initialised..

Well by that logic i've seen it also that way, but i couldn't tell before testing, when exactly it
gets executed now could you? 

Just for example: the script started from init field of a unit - i've never thought about
that it becomes executed before init.sqs because i didn't know.

~S~ CD

[Mr.Peanut]

My comment about MP was from personal experience. In the init fields for some east units (that I most first in the editor) I had a couple simple lines to add sidearms, mags, and nvg. On the server, they did often did not get any for at least 60 seconds.  When I instead did this with a script called from the init.sqs, they always got them.  I guess this is similar to what has been stated: their init fields were being processed last. I still think it is best to initialise units from a script  (or better yet, a function) called from the init.sqs.  If you have many units, and have to go back to change the init field for each of them either in the game editor or a text editor, it is quite a nuisance.  It is much easier to change a single script.

I have had long discussions with both CrashDome and UNN about the use of PV near a mission start.  From these discussions I was lead to believe the the init.sqs starts being processed as soon as the briefing screen loads.  If it is very long and complicated and everyone greens up very fast, it may not finish processing before the mission starts. Also, a ~ in the init.sqs will pause it there until the mission starts. A ~ in a script called from the init.sqs will pause that script until the mission starts.

Maybe init fields are the same? The game tries to process them all as soon as the briefing screen loads, but if there are many units and long init fields, they may not all get processed before the game starts?

I won't insert my ramble about the PV command here... 

[Chris Death]

May i? 

I've tested what you said and i must say the result was not like you expected it to be;

Code: [Select]

_i = 0

#again

a = a + 1

?a < 500000 : goto "again"
I've put that in init.sqs and then started the map.
After player selection screen there was the usual 'get ready' message then followed
by a few seconds of 'sending data'.
Once i reached the briefing screen i quickly pressed enter to start the game and display 'a'.

It returned: 500000

When testing the same with any event which from my previous results gets executed
after init.sqs, the result was always the value of 'a' which came from the event after init.sqs.


You're right with the ~delay, because when testing this:

Code: [Select]

a = 20

~10

_i = 0

#again

a = a + 1

?a < 500000 : goto "again"
I again quickly started the game after the usual short loading without 'sending data'
and it returned 20.
After 10 seconds the game got frozen for 2 or 3 seconds and then it returned 500000.

Well, when testing with 5000000 i found me back to desktop (even with 2 gigs of ram) 

Since this stuff is all running local and doesn't require network traffic, it doesn't matter, how
many clients are connected - result will be everywhere the same.

Init.sqs without a delay will be finished before starting the game in every case. 

To use publicvariable or a delay in init.sqs is something not to recommend or better say
a 'must not' because that's not what init.sqs is for.

btw - there were at least 200 units deployed on the map, so this also doesn't make any
difference on the outcome.

But it's good to include every single thought or suspect into the testings like you did
Mr. Peanut, at least the spectrum of tests gets more wide and one day we really can
have a reference of what happens when (exactly).   

~S~ CD

[macguba]

one day we really can
have a reference of what happens when (exactly).   

Even if you never quite make it, please make sure you leave whatever you do find out in a nice summary form so that people can use it.  Thanks.