UNN

The method I use is the AssignedVehicleRole command. If it returns a count of 2 i.e He got into turret. You can then use the turret path to determine which turret he got into. Something like this:_AssignedRole=AssignedVehicleRole _Unit; If ((Count _AssignedRole)>1) Then * * * *{ * * * *Switch (Str (_AssignedRole Select 1)) Do * * * * * * *{ * * * * * * *Case "[0,1]" : {Hint "Show Turret 1"}; * * * * * * *Case "[0,2]" : {Hint "Show Turret 2"}; * * * * * * }; * * * *}; Not exactly sure about the turret paths, you may have to check which path your gunners are returning.

Sorry, it was a typo. It should be ForEach not ForeEach: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{[_x] Call RKSL_InitStatic; [_x] Spawn RKSL_CargoAssign;} ForEach [AMMOBOX01,AMMOBOX02,AMMOBOX03,AMMOBOX04,AMMOBOX05,AMMOBOX06];

I did this a while back to work out the order of events in SP and MP, can't find the original post I made explaining it in detail. But basicly the horizontal scale represents all the different types of init events, addon, mission editor and init.sqf e.t.c The horizontal scale is the order they are called. The point is, everything starts from 0, as thats function launched from an objects init event. The rest are scripts and functions from various places like a mission editors init field.

Hi, The value of 1 dictates the size of the object. For example you can load 12 ammo boxes in to a 5ton truck becuase it has a capacity of 12. To initialise 6 ammo boxes placed in the editor, you could write your init.sqf like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">////////////////////////// // This Script By UNN V1.0 ////////////////////////// //Run this line first for Aces RKSL_System Set [0,True]; //Assign the common West object name _CommonNameWest="BIS_AMMOBOXWEST"; //Call the cargo assign command for the West ACE classes ["ACE_AmmoBox_West",1,_CommonNameWest,"RKSL_CBISAMMOBOXWESTDRAGOBJ"] Call RKSL_AssignCargoTable; ["ACE_WeaponBox",1,_CommonNameWest,"RKSL_CBISAMMOBOXWESTDRAGOBJ"] Call RKSL_AssignCargoTable; ["ACE_WeaponBox_West",1,_CommonNameWest,"RKSL_CBISAMMOBOXWESTDRAGOBJ"] Call RKSL_AssignCargoTable; ["ACE_RuckBox",1,_CommonNameWest,"RKSL_CBISAMMOBOXWESTDRAGOBJ"] Call RKSL_AssignCargoTable; ["ACE_MedicBox",1,_CommonNameWest,"RKSL_CBISAMMOBOXWESTDRAGOBJ"] Call RKSL_AssignCargoTable; ["ACE_SpecialBox_West",1,_CommonNameWest,"RKSL_CBISAMMOBOXWESTDRAGOBJ"] Call RKSL_AssignCargoTable; //Assign the common East object name _CommonNameEast="BIS_AMMOBOXEAST"; //Call the cargo assign command for the East ACE classes ["ACE_AmmoBox_East",1,_CommonNameEast,"RKSL_CBISAMMOBOXEASTDRAGOBJ"] Call RKSL_AssignCargoTable; ["ACE_WeaponBox_East",1,_CommonNameEast,"RKSL_CBISAMMOBOXEASTDRAGOBJ"] Call RKSL_AssignCargoTable; ["ACE_SpecialBox_East",1,_CommonNameEast,"RKSL_CBISAMMOBOXEASTDRAGOBJ"] Call RKSL_AssignCargoTable; //Call RKSL_InitStatic and Spawn RKSL_CargoAssign for each new ammo box {[_x] Call RKSL_InitStatic; [_x] Spawn RKSL_CargoAssign} ForeEach [AMMOBOX01,AMMOBOX02,AMMOBOX03,AMMOBOX04,AMMOBOX05,AMMOBOX06]; You should not need the above commands much longer, we are working with ACES to add support directly. But the example does show one way to configure your own, custom content ammo boxes e.t.c with the system. No worries mate, in an ideal world you should not have had to worry about these sort of things. Cheers

One way, would be to add the init event to say class CAMANBASE, using the Extended Event Handler?

It depends how the mission’s respawn is handled. If it uses the default Arma respawn command, then it's just a quick search and replace. If it were a custom script then you would have to call the init again. If anyone is seriously wanting to get the Cargo system working with EVO or Warfare, they should pm me.

Hi, The Cargo System Game Logic is used when you have no visible cargo or supported vehicles on the map. So you have to start the scripts using the logic. If you look at the example mission rksl-hiddencargo.Intro, you will see all the vehicles and objects use the hidden cargo commands with standard Arma addons. Hope that helps? Cheers

