"init" addeventhandler

[Doolittle 0]

Does anyone have an example of obj addEventHandler ["init", ...]??  And why was it so great that BIS made "init" work on all computers in MP?  I don't understand how this new 1.92 feature works or when to even use it.  Once I createVehicle something, isn't THAT its "init" time??  How could you possibly assign an event to an object such as "init"??  The object has to already exist in the universe to begin with!

More confused than he should be,

Doolittle

[canukausiuka 1]

I think that the most useful application of the init eventhandler is to start a script for that unit, without having to have the mission editor add it themself. I'm not sure though, as I've never used one myself.

[RED 0]

We at the ECP (was called the super config project ages ago) are using the init eventhandler to add effects automaticaly to units, when a unit is spawned on the map the effects will be added to the unit. It is good that the init eventhandler is run on all clients, this removes some complications like having to activate scripts that will run on all clients from the original init fired script.

I hope that made some sense to you.

RED

[BraTTy 0]

Also every addon for example that has hidden selections, needs to run a script to set the textures initially on all machines.The way that the "init" eventhandler was operating before was that only the server was running the script in a mp game

Fixes the problem we were having in this discussion

http://www.flashpoint1985.com/cgi-bin....t=27718

Cheers to Bis!

[hoz 0]

Question: Does this mean we now don't have to code the mpgame=true options and add scripts to each unit for MP play now? Can I do away with them? In particular the BAS choppers?

Hoz

[raedor 8]

this feature makes it possible, that you can make random numbers in mp (not with an animation, but with setObjTexture!) working, means that one tank has on all clients the same number.

you'll see this soon: on rhs T55 pack!

[BraTTy 0]

The Corsair F4U now doesn't need the init line for mp maps (altho has some extra stuff now I could take out)

It fixed my Helldiver as everything was running from the "init" eventhandler

Fixed the towing pak36 for mp maps

If the addon needed a init line for ONLY mp maps,chances are it doesn't now,depending on how it was scripted

[BraTTy 0]

Does anyone have an example of obj addEventHandler ["init", ...]??  And why was it so great that BIS made "init" work on all computers in MP?  I don't understand how this new 1.92 feature works or when to even use it.  Once I createVehicle something, isn't THAT its "init" time??  How could you possibly assign an event to an object such as "init"??  The object has to already exist in the universe to begin with!

More confused than he should be,

Doolittle

The "init" eventhandler is the one that is in the config.cpp and only can be used on addons that has a cfgvehicles section.

This will be called default when the mission is first started and the mission maker cannot change this eventhandler (dont think you can even remove it)

Will also run using createvehicle command without any intervention from the scripter (mission maker)

I am not sure about the command addeventhandler "init" as that is not much use to me

Messages above state their importance and uses and heres and example:

class EventHandlers

{

gear = "if (_this Select 1) then {[_this select 0,0] exec ""\brt_sb2c\gear.sqs""} else {[_this select 0,1] exec ""\brt_sb2c\gear.sqs""}";

init="[_this select 0] exec ""\brt_sb2c\manager.sqs""";

};

And it calls my manager script that needs to set some textures on all machines and my smoke scripts that now run on all machines!!

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

some of my old Helldiver manager.sqs

_plane = _this select 0

_plane setObjectTexture [0,"\brt_sb2c\wingbrakes.paa"]

_plane setObjectTexture [1,"\brt_sb2c\tail.paa"]

_plane setObjectTexture [4,"\brt_sb2c\gear.pac"]

_plane setObjectTexture [5,"\brt_sb2c\grn.jpg"]

? getpos _plane select 2 > 10 : goto "raisegear"

goto "cycle"

#cycle

? (driver _plane) in _plane && (driver _plane) != player && behaviour (driver _plane) != "SAFE" && ((_plane animationPhase "bbayla") < 0.5) : goto "openbbay"

? (driver _plane) in _plane && (driver _plane) != player && behaviour (driver _plane) == "SAFE" && ((_plane animationPhase "bbayla") > 0.5) : goto "closebay"

_pdamage = (getdammage _plane)

