Grimes

I did a thorough test on this. Usually no4 has the most extreme behaviors. Look for the more uniformity in their paths for the "best" at formation keeping behavior. https://imgur.com/a/TLFegLW

It is a DCS problem in general. The only workaround is something I wouldn't quite call a workaround, more of an exploit of the current logic by reusing existing units in the mission. Say you have a JF-17 placed in the miz file, you can use coalition.addGroup and re-use the unit and group names/ids. It could be halfway across the map from where it was placed, but to the game its still the same unit. The debrief screen might then know what that unit is.

The debriefing screen has never been great at dealing with anything spawned via scripting. It is simply a symptom of that longstanding problem. Initiator being the unique id, without other data for instance.

Static objects can block a given spawn point from being used if it is close enough the the spawn area. Here is an A-10 assigned to take-off from one parking spot, but the static object effectively blocks it, which results in the aircraft being spawned one parking spot over in the mission itself. Best to move the static objects away from where you want the aircraft to spawn at and gradually move them in until it moves the unit. Then you'll know you've gone to far.

Yeah it has been reported.

The AI take-off priority is pretty easy to figure out. For multiple groups the order is based on the taxi distance of the flight lead from the start of the runway. Then each group will taxi based on that order. For example in the screenshot below the top aircraft is closer to the runway, but has a longer taxi distance to get there. In this instance the aircraft with the blue path will taxi first. Additional wingmen add an extra rule, but it is still straight forward. Within a given flight the taxi order is always based on the flight member with it being 1, 2, 3, 4 regardless of location. The next flight will wait until the last wingman of the current flight begins to taxi and is closer to the runway. Using the screenshot again imagine if the blue path AI has a wingman at parking number 5, lets call it "blue 2". The red path AI will taxi almost at the same time as blue 2 because the path of blue 2 is still shorter than the red path AI, and it won't need to wait. It gets annoying if blue 2 is parked someplace further away from the flight lead. In one instance lets say blue 2 is at parking 120. The blue path flight lead will taxi, once it passes 120 then blue 2 will start to taxi, and then red path AI will taxi with little delay. Likewise if you put blue 2 way up in the north eastern corner of the base it will taxi at the same time as its flight lead, but the red path AI will wait until blue 2 is closer to the runway than itself. That said there are plenty of other nuances to AI taxiing behavior that are partly down to general AI rules and even how airbases themselves are setup. You can create a empty mission, slap some AI down, set the wind, and you can easily experiment with how unit placement impacts take-off order.

getRunways returns a table entry called "Name" that gives you the heading name. But it doesn't account for parallel runways. You should have enough data there to derive it via code if needed.

Think it is just the S-60 and KS-19. The value you are thinking of is the one below. Don't know the specifics but comparing it to other entries the "none" likely signifies that it can attack on its own, but may be less accurate or limited to its own sensors. The 2nd input likely refers to the type of dependence or what it provides. __LN.depends_on_unit = {{{"SON_9", 4}}, {{"none"}}}

Sadly no. Best you can try to create an explosion on the ship, but I don't have the math to get precise outcomes.

You have to make sure the markId is unique when you create it. The second input value is used as the id, and you have it being the same for both. You can use the mist.marker.add function to create it if you don't want to have to manage it yourself. local ref = trigger.misc.getZone("Novo") trigger.action.circleToAll(-1 , 1, ref.point , ref.radius , {1, 1, 1, 1} , {0, 0, 0, .2} , 1 , true) local ref = trigger.misc.getZone("Krymsk") trigger.action.circleToAll(-1 , 1, ref.point , ref.radius , {1, 1, 1, 1} , {0, 0, 0, .2} , 1 , true) You could pretty easily use world.getAirbases and the base capture event to draw the circles as needed.

Nope. Depending on the mission date it is either present or its not. There is a file you can embed into a mission where you can customize the satellite information, but it isn't clear which aircraft, if any, rely on this data. Possibly it could be limited to the KA-50 since it has that page on the ABRIS that shows satellite data. But again its a fixed value with no way to modify live in a mission.

It is the task queue. The FAC task needs to be completed before the options are set. So move the options to the top. https://wiki.hoggitworld.com/view/DCS_editor_FAQ#Why_isn.27t_an_AI_task.2C_option.2C_or_command_working.3F

Try running a repair on the game files. Do you have any mods installed? If so disable them, especially if it is an mod that adds an aircraft. Its odd if helicopters work just fine because they use the same file. So I think it would be a problem with the radio information it is trying to get. Does it occur just when you open the menu or only once you place any aircraft?

https://wiki.hoggitworld.com/view/DCS_func_isActive

The kilo doesn't have torpedos in game. You have to use either the WW2 sub or the Chinese sub.

Run the game as admin to ensure that the missionScripting.lua file is correctly updated.

They changed the name of the ROE settings. By assigning a search then engage task it is assigning a target that applies to the "only designated" setting. Basically a "do what you were assigned to do" as the setting. The two settings above it, priority designated and weapon free, allow it to attack other targets. For example if you have a SEAD flight tasking it could more proactively attack air threats. Priority designated simply means it will do SEAD first then worry about air threats. -a means it was automatically added. There is an -x that appears when the enabled box is unchecked.

That is probably a mission triggers thing more than it is AI.

Appears to be bugged. Just spotty with the types of trees it wants to remove and where. Looks like it is also suffering from an existing bug where it treats a sphere as a box to remove objects.

Post a track here for now. Knowing the target unit type and what it gets shot by is helpful for this sort of thing.

Deactivate is the same as destroy. This is where scripting is helpful because you can "respawn" groups an infinite number of times and get the same desired effect of deactivating and reactivating a group.

Yeah that has been another one of those longstanding behaviors that we can't really do anything about. Best we can do is to try and match it up as close as possible. I'll see about re-raising the issue.

Your function used this local sw = trigger.misc.getZone('SW') Mine was: local sw = trigger.misc.getZone('SW').point

https://github.com/mrSkortch/DCS-miscScripts/tree/master/ObjectDB

local foundUnits = {} local sw = trigger.misc.getZone('SW').point --- might as well be point local ne = trigger.misc.getZone('NE').point -- again ne.y = 10000 local volB = { id = world.VolumeType.BOX, params = { min = sw, -- you were doing {[1] = sw.point.x, [2] = 0, [3] = sw.point.z} instead of {x = sw.point.x, y = sw.point.y, z = sw.point.z} max = ne, -- again } } The vec3 table was being indexed numerically rather than x, y, z. Took me longer than I care to admit to realize that. Then when I did I just directly called the sw and nw tables while forgetting to specify point. Anyways it works.