Grimes

Viper Launch needs to be a switched condition. In the screenshot it is a "once" so it'll only set flag 2 off one time. Should also add the condition flag 2 is true to it. Viper Landing is fine, but you should then add the action setting flag 2 on. Effectively flag 2 would act as a toggle where it only checks the relevant conditions when you want it to. All flags start as 0 to begin with. Don't even need to set a value in order to use it. You could just set flag 2 on at the start and leave flag 1 being zero. Then change the flag 1 equals 5 to 4 to reflect the actual value you are wanting it to be. Might be a little easier than having to remember that you offset it.

Only used it to modify the editor with it all being trial and error. Usually looking at similar files for what I want to modify and going from there. Donno if there are any decent guides out there for it. Might look at the scratchpad mod for in game usage. But keep in mind it is just that, a mod. https://github.com/rkusa/dcs-scratchpad

Should be doable if you launch the mission as "prepare mission" and save the results. Though I honestly don't know what all that saves and for which aircraft. It'll also only work in singleplayer.

goToWaypoint is the task for ground and ship groups. Switch waypoint is for aircraft. I need to report the crash issue because it is easy to get them mixed up and it should be handled. Out of curiosity is waypoint 10 the landing waypoint? If it is then try setting it to 9 or add a waypoint over the base. AI ignore the task if told to go to a landing waypoint.

It depends on the lua environment and what is intended to be accessible at a given point in time from what you are accessing it from. A lot of the lua files from mission editor and scripts folders get loaded when the game starts or at the very start of mission loading. More over it is meant to be separate and different from the mission scripting environment. Only a few script files from there get loaded into the mission env. Its why if you "dumped _G" from mission you won't see any code related to the UI scripts. Likewise if you tried to access _G from the server environment it would be different from the mission env.

_G is always accessible, so you can read it just fine. io is needed to create and write to a given file. lfs isn't strictly required, its just really useful because lfs.writedir() returns the folder location of DCS in your saved games. Suppose you could always write given entries to the DCS.log, but there are plenty of use cases where that would be effectively useless. If you had a client side script that uses the gameGUI api then you have native access to io and lfs. Although I don't recall the differences of _G when checked from the server env compared to the mission env.

There are some long existing feature requests for scripting info on cities and forests. For each the best you can do is to setup some area definition as a disallowed zone. Get a random point, see if its in a city/forest zone, then allow or deny spawning there. With cities you can be a little more creative with code and depending on your needs can be relatively simple or add some extra processing. For example you can use world.searchObjects to return scenery objects near a given point. If its really simple you can just check how many objects are in the area, more than 10 it is probably a city. If you want more details you can use getDesc and getPosition on the returned objects then do some math on the box parameters with orientation and point from getPosition to figure out the rough area the object takes up. Now you can do a pointInPolygon to verify a random point you want to place the unit isn't occupied by a building.

Say you have a table that is global you can assign table entries as what gets returned by adding a command. table = {} table["Columns"] = missionCommands.addSubMenu('Columns') table["One column"] = missionCommands.addCommand('One column', A,function() trigger.action.setUserFlag('C1',1) end) table["Two columns"] = missionCommands.addCommand('Two columns', A,function() trigger.action.setUserFlag('C1',2) end) table["Combat missions"] = missionCommands.addSubMenu('Combat missions') table["Mission 1"] = missionCommands.addCommand('Mission 1', B,function() trigger.action.setUserFlag('M1',1) end) You could then call a given table entry when removing the menu you want. missionCommands.removeItem(table["Columns"]) table["Columns"] = nil -- best to delete it

Yeah the low detailed 3d models don't have ramp spawns so it defaults to spawning on the catapults.

