Some tips for addon scripter & mission designer

[uiox]

Hi,

I have script some code for the use of dialogs with an addon, it was hard and I have found some tips:

- The event init call in config.cpp is only on server side. (not test on a stand alone server, only hosting)

- If you want initialize a variable you do like this :

If  (format ["%1", MyArray ] == "scalar bool array string 0xfcffffef")  then { MyArray = [] }

- You can build array with public variables like this:
For build it in server or client

If  (format ["%1", MyArray ] == "scalar bool array string 0xfcffffef")  then { MyArray = [] }
_obj = _this select 0
MyArray = MyArray + [_obj  ]
_ID = (count MyArray) - 1
PubArrayIndex = count MyArray ;publicvariable "PubArrayIndex"
Call format [ "PubArray%1 = _objDrone  ; publicvariable {PubArray%1}",_ID ]

And use it in a client or server

MyArray = []
_i  = 0
#BuildArray
_Temp = Call format [ "PubArray%1",_i   ]
MyArray = MyArray  + [_Temp ]
If (_i  < PubArrayIndex - 1 ) then {_i = _i +1 ; goto "buildArray"}

This sample is for init, if you want a real time update array you add a public variable update and you manage the array in loops for looking changes in the array, if yes set the update boolean to true and start a build array sequence.

With this 2 tips you can know how many of specific addons are on the map, and manage them.

- You can use event for starting a script, some events are executed on all computers (obj setdammage 0.001 start the script)

Hope this help someone  

[Tactician]

Are you sure an init eventHandler only activates on the server?  Or just where the unit is local?

[uiox]

I'm sure after a hosting test, cause I use this method for a UAV script, for the moment it is in beta testing, and after this I will be compltly sure.

I have a loop server side with player globalchat in it, starts by client side you see only on server side the message, so the loop can't be local side.

[Tactician]

Vehicles are always server-side unless a player is driving.  Have you tested an init eventHandler on a soldier that was being played by a remote human?

[uiox]

Oh you make me think to the cross init, for what I say it's for empty addons (uav it's necessary)

[Dinger]

This method works, and works well. (This is how we kept track of CoC_Mines, with, well sure, certain minor differences).  But init EHs only fire locally.
If you have a unit in the group of a remote player, that init EH will not fire on the server.  You _might_ get some interesting synch problems, but that depends on how OFP works in MP (read: test that bridge when you get to it).

What I'm interested in uiox are the possibilities for loading dialogs into addon.  I am in fact working on a system that uses this MP registering trick and a few others for a highly flexible on-map artillery system.  Have you gotten around the description.ext limitation ?  And in any case, how "generic" can a predefined dialogue be? My current hint/action system allows each addon to specify its own display and menu structure.  In theory, this system would allow MP control over practically anything.
Is it possible to specify a "tabula rasa" dialog, and then "in mission" create one according to needs?

[uiox]

Some other tips around MP for addon:
The name:
The object variable on server side 1675ce00# NOID CLASSOFADDON
The object variable on local side 1675ce00# NOID CLASSOFADDON REMOTE

I have done some test with call fonction but not possible, some test with string (call format ["%1",call format["%1",Object + " REMOTE"]] ) not possible all of this == bugs.