If you call your checking code directly from an objects init event you get no latency, because it's treated as a function: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">init="If (IsNil ""MyScriptHasBeenCalled"") Then {MyScripthasBeenCalled=True; [_This Select 0] ExecVM ""MyScript.sqs""}"

For Styxx42 and anyone else hitting problems with dragging large static objects. I've now fixed the bug so a working version will be available in the next update. Only the UH60 and MI17 are currently defined with visible cargo in the system. They should be able to work with the ACES versions. Assuming the cargo positions haven’t changed. The Chinook will be added, just can't say when atm. Cheers

Well after a bit more experimenting you might run into other problems when you try and rotate the visible drag object The problem can be found on a variety of objects, it's just the larger they are the more apparent it is. Take this mission for example: SetPosGetPosBug.intro I've placed a standard M2 and MK19 tripod on the map. Both objects then spawn this script: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">WaitUntil {_Pos=GetPos (_This Select 0); (_This Select 0) SetPos _Pos; Sleep 1; False} If your familiar with scripting you would expect the objects to remain stationary while the loop is running. However if you run the actual mission, you see the MK19 slowly move across the map while the M2 does remain stationary. Thats the problem we have with the Cargo system. For some objects the value returned by getpos changes, when you use the same value with setpos. This appears to relate to the p3d's COG, we are looking into ways to detect and compensate using scripts. Yeah, we are looking into both these issues. Cheers

Try this line instead: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[This,12,TypeOf This] Call RKSL_CargoAdd It will assign an object instead of the white arrow. It's easier to match up the same objects, so it should remove the delay. But remember the drag object has mass, so you can easily kill yourself and others, if you drag the object onto a unit. Ideally we would create a dedicated drag object, with no Geometry. Cheers

We had this during beta testing with larger static objects, but I thought I'd fixed it. What object are you using? If you want, send us your test mission. Pm me for the details. Edit: Just tested it with a Warfare Air Factory. Large static objects can cause problems when waiting for them to reach the last mouse position. I did put a timeout feature in there, just in case. If you wait for about 5 seconds, it should update so you can exit the menu without any problems? Cheers

Here are a couple of example missions that use the ACES Ammo box objects RKSL-ACESCargo.zip RKSL_ACESProxyCargo.intro: Most of this is done in the init.sqf. Once the cargo class is defined, you only have to call RKSL_InitStatic and RKSL_CargoAssign everytime you create a new box using scripts. RKSL_ACESHiddenCargo.intro: Most of this is done in the mission editor, but you still need the quick fix in init.sqf. I've also demonstrated how you can use your own drag object in the overhead view, with an extra parameter: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[This,1,"RKSL_CBISAMMOBOXWESTDRAGOBJ"] Call RKSL_CargoAdd If you don't want a custom drag object, just use this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[This,1] Call RKSL_CargoAdd You just need to add the quick fix I mentioned a few posts above. The problem was, it would take a seemingly random amount of time to initialise the system. The code I posted solves that problem until the next update. Cheers

@Betsalel I will take a look tonight, I only just realize ACES used the same object for the Weapons box as Arma uses for the Ammo box. I will post an example mission for you, later on tonight if I can. @Stxx42 I'll check out the Sandbag object you linked to and see what we can do. Edit: Try Manzillas suggestion, the Sandbag fix is destroying the objects so the system thinks there dead. If you still need to use destroyed sandbags, then you might as well wait for the next update to the Cargo System (which won't be long, just tidying up the documentation). @Manzilla No worries, you weren't offtopic after all

If you define your proxies in cfgNonAIVehicles, then they show up in the pilots LOD. At least they did for the BIS A10: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class cfgNonAIVehicles         {         class ProxySOLmk82_rack             {             autocenter = 0;             scope = 2;             reversed = 0;             animated = 0;             model="\ca\air\mk82_rack.p3d";             simulation="alwaysshow";             };         }; So then in your p3d you would change your proxies from: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"proxy:/ca/air/mk82_rack.005" "proxy:/ca/air/mk82_rack.006" To: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"proxy:SOLmk82_rack.001" "proxy:SOLmk82_rack.002"

