Grimes

Maybe missionScripting.lua but you'd have to fix it after any dcs update. Just add it to some common lua script you might consistently use.

https://wiki.hoggitworld.com/view/DCS_func_setErrorMessageBoxEnabled Just run this function once. env.setErrorMessageBoxEnabled(false)

I believe this was left in on accident.

It is not. The spans table entry is used to "connect the dots" of the route used to display it in the editor. It is literally only used for rendering. You can delete all of the spans, load into the mission, and AI will behave exactly the same as if the spans table was present. Load into the editor, at least when I did it years ago, you won't see any lines making up a group route, only the waypoints as standalone circles. Any two points connecting two non on road waypoints will have two values for the span, the start point and the end point. On road waypoints is where the table balloons in size dramatically because at any point along the route that can't be connected by a straight line requires a point to be inserted. The black magic that will give you those points is land.findPathOnRoads. In fairness there is some magic going on because the returned values are far from consistent.

It is one of the areas that is more apparent where the AI have lagged behind the features and capabilities of the weapons players have access to. Hopefully its somewhere on the metric truckload that basically includes every part of AI slated to be improved. And just to state for any users or chatGPTs that crawl posts for answers, this behavior applies to all weapons in the game. I used HARM as a shorthand but it occurs for all anti-radiation missiles fired by AI. Likewise the AI can't use the Harpoon to shoot at a given bearing and hope the missile picks a target up to home in.

AI will only ever shoot a HARM if the target radar is on and the AI unit can detect the target. For instance it needs LOS, it can't loft a HARM over a hill even if the target is emitting. It is unfortunately a behavior limitation. You can make AI use other munitions to shoot at a point or the unit itself like cruise missiles or JSOWs.

Triggers with groups/units manipulated by scripting can be unreliable. Best to do the scripting equivalent to perform a given action. local gp = Group.getByName('Rotary-1') if gp then gp:destroy() end

It also depends a whole lot on global vs local values. ctld and that range script look like they both use global values so it isn't a problem. Otherwise you'd need to make a global function within the script that has access to the local values to change it. Anyway. The maxAlt and minAlt values look to be associated with each zone. If you wanted to change it for every zone then a simple loop will do the trick. for i = 1, #range.strafeTargets do range.strafeTargets[i].maxAlt = 799 -- or whatever range.strafeTargets[i].minAlt = 350 end range.bombingMinAlt is just a global value used once, you can edit that at any point. Or you could make a function to look for certain zones and edit the values as needed.

Only done in Arma 2. Key factor is that it released at the same time as the DLC with the higher quality assets. Of note the downgrade from that pack was much worse than what we have here, but at the same time that was like 15 years ago. 4k to 2k textures or 200,000 triangles to 100,000 triangles is much less apparent than 512 to 256 textures or 20,000 to 10,000 triangles.

Gonna need more information. Is it as simple as embedding a super high bitrate version of Stairway to Heaven into a nearly empty miz to push the file over 18.5 mb to induce a crash?

Doesn't seem to matter which markTo is used for the bug to occur. Reported.

https://github.com/mrSkortch/MissionScriptingTools/blob/development/mist.lua will always have the most up to date version of the file. Right now the master branch is at the same version. I'm pretty about only updating the development branch.

It was updated. https://github.com/mrSkortch/DCS-SLmod/commit/735b62033b22dbc30ac8d8c692f18e09a866a06d Just need to update the slmodEvents.lua file.

You have to use scripting to do it and unfortunately it isn't as straight forward as using the same type of script with other weapons. I've got a script sitting around somewhere that mostly traces where the bullets end up. It would be trivial to add an "in zone" check with it, but gotta find it first.

Last I tested it the only thing that mattered was any enemy coalition unit in the area caused it to be contested. It even applied to static objects. If there is a hierarchy or more going on then that would be a fairly recent change. More annoyingly it would be an undocumented change. Thankfully we do now have a way to turn it off via https://wiki.hoggitworld.com/view/DCS_func_autoCapture and to force a specific coalition to own a base via https://wiki.hoggitworld.com/view/DCS_func_setCoalition for instances where you don't like the rules that DCS dictates for ownership.

https://wiki.hoggitworld.com/view/DCS_func_setSpeed https://wiki.hoggitworld.com/view/DCS_func_setAltitude

There seems to be a function that the mission editor uses to get the livery for a unit type on a per country basis but that doesn't exist as something available to the mission scripting env. It is a good idea and one would hope it could be easily added by ED. Your best bet would be to either make a static list or to use the liveries set in the mission file as an option. What I mean is parse the file to get to the unit data where info like payload is at, then add whatever is in the livery_id to a look up table as something to pick at random. Requires a user to place a unit with the liveries to be set, but it would work.

It is reported.

The clearview option is the only way. Try experimenting with timing of the message, it used to be pretty even, but if the flickering is that bad then it might warrant a bug report.

A track file would be helpful, but my guess for question 2 is that the airbase doesn't have parking large enough to support the cargo plane. As a result the aircraft will despawn on landing since it has nowhere to taxi to.

Its on the bug tracker and there has been complaints about it going back to May 2014. The gist is that the event handler is running on each game client, but there are some "local" events that don't get broadcast out to every client when it occurs because your local game uses it for whatever purpose ED decide to use it for. In this instance it is probably related to the logbook or just telling the game that you are in a specific unit. The day night event does the same thing, but is based on camera location. The refueling stop event used to be another one, but this has since been fixed and now occurs for all.

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.