killswitch

Fair enough. Sorry about the slight detour. Now, back on topic: adding a fired event handler using an init event handler as hinted at in the "LAW/AT/AA RocketShockDust" example will, as noted, only work as intended with 1.92b and later versions. A suggestion, instead of doing <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ... init="this addEventHandler [""Fired"",{_this exec ""effects\RocketShockDust.sqs""}]"; ... why not just have <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ... fired="_this exec ""effects\RocketShockDust.sqs"""; ... in the addon. This will give a unit the desired fired event handler even in 1.91 and previous versions.

Mmm...dreaming of a nice new A10. Lots of different loadouts. Make sure to do a FAC version with WP rockets. And a "zoomed aiming view" like the DKM Bronco, the Mi-28 and some other aircraft has. <sarcasm mode> And add a lot of "useful" visual goodies that are activated through at least five to twenty different action menu items. Most important of all - do make sure to check that the "Eject" action cannot be reached unless you scroll down for ten  minutes. But hey, at least I'll have a friggin animated cigarette lighter in the cockpit. You know who you are, addon makers... </sarcasm mode>

In short: After a reload/resume of a game only one EH ever gets called. Also, spurious events are generated when they shouldn't be. Tested with: 1.91, 1.92 beta Summary <ul>[*]After a reload, only one of possibly many event handlers for a unit gets called, no matter what actual event ocurred. [*]The actual parameters for that EH call is the parameter list for the event that should be called. [*]The EH called is the first one found when going through the ordered list [init,Fuel,Gear,Dammaged,IncomingMissile,Fired,GetOut,GetIn,Engine,Hit,Killed] [*]The Engine event is being continously generated by AI vehicles even though it has stopped and shut down. Some xamples: Case 1: a unit/vehicle has one EH for the Fuel event, one for Engine and one for GetIn. After a save-> load/resume, the only EH that gets called is the Fuel EH, even if I GetIn into the vehicle or get out of it. If i get into the vehicle, the Fuel EH gets called with the parameter list that the getin handler should get, i.e. [vehicle, position, unit] If I start the engine, the Fuel EH is called with the params for Engine, i.e [unit,enginestate] Case 2: a unit has Fired, Hit and Killed EH:s. After a resume/reload, the Fired EH gets called whenever the unit is Hit or Killed. The fired EH gets whatever parameters the respective "actual" event generates. Case 3: an AI vehicle has a move waypoint somewhere. After moving, it will wait at that spot, engines off. What happens is that the vehicle moves to the waypoint, stops and (apparently, from looks and sound) turns off its engine. Then, a neverending stream of Engine events appears. On, off, on off (actually, true and false in the engine EH params). This is not affected by a save-reload/resume. Of course, after a reload, the actual engine EH may not be called if another EH that has higher "priority" according to the list mentioned is also attached to the vehicle. Note: during testing, the event handlers were added either from the init.sqs or the vehicles' init line. No difference. Thoughts, impacts As it stands, the usage of event handlers is...well...useless since one can not know if a certain event handler will be called properly after a reload/resume. Nor can one assume anything about the actual parameter list that a event handler gets - a Fuel EH might get the whole Fired EH parameter list, for example. Also, the "engine event noise" is a possible cause of great CPU load. Reference The order of event handlers above is exactly the reverse of the order of events listed in the command reference: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">   "Killed" object:killer   "Hit" object:causedBy,scalar:howMuch   "Engine" bool:engineState     "GetIn" string:position (1),object:unit   "GetOut" string:position (1),object:unit     "Fired" string:weapon,string:muzzle,string:mode,string:ammo   "IncomingMissile" string:ammo,object:whoFired   "Dammaged" string:selectionName,scalar:howMuch   "Gear" bool:gearState   "Fuel" bool:fuelState     "Init" No arguments (NB: the comref event list consistently lacks one parameter. Eg: Killed gets not only [killer] but [unit,killer] (victim and killer) Conclusion I believe the EH/savegame issue  to be a serious bug and would appreciate a fix for the 1.92 release. In the wider sense, this is but one of what seems to be many savegame issues left in OFP. For now, this is the only one I can reproduce. Here's hoping Suma sees this before it's too late...