It's a good enough test if it shows there isn't too much increase in FPS for a reasonable amount of hidden proxies. There will probably be some extra increase in used resource? But if you know how many proxies your going to use, then it's a nice, self-contained solution. Well Cargo proxies do allow for a more open ended approach. But they also have their own issues, geometry being the main one in my opinion. But that probably won't be a major issue with your ships. I guess your proxy geometry does not have to be that complex, just enough detail for fire and vehicle collision? You don't have to have scripts running for Cargo proxies to work, if your happy creating new p3d's to represent existing objects as proxies. Cargo Proxies are used for infantry and game logics, so once you move it in place, the engine handles the rest. Try adding a p3d to an object inherited from a game logic or class man, you should be able to use the extended moveincargo command to place it in a specific location. The BAS Chinook in OFP was the first example I ever saw of this, it uses Game Logics so it's a relatively simple example to look at if your curious. For our Cargo System we wanted to use existing p3d's so we could support any addon and share it's resources. So we used objects derived from infantry units. The proxies we use are actually meant for Night Vision goggles, so when we point to a BIS vehicle it hides all the extra stuff like muzzle flash. The only thing we can't easily hide for the default Arma addons is the BIS logo, but we can live with that compared to the savings we get elsewhere. For example, to represent the Zodiac loaded onto the back of a 5TonTruck, we only need this: But because were using NV proxies, we also need this script running to ensure they show up: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_CargoProxy=_This Select 0; WaitUntil     {     _CargoProxy Action ["NVGOGGLES",_CargoProxy];     (IsNull _CargoProxy)     }; I to prefer not to have scripts running myself, if I don't have to. But with the amount of resources and time saved, a small looping script like the one above has next to no effect on performance. The best way of using proxies really depends on what you want to do and how flexible you want it to be. Hard coded proxies keep things simple and self-contained. Cargo proxies allow for greater flexibility and efficiency, at the expense of simplicity.

Hi, Looks like, since the ACE update. The RKSL System has stopped initialising. I will take a closer look. Edit: A quick fix is to add this line to your init.sqf or an init field in the mission editor: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">RKSL_System Set [0,True];

What method do you use to detect ejected bodies server side?

Are you using hard coded proxies or cargo proxies? I've been told that hard coded proxies hidden with a hide anim, are still considered by the GPU. So there should in theory be a limit to how many heli's you can add before it starts to lag. With Cargo proxies you don't have to worry about that. Plus other addon makers can add support for your ships, without you having to re-release your addon every time a new heli is made compatible.

Because it makes sense. Why continue to sync dead infantry across server and clients. That in the majority of cases, won’t every move again? Sure there are exceptions, I ran into the same problem myself. But 90% of the time you may as well have dead bodies local to just the server. Perhaps I've misread your problem. But if you want to remove dead bodies (or crew) from a destroyed vehicle, then event handlers are fine. Can't you just flag the crew for removal and deletion before the killed event has finished? <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">This AddEventHandler ["killed",{[_x] Spawn {_Unit=(_This Select 0); _Unit SetPos [0,0,0]; WaitUntil {(Vehicle _Unit)==_Unit}; DeleteVehicle _Unit} ForEach (Crew (_This Select 0))}]

Just in case, it's "SCALAR" not "NUMBER": <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if ((TypeName _targets) = "SCALAR") then {[Format["%1Targets are numbers", _sideText]] Call TRACE; goto "MoveToLocation"};

The correct command is DeleteVehicle, not RemoveVehicle.

As T_D said you can read configs easy enough. But once you have the path to the p3d. I’m not sure what you can do with it, when it comes to changing your ships p3d or config? AFAIK You can't change a P3D's content using scripts, only turn stuff on and off. Which is probably a good thing from the aspect of a potential cheat? Certain config values can be influenced using scripts during Arma's startup. Scope being one of them. But your limited to numeric values only AFAIK. If the engine expects a string (like the path to a p3d) it will read it as a string and will not execute a function.

Hi, I thought that’s what you wanted, I wasn't exactly sure how everything was supposed to fit together. I have a solution for the init events, but I don't use the Eventhandlers functionality to the same extent as you do. So I'm not sure it would work the same way for the Fired events e.t.c I will take a look and PM you if I make any progress. Thanks for taking the time out to support our system. Would be interesting to see if we could get both systems to work with each other, in a support role for the AI.

@SNKMAN I've just finished tracking down the cause myself. At least the problem of it locking up during startup. The following code is not reliable when it comes to identifying vehicles: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if !(_a isKindOf "Man") It won't account for things like game logics, and infantry inheriting from classes above Man. In other words they return themselves as crew. I ended up swapping this line: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if !(_a isKindOf "Man") then {{[_x] call (GL3_Compile select 0)}} forEach (crew _a); With this code from the Extended Init Event Handler pbo: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if((count (Crew _a)>0)&&{(getText(configFile/"CfgVehicles"/(typeOf _a)/"simulation"))==_x}count["soldier","invisible"]==0) then {{[_x] call (GL3_Compile select 0)}} forEach (crew _a); You could also do this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if !(_a isKindOf "Man") Then     {     If ((Crew _a)>0) Then         {         If (((Crew _a) Select 0)==(Vehicle ((Crew _a) Select 0)) Then             {             //It's not a vehicle             };         };     }; The other solution is the one you've already implemented. Add your init events directly to class Man instead of AllVehicles. I wasn't exactly sure how you wanted to handle the Extended Init Event handler classes, did you want a separate pdo for the eventhandeler events. Or did you want to have the Extended Init Event Handler as a required addon for all your pbo's?