Grimes

Have to push a new mission task to the group. https://wiki.hoggitworld.com/view/DCS_task_mission Should be as simple as creating a waypoint where the aircraft is currently at and then another at the airbase in question. local unit = Unit.getByName("cargo") local uPoint = unit:getPoint() local ab = Airbase.getByName("Krymsk") local abPoint = ab:getPoint() local rtb = { id = 'Mission', params = { airborne = true, route = { points = { [1] = { type = "Turning Point", action = "Turning Point", x = uPoint.x, y = uPoint.z, alt = uPoint.y, speed = 650, -- 350 knots }, [2] = { type = "Land", action = "Landing", x = abPoint.x, y = abPoint.z, alt = abPoint.y, speed = 650, -- 350 knots airdromeId = ab:getID(), }, } } } } unit:getGroup():getController():pushTask(rtb)

Short answer is it can't be forced. Right now its in "additional properties" tab which can be set, but for HMD, Night Vision, and a few other properties the player can change it via ground crew. Hopefully some things will be moved to the weapon loadout panel so it can be restricted as needed. Best guess that the Apache's FCR might be the first to get this treatment, but its difficult to say for certain.

Use trigger.action.effectSmokeBig instead. https://wiki.hoggitworld.com/view/DCS_func_effectSmokeBig

Go to Waypoint is a bit different than following a route. The AI will try to directly drive to that point and ignore any waypoints you have setup. If you ditched the go to waypoint task and told AI to use off road to their destination you should see the exact same behavior as with the go to waypoint. Since they need to cross a river the AI will find the nearest point to cross that is valid for the group contents. The Bradley could "wade" through the river, but the bridge is the closest so it chooses that instead. I moved them just a tiny bit north and you can see the change that had. https://i.imgur.com/EEvdb4x.mp4 If the river is more substantial then it will need to be crossed via bridge unless the unit is amphibious. This is closer to what you are seeing in your mission where the AI choose to use a bridge, but less than ideal behavior occurs. In your case they get stuck. In this case it looks bad. Either way it appears the AI drive to the start of the bridge without caring how to actually drive across it. I would need to double check to see if there are any existing reports on this. https://i.imgur.com/YQQYjF7.mp4 Thats normal, the group always faces their next waypoint. Suppose its a weird quirk, but it is relatively minor. edit; need better embed support on the forum.

You do realize that the path assigned via scripting is in the same format as the editor right? Yes it is unreasonable to be given a large mission and having to figure out where and how their code works. However if one provides the group and route table which get passed into 2 scripting functions it is simple enough to report.

Reported. He could have had a little better logging, but that nil printed value corresponds to what was returned, which is nothing. Not a bug, getDesc is a static table that only gives information about the object type and nothing about that specific object in the mission.

Just need the location of the bridge, group composition, and destination. If you know how fast they are going is also helpful because I reported a bug earlier today where the speed of the group changed where they got stuck on a bridge. I can spawn in the same units easily enough via scripting and give them the appropriate task.

I take it you meant to say you can't report it because the mission is generating random groups in random locations going to random destinations which is useless for reliable testing and not that you can't report it simply because the route was assigned via scripting right? Because AI should have the same behavior if given a path from point A to point B regardless if it was assigned in the editor, Combined Arms, or via scripting. Civilian traffic isn't AI, they can only follow the line that defines a road and are not effected by threats, need to slow down to turn, or can navigate on their own. The only "logic" civilian traffic possess is to stop if the bridge was destroyed. That said bridges have long been an issue of some sort going back to LOMAC. Some of the time it is straight forward that you can create a new mission, place a group with a route, and observe them getting stuck on a specific bridge reliably. Most of the time however it is any number of other factors that seem to cause issues. Factors like group composition, speed they were going, if any threats were near, SP/MP, and total number of units in the mission can play a role. There is one bridge on PG where a group would more than likely get stuck at on Grayflag, but the problem only ever occurred in MP and no matter what I tried they never got stuck in single player. If you see AI stuck on a bridge then we need the location of that bridge at minimum. Maybe we can get AI to get stuck there reliably and potentially find a bug with their behavior.

Not 100% certain it is a bug. In your script you use Unit.getByName():getController():setTask(). I bolded unit because trigger.action.setAITask uses the group controller. If you change your script to assign the task via Group then it will work as expected. The part I'm not sure about is the behavior of the follow command when tasks get assigned to the unit controller. 1. 1 ship, task assigned to Lead results in follow task ends 2. 2 ship, task assigned to Lead; Follow unit switches to number 2. 3. 2 ship, task assigned to no2, Follow unit keeps following number 1. 4. 2 ship, tasks assigned to both at different times, Follow unit task ends It seems to be similar to the behaviors of when giving multiple tasks via Group and Unit controllers within the same group. Meaning if you used only unit tasks then the wingmen will forget to rejoin when the tasks get complete because the lead unit no longer has a "group" level task for them to rejoin on. Edit, fun fact I only realized this upon remaking the mission on Caucuses for the bug report. Only then did I notice the use of the "unit" controller instead of group because I instinctively wrote a test task and used Group.getByName.