Hit events are somewhat common on ships in MP unfortunately. It is usually desync related. The Vinson has an LOD problem, but the ship is also being phased out. You may have noticed you can no longer select it in the mission editor. It simply exists in the game files but isn't meant to be placed anymore with assorted bugs seemingly accumulating over time. The F-14 and E-2 issue is related to runway starts. Its best to stagger the spawns of aircraft set to take-off "from runway" on the carrier either with timing, forcing use of a given catapult, or use ramp spawns. The Su-27 we have in game is not capable of using the carrier and the editor will not let you place it there to take-off or land. Either you have an editor mod allowing it, an aircraft mod, or you are spawning it there via scripting which won't stop you from doing it, but also won't force AI to use it as you might expect. Yeah I would characterize that one as urgent or at the very least important and worthy of a track/sample. AI ships have some annoying tendencies but if a ship can get stuck going in a circle then that is a problem

The tables you are passing it aren't valid, but also aren't nil. The tables stored within A1 and A2 for example are actually this: { [1] = "Columns", [2] = "One column", } { [1] = "Columns", [2] = "Two columns", } However if you wanted to remove both of those at the same time you could just pass missionCommands.removeItem({[1] = "Columns"}) or effectively what is stored in A if you save that variable somewhere.

Lead unit on hold task behavior is now reported.

Case in point with something critical being different, you started the convoy with a hold task while I didn't notice that and never added it in my attempt to recreate it. Thankyou for posting the mission file it has made things easier to diagnose. It is a little weird because with your mission it took about 5 minutes to test a few theories and find a possible solution. Then followed by at least 20 minutes trying to re-create it on another map and completely failing to do so. Such is DCS AI and who knows what other contributing factors. What I can gather is that speed appears to be a heavily contributing factor. This worked on your mission but not in another test mission I created for that specifically, but simply adding a waypoint at a slower speed prevented the convoy lead from meandering. For one reason or another that change didn't apply to my isolated test mission. I ended up moving the hold task to a waypoint just after the start in order to show the problem. Which might be a more reliable solution until the bug with hold on initial waypoint is addressed. https://gfycat.com/welcomelimitedlabradorretriever As for the infantry, I'd have to experiment with it some more because I don't use ED's built in tasks for troop transport. Best guess is that the embarking task isn't treated as a hold task and they are actively looking for a transport which requires some initial movement.

Yeah you can see the infantry doing something weird, but its a blob on the map. It isn't unheard of for AI to do something strange purely out of weird object placement, but I can't tell what is going on, and that is where a mission file would be really helpful. Yes videos can provide some insight into behavior, but seldom as the primary source. Without the mission I had to figure out which map it was on and the location based on different clues. Thankfully the city name "Arizona Village" and a river were visible so I could narrow the search to southern NTTR. However attempting to recreate the mission has its own flaws like not precisely matching unit placement, waypoints, tasking, and other parameters. At the point of coming off as rude its why you see people ask for a track or a miz file. At best the same behavior happens on our end and its an easy bug report. At worst we can see the general idea of what might be happening and experiment on a mission where it has been known to occur. By all means if you get the behavior to occur with default units then upload the mission. But I was under the impression the AI are intending to drive west... https://gfycat.com/singleannualcarp nullLiveries won't change AI behavior, but there are clearly unit mods in the mission. You can safely upload missions with missing liveries anyway. My game will just choose something by default. Mod units are another issue and I can't debug a mission where they are the source example of a bug. If there were static object sandbags someplace that were left in I'd just mod the editor or delete the file requirement to load the mission. Hence why I've asked for a file with default units showing the problem.

Donno about the infantry since the video didn't really focus on them and I can only do so much to recreate a mission without a miz or track file. It is a moot point anyway due to there being units from mods in the mission. The unit type does matter because units have different sizes and turning capabilities. What? I said the units are oriented south, object avoidance kicks in, and thats why there is some general weirdness with their pathfinding. In 2.7.18 the initial setting doesn't work, but in 2.8 it does. In both version you can insert a waypoint for the AI to be pointing toward. Which allows for the AI to start facing the direction down the road and generally avoids the problems with the off road collision detection. Yes and I said that was a bug. For reference this is what they do in 2.7.18 when told to hold. They want to form a line based on the heading of the lead unit. In 2.8 the points they want to park at is correctly on the road, but don't follow the road to get there. I'd imagine the only change made is that they corrected the point where to go and nothing changed with how the AI try to get there.

