Hardcard

@Sierra99 According to intellisense and the documentation, the second parameter in :SetSquadron() must be a string (the airbase name) rather than the object. Checking the MOOSE declaration, I've seen that MOOSE automatically runs AIRBASE:FindByName() for you, with the given string parameter. So, instead of this: A2ADispatcher:SetSquadron( "Stennis",AIRBASE:FindByName( "USS STENNIS" ), { "ALERT 5" }, 20 ) Try this: A2ADispatcher:SetSquadron( "Stennis","unit name of the carrier in ME", { "ALERT 5" }, 20 )

@TLTeo Follow the instructions given in (it shows an older MOOSE version, but the procedure is the same). You'll find the latest MOOSE release here (the source code is required to set up LDT, Moose.lua is the file you'll be including in your DCS missions)

Interesting stuff! :thumbup: How did you discover canSwim and canWade? Are they listed somewhere? Btw, there are ways in MOOSE to spawn infantry at sea without the need for canSwim = true. :SpawnFromUnit(), :SpawnFromStatic(), etc. can be used to spawn infantry on ships and statics placed at sea. However, the problem is still the same, they will spawn on the sea surface instead of on the carrier's deck. I also tried stacking static buildings inside the carrier, in order to provide a "solid ground" (just below the deck) so infantry units can walk and helicopters can land... limited success so far, infantry units have trouble reaching the buildings on the top.

@Sierra99 Try using the unit name of the carrier AIRBASE:FindByName("Unit name of the carrier in ME")

@Bruce_D It's a pity that :getLife() won't work with runways. As I said, you can try placing tiny statics on the runway in order to achieve the desired behaviour. Other than that, I'm out of ideas :doh:

You know what? This makes for an interesting test, I'll try now and let you know :D EDIT Short answer: It's not possible Silly answer: You can place a static Tarawa on land and put the troops inside the 3D model. Since the static Tarawa has no collision box, troops and helicopters will be able to clip through it without problems... So, in a sense, the helos will pick up troops from the Tarawa :D

That's weird :huh: Did you do it like this? SPAWNSET = SET_GROUP:New() :FilterPrefixes({"GRP1-", "GRP2-", "GRP3-"}) :FilterStart() Yes, the values must be given as strings but, afaik, this --> "GRP1-" is as valid a string as this --> "GRP". I think that numbers and dashes can be included in strings without a problem. Yup, that was the easiest solution. I didn't mention it because I assumed you had other groups named "GRP..." in your mission, which you didn't want included in the set. Anyway, glad you got it working in the end :thumbup:

The "life 2" value is what I get from the runway description table, it's not a real-time "life reading". I think you got the life value from the description table of another object (your plane maybe), when it initiated a different event (a SHOOT event, for instance). That might be where the 3600 came from. :getLife() is the method we'd use to get the real-time "life reading" of objects, but it only works for units, statics and some scenery... afaik, it doesn't work for airbases/runways. EDIT: Ok, I stand corrected, the following line does return a value of 3600: local BatumiLife = Airbase.getByName("Batumi"):getDesc().life But again, I don't think this is a real-time "life reading", I believe it's still reading from a fixed table.

@Sierra99 Careful with the syntax, A2ADispatcher: isn't a class, AI_A2A_DISPATCHER: is. Here's the parameter info according to intellisense: AI_A2A_DISPATCHER:SetSquadronCapInterval(SquadronName,CapLimit,LowInterval,HighInterval,Probability) Were you asking for this? https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/AI.AI_A2A_Dispatcher.html##(AI_A2A_DISPATCHER).SetSquadronCapInterval

As I said, there's no way to get a real-time "life reading" from runways. That only works with units, statics and some scenery. When you run :getDesc() you're simply accessing a fixed table of attributes. If you do :getDesc().life, you're only getting the theoretical max life of the runway "on paper", so to speak. It's not the real-time life value, which is why I told you it can't be done (as far as I know). It's looking more and more like your best bet is to either stick with the script as is or to place tiny static objects on the runway, so HIT events can be generated.

Guys, I'm trying things out right now. So far I've discovered that bomb impacts on the runway simply don't generate any HIT events. HIT events are only generated when the bombs hit lights and other objects located on the runway. DEAD events, however, are triggered every time the runway is hit after being "destroyed" (that's my best guess anyway). You'll see none of this in the briefing log, you need to get the event data real time in order to see it. I'll get back to it now. EDIT: Ok, so, since HIT events ignore runway impacts, and since there's no way (that I know of) to get a real time "damage/life reading" directly from the runway or to track bomb coordinates, I think a compromise is needed. For instance, you could place small static objects (like tiny flags) along the desired runway, then use them to raise HIT events as bombs hit them. That way you could trigger the ME flag before the runway is "destroyed".

That's why I wrote the script for you, instead of telling you to write it yourself :D Anyway, all you need to do is introduce the group and zone name prefixes that you're using in ME. Then simply run the script via trigger in ME, as usual (you'll also need to run Moose.lua using a mission start trigger in ME). Required fields are marked in red (don't remove the quotes, just modify what's marked in red): I'm only offering you this scripted option in case you don't find a way to make the helicopter flight behave as you want using ME triggers.

You don't need to do that, it's a very simple script anyone can put together ;) If you want to give credit to someone, give it to Grimes, I couldn't have written that script without the help of his great Hoggit Wiki As for the screenshot you posted, if you take a look at the "Target" column for HIT events, you'll see "BLOCK_WALL". Unfortunately, I'm afraid that's a placeholder value, it doesn't show up during the simulation, so we can't use it in the script. Also, if you take a look at the "Details" column, you'll see that HIT events contain different weapon information as well (might be a problem too). Now I'll repeat my bombing tests using HIT events as well, see if I can find a way to make it work.

