Grimes

You will need to modify autoexec.cfg as noted here: I have not tested every combination but it should just be userhooks and scripting for net.allow_unsafe_api and then mission and scripting for net.allow_dostring_in. Additionally you will need to do a find and replace in the slmod files for DCS. and replace with Sim.

A "fun" aspect of AI tasking is that there are a number of ways to call a given task. Basically there are tasks, commands, and options. In this case it is a command. The last line needs to be: c:setCommand(goToWaypointTask) In order to use commands with setTask or pushTask you have to embed them into a wrappedAction task. If you wanted to create a whole new route with tasks at assorted waypoints like you would in the mission editor, then you'd have to use a mission task, which has a combo task, which has each task, wrapped action, or controlled action within. Hence the fun. If you are just calling the single task then setCommand is what you are looking for.

They are basically the same thing, just written a little differently. if (Group.getByName('GroupName') and #Group.getByName('GroupName'):getUnits() < 1) or not Group.getByName('GroupName') then Here is a direct copy/paste of the the function call within mist. function mist.groupIsDead(groupName) -- copy more or less from on station local gp = Group.getByName(groupName) if gp then if #gp:getUnits() > 0 and gp:isExist() == true then return false end end return true end

Here is the game crash forum: https://forum.dcs.world/forum/482-game-crash/ But in general keep uploading crash logs when prompted by the crash logger. The more logs the more likely ED will diagnose and fix the problem.

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.