Grimes

It could be defined in a table and then you just reference that table entry when calling it. local tbl = {} function tbl.doWhatever() env.info("hello world") end for fcnName, _ in pairs(tbl) do -- super lazy example tbl[fcnName]() end

Easiest would be to pass the optional value to inherit initial tasks and set the alarm state as desired on the group it is using as a template. mist.cloneInZone('groupName', 'zone', nil, 4000, {initTasks = true}) Next easiest would be to use the table returned by the spawning functions to get the group name and then assign the setting via Controller.setOption() a short moment after it spawns.

Ground vehicles don't have fuel. TBH I'm not sure what Unit.getFuel returns if you try to run it on a ground unit or ship. If it returns a number, which it might not, I doubt that value will change over time. Best you can do is to fake it.

Can you attach a mission with the script causing an error?

Two things come to mind. 1. Make sure the fireAtPoint task has a expend limit set. Otherwise the task will remain active and for whatever reason ED decided that units shouldn't try to reload as long as a fireAtPoint task is active. 2. Set the alarm state after firing so that the unit stows the launcher. This is more for allowing the SCUD to drive after shooting, but it could impact rearming. Last I tested the scud launcher no longer stows itself automatically after shooting.

Looking at the code and comparing to how the functions in mist work it looks like the math is correct. However there is an adjustment you will need to make to get accurate in cockpit bearings. Here is the mist function. Basically at map origin on the Z axis is the only place on the map where getting the bearing between two points would be 100% accurate. The further you move away from it the more error there will be. See the screenshot. If you were flying along the black like your cockpit would indicate 000. If you flew the cyan line, the bearing between the two points on the map, because it is flat, would be 0, but in the cockpit it'll show 10-11 ish degrees. The issue is most pronounced on the maps where map origin is offset heavily east/west. null function mist.getNorthCorrection(gPoint) --gets the correction needed for true north local point = mist.utils.deepCopy(gPoint) if not point.z then --Vec2; convert to Vec3 point.z = point.y point.y = 0 end local lat, lon = coord.LOtoLL(point) local north_posit = coord.LLtoLO(lat + 1, lon) return math.atan2(north_posit.z - point.z, north_posit.x - point.x) end

Nope, its hardcoded. Only option is to use lua where it is applicable to rewrite the conditions and actions to run at a faster rate.

You can't. The only rendering behavior with lua is only within the context of the mission editor.

1. It is just a table, it'll be the same way accessing any other table. Though in this instance everything is indexed numerically, thus a for i =1, #table do will give you the table in order. The wiki just mentions it on the main missionCommand pages. I didn't include examples in the forGroup or forCoalition versions because its literally the same. https://wiki.hoggitworld.com/view/DCS_singleton_missionCommands { [1] = "SubMenuInRoot", [2] = "Sub1", [3] = "Sub2", } 2. Think of it as a table structure. If you wanted to add a menu at level 2 then you'd use a path that goes up to that point. missionCommands.addCommandForCoalition('2' , "Simple Test Of Passing Menu item" , {'SubMenuInRoot', "Sub1"}, menuTest)

I would think if you just did it as glbalMenuID = missionCommands.addSubMenu it would work. If you know the strings that make-up the sub menu items then you should be able to directly use that. The path entry is just a table indexed numerically. The following ought to work. missionCommands.addCommandForCoalition('2' , "Simple Test Of Passing Menu item" , {'Scout Recon Missions'}, menuTest)

AFAIK the towns.lua is primarily used by the KA-50's ABRIS and its town search page. The town names that appear on the F10 map are baked in someplace else in the terrain files. There is an open feature request for a scripting function access to town information.

Bug. It is reported.

https://wiki.hoggitworld.com/view/DCS_singleton_world Which page were you looking at?

At least with the arty it seems to not want to rearm if it expended everything. Tested with a grad and fire at point. Set to fire 39 it will rearm after the task. Set to 40 it won't rearm. Reported.

Was likely on the wiki because its easy to miss these changes. Likely was removed or renamed in 2.9.0.47168. S_EVENT_UNIT_TASK_COMPLETE now occupies that event id.

Has to be AI and set to take off from ramp.

In DCS.log there will be a line stating mist loaded. The lines are basically it started loading and it finished loading. 2024-07-01 19:24:54.392 WARNING SCRIPTING (Main): MIST|init|1675: Init time: 0.101 2024-07-01 19:24:54.392 INFO SCRIPTING (Main): Mist version 4.5.127 loaded.

It needs a return statement in the condition box. Same goes for the condition in the start and stop conditions for tasks. nullAdd that and it'll work as expected.

It is currently only functional on FARPs. Its a little weird in terms of how the game treats the objects IIRC.

Setting a flag of the group name is the same thing as what that was doing. It was a value, that when it exists means that the group was going to respawn and acted as a lock of sorts to prevent the multiple messages or multiple respawns. Literally just a different way to do the same thing. And yes, the number value in outText is the display time. https://wiki.hoggitworld.com/view/DCS_func_outText With the 3rd value set to true it will display the message in a different format and will overwrite any existing message being displayed.

getPoint might be more directly useful as it only returns the coordinates. However getPosition().p is functionally the same thing. The rest of the values returned with position are used only with the orientation of the object. For example: local heading = math.atan2(unitpos.x.z, unitpos.x.x) Worth noting that the coordinates used in tasks is typically a "vec2" and not "vec3". Which basically means that the vec3.z value needs to be the vec2.y value. So... local point = Unit.getByName("target"):getPoint() local task = {} task.x = point.x task.y = point.z https://wiki.hoggitworld.com/view/DCS_task_mission

I think it is AI path calculation more than anything mist is doing. Most of what that mist function does is it generates the points given to the route table and assigns the task to the AI. Try it without the disableRoads being defined, meaning mist will find the closest road from the start and destination points.

Using a number for the 2nd parameter in mist.respawnGroup isn't a delay in respawning the group. It is a delay for when the group task gets assigned. At first glance you could schedule mist.respawnGroup to occur at a later point in time, however I assume you are constantly checking if not Group.getByName, as a result it'd just schedule mist.respawnGroup however many times between when its dead and when the group actually respawns. One way would be to add extra conditions. if not Group.getByName('RUS-T72B-6') then if not rusB6Respawn then --- checks if a time was saved when the group was killed rusB6Respawn = timer.getTime() --- creates a global variable for that group elseif rusB6Respawn + 120 < timer.getTime() -- checks if the time the group died + 120 seconds is less than the current time mist.respawnGroup('RUS-T72B-6', true) -- respawn rusB6Respawn = nil -- delete value so it can be created again with the initial check end end At that point it might be easier to just create a function that checks and manages the groups you want to check. Maybe it has a table of the group group names and each time they died at, which iterates the table to respawn them as needed. Basically the above lua example is fine for a few groups, but gets annoying fast because you need a unique global variable for when each respawns.

I've only ever done it outside of DCS with python. But yeah, same concept of doing it with something like luazip externally from DCS. Something like the web editor might be the easiest to use since it has a UI and you can modify time of day or weather in the miz pretty quickly.

No. The env.X tables are just a copy of a few files located within the miz file. You could edit the copy by adding triggers, units, or whatever and the serialize the files and re-insert into the miz so that on the next load the changes are reflected. I've done that a few times to fix or change entries outside of the editor in bulk.