@Zayets Let me walk you through the process I followed to come up with the script (hopefully that'll clear things up): 1- I started off with a general DEAD detection script which captured the initiator name, type and category of ALL objects in the airbase (as they were destroyed) 2- I had all that information sent to me real time via text messages (I seldom rely on the event data from the debriefing screen, since it only shows part of the picture) 3- I set up an AI runway strike (a Su34 with lots of 250Kg unguided bombs). 4- I analyzed the incoming initiator name, type and category data of all DEAD events as the bombs hit the runway. I only got category 4 initiators, with type and name corresponding to the name of the airbase. 5- Then I set up a regular AI bombing task with the bombs dropping on areas around the runway (hitting lights, vehicles, static aircraft, etc.) That returned all sorts of initiator categories, types and names, but none of them corresponded to the airbase. So, as you can see, using the airbase as initiator name and category 4 wasn't an arbitrary decision on my part, I simply followed the real time data I had gathered during the bombing tests. Now, sure, we'll need to come up with another solution in order to monitor runway damage rather than destruction. Tbh, I hadn't expected the HIT event to capture so much useful data, perhaps that's the way to go.

@Mano I might have made a silly mistake, sorry... Try replacing the SET declaration: SPAWNSET = SET_GROUP:New() :FilterPrefixes("GRP1-", "GRP2-") :FilterStart() With this one: SPAWNSET = SET_GROUP:New() :FilterPrefixes({"GRP1-", "GRP2-"}) :FilterStart() If it still doesn't work, try this one: SPAWNSET = SET_GROUP:New() :FilterPrefixes("GRP1-") :FilterPrefixes("GRP2-") :FilterStart() If it still resists, try this:

Are you sure that this has nothing to do with the AI plane hitting bingo fuel? (Just throwing ideas around, I'm not familiar with runway repair mechanics in DCS) Don't quote me on this (it's been a while, I might easily be wrong about this), but I seem to recall that unguided weapons like the mk-82 bomb don't generate HIT events (weapons are not captured by HIT events, that is). SHOT events do capture the initiator, weapon and target, but I'm not sure unguided weapons return a target...(I'd swear only guided weapons do). That should be doable, we'll see if we can crack the puzzle...tomorrow! :sleep:

@Bruce_D I don't think I understand the problem. What do you mean by "the runway stops working"? If no aircraft are allowed to use the runway for 1 hour after dropping those mk-82 bombs, I doubt very much it's because of the script. Could be normal DCS behaviour after a runway attack. All the script does is check DEAD events and trigger a flag if the conditions are met, nothing more. If you are interested in knowing the amount of damage dealt by both the mk-84 and mk-82 bombs, I think I'll be able to help with that (tomorrow, though). Although I don't know how that would solve your "runway not working for 1 hour" problem.

No life value in the description table I'm afraid, that's why I went directly for the DEAD event, which I knew it could trigger by dropping bombs on the pavement. If you need help setting up further restrictions, let me know, I'll see what I can do :thumbup:

@Zayets The script works as advertised, I've tested it several times before posting (as usual). Regarding the check: if InitiatorName == "Batumi" and InitiatorCategory == 4 It won't return true unless the initiator name is "Batumi", which is quite restrictive (I added the extra category check because...why not? :D). As far as I could tell during my tests, bombs falling outside the runway didn't trigger the flag. But sure, you are correct, further constraints could be added in order to avoid unwanted results in certain situations. Now, regarding the runway "not dying", bomb impacts trigger the dead event just fine, it just takes several bombs to damage the area sufficiently.

The ME flag name/number must be given as a string value, not as a numerical value. In other words, it needs to be surrounded by either ' ' or " " Replace this line: trigger.action.setUserFlag([i][b][color="Red"]1[/color][/b][/i], 1) [color="Blue"]-- sets the desired flag to a value of 1 [/color] With this one: trigger.action.setUserFlag([i][b][color="red"]"1"[/color][/b][/i], 1) [color="blue"]-- sets the desired flag to a value of 1[/color]

This script works for Caucasus airbase runways, should work for PG runways too (can't test it since I don't own PG map): It can be used to do all sorts of things every time the specified runway is damaged. As is, it only sets the value of the specified flag to 1 every time a part of the specified runway is destroyed (ie cratered) Let me know if it doesn't work, some tweaking might be required, but the concept should still be valid.

This short MOOSE script should do the trick: I've attached a test mission + script file. A group of 2 blackhawks will land near Kobuleti, pick up infantry troops, then head to the airstrip south of Kobuleti and deploy them there. Helicopter Transport test.miz Chopper Transport test.lua

Your diagnosis is correct, the script can't find the spawned groups because their names don't match. When dealing with spawned groups in MOOSE, don't use :FindByName(), since that'll target the late activated group templates in ME, not the spawned groups themselves. If you want to work with the spawned objects, there are several options available. You can either try the solution that Itzo proposed or you could do the following:

Try adding :InitCleanUp(), see what happens. Btw, I don't think you should remove posts that contain interesting questions/problems, if you do, there will be no record left in the thread. Imagine someone stumbles with the same problem next week... your post will be gone, along with the solution to the problem. How did you solve it anyway?

:InitLimit(1,1) simply means "spawn 1 unit at a time, spawn it just the once", there's nothing wrong with it. Again, I've tested it, the script worked fine for me, no errors (which means that the problem is probably elsewhere). Same results with both versions: [color="Blue"]-- SEPARATE LINES[/color] Plane = SPAWN:New("Plane") Plane:InitLimit(1,1) Plane:InitSkill("Average") Plane:Spawn() [color="blue"]-- TRAIN WRECK[/color] Plane = SPAWN:New("Plane"):InitLimit(1,1):InitSkill("Average") Plane:Spawn()