Grimes

Yeah probably. But also that is simple slot block and not slmod. As far as I can tell slmod is correctly recording CP/G stats for the Apache.

Post a DCS.log file from immediately after it happened. Might get a clue in there. Is the eeee.miz file posted one where you had tried to add the units? If so they aren't in the miz.

Assuming you pressed the green "Code" button and chose to download ZIP then yes.

Fun fact, with scripting AI don't really care about the task they were given in the editor. If you were using attack unit or search then engage you could give an A-10C a task to go attack Migs if you wanted to. It is more about the weapons and organization of who you want to go attack stuff because you could search for anyone with an air 2 air weapon and get an A-10 for instance. Combination of getAmmo and checking the values for category, missileCategory, guidance, and/or type name for each table entry to figure out what type of weapon is there. Basically if the weapon category is 1 and the missile category is 1 then it is an A2A missile. You can further check guidance type or some of the range information to try and further categorize it. You can't. Best you can do is know the approximate rules for it and try to manage it yourself. What I mean is to not rely on the built in systems that make AI RTB, instead keep track of their status and order them to RTB, therefore you know what is and isn't available to use for tasking. Suppose you could check weapons, fuel, and even location to guess if that unit is RTB. They are also unresponsive to tasking at that point so if they don't change that they are doing then it is safe to say they are RTB.

https://github.com/mrSkortch/DCS-SLmod/tree/develop Hotfix for DCS 2.7.11. Unsure of backwards compatibility but might be ok.

