Hardcard

First off, convert that wav file to ogg, in order to reduce total file size (this might also fix the issue). Also, post the wav file here, so people can perform tests with it.

The attached MOOSE demo mission (+ script) does what you asked... although it uses quite a few more lines of code :D I've dispensed with :SpawnScheduled( 600, 0.8 ) and InitRepeatOnEngineShutDown(), since they aren't needed to achieve this. I've used :OnSpawnGroup() to handle the DEAD and LAND events for the spawned groups, as well as flag management and cleanup. Basically, you have two late activated template groups in ME (2x F5s and 2x F117s) The F5 group will spawn first, then it'll immediately RTB. When it lands (or is destroyed), a flag checker and a randomizer will decide which group to spawn next (50% chance for each group. 1-5 roll = F5 spawn, 6-10 roll = F117 spawn). I've also included a cleanup routine for the landed aircraft (it'll run after 30 seconds of the LAND event). The F117 group uses the same logic, so it will follow the same steps. This mission is basically an infinite loop: spawn > land > cleanup + randomize next spawn > rinse and repeat... Hope this helps :thumbup: Conditional Random Respawn.miz Conditional Random Respawn Test.lua

@johnv2pt0 If I remember correctly, the problem with using S_EVENT_ENGINE_SHUTDOWN is that it might trigger during flight (due to engine damage). I'd use altitude and velocity checks instead, combined with a flag (which would be tied to S_EVENT_LAND) However, if the OP can live with having each unit in a separate group, then there's no need for a scripted solution (although it would be quicker and cleaner, imho).

Yes, that's doable. You'll probably need to script it, though.

@corvinus I have very good news and pretty bad news. :doh: The good news is that, after 3 hours of insanity and despair, I figured it out (I think). The bad news is that the MOOSE documentation and Moose.lua will probably need to be corrected. 1# What I told you earlier about "compatible" roles is correct. I still don't know what's going on, exactly, but if you pick "Nothing" as a task/role, the AI group(s) will simply ignore the scripted task and RTB. During my tests, I've been able to confirm that the following roles/tasks are "compatible" with :TaskBombingRunway() (meaning that they won't interfere with it) : - CAS - Ground Attack - Runway Attack - Anti-Ship Strike - AFAC - Pinpoint Strike 2# :TaskBombingRunway() REQUIRES that the attacking planes carry UNGUIDED BOMBS or/and HEAVY UNGUIDED ROCKETS (light rockets and guided bombs/missiles won't be used against runways). If the attacking aircraft carry guided missiles/bombs and/or light rockets only, they'll RTB. NOTE: The target airport can be set to neutral, :TaskBombingRunway() doesn't seem to care. 3# The MOOSE documentation for :TaskBombingRunway() seems to be incorrect. #number AttackQty is NOT an optional parameter, it's absolutely required for the controllable(s) to actually perform the attack (btw, the Hoggit Wiki also seems to be incorrect in this regard). I discovered this while scripting the task following the Hoggit Wiki method: 4# In order for :TaskBombingRunway() to work, I've had to modify my Moose.lua (build 2.4.13, the mission version). Line 28070: Line 28075: Don't ask me how or why, all I know is that after making these changes, :TaskBombingRunway() started working. I'll report this over the MOOSE discord channel, see if the gurus can explain what's going on. Btw, I've attached a couple of versions of my test mission (both of them use the modified Moose.lua) The first version uses the DCS (Hoggit) tasking method, the second version uses the MOOSE tasking method. Both of them work as intended. IMPORTANT NOTE: The task can't be pushed immediately at mission start, otherwise the AI groups will RTB. They must be allowed to follow their initial waypoints for a few seconds. That's why I've used a scheduled 10 second delay in the attached test missions I hope this helped! :thumbup: Runway Attack test (DCS Tasking Method).miz Runway Attack test (MOOSE Tasking Method).miz

@corvinus I'll give it a go tomorrow, see if I manage to get it working... For now, have you tried using AIRBASE:Find() instead of AIRBASE:FindByName()? From what I see in the MOOSE declaration, AIRBASE:Find() lets the DCS scripting engine find the name of the airbase for you (needs the airbase object reference as parameter, though). Chances are it won't change anything, but who knows? Scripted tasks are rather touchy :D Anyway, as I said, I'll give it a go tomorrow.