Please post a mission file. Even with the best description there is no guarantee that I will recreate it in the same exact way as you did to reproduce the bug.

AFAIK they are unlimited for now. The warehouse info isn't saved in the mission file, its in the warehouse file within the miz. Thus there aren't any input parameters right now to define the warehouse functionality.

Post the server's DCS.log file. Usually there is a message in there about model not being found and then replacing it with the leopard. Could be as simple as needing to run a repair or update the dedicated server install.

Yeah you can get the heading of the object via getPosition and some math. One of the inputs for spawning a unit is a heading value so you just assign it to whatever you got as the heading. IIRC I had to offset the heading value by 90 degrees and the position slightly to better align the units. local unitpos = unit:getPosition() local heading = math.atan2(unitpos.x.z, unitpos.x.x)

The nice thing is all of those revetments are objects that can be detected via scripting. Vast majority don't have anything in them. It is a very easy way to randomize object location without having to do extra calculations to ensure the objects aren't blocking a runway or anything like that. Simply search the area for that object type, filter objects as needed, and use their coordinates to place the dynamic group you want. Wish more maps had stuff like that. Sinai has some, but it is a lot more bespoke for certain system types and requires a little more work due to how it is implemented.

Yes, they are part of the map. In the editor and on the F10 map you should see icons somewhere near the base that designate the warehouse objects. Unfortunately the icons disappear if you zoom in to much. The cylinder type icon represents fuel stores and the circle with lines sticking out are the ammo and aircraft storage. Typically if you see the same object with multiple icons in the area then each object will be a warehouse object, it simply isn't drawing an icon for every single object. Due to these objects being placed on the map itself you will see a wildly differing amounts of warehouse objects at a given airbase. It also varies map to map. Caucasus is probably the most universal because the same group of objects exist at several bases. Sinai seems to have more fuel storage than ammo. Syria is all over the place. Anyway if warehouses are enabled at the base then the destruction of a storage object will reduce each item of that storage type. The formula is (1/totalNumberOfStorage) * itemCount for each item. If the base has 4 ammo storage and has 100 AIM-120Bs, if one storage got destroyed it will remove 25 AIM-120B from the warehouse leaving 75 remaining. In the screenshot below I am fairly certain that base has just 1 ammo storage, which means if it got hit then that base will not have any storage for weapons. null

https://wiki.hoggitworld.com/view/DCS_editor_Randomization#Single_Choice_from_List That is the trigger equivalent. It won't be instant, but you can set the random % to be higher to make it faster. 10% would be plenty fast with it occurring within a few seconds. A super simple lua way would be something like this: local flagChoices = {"flag1", "flag2", "flag3", "flag4", "flag5"} -- flag names local picks = {} -- empty table that gets filled with flags that are still false for i = 1, #flagChoices do if trigger.misc.getUserFlag(flagChoices[i]) == 0 then -- checks value of the flag table.insert(picks, flagChoices[i]) -- add flags that are still false end end if #picks > 0 then -- if a choice is to be made local flagInd = math.random(#picks) -- pick one trigger.action.setUserFlag(picks[flagInd], 1) -- set that to true end

Like I said its an issue in lua 5.1 when attempting to run loadstring on a large enough file. Lua 5.1 dates back to 2006 and the up to date version is lua 5.4. Fairly certain the web editor converts the file to json for its own uses. Its part of the miz file, so people who connect in MP must download it. However the mission part of a miz file is quite small in terms of file size. Its all text which compresses extremely well. Uncompressed it could be 50mb, but with it compressed its only a few MB. Chances are you have an image or audio file that takes up as much space.

There aren't many instances of data doubling that are quite as bad. Closest would be stuff that may be considered more of a "reference" type of information. A 4 ship of client aircraft each have a unique table entry for custom radio frequencies for example. Each F-18 client has 80 total entries to define 40 radio channel frequencies and modulations. It adds up, but its not quite as insane as the spans.

It seems to be a problem of lua 5.1 in terms of reaching the maximum table size and erroring when it attempts to load the table string. The vast, vast, vast majority of that miz file is taken up by "spans" for each on road route for each group. Basically the editor saves the lines that are drawn on the map representing the path the AI will use, this data is not actually used by the AI. It is used to render the lines quickly in the editor. It isn't quite a group/object limit, more of a what is contained within each group data. In the mission I reproduced the problem in I used only 12 groups. To put it in perspective in the mission I reproduced the error with was on Caucuses with a route from Tbilisi to Kerch Straits of about 1050km. It had approx 13500 span entries. On that Cyprus mission there are routes under 150km with 6000 span entries. It is possible Syria is generating more than it needs, but the spans bloating the entries in the miz file has been a problem for a while. Not much you can do about it other than avoiding excessive use on on road routes over hilly terrain. If you are using scripting to use those groups as a template of sorts you can use any other formation type, then convert it to onroad when giving the task and the AI will use roads as expected.