I'll answer that with another two questions for you to ponder:<ul>[*]Could this possibly be a question many have asked before and is answered in some of the sticky posts above? [*]How would you go about searching these forums? (keywords: "pilot" and "eject")

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.

The OFPEC Blood addon/scripts as of ver. 1.41 do not use preloaded functions, nor do they use scripts larger than 4 kB in the way described by bn880, so that is not the problem. Can you describe in what way "OFPEC blood gives errors after a reload"?. It may be that what you believe is a error in the blood scripts is related to the savegame/event handling bug. @RED: In what way is the blood stuff "fixed" in the ECP?

1.93b? What? When? Where?

Indeed. Note that I was considering the situation just before someone gets into a vehicle, i.e when one may issue the moveInDriver. At that point, a vehicle is not neccesarily local to the same machine as the unit about to get "moveInDriver:ed". Afterwards, the vehicles "locality" is indeed get transferred to the driver's machine, just as you say.

SFP vs FDF finnish units: (80's robot voice) "does not compute" Finlands sak är vaar sak!  (Finland's cause is our cause!) (PS. How does one write an "letter a with a ring on top" on this board, instead of using "aa" as a substitute)

One has to be careful with the wording when discussing these client/server issues. Besides the client-server distinction, there is also the local-not local dilemma. An example: Commands that affect units should be run where that unit is local, be it on a client machine or on a server. To list some of the commands that have been mentioned as "client only" that should actually be done "locally", i.e where that unit is local:<ul>[*] setDammage, getDammage, setFuel, setSkill... [*] addWeapon, addMagazine and so on [*] setUnitPos, getPos [*] animate [*] action (ever had a paradrop fail in MP even though some script does action ["EJECT",plane] ) addMagazineCargo seems to be different from addMagazine, right? (The ammo crate example above has me wondering...) addEventHandler can/should be run on all machines that should respond to a certain event. One can imagine having only the machine where a unit is local run a certain event handler. Then again, since some events are broadcast, it may make sense to have all machines add an event handler to a unit, even though it might not be local. What I'm saying here is that the statement "addEventHandler must be run on a client" is not neccesarily true. Take the "killed" event, for example. As of 1.92 this event is not broadcast, so having a "killed EH" attached to a non-local unit would be pointless. moveInDriver: Interesting...since that command has two object parameters, I wonder which one of them controls where to run it. From Doolittles experiences it seems that the driver, not the vehicle, decides where to "run it locally". Another riddle is the setViewDistance command. This seems like a "client only" thing to do. However, the view distance also has an effect on the AI:s ability to see you. Therefore, my guess is that one would have to run setViewDistance even on a dedicated server. Imagine a open desert battle with client viewdists of 2000 m. Lets say this "setViewDistance 2000" was run on clients only. That has the server running with a view distance of 900 m internally. This would have any AI enemys somewhat "short-sighted". In essence: I don't think one can do a list of commands and categorize them as client and/or server side. The locality aspect has to be reflected too.

So that's where the SPF page has been hiding since the demise of axleonline... Excellent. Good looking stuff in the screenies! Take your time with the pack, we'll be here when its done... Â

BAS Rangers using the 10th MD arm patches as described in the readmes sounds like a possible solution.

Hear hear! How about the M992 support vehicle (used for resupply of SP artillery units, IIRC). I imagine it as a "ammo truck on tracks" in the OFP world. Likewise, the M88 recovery vehicle doubling as a "repair tank" Going the other way, add a ambulance truck. Or perhaps a ambulance bus. If you have ever watched the TV series M.A.S.H. you'll know what I'm looking for.

