theend3r

Of course it does. It's not supposed to be SAFE but CARELESS. No need to disable any AI either. The gunner will still shoot unless you remove his ammo but the heli will not change its route.

The solution above works but if you really absolutely need it, you can do this with your original code: _type = param [0,"none"]; _roundTime = 60; if ((isNil {roundInProgres}) or (_type == "end")) then { roundInProgres = false; } if ((_type == "start") and (!roundInProgres)) then { roundInProgres = true; while (_roundTime >= 0) do { if ((_roundTime == 0) or (!roundInProgres)) exitWith { diag_log "round finished"; roundInProgres = false; }; sleep 1; _roundTime = _roundTime-1; }; }; Untested, just an idea.

Again, just to make sure, does the car have damage disabled as well or is there a trigger for game over if it gets blown up or the driver dies? What I usually do is to make it Captive until player(s) gets close and then give player(s) (i.e. spawn another one somewhere and drive it / give another heli call in the case of helis) another chance. If the second one gets blow up as well then then either tell the player(s) to get out themselves or fail the mission. Making stuff immortal (the Bethesda way) is extremely boring. Forgetting to account for the possibility is even worse as you can find out, after an hour long mission, that you won but won't get to see the ending screen.

Are they immortal or can you just shoot them yourself to complete the task? Asking out of curiosity.

If you are talking about a var name of an object then you can do that with setVehicleVarName, otherwise, as Dedmen said, your question doesn't make much sense.

Not that I know of. What you can do is display the information in player diary (createDiaryRecord) with a picture of the medal/feat, description of some bonus and use commands like e.g.: unit setUnitTrait ["camouflageCoef", 0.7]; unit setUnitTrait ["audibleCoef", 0.7]; unit setUnitTrait ["loadCoef",0.7]; unit setUnitTrait ["Engineer",true]; unit setUnitTrait ["medic",true]; unit setCustomAimCoef 0.5; unit setUnitRecoilCoefficient 0.6; // ...etc. to give the player some traits this way.

No idea, sorry. I can't even check it now since I'm on my work laptop. Also it seems like the subtitle is not really needed. Also no need to have 2 identical endings.

Unfortunately I don't think you can play the music simply by editing the class. Playing a music with playMusic after "plane1 addEventHandler ["Killed", {"PlaneDestroyed" call BIS_fnc_endMission;}];" might work, at least I know I got it to work somehow in one of my missions but I'm not sure where I have it in the pile of them. Text getting cut off... didn't happen to me. Do you use some very large text for that? Failure screens shouldn't really need that unless you're making a campaign where you can fail something and continue on. It's better to make a radio call in game after said event happens and explain to the player directly like that, like a call from HQ how you messed up and then show a simple game over screen.

I used "frickin" to try to sound not too serious about that. Sorry, I'm not the best when it comes to communication. Added something about another potential problem to my previous post.

You said that you use plane1 addEventHandler ["Killed", {"end1" call BIS_fnc_endMission;}]; where end1 is the class name of the debriefing that you are calling with BIS_fnc_endMission. In your case you'd do // in mission plane1 addEventHandler ["Killed", {"PlaneDestroyed" call BIS_fnc_endMission;}]; // in description.cfg class CfgDebriefing { class PlaneDestroyed { title = "The plane got destroyed!"; subtitle = ""; description = "The plane got shot down, mission failed."; }; }; But really, you would know this if you read the frickin wiki. Also note that using Killed EH may not be the best because it might get just damaged and land somewhere and your missions gets broken. It'd be better to check for damage.

Switch may provide some performance improvement over if...else and make the code prettier but unless you're running this statement on every frame, it should not really be noticeable. If you need some more complicated logic, just do it separately, imo. What do you mean by unmaintainable? You could use "in" or even use it in a for loop to create a more complicated condition.

I kinda intentionally don't go into detail because people will gain more by learning to read the wiki and the existing hundreds of threads than by getting stuff handed to them. But yes, you just put it into description.ext, change the title and call the class name with BIS_fnc_endMission.

You can use simulation manager or freeze everything far from players manually by scripts so it gets ignored. The problem that prevented me from using this solution is, that it makes artillery wonky as it either won't work or you'll need to check for firing EH, unfreeze stuff in impact area and refreeze after which is... not ideal and makes the mission less organic unless you simulate enemy movement by moving some coordinates around and if you could do that then I guess you wouldn't be asking this. If you have no arty then use sim man or a simple script that checks the distance to the nearest player periodically and hides + disables sim.

https://community.bistudio.com/wiki/Description.ext#CfgDebriefing E.g. from a random mission of mine: class CfgDebriefing { class End1 { title = "Mission Completed"; subtitle = ""; description = "The warhead is safe thanks to your efforts. Well done."; pictureBackground ="overviewPicture_ca.paa"; picture = __EVAL((__FILE__ select [0, count __FILE__ - 15]) + "GhostSkullS"); pictureColor[] = {0,0,0,1}; }; class Fail { title = "Mission Failed"; subtitle = ""; description = "You have left the area."; }; };

Not if they have simulation disabled, afaik. Edit: So it seems they can take damage. In that case I apologize, your solution is indeed the correct one. Spawning by script is still preferable, though. I can't really check either way because I'm on a business trip 500km from home.