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.