?_pdamage > 0.3 && alive _plane : [_plane] exec "\brt_sb2c\ltsmoke.sqs"

?_pdamage > 0.4 && alive _plane : [_plane] exec "\brt_sb2c\ltsmoke.sqs"

?_pdamage > 0.5 && alive _plane : [_plane] exec "\brt_sb2c\medsmoke.sqs"

?_pdamage > 0.6 && alive _plane : [_plane] exec "\brt_sb2c\hvsmoke.sqs"

?_pdamage > 0.7 && alive _plane : [_plane] exec "\brt_sb2c\xsmoke.sqs"

?_pdamage > 0.8 && alive _plane : [_plane] exec "\brt_sb2c\ltsmoke.sqs"

?_pdamage > 0.9 && alive _plane : [_plane] exec "\brt_sb2c\medsmoke.sqs"

? (_plane animationPhase "foldwings") >= .03 && (speed _plane) > 60 : [_plane,1] exec "\brt_sb2c\foldwings.sqs"

~1

goto "cycle"

[hoz 0]

bump BAS?

[denoir 0]

Cheers to Bis!

Hmm, yes, it would have been "cheers to BIS" had the init EH been global when it was first introduced. Right now it probably does more damage than good since there are a lot of addons out there that don't work properly in MP now as they rely on the init EH being local.

This is especially true for all addons that use some form of setVelocity or setPos scripts. These should be run on one client only and then let OFP to synch with the rest. If you use it on every client, OFP gets confused and you get some serious lag in the velocity and position updates.

[BraTTy 0]

Update..I forgot one very important thing that the global "init' also fixed... now when someone "createvehicle" the init will run and allow global scripts still

[suma 8]

Right now it probably does more damage than good since there are a lot of addons out there that don't work properly in MP now as they rely on the init EH being local.

This is especially true for all addons that use some form of setVelocity or setPos scripts. These should be run on one client only and then let OFP to synch with the rest.

I understand this point and we were really unsure if we should fix this bug or leave it unfixed. We dediced fixing it is better option.

I am not sure how many addons will be working bad after this fix, but it should be relatively easy to fix them to be 1.92 compatible - all you need is to use "local (_this select 0)" condition in the eventhandler code to execute the handler only locally.

[dinger 1]

sure, but for that one line fix to occur:

A) someone has to do it -- in some cases the authors are no longer with us.

B) it has to be downloaded to everybody

now, the $60,000 dollar question is "how many addons are we talking about here?"

As for myself:

