Grimes

Gonna have to add some details. If you know the runtime object id then it is accessible via the scripting engine. So yeah, you can right click to populate a trigger zone that represents the object, however the object id can still be useful. Here is a basic function that takes the object Id displayed in the trigger zone and creates a table using that id value. Which then use an Object function on and lo and behold it returns a value. This is the result. So yes, if you know an object id you can just make a table in the format of {id_ = number} and scripting functions will work with it. Can't call functions like {id_ = whatever}:getTypeName() because its not an object in the traditional sense. The downside, and its a biggie, is that when the map updates EVERY single object id will be changed to something different. This is where the trigger zone can come in handy because you know object type exists at a specific point. You can use world.searchObjects to get the current runtime id of the object by checking known coordinates and typenames. The upside is that the id values don't update all that often, but they can update, which will throw a spanner in the works.

Yup its very much possible. https://wiki.hoggitworld.com/view/DCS_event_mark_change to get the point and if you want to parse the text for the command. Pass the coordinate to a function that assigns a route.

I don't really keep the pdf up to date anymore. Best to check the hoggit wiki and the pages on mist for better examples. https://wiki.hoggitworld.com/view/MIST_group_alive_less It is simply easier to update the wiki with new info or fixes than the pdf. This function doesn't support multiple group names, it will only accept one. You would have to call it for each group that is valid. Which might look something like this: spawnGroups = {} -- table containing units for respawning (and other things) spawnGroups[1] = "Halo 1" spawnGroups[2] = "RED AWACS" spawnGroups[3] = "HOS SU-27" spawnGroups[4] = "SAM NORTH" spawnGroups[5] = "SAM SOUTH" spawnGroups[6] = "CONVOY 1" spawnGroups[7] = "Train 1" -- Populate groupNames with values from spawnGroups[4], spawnGroups[5], and spawnGroups[6] for a = 4, 5 do -- you had 6 here, it would have included the group at index 6 mist.flagFunc.group_alive_less_than( { groupName = spawnGroups[a], flag = tostring(a), percent = 20, toggle = true, }) end Alternatively making your own function isn't that bad. local checkGroups = {"SAM NORTH", "SAM SOUTH"} local function checkAndRespawn(gName) timer.scheduleFunction(checkAndRespawn, gName, timer.getTime() + 60) local gp = Group.getByName(gName) if gp then local ratio = gp:getSize()/gp:getInitialSize() if ratio < 0.2 then mist.respawnGroup(gName, true) end end end for i = 1, #checkGroups do checkAndRespawn(checkGroups[i]) end

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)