Have you tried having both types of "shrubbery"? As you say, it might look and feel strange, but if there's any chance at all that it might look acceptable, I'd welcome more concealing vegetation. Of course, #2 sounds nice. #3 will probably just lead to servers having the one most suited for the mindless hordes of 5-minute-PvP-respawn-fest players, i.e. the "looker variant". Thanks for considering our suggestions, Jakerod! The island looks real nice from the screenshots. Â

That was my first thought too. But trust me (and bn880)...or better yet test it. The whole enchilada is run on all machines. "Consistency in implementation and documentation" and "OFP" don't work in the same sentence.

I have been thinking a while about it and remembered this, as recited by Abraham Simpson (from "The Simpsons"): "I think Rudyard Kipling said it best: If you can make one heap of all your winnings and risk it all on one turn of pitch-and-toss, and lose, and start again at your beginnings, and never breathe a word about your loss, yours is the earth is everything that is in it, and, which is more, you'll be a man, my son." In essence: the American dream is: one can try, fail and keep on trying. The pursuit of happiness, in other words. Another quote that comes to mind is one I heard in a song by Beck: "Fake it 'til you make it." That this pursuit leads to narrow-mindedness, "looking out for number one" is the dirty flip side of the coin.

Looking at the screenshots, I'll second Avon's vote for more of the "old" vegetation that one can actually hide from the AI in. There's no "either or". Please have some of both types of vegetation, the "good for screenshots" Resistance kind and the usable "sneak up on unsuspecting AI:s" variants.

Noticed this today (1.92): code in the init parameter of a createUnit call seems to run on all machines and not only on the one where createUnit is called. E.g: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; somespawner.sqs ?!(local Server):exit ... ... "Man" createUnit [_pos, somegroup, {dude = this; [] exec "initstuff.sqs"}] ... ... will have the createUnit call run only on the hosting machine (due to the "local Server" check). However, from my testing, it seems that the init part, i.e. "{dude = this; [] exec "initstuff.sqs"}" will be run on all connected machines. This is different from 1.91, right? Or have I missed something? It makes some sense, though, now that the init event is broadcast in 1.92. And I like it. All we need now is for all events to always be broadcast... *cough* "killed" *cough*

Interesting... The official comref says this: ...which I, together with reports of differing event behaviours have interpreted as follows: <ul>[*]The "Killed" and "Hit" events are not broadcast [*]All other events are broadcast (to some extent, "fuel" being one example) About the "Fuel is broadcast to objects within a certain range" - does that mean "fuel events are broadcast to those client machines that have units local to that client (such as the player or AI:s under his/hers control) close to the vehicle the event originated from?

Done. Here's hoping they'll see it and agree on that it is worth fixing.

Or, simply ditch the goto:s and do <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _tank= _this select 0 _r=random 100 ? (Crewescape==0):exit ? (not alive _tank):exit ? (canmove _tank) and (canfire _tank):exit ? (Crewescape==2) and (canfire _tank):exit ? (Crewescape==3) and (canfire _tank) and (_r < 50):exit #getout ? (not (commander _tank  in _tank)):exit ~ 3+ random 3 _tank stop true ~ 3+ random 3 commander _tank leaveVehicle _tank ~ 0.5 + random 0.5 driver _tank leaveVehicle _tank ~ 0.5 + random 0.5 gunner _tank leaveVehicle _tank _j= (random 100) ? (_j > 50  && _j  <= 100):commander _tank allowFleeing 0;driver _tank allowFleeing 0;gunner _tank allowFleeing 0 ? (_j >= 0  && _j  <= 50 ):commander _tank allowFleeing 1;driver _tank allowFleeing 1;gunner _tank allowFleeing 1 exit

Excellent! One problem, though. That value is not present in the exp_init (or any other script) in GMR.pbo of the 1.42 beta....

