Hardcard

Try reaction to threat = evade Also, I can see several "attack group" waypoint actions in that screenshot, they might be interfering with SEAD.

Create a thread here, for instance.

@SpecterDC13 Have you reported this issue?

@Chafer Keep in mind that programming stuff based on RPM gauge readings can't be done unless the relevant gauge argument is accessible via ME trigger (I don't think this is the case for the F-15C). The DCS scripting engine can't access cockpit arguments, unfortunately, so this can't be done using scripts either. It's better to adopt a simpler approach, like Rudel_chw suggested. EDIT: I've managed to get the F15C's RPM gauge arguments using model viewer Left RPM indicator needle = Arg 16 (80% RPM = 0.750) Left RPM indicator first number = Arg 525 ( no number = -1.000 or 1.000 ) Left RPM indicator second number = Arg 526 ( number 8 = ~0.800 ) Left RPM indicator third number = Arg 527 ( number 0 = -1.000 or 1.000 ) Right RPM indicator needle = Arg 17 (80% RPM = 0.750) Right RPM indicator first number = Arg 528 ( no number = -1.000 or 1.000 ) Right RPM indicator second number = Arg 529 ( number 8 = ~0.800 ) Right RPM indicator third number = Arg 530 ( number 0 = -1.000 or 1.000 ) In order for all the F15C cockpit gauges to show up in model viewer, you'll need to do the following: 1- After installing model viewer, navigate to --> Gamedir\Mods\aircraft\Flaming Cliffs\Cockpit\Textures. There you'll find the file "F-15C-CPT-TEXTURES.zip" You'll need to extract all the textures within that zip file and put them in--> edModelViewer installdir\Bazar\TempTextures 2- Once that's done, navigate to --> Gamedir\Bazar\Textures, then copy the folder "HUD_FILTER_DS" and paste it in --> edModelViewer installdir\Bazar\Textures (actually, "F-15C_Cockpit_HUD_texture.dds" should be enough, but nvm) Model viewer should be able to load all the cockpit and gauge textures correctly after that's done. Btw, in order to open the F15C cockpit model with Model Viewer, simply do---> File > Load Model... > navigate to "Gamedir\Mods\aircraft\Flaming Cliffs\Cockpit\Shape" > Select "Cockpit_F-15C.EDM" and open it. Model viewer will give you the list of textures and arguments for that model. Problem is that there are 1000 arguments, you'll need to test them one by one in order to identify them. But, as I said, looks like ME doesn't care about F15C cockpit arguments, so this is kind of pointless :cry:

Sure, it's completely understandable. The thing with scripting is that it requires keeping up with changes in the DCS scripting engine. Sometimes ED will make changes that break some scripting methods, so workarounds must be found...that's certainly a nuisance :mad: Unless you have a "coder" who checks and updates the scripts, things can get really messy, as you pointed out :cry: Good to hear that you've found a working solution, have fun! :thumbup:

That depends on the mission. Also, keep in mind that writing 100 lines of Lua is quite straightforward (once you know the basics) and takes less time than creating 100 ME triggers with all their flags and conditions. Complex ME triggers can be merged into a single scripted function and/or just a few lines, that's powerful stuff. I can get considerably more stuff done per hour if I script a mission, instead of using ME triggers. I mean, handling complex conditions/actions for specific group / unit sets using ME triggers is already a time consuming task (quite maddening too). That same stuff can be achieved with a dozen lines of code, in 5 minutes or less, without the need for those dreadful trigger lists (where each trigger becomes a needle in a haystack, pretty much). Besides, creators are quite restricted when using ME triggers, much less so when using scripts. Despite what you might think, scripting is faster and less painful (when it comes to programming complex missions / mechanics), it's not that hard to learn either. But ultimately, as you pointed out, to each his own. If you find that ME triggers are less challenging to work with, go for it :thumbup: As for script performance hit, I guess that depends on the amount of continuous schedulers / checks present in the script. Anyway, in order to investigate the script performance hit, you'd need to use the same server, with the same clients, at around the same time. First record performance using the ME version of a given mission, then do the same using a scripted version of it. If you don't do that, you have no way of knowing what's actually causing the performance hit. Personally, I've noticed that the amount of units, trees, buildings, rockets, missiles, explosions, etc. contribute the most to performance hits.

I'd recommend a scripted solution too. Btw, is there a particular reason you didn't take screenshots?

"Stubbornness and OCDs aren't flaws as long as they lead to useful places" -Hardcard's motto- :megalol: (hey, I might even use this as signature) PS. Btw, I just realized it's "advanced (waypoint actions)", not "advanced waypoint actions" :doh:

