kira_mikamy

after you had create the drone in mission editor and named it as example "DRONE_TEMPLATE" (the GROUP name) you can use MOOSE and declare just remember that moose ad a #001 at the end of the group name after the spawn, this function will check every 5 minutes (300seconds) if a group named SPAWNED_DRONE#001 exist. if exist, nothing happen. if not exist (destroyed or not yet spawned) it will spawn one. the drone will spawn in the place where its placed in missione editor and follow his waypoint every time function IS_DRONE_ALIVE() if not Group.getByName("SPAWNED_DRONE#001") then DRONE_SPAWN = SPAWN:NewWithAlias("DRONE_TEMPLATE", "SPAWNED_DRONE"):Spawn() end end local timer_DRONE = TIMER:New(IS_DRONE_ALIVE):Start(300, 300)

I suggest using MOOSE if you need to handle complex trigger logic. I’ve completely stopped using the Mission Editor’s built-in triggers..they’re just poorly designed. Anyway, a Lua Predicate condition must return either true or nil to be considered valid. It simply executes the scripting engine code written in the text box. The code must include the statement return true for the condition to evaluate as true , that’s basically it. For example: return timer.getTime() > 300 This means the trigger will activate once 300 seconds have passed since the mission started. In short, it’s a way to create conditions that don’t exist natively in the Mission Editor. But be aware: this method checks the condition every second, so it can become a performance killer if you run complex calculations. In that case, it’s better to use MOOSE with a scheduler instead.

As far as I know, it’s not possible. Not even through scripts.

In a S_EVENT_HIT event, the event.initiator can sometimes be the ammunition object instead of the firing unit. Since ammunition objects don’t have a getName() method, calling it directly will return nil. To avoid this, you need to check that the initiator is a valid unit before trying to get its name. This can be done by verifying its object category.

he need a bombing task probably. i have a b52 that launch cruise without any problem but i use moose not mission editor: CONTROLLABLE:TaskBombing Also: the purpose of the AI aircraft's "Reconnaissance" task in DCS it tells the AI that this flight is performing a recon mission, not a combat or transport mission. This affects formation behavior, radio chatter, and ROE (Rules of Engagement) defaults, but does not automatically cause it to detect or report targets. Recon AI flights tend to avoid combat and may maintain altitude and distance rather than engaging You can make the “Reconnaissance” task mean something by combining it with triggers or Lua scripting.

cribob ctld is a bit outdated, better move to moose ctld. anyway, if you want to copy paste your code i can take a look on it, it was some year last time ive used cribob ctld

Hi! You should be able to solve it by adding a trigger that uses "Time Since Flag" together with "Coalition Has Airdrome" as conditions. Since you already have a trigger that activates Flag 1 when Red captures the base, you just need to add a "Time Since Flag 1" = 600 seconds condition combined with "Coalition Has Airdrome = Red". This way, the trigger will only fire after Red has controlled the airbase for 10 minutes. If Blue captures it in the meantime, Flag 1 turns off and the timer resets automatically. Since the trigger is set to Switched Condition, it will start counting again if Red recaptures the airbase later. You can do exactly the same logic for Blue, just reversed. Let me know if this works for you

You can’t use a Mission Editor trigger to remove a group because the groups spawned dynamically don’t exist in the Mission Editor. You need scripting for this. MOOSE is likely the best option: you can use a SET_GROUP combined with FilterPrefixes. For example, every group spawned via CTLD can have the same prefix in their name. Then you can use ForEachGroup to destroy all of them, or just a specific one or more within a trigger zone.

Can you use MOOSE? If not, I recommend moving to it. MOOSE has a function called SpawnNewWithAlias that lets you spawn a group from a Mission Editor template and give it any name (alias) you want each time you spawn it. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Spawn.html##(SPAWN).NewWithAlias

Unit.getByName("Tank") → here "Tank" must be the Unit name, not the Group name. Group.getByName("Tank") → use this only if the Group is named "Tank" in the Mission Editor. I’m guessing the issue is that your unit might already be named "Tank". If that’s the case, let me know so we can fix it properly.

Knowing Lua is definitely a plus, but it’s not super essential when you’re just getting started. Once you understand when to use things like an if statement or a for loop, you’re already halfway there. Of course, deeper Lua knowledge will speed up your workflow and open more possibilities over time. I started scripting in DCS without actually knowing Lua..I began by using only MOOSE. Then Lua came naturally as I progressed, and now I have no issues working with any type of script. Still, I prefer using MOOSE for DCS rather than relying on the native APIs. P.S. Judging by your name, I guess you’re Italian (I am too). Not sure if I can say this here, but if you want, look for “DCS ITALIA” on Discord, we can get in touch there in the future.

use a math.random and set the flag trough trigger.action.setUserFlag https://wiki.hoggitworld.com/view/DCS_func_setUserFlag

