UNN

An example mission would be appreciated.

LimitSpeed or ForceSpeed would be the ideal choice? But you may have to resort to something a little more drastic.

@Victor I think the problem is, he wants to stop them moving until the COC command engine issues some orders. You will have to expand your stay put script. Once you've told them to DoMove to where they were initially place, run a script that waits until your leader gets an order from CEX. I can't test anything atm put something like this might work. But you will have to debug it yourself: StayPut.sqf _Officer=_This Select 0; {_x doMove (getPos _x)} forEach (units _Officer - [_Officer]); WaitUntil { //See what command CEX issues to the officer of each group Player SideChat Format ["Officer %1 CEX Order %2",_Officer,currentCommand _Officer]; //If you can see the CEX command and it isn't MOVE then change the next line ((currentCommand _Officer)=="MOVE") }; //Get them to follow the officer once CEX has started issuing orders {_x doFollow _Officer} ForEach (units _Officer-[_Officer]); In your init for each group leader: sP=[This] ExecVM "StayPut.sqf"; Like I said, not sure it will work. But you will need to find a trigger that tells you when CEX is issuing orders, so you can tell a group leaders units to start following him again.

Try adding this instead of the DoStop command. This DoMove (GetPos This) They will stay put, but should be willing to accept additional orders.

Cheers, would like to have added some significantly new functionality, but really busy atm. Hopefully we may be able to add one more feature before Arma2 is out. The allocated sizes are: Fuel_Roll=4.1 (the .1 is to prevent it being carried by smaller vehicles like the 4x4, as invisible cargo). Repair_pallet=4 Crate=4 So the capacity for the CH47 can be around 13. If you add this line to it's init field you should be ok: [This,13] Call RKSL_TransportAdd I will document the size and capacity for all the visible Cargo and Vehicles.

My fault, I used the wrong links when writing the text. Rock has fixed it now. Cheers

Yeah we have those you listed along with some more. But it's not necessarily a case of adding new ones, but being able to interact with them via scripts and animations e.t.c. Look at just two additions to VBS: HitPart Event Handler: And the setHit command. Take tires on a truck, that actually needs to work properly, never mind being improved. AI still doesn’t respond to a repaired vehicle in MP.

Hi, The cargo system handles all the MP stuff itself, so you don't need to use SetVehicleInit. In fact it will cause a CTD if you use those functions with the SetVehicleInit command. Just do this: [_Vehicle] Call RKSL_TransportAdd; _Vehicle Animate ["lcuramp", 1]; The animate command should also work in MP without having to broadcast it to all the clients or JIP's. Regards UNN

In retrospect, I figure there must be some interaction allowed. Otherwise there is no point in having dialogs, if you can't do anything with them.

Any ideas what this means exactly. Will we still be able to interact with our own dialogs and scripts/objects running in game, in real time?

Using Nil like this is bad, as Worldeater already mentioned on the wiki: // ** * * * * * Use: nil = [name_unit/this, seconds/freeze] execVM "freeze.sqf" // ** * * * Example: nil = [this, 10] execVM "freeze.sqf" Not sure who first suggested it, but it just causes problems for anyone who wants to use Nil to remove variables. It's easy enough to create a variable that does not screw up other peoples scripts. sP=[this, 10] execVM "freeze.sqf"

I might be wrong, but I thought he wanted to pass the pointer to the array, not a copy? Command Engine X by Spinor, but he uses configfiles to do pseudo object oriented code.

A JIP player will be sent the content of the last broadcast with PublicVariable. So it will also trigger the event. If your using it on more than one vehicle you can either create global vars for each vehicle. Or create an array of all the vehicles assigned an action along with the ID's. Or use SetVehicleInit instead, that will automatically remember all the calls to remove actions. Your spoilt for choice

If you use AddPublicVariableEventHandler you can set it up so it will handle any user action you want removing. So for each client at startup you would add: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"UNN_REMOVEACTION" AddPublicVariableEventHandler {_Params=_This Select 1; (_Params Select 0) RemoveAction (_Params Select 1)} In the script called by your action you would have something like: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Vehicle=_This Select 0; _Unit=_This Select 1; _ID=_This Select 2; UNN_REMOVEACTION=[_Vehicle,_ID]; PublicVariable "UNN_REMOVEACTION";

To be fare, this is a problem with just about any addon that uses the KeyPress event handler outside of dialogs e.t.c I'm increasingly seeing my own Arma key configuration being compromised by user made Addons.

Not being sure what weapons you give to your default crew, I’m assuming it works the same as OFP. In that you can only define a single crew type for the entire vehicle? If so, then at startup you know that all the crew have the same weapon so you can just make all the mounted weapons visible for a crewed vehicle, without having to check each crewmember. Failing that, you can probably add a loop, that waits for the assigned roles to be allocated before running the rest of your script. I will PM you about the rest.

Then you won't really need any of the turret path stuff for you looping script. You can use the Gunner command to find out who is in the primary turret. Something like this launched from the init for every client should be ok, hard to say without being able to test it with the target addons, but it's a start: _Vehicle=_This Select 0; _OldGunner=Gunner _Vehicle #Loop ? !(Alive _Vehicle) : goto "Exit" ? IsNull (Gunner _Vehicle) : _OldGunner=ObjNull; goto "Skip" ? !(Local _Vehicle) : _OldGunner=Gunner _Vehicle; goto "Skip" ? IsNull (_OldGunner) : _OldGunner=ObjNull; goto "Check" ? ((Gunner _Vehicle)!=_OldGunner) : goto "Check" #Skip ~0.1 goto "Loop" #Check _OldGunner=Gunner _vehicle ? !("ukf_sa80" In (Weapons _OldGunner)) : goto "Hide" ? ("ukf_sa80" In (Weapons _Vehicle)) : goto "Loop" _vehicle addweapon "ukf_sa80_topcover_one" _vehicle animate ["hide_sa80_primary",0] goto "Loop" #Hide _vehicle removeweapon "ukf_sa80_topcover_one" _vehicle animate ["hide_sa80_primary",1] goto "Loop" #Exit

Thats always been a problem in OFP and ARMA. But does'nt the same apply with the pure maths function as well? I assumed you had already prepared some sort of sampling script to determine the land intersect, similar to the way COC's Command Engine does it. Although I appreciate in your case it's not ideal, as you probably want a quick routine to run every cycle to ensure an accurate impact point without the performance hit. All this is handle quite well in VBS2 so we can only hope it makes it's way into ARMA2.

I see, it will take me a little time to work it all out. But are you sure you want to go down this route given the problems with AddWeapon? It's not impossible to do, only it requires increasingly complex scripting and work rounds.

I would be interested in any pure maths solution, if you find one. Not sure if it applies to your problem, but what about the modelToWorld command? That should handle all the translations, so any maths you do before that can assume your aircraft is flying straight and level?

True, but I should have tested it first. It can be frustrating if you’re given an example that doesn't work. Ahh..You have hit a limitation. They never updated all the commands when they added multiple turrets. You can only add and remove weapons from the first turret you define (I think). Unless you can find a better way, the only alternative I can think of is to define three turrets. The first turret you can add and remove your weapons as you already mentioned. For the second turret you hardcode the ukf_sa80_topcover_two and the third turret holds a dummy invisible weapon or no weapon and is automatically locked using a game logic. If a guy gets into the second turret when carrying the ukf_sa80_topcover_two, then you don't have to do anything. If he isn't carrying the specific weapon when he gets in, you move him to the third (empty) turret and place the gamelogic in the second turret to lock that. Not ideal and you will need some extra scripting to handle disabled vehicles and set the config to prevent the move to turret action menu options e.t.c Perhaps it's not relevant given the above problem. But from an addons init you can make two assumptions. If the vehicle is empty there is no crew in any turret so hide everything, if it's crewed then all the turrets are occupied, so show everything.

Memory, angle0 and angle1 should be numbers not text and the value for angle1 should be rad 360: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">memory=0; angle0=0; angle1=rad 360; The number of steps in the rotation anim is taken from the amount of ammo in the magazine. So six rounds is 360/6=60 degree increments. Apart from that the rest of the config is fine.

Sorry mate, I just realized I hadn't accounted for the additional parameters in the example I posted: It should have been: id="CODE">_vehicle=_This Select 0 _unit=_This Select 1 _hatch=_This Select 2 _gun=_This Select 3 ?!(Local _vehicle) : exit _AssignedRole=AssignedVehicleRole _unit ? ((Count _AssignedRole)==1) : exit _GunIndex=(_AssignedRole Select 1) Select 0 Hint Format ["Here %1",AssignedVehicleRole _unit] ? (_GunIndex==0) : goto "primarygunner" ? (_GunIndex==1) : goto "secondarygunner" exit #primarygunner _vehicle animate ["top_hatch",_hatch] _vehicle addweapon "ukf_sa80_topcover_one" _vehicle animate ["hide_sa80_primary",_gun] exit #secondarygunner _vehicle animate ["top_hatch",_hatch] _vehicle addweapon "ukf_sa80_topcover_two" _vehicle animate ["hide_sa80_secondary",_gun] exit Then call it like this: id="CODE">ukf_snatch_getin="[_this select 0,_this Select 2,1,0] exec ""\ukf_landrovers\scripts\snatch_getinout.sqs"""; id="CODE">ukf_snatch_getout="[_this select 0,_this Select 2,0,1] exec ""\ukf_landrovers\scripts\snatch_getinout.sqs"""; Best to make sure the code I posted works as expected before trying it with the event handler. I've added a hint ot the script above so you can work out the turret paths. I tried the script with a 4x4 which returns a turret path of ["Turret",[0]]. So I had to change these lines accordingly: id="CODE">_GunIndex=(_AssignedRole Select 1) Select 0 Hint Format ["Here %1",AssignedVehicleRole _unit] ? (_GunIndex==0) : goto "primarygunner" ? (_GunIndex==1) : goto "secondarygunner"

I find the sqf format easier and quicker to write. So if you don't mind it in sfq, send us a pm and I'll do a continuous looping version if you’re stuck, won't take long to do.

As much as I hate doing it Here's an sqs version, but I'm not sure if the syntax is 100% correct.snatch_getinout.sqs: _vehicle=_This Select 0 _hatch=_This Select 1 _gun=_This Select 2 ?!(Local _vehicle) : exit _AssignedRole=AssignedVehicleRole (_this select 1) ? ((Count _AssignedRole)==1) : exit _GunIndex=(_AssignedRole Select 1) Select 1 ? (_GunIndex==1) : goto "primarygunner" ? (_GunIndex==2) : goto "secondarygunner" exit #primarygunner _vehicle animate ["top_hatch",_hatch] _vehicle addweapon "ukf_sa80_topcover_one" _vehicle animate ["hide_sa80_primary",_gun] exit #secondarygunner _vehicle animate ["top_hatch",_hatch] _vehicle addweapon "ukf_sa80_topcover_two" _vehicle animate ["hide_sa80_secondary",_gun] exit The code should work for both get in and out events if I remember correctly. The get out event is called before the gunner actually leaves the vehicle. ukf_snatch_getin="[(_this select 0),1,0] exec ""\ukf_landrovers\scripts\snatch_getinout.sqs"""; ukf_snatch_getout="[(_this select 0),0,1] exec ""\ukf_landrovers\scripts\snatch_getinout.sqs"""; Your init event would look something like this: id="CODE">init="{[_x,1,0] exec ""\ukf_landrovers\scripts\snatch_getinout.sqs""} ForEach (Crew (_This Select 0))"; No worries mate, but there are a couple of other potential problems I can think of: 1) The MoveToBack\driver user action, if it's available? 2) MoveInGunner and setpos (for removing units) don't fire off any events. Although it would probably be a rare occurrence. You could cover all the above with say a single looping script that checks the gunner positions every second or so. But*the script runs on all the clients for each vehicle, alive in a mission. Nothing to processor hungry though, as it only has to check for a change in the assigned roles. Cheers