Hi Delta99! As I already mentioned in our previous Discord conversation about this, the scripts worked all the same with or without the advanced waypoint actions you are referring to. Script 1: local Attacker = GROUP:FindByName("Name of the attacker group in ME") local Target = GROUP:FindByName("Name of the target group in ME") local AttackTask = Attacker:TaskAttackGroup(Target) Attacker:PushTask(AttackTask) Script 2 (zone restricted behaviour test): local Attacker = GROUP:FindByName("Name of the attacker group) local ZoneUnit = Attacker:GetUnit(1) local FlightZone = ZONE_UNIT:New("Flight_Zone", ZoneUnit, 10000) SCHEDULER:New( nil, function() local Target = SET_GROUP:New() :FilterCoalitions("red") :FilterCategoryAirplane() :FilterCategoryGround() :FilterStart() if Target:AnyInZone(FlightZone) then Target:ForEachGroupAnyInZone(FlightZone, function(Target) local AttackTask = Attacker:TaskAttackGroup(Target) Attacker:PushTask(AttackTask) MESSAGE:New("Target in zone!\nAttacking!",10):ToAll() end ) else local HoldPosition = Attacker:TaskHoldPosition(30) Attacker:SetTask(HoldPosition) MESSAGE:New("No targets in zone!\nHolding Position!",10):ToAll() end end, {}, 1, 30 ) I tested these (and several other versions of them) with and without ME roles + with and without the role advanced waypoint actions. They only work when CAP, CAS, etc. roles are selected, regardless of advanced waypoint actions being present. Now, I won't argue with you, Grimes or Sven about what's actually going on. I just tested :TaskAttackUnit() and :TaskAttackGroup() and noticed that they only work when certain ME roles are selected (again, no visible ME advanced waypoint actions involved). Not trying to be a smartass here, just trying to understand how it works :thumbup: EDIT: Just thought it would be helpful to attach a test mission as well (it runs on script 2). As you can see, the F15C group doesn't have any advanced waypoint actions, in fact, there are no waypoints (really!), yet the programmed behaviour works. And yes, I've also tested it with waypoints (Waypoint 0 and waypoint 1 ), same results. However, if you try using "Nothing" or "Reconnaissance" roles instead, it won't work anymore. Why? :dunno: Engage any bandits in moving zone.miz Task attack any in zone.lua

If you tell us what you want to do, exactly, we can show you ways of scripting it. Personally, I don't own the PG map, so I can't even open your mission in ME. However, if you post a Caucasus / Nevada version (using standard DCS units, preferably), I'll be happy to show you how to convert all your ME triggers into a single script. PS. The way flags (and other things) are handled in ME is pretty confusing and unpractical, if you ask me. One of the advantages of scripting is that it allows you to easily keep track of logic and structure (once you know the basics, that is). I mean, scripting is already worth it by the simple fact that it frees you from those endless ME trigger lists (where finding stuff alone becomes a challenge). It doesn't just empower you, it saves plenty of time and helps you keep your sanity :D

Hi Sven! Yes, I already tried that during my tests and noticed that it didn't work, same happened with "Reconnaissance" and "Nothing" roles. At first I had assumed that scripted tasks worked independently from ME roles, but looks like this isn't the case. After several hours of tweaking and testing, I noticed that setting AI roles to CAP, CAS, etc. allowed them to attack (problem then was that I didn't know whether it was my script handling the AI behaviour). Then, I checked the Hoggit Wiki documentation and found this: Available Under: CAS, CAP, Fighter Sweep, Intercept, SEAD, AntiShip So I concluded that :TaskAttackUnit() and :TaskAttackGroup() were linked to ME roles. Finally, I restricted :TaskAttackGroup() in my test mission to a moving zone, in order to see whether the AI was actually following scripted behaviour... turns out that it was! Thanks for confirming it! :thumbup: PS. Would it be possible to note this in the MOOSE documentation / intellisense? I think that would help prevent confusion.

Make backup copies of your key mappings, custom missions, etc. then delete your DCS folder over C:\Users\UserName\Saved Games\DCS Also, you can try repairing your DCS installation using cmd: Gamedir\bin>DCS_updater.exe repair See if that does the trick.

@A Hamburgler There are several problems involved as far as I can tell. First off, this will only define the task, it won't execute it: Grp:TaskAttackUnit(Unit) In order to execute it, you'll need to store that task in a variable and then set/push it: GrpTask = Grp:TaskAttackUnit(Unit) Grp:PushTask(GrpTask) [color="Blue"]--OR[/color] GrpTask = Grp:TaskAttackUnit(Unit) Grp:SetTask(GrpTask) Unfortunately, that only seems to solve half of the problem. The other half is that :TaskAttackUnit() and :TaskAttackGroup() don't seem to work. EDIT: After more testing, I've concluded that :TaskAttackUnit() and :TaskAttackGroup() work, but only if the attacking group has one of the following roles assigned in ME: CAS, CAP, Fighter Sweep, Intercept, SEAD, AntiShip From what I've seen, CAS seems like the best option, since it can be used for both air and ground targets. In any case, I wouldn't use :TaskAttackUnit() or :TaskAttackGroup() if I were you, there are better / more practical ways of handling AI behaviour (ROE, Alarm states, zone detection, etc). Btw, if someone can provide an explanation of why :TaskAttackUnit() and :TaskAttackGroup() only seem to work when specific roles are provided in ME, I'll be grateful!

@Silvern It's linked at the bottom of the post you quoted earlier. Anyway, I'm attaching a newer (and more complicated) version of the script + test mission, which includes respawn mechanics and AI aircraft removal after landing. In a nutshell, the script allows for randomized SEAD evasion mechanics (as long as there are no SEAD bandits within 15Km of the AA groups.) If there are SEAD bandits inside the 15Km killzones, the AA groups will stay active until the area is cleared (this can be changed, of course). SEAD bandit groups are allowed to spawn 6 times, AA groups are allowed to spawn twice (blue) and thrice (red). They'll do so when they're completely destroyed. Perhaps you'll find some useful bits for your own missions :thumbup: PS. Comment out the event messages if they get annoying! SAM_PARADISE_MOOSE v3.miz SEAD Test (Ad Infinitum).lua

@Silvern I already reported the issue over MOOSE github. I'll use my script in the meantime, it works pretty well :thumbup:

I'd definitely play such a campaign, sounds like a great idea! :thumbup: However, pitting hornets and hogs (especially hogs) against BF-109s and FW-190s seems hardly fair :D Based on a GrimReapers' dogfight test I watched on YT, I believe that hornets might struggle in dogfights against WW2 fighters, but hogs perform better, thanks to their tight turn ability (that's what I recall anyway, might be wrong! :doh:). Found the video! (it's both informative and fun to watch) Btw, how did you manage to program the time slowdown? Sounds like a pretty interesting feature, tbh. Nah, that doesn't work, it returns the following DCS scripting error: 21: attempt to index field 'x' (a number value) If you want to modify the returned Vec3, here's one possible way of doing it (I've tested it and works for me):

I don't think so, this will return Position3, I believe :SpawnFromVec3 needs Vec3 instead. After some testing, I got it working with the following code: local Group = GROUP:FindByName('Player') local GroupVec3 = Group:GetVec3() [color="Blue"]--Gets Vec3 from the group leader[/color] local SpawnAirplanes = SPAWN:New("Airplane") :InitLimit( 20, 10 ) :SpawnFromVec3(GroupVec3) Now, if you want to get the Vec3 from a unit other than the group leader, you can do this instead: GROUP:GetUnit(Number of the unit):GetVec3() Hope this helps. What is it exactly that you're trying to accomplish, btw?

Yes, that's the easy part. The problem comes when programming AI behaviour. To my surprise, I've managed to pull this off with relative ease using MOOSE. I've attached a simple MOOSE demo mission + the simple MOOSE script it runs on. A flight of two F15C will engage ANY red plane/chopper groups entering a 60Km moving zone (F15C group leader acts as the center of the moving zone). The script has a "bandit in zone" check that runs every 5 seconds, when a bandit group is detected, the F15C will engage. If no enemy groups are detected in zone, the flight will hold position for 5 minutes (probably more than that, though). This behaviour will be repeated until the F15C flight either enters bingo fuel or runs out of it (I guess). The first catch is that the F15C flight needs to be told what to do at every step... failure to give it a scripted task will lead to immediate RTB. The second catch is that the script will stop working if the F15C flight leader dies. EDIT: Btw, I've done some more testing and looks like the F15C group will only engage if its role is set to either CAP or CAS (the scripted attack task won't work otherwise. I've no idea why) Engage any bandits in moving zone.miz Task attack any in zone.lua

Lately, I've been playing around with SEAD evasion mechanics for AA groups. In the process, I've noticed that the MOOSE SEAD functionality for this doesn't seem to work: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Functional.Sead.html##(SEAD).New According to the MOOSE documentation, this should be enough: SEAD:New({ 'name of an AA group in ME', 'name of another AA group in ME', etc... }) However, this doesn't seem to disable AA group radars when anti-radiation missiles are fired at them. Also, AA units only seem to move the first time there's an explosion nearby, they seem to stop moving after that. Out of curiosity, I opened the declaration for the MOOSE script example above and found something odd (possible bug?): As far as I know, EventData.WeaponName doesn't actually return the string values specified in the last line, it returns different ones. For instance, for Kh-58U missiles, EventData.WeaponName will return the string "weapons.missiles.X_58" instead of "KH-58". Same thing applies to the rest of missiles listed. If this is indeed an error, then that last line should look like this: Am I missing something here? Is Functional.SEAD still WIP? PS. Btw, this is the MOOSE SEAD evasion script I've been working on. Plenty of room for improvement, but the results look promising so far.

After some more work, I've been able to make substantial improvements to the previous script. This new version successfully captures the initiator SEAD group when each anti-radiation missile is fired. Thanks to this, SEAD evasion mechanics for each coalition are now handled independently. Additionally, the script now supports ALARM anti-radiation missiles as well (Panavia Tornado). PS. I've also dispensed with the MOOSE SEAD functionality, since it doesn't seem to work :cry: SAM_PARADISE_MOOSE v2.miz SEAD Test v2.lua

@Sport Well, well! After a couple days of work, I've been able to produce a decent SEAD evasion script using MOOSE. It doesn't follow the triggers from your mission, but it gets all the job done in a single script. The attached demo mission has a couple of large AA group concentrations (one for each coalition). Six AI SEAD groups are set to attack them (3 groups per coalition). Those AA groups are positioned at the center of their respective zones (70Km and 15Km), which are used by the script in order to handle the SEAD evasion mechanics. The SEAD evasion mechanics will be set in motion whenever one of the following anti-radiation missile types is launched within a zone: -Kh-58U -Kh-25MP -Kh-25MPU -Kh-31P -AGM-45A -AGM-45B -AGM-88C -AGM-122 Sidearm When any of those missiles is launched within any of the 70Km zones, the relevant AA groups will perform an "evasion roll" in randomized time intervals (between 60 and 180 seconds). There's an 80% chance of success for each roll (this can be modified by the user, ofc). Now, if the evasion roll succeeds, the relevant AA groups will adopt a green alarm state (aka become inactive) for a randomized amount of time (between 60 and 180 seconds). This will be repeated for as long as the SEAD bandits keep firing anti-radiation missiles and remain outside of the 15Km zones. However, if SEAD bandits enter any of the 15Km "killzones", the relevant AA groups will become permanently active (until the killzone is clear). PS. Since this script also uses MOOSE SEAD functionalities, mobile AA units will randomly disperse when under fire as well. :thumbup: SAM_PARADISE_MOOSE.miz SEAD Test.lua

Sounds like a good idea, but keep in mind that some MOOSE event catching methods are known to cause problems (according to my own experiments and replies I got over the MOOSE Discord channel a few months ago). Of course, there's always the possibility that I might have used some of them incorrectly and that the replies I got over the MOOSE Discord channel were inaccurate. Black listed (These never worked for me): White listed (These have worked for me): As for the rest, I've either never tested them or simply don't recall the results. :doh: Also, I recall that :UnHandleEvent(Event) caused a MOOSE error (which I reported). Haven't tested it lately, though. It would be great to get input from the "MOOSE grownups" on this one. :helpsmilie:

Look for DCS scripting engine / MOOSE errors in dcs.log, you might find clues there. (If I had to bet, I'd say that you're getting nil call errors when trying to handle those events). At first glance, I see that AISirriCap isn't declared anywhere in the snippet. If you have declared AISirriCap somewhere else, include it in your snippet as well, for clarity. Also, I'm not convinced that you can use SpawnGroup the way you did (might be wrong about that, though). In any case, I wouldn't use events as triggers if I were you (some of them tend to cause problems), I'd use schedulers + checks instead. For instance, instead of :OnEventDead, you could use:

@Sport I believe MOOSE has this kind of behaviour already built-in. https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Functional.Sead.html I've never used it, though. Might look into your mission tomorrow, see if I can reproduce your trigger logic in a single MOOSE script. EDIT: Can you change the A-4E-C aircraft in your mission to something DCS generic like Su25T? Your mission can't be loaded unless the A-4E-C module is present.

@SeaFoam342 Two months ago I created a simple MOOSE demo mission which allows a set of clients to spawn different ground vehicle templates randomly inside a couple of zones (all done via F10 menu, as many times as you like). You might find it useful. Post + demo mission + script