Hardcard

Hi Habu weaponType is an internal weapon enumerator that the DCS API uses to select weapons for tasking. It's explained here In this case, I decided to use a combo enumerator, which includes any AG weapons (laser mavs are included in the ASM group): 2956984318 = AnyAGWeapon (BuiltInCannon + GUN_POD + AnyBomb + AnyRocket + AnyASM) [color="Blue"]-- I could've used the following enumerator as well:[/color] 3221225470 = AnyWeapon (AnyBomb + AnyRocket + AnyMissile + Cannons) I've recently learned that, when dealing with tasks, the DCS API doesn't use the "typical" weapon type values that can be obtained using methods like Object:getTypeName() Instead, it uses weird internal enumerators, which are basically numbers... problem is that those enumerators don't seem to be accessible via known scripting methods (at least the ones I know) Fortunately, I found an alternative way to reveal these "hidden" enumerators (other than checking the enumerator list from the Hoggit Wiki, that is :D): 1- Program the task(s) using ME alone (set all the task options to the values you want to know the enumerators for) 2- Save the mission 3- Open the .miz file using winzip / winrar / 7zip, etc. 4- Grab the unformatted file named "mission" and extract it 5- Turn it into a lua file 6- Open it with your lua editor 7- Find the task identifier, all the relevant internal enumerators should be there, indexed in the task table

Or... it means that the group no longer exists / is no longer reachable while it's "embarked", so the DCS scripting engine can't perform any sort of check on it. Let me think... Ok, if the embarking group generates DEAD events when it "embarks" the chopper(s), that could be used to set up whatever mechanic you want, so the CTLD way should be valid. Why can't the units die? Do you have “group is dead” triggers somewhere else? If so, you could modify them so they don't go off when embarking (adding a distance from chopper + flag check to it?).

Are the OSA boats part of a mod? That might be the problem.

Set the hornet group task/role to Anti-ship Strike or CAS, your wingman should engage the speedboats automatically. However, if you want your wingman to start the attack run at a specific moment, you can do the following: - Set the hornet group task/role to something that ignores ground/sea targets, like CAP, Reconnaissance, etc. , this way your wingman won't engage out of turn. - Run the following script at the appropriate moment using a DO SCRIPT trigger (required fields marked in red. Don't remove the quotation marks!): local Boat_Killer = Unit.getByName("[color="red"][i][u]Unit name[/u] of the hornet [u]wingman[/u] in ME[/i][/color]") local Boat_Group = Group.getByName("[color="Red"][i][u]Group name[/u] of the speedboat group in ME[/i][/color]") local Engage_Boats = { id = 'AttackGroup', params = { groupId = Boat_Group:getID(), weaponType = 2956984318, expend = "One", attackQtyLimit = true, attackQty = 1, } } Boat_Killer:getController():setTask(Engage_Boats) - Don't equip the hornet wingman with AGM-65F mavs, the AI doesn't seem to fire them at speedboats. Use AGM-65E mavs instead.