There are two facets to this. One is an easy fix and the other is similar to an existing bug report for ground AI and the hold task. 1. For one reason or another the ground AI always face the direction of their next waypoint even if starting on road and if that waypoint is on road. As you can see in the video all of the ground AI drive south slightly and then some chaos ensues due to pathfinding issues in object dense locations like cities. Which is a whole subset of other issues. Anyway its an easy fix by adding a waypoint on that road or by ticking the "Initial" box to force AI to orient with the road. If you add a waypoint then you'll note that the rear of the convoy will drive west-ish toward it, but probably won't meander because its an empty field with no obstacles. 2. For the hold task the AI want to stop where they are expected to be in a given formation. The bug being that they will go off road to get there. Due to the chaos, in general the unavoidable concertina effect of convoy movement, and the road layout results in the AI near the back of the convoy will be out of position. Said AI then make a B-line for that coordinate rather than following the road to get there. Then the aforementioned issues with AI driving through cities kicks in. I updated the existing bug report. In it they did the same thing but the difference was they formed a line based on the heading of the leader, so you got results where there is a line of AI stretching off road. That part appears to have been accidentally fixed, but the "going off road to get there" is still around.

The coalition is no longer a factor now. Any of those units providing a given service just need to be on the team and in the radius. You can have a red humvee provide ATC for instance.

Yeah the page that is linked from is what gets updated. https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation . Click on the class, singleton, or whatever you want to see the relevant pages. Could also browse via the categories like: https://wiki.hoggitworld.com/view/Category:Scripting I'm not ever going to change the Part_1 and Part_2 pages because those are kept purely as a historical document of how ED documented things previously.

Was more referencing how mist does it where the group name and as a byproduct the group object can be directly accessible from the unit database. But why would you loop to count them when you have the group name? Remove the -## and Group.getByName(string):getSize() would be way more efficient.

Reported. You have the unit name and unit Id, it isn't impossible to figure out the parent group. Its just annoying.

Here is a way to do it. local player = Unit.getByName("player"):getPoint() local target = Unit.getByName("b747"):getPoint() -- mist.utils.getHeadingPoints is basically the same thing your code does. local angle = math.deg(mist.utils.getHeadingPoints(player, target)) + 15 -- add 15 degrees because each oClock is a +/- 15 degrees. Without it a target at 179 would reutn as 5 o clock local oClock = math.modf(angle/30) -- divide it by 30 and math.modf returns two values, the first being the integer and the 2nd being a decimal of a give number. Only care about the first here. if oClock <= 0 then -- if its 0 or lower somehow change it to 12 because there is no zero o clock. oClock = 12 end

It was fixed on development build back in July: https://github.com/mrSkortch/MissionScriptingTools/commit/2c54802861b97bcd581664d4f9e23191fd72539c I should probably merge it to the main build.

Donno if that is pointed toward Grayflag, but the intention is to do it eventually. That said I think there is a difference between hosting a server and posting code that is compiled/redacted for anyone to use. One is trying to get people to join a server that has assorted costs with running it (and the exclusivity of that code) and the other is posting code with the intent for others to use. One of those is trying to extract a competitive advantage and other is kinda being a dick about it.

In general there have been some oddities with simply relying on checking Group.getByName to know if a group is actually dead. There is a mist function mist.groupIsDead that you can use that handles the exceptions to the rule. if mist.groupIsDead(groupName) == true then -- do code to respawn group or whatever. end

That I don't actually know. I honestly have never tested what statics do when placed on late activated ships. Yes their position as saved in the editor will be there either as the X, Y coords or as an offset table.