With this you can understand how OFP manage objects for a MP session.
On local side names of objects are differents, so if you apply to it a command in local the object has remote in end, BUT if you have store the names without remote (server side names), if you put it in line of code maybe (conditionnal cause I don't explore this way) you will have something like a public command.
In fact there is TWO inits one without remote, one with remote, don't test yet this way, have to confirm, not need, it's the problem of "start and get back" or desynchro, you give an order to the remote object, and immediatly after server set the object to the value of the server database.

For dialogs I have to do some test cause I have some strange effects with addons with same name of dialog and class name. Some other with files chain with #include, cause next months a lot of addons with dialogs will out.
This creates bugs, but bugs are sometime the path to a tip, and after debugging & release of the addon, it's the time of discover tests...

[Dinger]

alors:

The name:
The object variable on server side 1675ce00# NOID CLASSOFADDON
The object variable on local side 1675ce00# NOID CLASSOFADDON REMOTE

I have done some test with call fonction but not possible, some test with string (call format ["%1",call format["%1",Object + " REMOTE"] ) not possible all of this == bugs.

Are you sure that's what the object is called remotely?  could it be: [1675ce00# NOID CLASSOFADDON, REMOTE] ?
I vaguely remember remotes being some sort of array.

With this you can understand how OFP manage objects for a MP session.
On local side names of objects are differents, so if you apply to it a command in local the object has remote in end, BUT if you have store the names without remote (server side names), if you put it in line of code maybe (conditionnal cause I don't explore this way) you will have something like a public command.
In fact there is TWO inits one without remote, one with remote, don't test yet this way, have to confirm, not need, it's the problem of "start and get back" or desynchro, you give an order to the remote object, and immediatly after server set the object to the value of the server database.

If I understand what you're saying here:

The problem is that most commands issued to a remote object are ignored.  Some are transmitted, but not all of them.

For each object in MP, there are two "names".  There is the "real" name, on the client (1675ce00# NOID CLASSOFADDON), and the "remote" name, on all the others (1675ce00# NOID CLASSOFADDON REMOTE).

Your hypothesis is that if a client can address an object by its "real" name, even if the object is not on that client, it will be able to affect it as if it were local.

Here are what I see to be the problems:

I. Names like 1675ce00# NOID CLASSOFADDON cannot be accessed from OFP scripting.  They're purely internal (like: WEST Alpha Black: 1).

II. "Remote" may serve to discard some signals, but it's probably also a means by which OFP knows to transmit state information to the local machine.  If we take away "remote", wouldn't we in effect be treating the object as if it were local on our machine, without affecting the machine that has the object as local?

or have I misunderstood you?

For dialogs I have to do some test cause I have some strange effects with addons with same name of dialog and class name. Some other with files chain with #include, cause next months a lot of addons with dialogs will out.
This creates bugs, but bugs are sometime the path to a tip, and after debugging & release of the addon, it's the time of discover tests...

addons with same name of dialog and class name? You mean, as if the config.cpp class were interfering with the function of the dialogue?  Would this suggest that OFP was looking in the config.cpp for the dialog information (and if this is indeed the case, don't keep the infos to yourself )

so the description.ext
#Include "mysetofdialogues.sqh"
presents some problems?


well, we hope to get a beta version of our stuff out soon, sans dialog (action+hint), and maybe that will help spur further discussion.
 

[uiox]

Sorry something is wrong. The "names" are completly different, I have done a test with setpos on local side, this works:

Name without remote setpos [0,0,0]
Name with remote setpos [0,0,0]

with 2 difeerent addons, they go to the position 0.

Now I have to test this with an AI, with some commands only start on server side but call on local side, if this works you need only server side "name" of objects for doing moveto,etc...

For dialogue they are loaded when OFP start for addons. The strange bugs I didn't note them and I don't remember exactly what it is it. So I have to test.

[Rubble_Maker]

Hi Dinger, could you explain what "remote units" are?

As far as the dialogs, I think the only way is to have the player copy&paste something like

#include <addonname\bla.h>

to his description.ext. I'm also working on a mp-compatible dialog script, and so far it works fine with this method.

[Dinger]

"remote unit" = a unit that is local to an instance of OFP other than the one currently running.

My dialog issue is the following:
I'm working on  a unified indirect fire package, where every indirect fire asset (=mod or in the unified mod) can specify its interface.  For hint screens and addaction menus, this is easy to do.  The question is: can you have a generic mod reference, possibly one included in a description.ext, that allows you to create any dialog you want from an array?

[Rubble_Maker]

not sure I understand correctly, but generic dialogs are not problem I think. Make one with all graphics components you could possibly need, and switch them on/off using ctrlShow; the text can be added on the fly using ctrlSetText.
that way all mods could use the same generic dialog, and configure it as they need it. Even the color and background pics can be added on the fly, so no need to have each mod keep its own dialog definition; just do this via scripts.

Another q: As long as I launch my scripts from EH and add-actions (that are defined in config.cpp) I'm relatively save as far as synchronisation, right? Both EH and addactions are automatically run on all machines?

Quote

"If you have a unit in the group of a remote player, that init EH will not fire on the server"

So that init EH will run only on the machine where the unit is local right?

[uiox]

Sorry something is wrong. The "names" are completly different

False they are identical, and I'm wrong with the init sequence there is two inits one local, and a server side.

For dialogs I don't understand your problem. If you do a real arty script, you need a chief of battery, and some pieces.
For an arty armored it's easy, you have only one piece, so the values in dialog are easy to broadcast.
But for many pieces I don't have the tip for the moment for knowing how many pieces the battery has.

The solution is in addonner side, an addonner can solve the problem, the battery is an addon compose of 5 pieces, and you know when init start the id , pos and dir of each pieces.
For manage this only a chief of battery and only one dialog.

[Dinger]

RubbleMaker: quite the opposite.  Init EHs and Addactions are both local-only.  THey don't work across MP.

For dialogs I don't understand your problem. If you do a real arty script, you need a chief of battery, and some pieces.
For an arty armored it's easy, you have only one piece, so the values in dialog are easy to broadcast.
But for many pieces I don't have the tip for the moment for knowing how many pieces the battery has.

The way I'm doing it this isn't a problem.  With the howitzers I'm doing away with the "chief of battery" (FDC unit), and only doing the guns.  I have a double registration system: individual units register (CoCIFunitN), and "assets" register (CoCIFAssetN).  Each unit has an init EH that runs a "handler" script.  For some things (like the MLRS, a cruise missile launcher), a unit will be an "asset"; for others (like the m109), all the units in a group will be an "Asset".  So if you put four M109s in the same group, four init EHs fire, starting four scripts.  These scripts register each 109 as a "unit", look around, and determine how many howitzers are in the group.  One script registers the group of four m109s as an "Asset".

The master program on all clients loads in the units and the assets.  For each new asset type, it loads in an interface specific to that asset.  So broadcasting "dialog" type isn't necessary.

In this way, a single control script could be used in MP to acquire and control everything from mortars to cruise missiles to uiox's UAV.  But I don't know much about dialogs.

[uiox]

If I undstand you need a dialog with an update of informations in it, one part for collect orders, an other one for give orders.
If it's this, I have done.
Sorry, if I don't understand yet, it's always the same problem: language.