It isn't required local cZones = mist.utils.deepCopy(zones) Isn't a reference to the zones table, it is a completely new copy. Therefore cZones effectively gets deleted once the function is complete. It has a "fresh state" of what is in the zones table. That said the whole function could be written like you are keeping the data of the previous run.

You run it as often as you want. Either by just throwing it into a trigger action and executing that trigger action every so often. Or by adding the whole thing to its own function and then using timer.scheduleFunction to call it at the set interval.

local blueUnits = mist.makeUnitTable({"[blue][vehicle]"}) -- need to make table since [blue][vehicle] is not a unit name local zones = {{zone = 'Red City - 1', flag = 64},{zone = 'Red City - 2', flag = 65}, {zone = 'Red City - 2', flag = 66}, {zone = 'Red City - 2', flag = 67}} local function checkZones() local cZones = mist.utils.deepCopy(zones) local num = 0 for i = 1, #blueUnits do local unit = Unit.getByName(blueUnits[i]) if unit then local pos = unit:getPoint() for j = 1, #cZones do if not cZones[j].found then local zone = trigger.misc.getZone(cZones[j].name) --- typed cZone[j].name instead of cZones[j].name if mist.utils.get2DDist(zone.point, pos) < zone.radius then -- whatever your code for checking it is, whether its a circle or polyzone trigger.action.setUserFlag(cZones[j].flag, 1) --- action to set the flag cZones[j].found = true num = num + 1 end end end end if num == #cZones then -- once all zones have 1 unit then the loop can be broken out of break end end for i = 1, #cZones do --- check it down here. The way you had it would set a flag off a ton if not cZones[i].found then trigger.action.setUserFlag(cZones[j].flag, 0) end end end This is more what I had in mind with the setting flag to 0 at the end of the check. The way you had it the setUserFlag function would run for every unit until one was found to be in the zone. It just needs to run once. if not someCondition means that if that it will do that check if it isn't present. The function doesn't change which zones are listed in the cZones table, it just adds a value to one of them. A change mind you that is temporary because cZones is a true copy of the zones table. Anyway it'll check all 4 zones for that value and then for each zone that doesn't have it, it will check the position of the units relative to the zone. Think of it as it just skips the zone that has already been found.

Replace "threatened" with "detected" and you will get a more accurate idea of how AI choose targets with that task. Their job is to attack detected sam sites, the moment they detect one, usually from RWR getting an indication, they know where it is at and will then go attack it. Once you start adding radars into a mission there tends to be more "Eye of Sauron" AI detection behavior. So as a mission editor tool that you select a waypoint, press a button, then click part of the map, it searches the enemy forces in that area, based on the mission role it finds the nearest units that fit that target, then auto populates the waypoint's tasking with those targets assigned? Yeah its doable, and a decent QoL thing. Thats more or less how some AI flight generation code I wrote works. Unless it allowed you to configure which task you wanted it would have the same problem of needing to configure what was automatically generated. Could also ask those web editor guys, they seem to code features in rather quickly.

Yes you can define the blueUnits table however you want. However {"[blue][vehicles]"} is a special thing that a few mist functions use. Otherwise it will do nothing simply because it is looking for a specific unit name "[blue][vehicles]". local blueUnits = mist.makeUnitTable({"[blue][vehicle]"}) Its checking a list of unit names, you don't have the unit object at all which is what is used to get where that unit is at. If Unit.getByName("whatever") doesn't return anything then that unit is dead. It isn't saving the unit object anywhere so each time its gotta get the object again. I left the part where it would be used blank, hoping to A. not do all of the work for you. B. You can figure it out. local zone = trigger.misc.getZone(cZone.name) if mist.utils.get2DDist(zone.point, pos) < zone.radius then -- whatever your code for checking it is, whether its a circle or polyzone trigger.action.setUserFlag(cZone.flag, 1) --- action to set the flag end I'd just define it in the zones table. {zone = 'Red City - 2', flag = 65}, {zone = 'Red City - 1', flag = 64} Toggling it off would be just a simple check at the end for each zone. Put it outside of the loop iterating the units. You could make it smarter to check if the flag is enabled true before setting it to false, but that doesn't really matter all that much. Same goes for setting it to true. for i = 1, #cZones do if not cZones[i].found then trigger.action.setUserFlag(cZones[i].flag, 0) end end An optimization. For the sake of argument you have 2000 blue ground units in the mission, how many need to be in each zone for it to set the flag to true? If it is just 1 then you don't need to check that zone anymore once the requirement was reached. If no units are in the zones it is running 8000 checks. If the first unit it checks is in the first zone then it will just need 5999 checks. Which is what the break lower down is for because it occurs if units are found in all zones, it stops checking the remaining units because it doesn't need to.

Ask a moose. Seem to be using their classes.