BlindNavigator

I'm guessing it's about uppercase file names. This link contains some info about it. https://community.bistudio.com/wiki/Arma_3_Dedicated_Server

I've noticed one small flaw, it doesn't accept addresses like proultraserver.exampleserver.com being saved. Manually putting it in the save .XML don't work either. Not the end of the world, but would be kinda nice for people with dynamic IPs (that change).

A trigger with the condition !alive WARLORD_NAME. I guess you may already have the above, but anyways, in that trigger: Condition: !alive WARLORD_NAME; On activation: 0 = [] execVM "yourscript.sqf"; In your mission root folder, you create the file "yourscript.sqf".

Export to sqf in a sane format, 'Type createVehicle Pos' for example. Either the whole Eden mission or the selected objects.

Nicely done Grumpy! I've implemented this in my jets missions, works good so far!

This is by far the best one I've found so far. Works good and no annoying popups like "Please donate now" and crap like that. Thanks for this!

Yep, good ol' times, especially miss your version with Mando's missiles script in A2. These comments below are mostly based of Warfare in A2. + The RTS aspect, a good commander could really matter. Base placement, spread out, upgrades and so on. + AI and player classes. Medic being able to build respawn tents for example. + Economy and progression. You always had something to look forward to. You started out poor with crappy weapons, and barely any vehicles. + PVP and TvT, had some very fun back-and-fourth-battles on Takistan. - Long matches, sometimes so long they was never finished. At least when doing a full Chernarus or Takistan. - Matches could sometimes end abruptly by a good pilot bombing out all bases. Related to: - Bad commanders could early in the match destroy any chances for the team to win. I think the biggest problem was that you never knew if a match would be completed/fair/good. I wasted 4h for nothing more than once. And the early game could feel like a boring chore.

50? I am not the one to say. But I'm guessing that the actual AI of the soldiers (especially when engaged) is eating up far more resources than the EH tied to them.

Thanks again, I also found the in game config viewer and saw the canopy in there. I miss the motorcycles in Arma II, and this is the closest we have in A3: ["Ejection_Seat_Base_F","Motorcycle","LandVehicle","Land","AllVehicles","All"] Anyways, this will remove all scrap for anyone interested: cleanUpPlaneParts.sqf { if (vehicle _x isKindOf "Ejection_Seat_Base_F" OR vehicle _x isKindOf "Plane_Canopy_Base_F") then { deleteVehicle _x; }; } forEach vehicles;

Thanks, how do one easily find parent classes? Sweet!

I've noticed something that can get somewhat annoying after a while. 1. Spawn a new plane, like Shikra. 2. Destroy it with something like a Zeus lightning or similar. 3. Ejection seat goes off. After a while on a MP server there will be quite a lot of broken ejection seats all over that doesn't despawn. Also I haven't found a good way to clean it that doesn't remove something else. Like vehicle _x isKindOf "Thing" // removes boxes and lights. vehicle _x isKindOf "Plane" // doesn't remove it. When put into a script like this: { if (vehicle _x isKindOf "Thing") then { deleteVehicle _x; }; } forEach vehicles; I'm thinking this will be changed, so that we don't need custom cleaning script like these.

Have you checked out event handlers, like the "Killed" for example: https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#Killed You can put it on the objects and do something like this: SOLDIER addEventHandler ["Killed",{ YOUR_FUNCTION }]; It will trigger once the SOLDIER dies and run YOUR_FUNCTION which spawns a new one (soldier). The group cant be _local though I'm pretty sure. You can put it in a forEach-loop too, and you wont be needing any while loops since the event handler will do the triggering. I would probably also create a new, separate .sqf called something like setUpSoldier.sqf where I put all the skill and gear stuff and later on call it (or execVM). The function can be defined like this, in init.sqf for example: YOUR_FUNCTION = { ... _tempSoldier = _myGroup createUnit [ "B_Protagonist_VR_F", _position, [], 0, "NONE" ]; ... }; That way you can always reach it by: [] call YOUR_FUNCTION; // call can't use sleep or while loops. or [] spawn YOUR_FUNCTION; // Same rules as execVM, sleep and loops can be used. This is probably not the smoothest way to do what you want. And you would have to change the structure of the scripting quite a bit. At least it gives an alternative!

The Shikra can now use KH25 Kedge AG. Great!

Yes, put your commands in the sqf. You can still have the attributes set in Eden, this script is for when the vehicle respawns. If you follow my example with myVehicleRespawnScript.sqf the vehicle is referenced by "_vehicle" instead of "this". The first line: _vehicle = _this select 0; means that what ever vehicle synced with the module will be called _vehicle inside the script. It's almost like _vehicle = this in this case. So your: this animate ["cargodoor_1",1]; should be: _vehicle animate ["cargodoor_1",1]; when you put it in the script. Other than reading my earlier post again, you have to just test it. It will be easier for you to understand while in the game, playing around with it.

This is one way to do it, with the Eden respawn module. 1. Place the vehicle in Eden. 2. Place a vehicle respawn module. 3. Sync the module with the vehicle. 4. Double click the respawn module. 5. In Expression, put: _this execVM "myVehicleRespawnScript.sqf"; 6. In your mission root folder, create the file "myVehicleRespawnScript.sqf". myVehicleRespawnScript.sqf: _vehicle = _this select 0; clearWeaponCargoGlobal _vehicle; clearMagazineCargoGlobal _vehicle; _vehicle addItemCargo ["Toolkit", 1]; Feel free to put anything in that file that you want to be applied to the vehicle. setObjectTextureGlobal for example.