It should work if group is either a group name or the actual group object. So you could skip getName part from EV:getGroup():getName(). The speed value might be part of the problem because you are trying to tell a ground unit to go 80 meters per second. Which is 288 km/h and I don't think any ground unit can go that fast. Also point is not relative to where it is at, rather it is relative to map origin. Honestly I'd just do something basic like: local path = {} local posStart = mist.getLeadPos(EVG) -- gets current position path[#path + 1] = mist.ground.buildWP(posStart) -- makes a waypoint there local target = Unit.getByName('whatever'):getPoint() -- gets the point where you want it to orient toward local offset = mist.projectPoint(posStart, 10, mist.getHeadingPoints(posStart, target)) -- projects a point from current position toward a target with a set distance of 10 m path[#path + 1] = mist.ground.buildWP(offset) -- adds that as a WP mist.goRoute(EVG, path) -- told to go there.

I would like to think I asked nicely when making feature requests to detect trees. But alas, it is not really* a thing. *They are objects but world.searchObjects can't return them. I'd have to find a screenshot of it. The gist is I had saved world object Ids for checking some bug on the Syria map, I checked the mission after one of the updates to the map, and in that one version of the map some of the object ids corresponded to trees. At least getPoint, getTypeName worked on them. Anyway map updated again and those ids correspond to different objects now. The same goes for other knickknacks on the maps that are very small and have short rendering distance. At least with some of those the ids appear within hit events.

Unfortunately no. That is all ED's UI.

Right now they are two very different systems in several respects. You can't modify drawings from the editor via scripting, but you have access to their information. However the scripting engine doesn't have the same parameters as what is available in the editor. The two main ones being that line types are not the same and line thickness is not available in scripting. There are several other differences in the form of format, but those can be worked around. Namely: Scripting color format is {r, g, b, a} in values 0 to 1 while editor is in hex Points for drawings are stored relative to the first point with a mapX and mapY value defining the offset of that first point from map origin Angle of a drawing is often its own value, so similar to mapX and mapY it will offset any points based on that value. Oval and rectangle in drawings are defined as mathematical shapes. In other words a rectangle is height and width instead of being 4 points. Arrow in the editor is a set of points making up a polygon while the scripting arrow is just between two points. Easiest would be to use the editor to get the drawing information but actually add the shape via scripting, then changing it however you see fit via scripting again. Might even be easier to use a group's route to define the points and just call trigger.action.markupToAll with the valid parameters.

It is still that. Maybe it was an unsupported image file type? Only other thought is that something isn't spelled correctly. If it is causing a crash on load there should be an error in the DCS.log file to help pinpoint what might be the source of the problem.

Check if the helicopter is inside a trigger zone? If so it just looks worse than it is because its just math. if event.id == 4 then -- land event local uPoint = event.initiator:getPoint() local zone = trigger.misc.getZone('zoneName') if math.sqrt((uPoint.x - zone.point.x)^2 + (uPoint.z - zone.point.z)^2) < zone.radius then -- unit in zone when it landed end end The problem being it doesn't work with a polygon shaped zone. For that you must do a point in polygon check, which is where something like mist.pointInPolygon or equivalent functions from other scripts is useful.

Yes and no. No, in the sense that lua doesn't modify the actual mission file itself. I mean you could do that externally from DCS, but as far as the API goes that isn't what it does. You could also do that manually push comes to shove. Yes, because you could get the data from the mission, modify whatever you need, and spawn in that group with the changes or just assign the task while the mission is running. Spawning a new group might mess with the triggers however. The "direct SDK" as you put it used within mist to get a group route can be seen here: https://github.com/mrSkortch/MissionScriptingTools/blob/master/mist.lua#L8165 It literally just parses the big ol' mission table to find the route associated with a group. All it would take to modify the speed value is just that, change the speed table entry that it is using. Pass that table to Controller.pushTask or spawn a group with the change. Viola.

Even with stat mods that use the scripting engine the information for that simply doesn't exist. The closest could be an assumption made via checking line of sight at the time of destruction. However often enough that assumption would be outright wrong.

Activate might be the operative word here. However I still couldn't replicate it. Attached is the test mission I used. Uses the WW2 asset pack as I was checking all submarines. sub_sync_2_7_10.miz

I reverted the message display to v4 version of it for now. Its on development branch. If you dont have any issues I'll pull request it to the main branch. DCS limitation presently. Well its been a feature request for over 6 years at this point so saying "presently" is a bit of an understatement. There simply is no outTextForUnit, outSoundForUnit, or addCommandForUnit functions. The smallest it goes is at a group level. Mist filters all of the messages being sent down to the appropriate group. If you assigned a message to be displayed for 2 specific units that are in the same group then it'll realize a copy is being sent and ignore it. Alot of the problems encountered with the messaging changes (v5) was that I was trying to be a little more efficient with how it processed the messages. Basically it was constantly checking all of the active messages and re-printing a single message to each client. This is due to any possible "privacy" of wanting to send a message to a specific group. It also checks for any Combined Arms slots and if any are present sends a message to red and blue coalitions before sending to each client. Thus any CA specific message is immediately overwritten by the group messages. Anyway ED added the message log and it turns out constantly displaying a new message several times a second tends to needlessly spam the log and people find that annoying. Also one of the original reasons for the mist functionality was so that multiple messages didn't overwrite older messages, however many years ago ED rectified this by changing how messages work. So I got to thinking to essentially do the message code only as needed instead of constantly, and that is where the problems occurred.

Any chance you enabled historical mode?

Happen to know if moose spawns the units with the callsign or spawns it first and then calls setCallsign?

In a quick test the ship object existed, but there was oddity with the wake.

Triggers don't really provide the fidelity needed to accomplish that. Best you can do is use weapon in zone, but you don't know who shot it, where it is going, and easily account for multiple missiles being launched to call magnum on each. Easiest would be to resort to scripting and using an event handler to manage it. Simply because with the shot event you can know the unit that shot it, the weapon type, and if available the target object.

They can because there are triggers that look at player score. However it isn't always clear what, if any, triggers a mission maker sets up for the result or if the player score is used without looking at it in the editor. Guess my point is it is far more likely to see unit or group is dead conditions than player score greater/less than. It is rather hit and miss whether or not a non campaign mission has goals (result score) setup within. I think it was more common with older missions than newer ones. Outside of the usage within campaigns it has no impact at all on your logbook. It is purely relevant to the debrief screen, though quite a few people do use it to judge success.

Gonna need a miz or track file to figure out what is going on.

It is a result of the reaction to threat option. Needs to be on evade fire or any other option less severe than that in order for the AI to engage more logically. Unfortunately it isn't considered a bug because it can be "fixed" by the reaction to threat option.

It has to do with the number of static objects and is not related to unitId. Best I can tell it changes based on the other statics in the mission for any coalition. Say you only have 3 statics on blue their numbers will be 1, 2, and 3. Add in 2 statics on red then the blue bort numbers shift to 3, 4, and 5. Likewise the number gets counted up on neutral statics before it does red.

Fixed it and a few other small fixes. https://github.com/mrSkortch/MissionScriptingTools/releases/tag/4.5.107

I don't think it is unitId. It looks more like it is the index the entry is at within the .miz file. Make new mission, place 1 static aircraft, then place a static building, then another static aircraft. The bort numbers will be 1 and 3. It is possible spawning via the scripting engine if the bort number would be used. If that is the case then the table index might be a fallback value. In which case bort should be added to the editor UI.