Grimes

Can't reproduce on my end. Can you attach a miz that generates the error? Would be extremely helpful.

At somepoint this will change. There is a dedicated LSO score event that will eventually be added.

Bazar: Older art assets for the core game are in there. Dates back to LOMAC era even if the models aren't that old. Coremods: Eventually ED started adding models in a more modular file structure, so any 3rd party and most new models and other relevant files get added there. For example lua files to define the AI aircraft, new weapons, etc in addition to the models, textures, and sounds. Saved games/DCS/FolderName for the most part mimics your main install. This is where any custom object mods and liveries should go. The idea being running cleanup or updating the game won't overwrite the files, you know everything in there are mods, and the files generally won't cause an integrity check failure.

The way you have it setup is not how you cancel an AI's task. You are pushing a deactivated new task, hence it does nothing. You have to add a "stop condition" to a given task and then make that condition occur. Easiest way is to set a flag value. The CAP task, and every task that is automatically assigned, will take precedence over any others that you add. Its basically the "search and engage" task with default settings. So if you had the default CAP task, then added a "search and engage in zone", the AI will just engage any aircraft that is detected regardless of whether it is in the zone or not because it was told to do that. Your ROE tasks are all in triggered actions and at least in that version of the miz they are not called.

I've reported it as a bug a couple years ago, I think Mbot might've posted the original report on the forums. Its one of those things I'm not sure if the behavior had changed at all or if this is indeed the intended behavior. For instance it would be kind of annoying if it was a "max dist from self" check that could result in the AI constantly discovering and chasing new targets. Granted they'd likely die before they get that far. The point is to restrict where it is allowed to attack. Right now that means its only checking the distance along a given route, it should do that, but also check distance from self and only attack if both conditions are met. At least thats what I think it should do.

It is still advantageous to know what exactly any sort of wrapper script is sending the scripting engine. As for why its not working, I'm not sure. It appears you are just taking a task as generated by the editor and copying it to your script, which is usually extremely reliable and a great "starting off point" for modifying a task via scripting. Only thing I am curious about is if in your testing the ME placed group had roughly the same exact waypoint positioning as the spawned group. I say that because there is a known behavior of the maxDist setting where it doesn't apply to where that group is right now, but to any point throughout their route. So if that enemy awacs was ever with 50nm of the route they would see it as a valid target to engage. Attributes have the same meaning, but you have MUCH more flexibility with the scripting engine in this regard compared to the editor. This flexibility is entirely down to 1. Editor doesn't list all attributes. For example the editor just has "fighters" and "bombers" for airplanes, but you can specifically tell a flight to only hunt AWACs, tankers, transports etc if you wanted to. This is extremely useful with SEAD tasks because you can just give AI a task to engage search and tracking radars but to ignore the launchers. 2. You are not limited to the scope of attributes allowed for a given task. For example if you wanted a flight to self escort you can allow AI to engage fighters at longer distances but still target sams or ships within the same task.

Yes, but it isn't very practical if you plan on using it a lot. The gist is to use the trigger action "X: Set Command with Value" at or learn mission start. Another part of the impracticality of it is figuring out what the command Id for a given instrument should be. I recommend looking through the training missions that cover the instrument and trying to figure it out that way.

Its possible via the scripting engine but each solution is effectively a workaround to the same core problem. The problem being there is no full proof way to know if you have detected a target, so you have to find a way to relay coordinates to assign an AI flight to do something. 1. Easiest method would be similar to what Jezzer suggested. Only difference being that you create a F10 menu for a specific group and then whenever that option is chosen it passes who called it to a function, which can then use the coordinates of that unit assign an AI task. 2. Same premise but with the mark panels and using event handlers to track where they are created and maybe search for a string value in it. 3. The most direct way would be to use an event handler to track weapons fired, if someone fires a smoke rocket then it tracks that rockets position and calculates its impact point to assign targets for the AI.

The track in my reply is your mission. Perhaps the only difference behavior wise is since I tested without having my HOTAS plugged in I just gave the radio command and watched the AI do the attack. But in my quick test with me as flight lead the AI did drop all their bombs in one pass.