I encountered a similar issue last month. Turns out that in order for scripted tasks to work, the relevant AI groups must have a "compatible" role selected in ME (under "TASK" slot, that is). In my case, :TaskAttackGroup() only worked when the relevant AI groups had CAP/CAS roles assigned in ME...otherwise they'd simply ignore the scripted task and RTB. I your case, I'd try assigning CAS / Ground Attack / Runway Attack roles to Airplane group in ME, see if your script works. (Btw, you can delete the automatically generated waypoint actions if you want, scripted tasks should work regardless, the group's role setting is what really matters).

Use a group/unit set that includes all blue coalition planes, then iterate the set with a zone check (which includes an altitude check as well). I don't know MIST, but this is how I'd do it in MOOSE: This is pretty much the same as having a 70ft high cylindrical zone centered 100ft off the ground, I guess. Just translate this concept to MIST and problem solved! :thumbup:

@Grimes Thanks for the explanation and for the getDesc().life, it'll come in handy! Unfortunately, I've noticed some discrepancies in the returned life values of certain statics. I've attached my test mission, here's the script it runs on (no errors in dcs.log): Is the description table out of date? It's a real pity, this is really useful stuff :cry: Weird life reading discrepancies.miz

Glad I could help! Careful with that method, I don't recommend dispensing with DEAD events. From what I've seen in my tests, sometimes the static objects are destroyed even though their last HIT life readings are greater than 0 (their life becomes 0 after the HIT reading happens, I think). For instance, in my percentage test mission (from the other thread) you'll notice that Tarawa is destroyed even when its last HIT life reading is ~5%. So (if I understand what you're doing), if you make a check like... function Attacker:OnEventHit(EventData) if Tarawa:getLife() == 0 then Tarawa is ded! end end ...it might fail to detect the static's destruction in situations where its last HIT life reading isn't 0. That's why I'd rather use the DEAD event, you can't go wrong with that one. :thumbup:

You might have solved a really annoying problem with this! Have you shared this already in the MOOSE discord channel?

@CougarFFW04 If you're interested, I've modified my test mission from the other thread (yet again) in order to obtain the "life status" of all static objects (except for the two Sea Shelf Objects, which aren't supported). I'm attaching the two modified versions here. The first version will provide the raw numeric life value for each static object when it gets hit (as well as the rest of data you requested in the other thread). NOTE: You'll get spammed with status messages as bombs hit several static objects simultaneously...sorry about that Here's the script it uses: The second version will provide the raw life numerical value for each static object at mission start, then you'll get their individual life values in percentages, as they get hit (as well as the rest of stuff you requested in the other thread). NOTE: You'll get spammed with status messages as bombs hit several static objects simultaneously...sorry about that Here's the ugly script it runs on (I had to do it this way because I couldn't make :getLife0() work with the static objects): Hope this helps!:thumbup: OnEventDead Static Test life numerical.miz OnEventDead Static Test life percentages.miz

@Grimes Hi there Grimes! I've been trying to make :getLife0() work with static objects (to help CougarFFW04), but it keeps generating the following scripting error: attempt to call method 'getLife0' (a nil value) However, :getLife() works like a charm. Here's my test script: After struggling with this for hours, I went back to your wiki and noticed something that might explain this behaviour. According to the documentation, :getLife0() isn't available for classes other than Unit (so it can't be used with Static Object or Scenery Object classes). On the other hand, :getLife() seems to be available for Unit, Static Object and Static Scenery classes (that's probably why it works with the statics in my test mission). Can you confirm this? (Or just explain what might be going on) Thanks and happy new year! :thumbup:

Ok, after some more tweaking and testing, I've managed to create a script that does exactly what you asked (it uses event HIT instead of event SHOT, btw). I've attached the modified demo mission + script. Whenever a static object is destroyed, you'll receive a message indicating its ME name, the coalition it belongs to and the ME unit name of the aircraft that destroyed it. Here's the modified script: EDIT: StaticSet was using the wrong class, I fixed it and uploaded the corrected files OnEventDead Static Test v3 (corrected).miz OnEventDead initiator test (corrected).lua

It's in the MOOSE documentation, specifically, Core.Event section Yes, it's a "MOOSE thing", but keep in mind that all frameworks use DCS scripting engine functionalities in the end. Frameworks are meant to make things easier, not harder :smilewink: I don't know that either. All I can tell you based on my tests is that flags belong to category 3, just like static airplanes, helicopters, vehicles, ships and structures. I've added a couple of flags for each coalition to the demo mission (on the runway), also, I've expanded the script so it'll return the coalition value for destroyed statics as well (except for sea shelf objects). 1 = Red coalition, 2 = Blue coalition. Expanded script: As far as I can tell, event DEAD will only give you access to information about the static object that was destroyed, it won't tell you who destroyed it (I'm not 100% sure, though). If you want to know who destroyed it, you'll have to use event SHOT instead. This will complicate things, but it's doable. OnEventDead Static Test.miz OnEventDead initiator test.lua