Red Alert behavior is a built-in feature. Normally, Red Alert activates automatically when a unit detects a target (either by radar or visually). This state causes the unit to prepare for engagement by deploying all available systems, such as radars, launchers, and other assets. If you manually set Red Alert in the Mission Editor, it simply skips the warm-up phase. Additionally, an ammo truck nearby can rearm systems like MLRS units. The rearming process usually takes around 30–40 seconds, and you can actually observe each missile being loaded during that phase.

You can use MOOSE events to catch when a Dynamic Cargo is loaded or unloaded: MOOSE Docs – OnEventDynamicCargoUnloaded However, this approach has a drawback: all types of Dynamic Cargo will be processed, so you’ll need multiple if conditions to check for the correct delivery zone and the specific cargo models. A much cleaner method is to use MOOSE SET_CARGO: Apply filters to select the cargo types you want to track. Use :ForEachCargo() to iterate over the active cargo objects. For each cargo, check with :IsInZone() whether it’s inside the target zone. If it is, increment a counter (counter = counter + 1). This way, you can implement logic such as: if counter >= 10 then -- build FARP end Remember to reset the counter every time you call the function to avoid counting the same cargo multiple times.

Yes, if you need the ground crew, adding just one Humvee is enough. I did the same thing years ago, I guess you’re using Cribob’s old CTLD. I’d recommend switching to the MOOSE one so you can do cooler stuff, but in any case just adding a Humvee will be enough.

Alright, if you want to achieve this without using scripts and only through the Mission Editor's triggers, I recommend posting in the Mission Editor section of the forum to get more precise answers. That said, I haven't used triggers in a long time myself — I prefer scripting with things like MOOSE — but I believe you can achieve something similar using the "Triggered Actions" tab (on the right side of the group’s settings) when you select the helicopter. Set a task as "Land", then click on "Stop Condition". In these stop conditions, you can specify something like "when Flag X is true". Now, create a trigger that fires after 1 second using "AI Task Push", and select the "Land" task you just created. Then, set Flag X to activate when one of the pilots takes off, so the helicopter will stop the "Land" task and continue with its flight plan. Side effect: At the beginning of the mission, the helicopter will take off, but after 1 second it will be ordered to land at the point you defined in the "Land" task. If you don't strictly need the aircraft to stay on the ground from mission start, and it's acceptable for it to take off for 20 seconds before landing, this can work.

if you still have the problem pleas copy-paste your script to let us check it

next time tell us that 1 second before patch, thanks.

yeah the attribute are manager very wild. null never understand what this means ["IFV"] = {"Infantry carriers","Armored vehicles","Armed vehicles","AntiAir Armed Vehicles","LightArmoredUnits",}, ["APC"] = {"Infantry carriers","Armored vehicles","Armed vehicles","AntiAir Armed Vehicles","LightArmoredUnits",},

mumbling maybe with moose have to try that https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Wrapper.Scenery.html##(SCENERY).FindByName

i have never do that, didnt explore the various command id but i guess if you have to press a button for doing that, that thread can probably be usefull

i dont believe so cause theres no event related to the missile lock itself, as far as i know. the only related event you can use is On Event Shot, i imagine server doesnt need to know that lock event so its probably client side coded inside the plane itself, the only event the server manage is the shot one. source for events managed by sim: https://wiki.hoggitworld.com/view/Category:Events

would be annoying setting up trough mission editor. you can look at moose class autfrag that do that very well https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Ops.Auftrag.html##(AUFTRAG).NewCAP if you cannot script you had to deal with a bunch of flag and ai tasking. when enemy coalition is in zone (flag1) the ai tasking (condition: flag1 on) should be a repetitive loop between two identical wp1 and 2 separate by some nm, both with search then engane in zone when no enemy is in zone (flag1 off) the ai task should be hold\orbit on a wp and may in weapon hold to avoid they to follow untill the end of the map. all trigger and flag had to be settet as switched condition, so they can looping everytime planes eneter the trigger zone and let the flag change.

ive see youre using "rookie" AI as skill, have you tried with Ace or almost Veteran? we see lot of difference with AI behaviour changing that more than trick the task itself, that looks good. the only thing i "know" for experience is the "search then engage" task, is a 1 time call, the group need to be in a reasonable finding range when the trigger start otherwise they didnt found nothing and skip the task. we usually make a bunch of waypoint really near each other with the same identical task so if they miss at the first waypoint they try again and again. as example: waypoint 3 -> search then engage group waypoint 4 -> return to waypoint 3

we have a server with around 1000+ units in it, douring years of testing we found that the biggest and demanding resource for the server are moving units. especially if they move offroad, but also on road have similar impact. it is better to have a single moving group formed by 10 units, than 2 group formed by 5. another big impact on perfomance are the sam shorad , if there multiple sam shorad (or sam tracking\search radar), each radar need to be managed by server. also i think manpad act as well. this is un-scientific and just based on our experience with large server! we have 1000+ units and just 5\6 movable convoy in the entire map as maximum. and usually not more than a cuople of shorad every 20\30nm