Couple of things. 1. The AI isn't really programmed or currently meant to have the player aircraft be a wingman. 2. It works when the player is flight lead and you tell the AI to do the mission. See my track and screenshot, those are the bombs the AI drops with me as flight lead. 3. The bug fix for multiple JDAMs had to do with the timing and behavior of the drop. It only impacted a few aircraft types due to the number of bombs needed to drop in a single pass. If I recall with the old behavior the limit was about 7 bombs per pass if you had 7 targets. The tacview screenshot has a different target for each bomb and shows the results of the fix. do_mission_rejoin.trk

It is in DCS World\Doc\DCS User Manual <language> 2020

As far as I am aware the functionality has not yet been added to the aircraft avionics. The UI is implemented, nothing more.

It doesn't matter what the saved games folder is named. As long as the slmod files are in the correct location it will work. Best guess is you aren't running the server as admin and slmod can't modify the missionscripting.lua file. Would need to see logs to get an idea of what is happening.

https://wiki.hoggitworld.com/view/DCS_func_destroy would be the primary way to go about doing that. Could use an event handler to check for certain events (or just periodically check all aircraft), check if the aircraft is on the ground, and then use destroy() on it if the conditions are right.

I am not 100% certain what the purpose of this event is for. What I mean is there are multiple events that basically mean the same thing, crash, dead, kill, and unit lost. Each with slightly different information for the most part. Its either a single event that will occur no matter if a unit generated a crash or dead event OR its for something else entirely. I'll check it out.

Not sure about the EWRS script, I've never used it. The respawn/clone/teleportInZone functions are more meant for ground units with no route. If you used my example you can get their existing route data via mist.getGroupRoute(gpName, true). newGroup.route = mist.getGroupRoute('whatever', true) Now the important thing to keep in mind with all this is that the route data is what was assigned and setup in the editor. Coordinates of waypoints and tasks won't be shifted. The solution is to either shift them similar to what I did with each unit in the group or create a new flight plan and tasks based on what you need them to do. Which can be done either by assigning a task directly or assigning a mission task which has their flight plan and other tasking information.

It depends on how complicated you want to get with it. At a simple level you can use either mist.cloneInZone or mist.respawnInZone for a group and it will randomly spawn those units somewhere within a given zone. Something a bit more complicated would be to use something like mist.getGroupData, figure out a new randomized point however you want, change the coordinates for that group, then spawn it. It'd be something like this: local newGroup = mist.getGroupData('whatever') local newPoint = mist.getRandPointInCircle('whateverPoint', 'whateverRadius') for i = 1, #newGroup.units do newGroup.units[i].x = newGroup.units[i].x + newPoint.x newGroup.units[i].y = newGroup.units[i].y + newPoint.y end mist.dynAdd(newGroup)

The on destroy event setting is limiting when that check will be run. Literally anytime someone is destroyed it'll run that check, not necessarily if that specific unit you are checking was killed. Also you can't remove the wrecks of any objects that are destroyed, so that script won't work. As for why it is removing other objects, that does sound weird. Make sure all the object names reference the individual object you actually want to remove and within the condition for each. Could add a message for each to see if they are getting triggered or if for some reason StaticObject.getByName('someObject'):destroy() is destroying other objects, then please attach the mission.

This is long reported.

As far as I can tell the mod works without issue in DCS 2.5.6.55960.

I think it follows the same priorities that AI use when engaging targets. Fire and forget missile> Fire and forget bombs > laser guided> Dumb munitions (in order of explosive power) > Guns.

Need to know the exact version you are running. On Friday I didn't test a fix fully (rev 138), which I then hotfixed on Sunday (rev 139). Build 139 should be ok. If it has issues you can always go back to the previous build of 137 from the end of September.

Try to save the mission as a new file name. It should only appear if a single unit was placed form the asset pack. But once you remove that object and save again it should delete it from the requiredModules table within the miz. If all else fails you can edit the miz manually and remove that entry. I do it all the time when people post missions with bugs that use and require mods.

The silkworm isn't something that you can just tell it to blindly fire at a point, at present it requires a target. As for artillery, as long as the target point is between the min range and max range of the unit it should engage. If the target point is outside the range of motion of the turret/launcher the unit should move itself to get into firing position. If it doesn't could always try changing the orientation of the unit to see if it shoots.

It is in plain text. Just load it in the editor and copy the text out of the do script box.