When you spawn a group using MOOSE, its group name changes (since it's actually a copy, #001, #002, etc. will be added as suffix), this might be related to the issue.

Right, I figured as much, that's why I said it might be silly to ask :D Regarding the alarm state thingy for ships, I seem to recall that I used it a few days ago, can't recall if it worked as intended...

@funkyfranky Perhaps it's a silly question, but isn't controller supposed to be written with capital C? As in: Controller:setOption() Thanks for those ids, btw, they'll come in handy :thumbup:

After many hours of testing, I've concluded that AI_BALANCER isn't working as it should. Like you said, all AI aircraft spawn on a single spot, being destroyed in the process, also, :InitCleanUp() seems to remove freshly spawned AI aircraft even when they're active (ie moving). This is why I seldom use MOOSE "automation", it breaks sometimes (due to DCS updates or whatever), also, I prefer to rely on code I can understand and mess with ^^. So, basically, I ended up writing my own ai balancer script (seems to work quite well, although it's far from perfect. Haven't tested it in a multiplayer environment, though). Test Mission + Script file attached. Here's how it works: - A scheduler will perform all the magic every minute (the timer can be set to any value you want, ofc) - Four Su33 clients are available at Novorossiysk airbase - If none of these Su33 clients are active at mission start, four copies of a late activated AI Su33 will spawn (I managed to make them spawn on different slots using :SpawnAtAirbase) If one Su33 client is active at mission start, three copies of a late activated AI Su33 will spawn If two Su33 clients are active at mission start, two copies of a late activated AI Su33 will spawn If three Su33 clients are active at mission start, one copy of a late activated AI Su33 will spawn If all four Su33 clients are active at mission start, the late activated AI Su33 won't spawn (well, it shouldn't) - These AI Su33s are programmed to CAP over Gelendzhik airbase. It's a placeholder task, of course, you can give the late activated AI Su33 any task you want - The script will count the number of active AI Su33s as well as the number of active Su33 clients, then use these values to figure out how many AI Su33s need to be spawned (if any) - If the number of active AI Su33s doesn't match the number of inactive Su33 clients, the AI Su33s will RTB (there's an altitude check in place, to prevent the RTB trigger from activating while the AI Su33s are still on the ground) - I've also included a cleanup routine, the AI Su33s will be removed from the map after engine shutdown (there's an additional speed check, to make sure that they aren't removed if their engines stop while flying) - After all the AI Su33s have been removed from the map (or destroyed), the script will automatically spawn extra AI Su33 copies, just enough to make up for inactive Su33 clients. - The maximum number of active AI Su33s allowed at any one time is capped to 4. - The AI Su33s have 100 spawns available (this spawn value can be set to any number you want, ofc) I haven't tested any of this with the Su33s spawning on the Kuznetsov, btw, it might not work. Here's the raw script: AI BALANCER Test.miz Homemade AI_BALANCER Test.lua

Ok, AI_BALANCER makes sense in that situation. I'll have a look tomorrow, but I recommend that you join the MOOSE Discord channel and have a look at the #ai-aibalancer section (check the comment history). If you don't find an answer in the comment history, then just ask there, chances are someone will be able to help. PS: I just noticed that you're using a client set for the AI_BALANCER. Keep in mind that client sets work with unit names, not with group names. This means that, for instance, if you want to use "279th" as prefix, it must be placed before the unit name of each client, not before their group name

Ok, I've watched it all. Sven wasn't spawning clients using the AI_BALANCER, he was spawning AI aircraft, based on the presence of clients in the mission. Now, if you simply want to spawn 4 AI Su33, you don't need AI_BALANCER for anything.

I'm still watching the AI BALANCER series, sorry. Anyway, I guess I didn't express myself properly, I wasn't telling you to try :Spawn, I was just saying that whenever you need to spawn a SPAWN object, leave :SpawnScheduled or :Spawn for the very end, that's all. Be back in a few minutes.

Regardless, always place :SpawnScheduled or :Spawn at the end of the SPAWN object declaration, in order to avoid conflicts with other methods. I'll take a look at the video now

As far as I know, the only way to spawn clients is by players "entering" the client slots, I don't think client aircraft can be spawned using scripts, that's only possible for AI aircraft (and statics, maybe). If you want to have 4 clients available, simply place them on the ME map (either in the air, on the ramp, etc.) and then set their skill to "Client". They'll be available for players, and spawn when the players "enter" the slots. Btw, the example code contains a syntax mistake: [color="Blue"]-- The final colon shouldn't be there[/color] RU_PlanesSpawn = SPAWN:New( "AI SU33" ):InitCleanUp( 20 )[color="Red"]:[/color] [color="Blue"]-- Corrected line [/color] RU_PlanesSpawn = SPAWN:New( "AI SU33" ):InitCleanUp( 20 ) Also, there's another mistake in the following snippet: [color="Blue"]-- The last colon needs to be removed, also [i][b]:SpawnScheduled[/b][/i] and [i][b]:InitCleanUp[/b][/i] should be swapped (I think):[/color] RU_PlanesSpawn = SPAWN:New( "AI SU33" )[color="red"][i]:SpawnScheduled( 60, 0.5 )[/i][/color][color="red"][i]:InitCleanUp( 20 )[/i][/color][color="Red"]:[/color] [color="Blue"]-- Corrected line[/color] RU_PlanesSpawn = SPAWN:New( "AI SU33" ):InitCleanUp( 20 ):SpawnScheduled( 60, 0.5 )

Could you please describe what you're trying to achieve? Also, what's the problem, exactly? Are those AI aircraft spawning on top of each other and then blowing up?

I hope I'm mistaken, but I seem to recall people saying that the DCS scripting engine can't be used to access controller inputs. As a workaround, I guess you can play around with argument conditions in ME.

There are easy ways of getting target elevation (MSL)... the problem is incorporating the mechanic to the CTLD script (which requires understanding of ~6000 lines of code... :surrender:) Anyway, here's what I use to get elevation readings from units (perhaps you'll find some use for it):

Mi-17 can be equipped with TV3-117VM engines (the same the MTV2 uses) Anyway, I don't know about the future of the Mi-8 module... I'm more interested in this baby

According to the documentation, modex is the tail number of the tanker As for :SetTACAN() you can see what it does also in the documentation

Works for me. You need to click on the tank icon at the bottom of the ME screen.

Is there an object on that map coordinate? Perhaps I'm mistaken, but I don't think you can create coordinates out of thin air, there must be a reachable object on that map spot (a zone would do, I guess). Actually, I'm going to test it, see what happens. EDIT: Ok, looks like I was mistaken, coordinates can totally be created "out of thin air". Now I've just noticed your problem...you are using the wrong syntax for coordinate class, it must be written in all caps (all MOOSE classes are written in caps, remember): coord = COORDINATE:New(-00032476,0,-00129714) In order to avoid such problems, always check the MOOSE documentation. Cheers :thumbup:

Immortality does work for drones (it's just kind of bugged in ME, IIRC). This snippet should do the trick:

If your goal is to save ground units as well as red coalition ships, then you'll need to include additional code in that script (I don't think a separate script is required). But if you're only interested in saving red ships, I think that replacing those two lines should be enough. Hopefully Pikey will come back and clear this up for us.

I guess there shouldn't be a problem then:

I encountered a similar problem last year, while creating a test mission. In the end I decided to use :SetAIOnOff() to prevent 2 fleets of Ticonderoga and Moskva cruisers from attacking each other. Right now I can't remember if that was enough, but I do remember that the ground target zones got pounded by autocannon and tomahawk barrages every time I called for a naval strike. EDIT: After hours of testing several different things, looks like :SetAIOnOff() isn't enough to prevent ships from attacking each other when FireAtPoint is set. Looks like feefifofum's workaround is the way to go (ie making enemy ships temporarily invisible), it does seem to work quite well. I've attached my test mission + script. There's an immortal Su25T client available at Gudauta (ramp), it has an F10 menu available to call fleet strikes from both Red and Blue fleets (they'll aim at a nearby zone). Script: Fleet fire at point AI on-off test.miz Naval barrage specific zone.lua

From the script comments: