UNN

In that case. My apologies for tarring you with the same brush, as those that have levelled criticism at the wiki.

If you’ve never programmed anything in your life, then try learning java script or something. Just to get your head around the idea. There are plenty of tutorials on the net. Look at other people’s scripts and reverses engineer them. Don’t try and do too much in one go. The amount of times I’ve seen people posting large scripts full or errors, that fail at the first couple of lines. There is more info on scripting now, then there has ever been. Perhaps that’s the problem. The wiki is a reference, not a tutorial for teaching people about programming languages. Rather than needlessly pointing the finger at all the people who put their own time and effort into populating that valuable resource. Try writing your own tutorials, if you’re that bothered.

If I understood it correctly, GearRetracting=False means the engine assumes the landing gear is permanently deployed? So you don't get the visuals but it's still there. You can of course, animate the land contact points. But as far as the flight model goes, your gears are always down. Not that I can tell the difference between landing gear up and down, when it comes to flying. But it is worth a mention. It's probably only relevant when your belly hoping off a mountain :)

This was pretty spectacular! http://s48.radikal.ru/i122/0912/1c/1f700099d0b2t.jpg

Depends what your trying to do with your Action. But there are two methods, each one has its own set of behaviour. For example if you want to execute a script on all clients and server from a user action. And that script requires a variety of parameters, then use AddPublicVariableEventHandler. If you only need to pass a single object, like the person who activated the action. You can use setVehicleInit. That's just a basic rule of thumb, you can sometimes get away with using either of the above methods to accomplish the same task, with and without some minor restrictions. You also have to consider that every call to setVehicleInit is remembered by the server. So anyone who JIP's will have them all executed one after the other. Where as PublicVariables only remember the last action sent. By way of an example lets take your flag texture problem... AddPublicVariableEventHandler Init.sqf: "MY_FLAG_POLE" AddPublicVariableEventHandler {((_This Select 1) Select 0) setFlagTexture ((_This Select 1) Select 1)} Your addAction script would then look like this: _Object=_This Select 0; MY_FLAG_POLE=[_Object,"\ca\misc\data\sever_vlajka.paa"]; PublicVariable "MY_FLAG_POLE"; With SetVehicleInit you just need this in your addAction script: _Object=_This Select 0; _Object SetVehicleInit "This setFlagTexture ""\ca\misc\data\sever_vlajka.paa"""; ProcessInitCommands; Well that's just a basic example, you can execute scripts or code. Again the best method is down to what you want to do. For one of two flag poles i.e. like a Capture The Flag mission, then AddPublicVariableEventHandler will do. If you have multiple objects, you might be better off with setVehicleInit.

@[GNC]Lord_MDB Replied here as it's the latest thread: http://forums.bistudio.com/showthread.php?p=1525747#post1525747 Will ask for this thread to be closed.

We are pleased to release an update to the first Public BETA of the RKSL-Arma2.pbo V2.01 Stated a new thread, ask the moderators to close the old one. This is the latest version of our ArmA2 countermeasures system, with the following fixes applied. Fixed "Deleted content error". Fixed radarflareplayer property in description.ext didn't disable automatic flares for players. Fixed multiple audio warnings. Fixed flares launch vectors are disrupted by terrain. Added support for the Extended Event Handler if installed. New description.ext property radaraudiowarning. 0 Turns audio warnings off for players, 1 reactivates them. Project Page: Arma2.pbo Project Related Documentation: System Core Documentation Radar System Documentation Required Addons: RKSL Arma2 V2.01 - Applies RKSL systems to BIS vehicles and Aircraft RKSL System V2.01 - Core system files required by all RKSL addons RKSL Flares V2.01 - Chaff and Flare system

Yes you have to land the helicopter, within 50 meters of a stationary Ammo truck and turn the aircrafts engine off.

Realy. True, I have met people who can't quite grasp the concept. But there usualy over 60? How abstract is a forum compared to a directory :)

Depends on what your trying to change with the include?

@gunterlund21 Check your PM's.