Looking at the scripts for CoC_mines, the addons should work with 1.92, but with added degradation of performance at mission start (since every client will think it's the server and PV the mines). If 1.92 MP start-of-mission synchronization is like 1.91, this could mean some interminable "receiving data" pages, and in some cases, failure of the MP game to load.

Of course, we do need to revisit CoC_Mines to make some optimizations anyway.

CoC Unified Artillery works equally well in 1.91 and 1.92 beta.

[bn880 5]

The CoC Network Serivces will also have to be revisited, but this is a welcome change over the fuel EH or adding init line in mission editor manually. (better if the problem had never existed, but hopefully in OFP2 everything will be more predictable)

[Romolus 0]

now, the $60,000 dollar question is "how many addons are we talking about here?"

Honestly, how many addons are regularely used on servers that are using scripts that could have problems with 1.92 and the author isn't around anymore?

I really don't think that it's that much.

And I would rather change all the BAS scripts than not having the init EH changed in 1.92!

I mean that's what we all wished for a long time and now you don't want to have it anymore?

Come on  

[Bullz_eye_on_my_back 0]

I welcome this fix! Before the fix was out I had already started creating several addons that would implement the "init" on MP missions and now I don't have to worry about it only being executed on client side . Hopefully I can get them out there for everyone in the WWII community, but I'm lacking any textures for them. I've got about 7 addons tested and waiting for textures

[uiox 0]

I welcome too this fix...

But some guys use this before the fix for having a only server side loop. If they don't know how do now:

If (!(format["%1",player] == "<NULL-object>" ) ) then {exit}

For dedicated server only of course.

[killswitch 19]

I welcome too this fix...

But some guys use this before the fix for having a only server side loop. If they don't know how do now:

If (!(format["%1",player] == "<NULL-object>" ) )  then {exit}

For dedicated server only of course.

Problem: player is "<NULL-object>" during a SP intro or outro too, so that method isn't 100%. Lets say that one wishes to use that method in an addon init event handler to disable some graphical and/or unwanted features on an addon, features that would only eat CPU on a dedicated. For example, visual effects stuff need not be run/genererated on a deddy, but in an intro, one may want it.

@hoz: No, the fact that the init event is broadcast in 1.92 does not mean that you don't have to take special care with current BAS addons in MP.

However, I assume BAS and others will rework much of their addon scripting in order to eliminate some of the "MP workarounds", where possible. So in the future, with newer versions of a lot of addons, it may be possible to "just use them" or at least with less work from the mission designer's side.

[uiox 0]

I welcome too this fix...

But some guys use this before the fix for having a only server side loop. If they don't know how do now:

If (!(format["%1",player] == "<NULL-object>" ) )  then {exit}

For dedicated server only of course.

Problem: player is "<NULL-object>" during a SP intro or outro too, so that method isn't 100%. Lets say that one wishes to use that method in an addon init event handler to disable some graphical and/or unwanted features on an addon, features that would only eat CPU on a dedicated. For example, visual effects stuff need not be run/genererated on a deddy, but in an intro, one may want it.

@hoz: No, the fact that the init event is broadcast in 1.92 does not mean that you don't have to take special care with current BAS addons in MP.

However, I assume BAS and others will rework much of their addon scripting in order to eliminate some of the "MP workarounds", where possible. So in the future, with newer versions of a lot of addons, it may be possible to "just use them" or at least with less work from the mission designer's side.

For solve designer problems, scripters create entrey points to the scripts.

I have create a method for entrey points of events, but not test one for init event...

soemthing like this:

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

;**********Event Fired

_TheAddon = _this select 0

_Weapon = _this select 1

_Muzzle = _this select 2

_Mode = _this select 3

_Type = _this select 4

_AddonUnitTag = _this select 5

If ( format ["%1",call format ["%1HookFired", _AddonUnitTag ] ] != {scalar bool array string 0xfcffffef} ) then {If ( call format ["%1HookFired", _AddonUnitTag] ) then {[_TheAddon ,_Weapon ,_Muzzle ,_Mode ,_Type] exec format ["%1Fired.sqs", _AddonUnitTag ]}}

If ( format ["%1",call format ["%1HookFiredOverwrite", _AddonUnitTag ] ] != {scalar bool array string 0xfcffffef} ) then {If ( call format ["%1HookFiredOverwrite", _AddonUnitTag] ) then {exit}}

With this a designer/scripter can trap an event of your addon, you can test your event script without compact your addon again and again.

Conclusion: advanced scripts for addon - > advanced problems for designer

[killswitch 19]

Yep, that's a very useful addon editing/testing trick and all.

But why quote my message? I don't quite understand what it has to do with the problem of reliably detecting wether an init event handler is running on a dedicated server or in a single player intro/outro? Or how it in a general sense solves any "MP usage workarounds" that I mentioned, without naming any particular such MP-addon-problem.

Anyway...on with the thread...

[uiox 0]

I quote your post cause you are in the "heart"/"core" of the problem. Advanced addon script generates often problems.

For init command the fix increases the ways for solving the problems.

An I give the sample of entrey point for demonstrate the utility of global addon variable. Imagine if someone creates a canon with a real time projectile, he needs a lot of very advanced calculations for the addon they have done, why don't give them to the designer trought global addon variables? The designer could use them for solving specifics problem in a mission...

For the tip I have forgot this:

Config.cpp

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

{

Fired= "[ _This select 0, _this select 1,_this select 2,_this select 3,_this select 4, {YourAddonTagScript}] exec {\YourAddonName\Scripts\events\Fired.sqs} "

};

For use it in the mission folder:

If you set "YourAddonTagScriptHookFired" to true so the script "YourAddonTagScriptFired.sqs" in your mission folder will be executed.

The second test is for exit the event, because the script of the event is always placing after this line.