Su34 and Su24, for instance, but they're not flyable.

I've tested this using MOOSE and noticed that statics can't be captured using EventData.initiator (since that returns a table value...in MOOSE, at least). However, I managed to capture them using EventData.IniUnitName instead (except for the new "sea shelf object" statics, which only seem to work with EventData.IniObjectCategory ) I've attached a MOOSE demo mission + script. (Whenever a static object is destroyed, you'll get a text message indicating its ME name, type and category. In the case of sea shelf objects, only their category will be indicated) Here's the script: You can use this capture method to create elaborate "alive checks" for each static object (I'd use flags and name checks for that, I guess). Hope it helps! :thumbup: PS: Check out the new Su34 model in the mission, it looks great! OnEventDead Static Test.miz OnEventDead initiator test.lua

@BlackLibrary Heed the word of MOOSE master funkyfranky. @funkyfranky :worthy: @Everyone

@Swany Sure, :ForEachGroupPartlyInZone() can be used instead. I didn't use it precisely because of what you mentioned: "as each one (client) enters the zone, it'll trigger (the message will be sent to all the clients in the group, regardless of them being inside the zone)" I assumed BlackLibrary wouldn't want clients outside the zone to get the message, :ForEachGroupCompletelyInZone() ensures this doesn't happen, since it'll only run when all clients in the group are inside the zone. The fundamental problem here is that the DCS scripting engine doesn't offer "message to unit" functionality, so workarounds must be used. Another possible solution would be to put each client in a separate group, that way both :ForEachGroupPartlyInZone() and :ForEachGroupCompletelyInZone() would work exactly as requested.

I've never scripted a radio transmission before, but, according to the MOOSE examples, this should do the trick: Btw, you made a small mistake (which would generate a scripting error): There's no "if" logic in the script example I gave you, but I think I understand what you mean. Sure, you can store the radio transmission in a variable and then broadcast it whenever you please. Example: Hope this helps :thumbup:

Hi there! There are several ways of doing this. One of them would be to include the helo client groups that you choose in a SET_GROUP, then iterate that set so only the client groups that are within the zone will get the message. For instance, this script example should do the trick (includes usersound + ship flare): If you need this to run continuously, put it inside a scheduler.

@Chopper A-10 Molniya corvettes will fire at incoming missiles with their AK-630 rotary cannons, not with their massive cruise missiles. @baltic_dragon Ticonderoga class cruisers will attack both ground and naval targets using tomahawks. However, the massive cruise missiles Molniya corvettes and Moskva cruisers are equipped with, won't be fired against ground targets, only against other ships. At least that's how it used to work when I tested it several months back. @GrizzlyBear83 In order to get Molniyas to attack statics in the sea, try placing inactive enemy ships inside the static (if possible). See if that does the trick :megalol: They should automatically fire their massive cruise missiles as long as their alarm state is red. Also, the enemy ship should be within firing range (but not too close, otherwise the Molniyas might use cannons instead of cruise missiles) AND within missile firing angle (the ship's bow should be roughly pointing towards the target). Also, as I mentioned, this problem only seems to apply to Russian ships, US ships will fire pretty much at everything with their tomahawks.

I think that the cruise missiles they carry are only meant for enemy ships. They won't be used against statics.

I appreciate the fact that you're trying to help people, however... You don't need to filter voice tracks 4 times in order to achieve a radio-like sound. Just run an FFT filter once (kill all frequencies except those in the 400 - 4000Hz range), then mix that with a static noise track on the background. And yes, you're correct, in order to hear the voice tracks properly in-game, it's a good idea to boost dB (while capping max amplitude, in order to avoid unwanted saturation) EDIT: I've attached a zip file containing a couple of radio message examples from my training mission project (yes, I know, she can be quite cold :cry:) Cold_Flight_Instructor.rar

Weird, AI SEAD works when I use it in the Caucasus map (I don't own the PG map, so I can't take a look at your mission, sorry). For, instance, you'll see that SEAD AI groups in this test mission actually engage the AA groups. As I said, I think that those "attack group" waypoint actions that you have in the screenshot might be causing trouble, try removing them and work with "search then engage" instead. Also, I guess it wouldn't hurt if you put that waypoint 5 closer to the AA groups.