Thats what I always thought, until I was recently told different. Spawned vehicles are local to the client or server that spawns them. So a vehicle created as a result of a user action, will be local to the player. I tested it, just to be sure. It does appear to be the case.

Yeah, if you have the time to put a basic example together? I would be like to check it out to, I have a general interest in anything proxy related.

I've been using it by default in those scenarios since OFP. Especially when it comes MP: _man action ["EJECT", _sub]; WaitUntil {vehicle _man==_man}; unassignVehicle _man; _man assignasdriver _xzod; _man moveindriver _xzod; WaitUntil {vehicle _man!=_man};

The attachTo command is a welcome addition, it saves many hours of scripting, as both me and CSJ know from adding about 7 or more turrets to his ATC, back in OFP. But it isn't the same as aircraft with working turrets. It's just the next best thing. There is still a lot of effort required, to get it working like any other vehicle in game.

It should be init.sqf. That's why your getting that error. Your using old style script format (init.sqs) with the new execVM script format.

What you really need is: If (!(IsNull Player)) then That way it will never be called on a dedicated server, but will be called on a Player server. Not only that, but if you then go on to create a vehicle, that vehicle will be local to the player, so moving him into it becomes a formality. ExitWith works fine for me at the top of a script, if I want to exit the script straight away under certain conditions. But then it would only be if the script was a long one, just makes it a bit easier to follow. But ideally you shouldn't call the script in the first place, if there is a chance it will exit as soon as it's run, check those conditions before making the call. But sometimes (JIP) there isn't a better option. As for the result of using ExitWith, being unpredictable. Computers don't do unpredictable things, if they did then they wouldn't be used for anything other than entertainment. They just do things we don't understand or anticipate. In the case of the Wiki comments, I think they just didn't want to go into detail regarding a scripts scope and its many variations. Using ExitWith on a basic script that's been called with execVM works 100% all the time, simple as that. If you're doing anything more complicated, then it's easy enough to check it all works ok.

Do all that local to the player, it will make life easier all round. If all you want to do is make one parachute per player?

Are we talking about p3d's that will eventualy be proxies on the aircraft? If so, then it's probably being overriden when inheriting from the ProxyWeapon class.

Confirmed, thanks for the report, added to our bug tracker. Sorry I couldn't get back to you sooner. I have one more issue to resolve with the latest patch, will post an update once that fixed.

Could you give us a more detailed description. SP or MP, Map, Aircraft and possible a simple example missions e.t.c Cheers

As it happens your in luck, the flare points were mapped out for the ACE CH47 in Arma1: RKSLch47dSystem.zip You can run this script from the init field in the mission or init.sqf: [this,false] Compile PreProcessFile "RKSLch47dSystem.sqf" If you respawn a heli or create one during a mission, you have to run the script again for the new vehicle. But as Rock says, addons need to add support for the RKSL flares directly. It doesn't require any dependencies, the scripts can be setup to run only if the RKSL flares are installed.

The flares are available for either the primary gunner or the pilot. You still have the same amount. The muzzle flash is one of a few unfortunate side effects.

We are pleased to release an update to the first Public BETA of the RKSL-Arma2.pbo V2.01 This is the latest version of our ArmA2 countermeasures system, with the following fixes applied. Fixed "Deleted content error". Fixed radarflareplayer property in description.ext didn't disable automatic flares for players. Fixed multiple audio warnings. Fixed flares launch vectors are disrupted by terrain. Added support for the Extended Event Handler if installed. New description.ext property radaraudiowarning. 0 Turns audio warnings off for players, 1 reactivates them. Project Page: Arma2.pbo Project Related Documentation: System Core Documentation Radar System Documentation Required Addons: RKSL Arma2 V2.01 - Applies RKSL systems to BIS vehicles and Aircraft RKSL System V2.01 - Core system files required by all RKSL addons RKSL Flares V2.01 - Chaff and Flare system

Thats not our fix, our update includes fixes for a couple of bugs and support for XEH. If the pbo you mentioned above also adds XEH support, then there is a good chance that the same scripts will be called multiple times, if that addons present.