<ul>[*]Large land areas. Big islands. 25.6x25.6 km. [*]Extensive road networks (more than one way to travel from A to C via B) [*]Ports [*] Rivers, lakes and valleys [*] Urban areas and rural/farmland areas [*]Somewhat flatter landscapes. No more 600 m peaks 100 m from the shoreline. 200 m hills 1 km from the shoreline is better. [*] Bridges. Lots of them. Wide so the AI can traverse them. [*] Winter version of same island on release. (I can dream,can't I? [*] To repeat, mountains don't just pop up out of nowhere. Highlands away from coastal areas. Ok, Dover is nice and steep and by the sea but AI pilots cant handle cliffs.

Lots of good points there, Chris! I too cringe when I see loops such as (somewhat exagerrated)<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #loop ?!(alive somedude): goto "next" ~0.000001 goto "loop" ... ... ... #next .... with very short loop delays. If this is a script that runs in many instances on a server they will hog the CPU like it's going out of style (the "lets wait for 1 microsecond" is the culprit). Other sources of lag/desync: doing too much almost at the same time. A classic example of this is spawning a group of units and running a CPU-intensive "init script" for each of them. As an example, here's an excerpt from D.Murphy Mans older version of the Skye Virus. That mission lagged horribly every time a new group of zombies was spawned. This is the code where three of the seven zombies gets spawned: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> "civilian" createunit [getpos _trig,bob,"zombiename1=this;[zombiename1,man1] exec {zombie.sqs};zombiename1 addweapon {strokefist};this setbehaviour {careless};this setunitpos {up};this setdammage 0.80;group=grpNull"] ~1 "civilian2" createunit [getpos _trig,bob,"zombiename2=this;[zombiename2,man1] exec {zombie.sqs};zombiename2 addweapon {strokefist};this setbehaviour {careless};this setunitpos {up};this setdammage 0.80;group=grpNull"] ~1 "civilian3" createunit [getpos _trig,bob,"zombiename3=this;[zombiename3,man1] exec {zombie.sqs};zombiename3 addweapon {strokefist};this setbehaviour {careless};this setunitpos {up};this setdammage 0.80;group=grpNull"] ~1 ... // four more zombies in a similar way ... Have a look at the "init code" part of each createUnit call - there's a script (zombie.sqs) started followed by some unit setup commands. Zombie.sqs, on start, immediately enters a "~1 delay loop" to chase the player. The code above doesn't look like too much for our 1+ GHz computers of today, but still, I was able to do a few things to it. What I did was to strip the createUnit init string down as much as possible and move all of the unit setup things (weapons, behaviour and such) into a slightly changed zombie.sqs. Here's the first createUnit line from the new spawn script: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> // Spawn the zombie if it doesn't exist and only on the server ? isNull zombiename1 and local Server:"civilian" createunit [getpos _trig,bob,"zombiename1=this;[zombiename1,man1] exec {zombie.sqs}"]; And the relevant part of a new variant of the zombie control script: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ... ; Wait a while before "activate" the zombie. This to lighten the load while spawning a lot of ; zombies, since each one executes this script on creation. ~(5 + random 5) // Stuff moved from the createUnit init parameter [_zombie] join grpNull; _zombie addweapon {strokefist}; _zombie setbehaviour {careless}; _zombie setunitpos {up}; _zombie setdammage 0.80; ... ... // zombie starts looking for fresh player brains... I guess what I'm trying to say is: when one spawns many units in a short time, don't run a lot of CPU-intensive code at once. A good trick is to move a lot of the init code into a script and let that script sleep a random amount of time when it is run. That way one can spread the CPU load over time a bit, thereby lessening the "cpu lag". The catch: with this cpu-lag reducing technique, don't go overboard on your spawning needs. The desync, I believe, would increase since a lot of new entities are created on e.g. the server and needs to be replicated on all player clients. So:<ul>[*]Like DV Chris said, dont do ~0.0000000001 loops [*]Dont spawn units without spreading the load over time

Yep, what softegg said. Don't confuse assignment of variables with definitions of macros or function calls.