Grimes

Unfortunately the best that can be done is to create a mission command at a group level and pass the relevant id as one of the values within the command. The example on this page does exactly that. The passed value to the function is the group name. https://wiki.hoggitworld.com/view/DCS_func_addCommandForGroup Much to our collective lament ED has yet to add commands for units. The smallest it goes is for groups. This is why CTLD requires the helicopters to be their own group. Its the only way to be 100% certain which player issued a command.

It isn't a function. Its just a table that exists. The way we find things that we didn't know existed in previous versions is by "writing the _G" table. Here is the relevant code from mist that you can copy or use at your leisure to get the file yourself. If you need some help understanding what _G is in lua then this page might help. http://underpop.online.fr/l/lua-gts-stolberg-de/en/tables.html Short answer is that _G is everything that is accessible. It is a giant table containing functions and more tables. You will see all of the scripting functions and most of the constant values that you know and love from the documentation. As you may note from my attachment that mist is loaded and appears to be similar to entries like Airbase and Unit. In other words you can see the contents to the same extent. A note about the attachment, I did delete one giant entry that was over 8mb of data within the country table. Its basically a huge list of units available to every single country with a bunch of extra data. At line 319 is where the env table can be found. You see the env.info and other functions. But env.mission and env.warehouses will be identical to their respective mission and warehouse files embedded within the .miz. for name, tblData in pairs(env.mission) -- this will print to the log all of the root entries found within a mission file embedded in a .miz env.info(name) if type(tblData) == 'table' then -- if its a table then iterate it to print whats on the next level down. But really you should just start where-ever you are looking for data anyway. for L1N, L1D in pairs(tblData) do env.info(L1N) end end end 2_8_0_32235.lua

It is a separate lua environment from the mission scripting engine. Thus I gave it its own section on the wiki. ED also have documented it better than mission scripting and have a html file with that documentation included with the game. https://wiki.hoggitworld.com/view/DCS_server_gameGUI The "net" functions were added to the mission scripting environment sometime between this new server env and now. So some functions are accessible in both. The server env is more like a mod where you can place files in savedgames/DCS/scripts/hooks that can run code or execute other files on that computer to run whatever scripting of your choice. It is used on client side mods like tacview and SRS to interface with the game to know when you are in a mission for example. There are also server side admin tools, stats, etc for running a game server. Basically everything you see in the "simulator scripting engine" section (aka mission scripting) simply doesn't exist to code you run from the server environment. There is no "env" table, nor sub tables like env.mission. As a result there is the function DCS.getCurrentMission() that returns the mission table for whatever use you may have for it within that environment.

There isn't any intentional gatekeeping going on with it. The single biggest contributing factor is that it isn't ED that created and maintains the "go to" documentation for the scripting engine. The hoggit wiki hosting the scripting documentation came about due to ED shutting down their own wiki. Then however many years ago with me being annoyed with the original documentation went through and tried to remodel it off of the Arma wiki design. To this day things are missing or examples are needed. Its one thing to go through and create basic documentation that is usable, its another to know what needs more detail the most. Over the last few years it usually results in me making a mental note to try and add detail to any given page whenever it gets brought up. The other part of it is being basically just me doing the wiki edits and I'm spread thin throughout every little aspect of DCS that I volunteering spend my time. The original documentation, which I've kept for the sake of posterity isn't much better. https://wiki.hoggitworld.com/view/DCS_Scripting_orig_Part_1#env While I agree that looking through code written by other people can be annoying simply due to differences in formatting, it should be easy enough to note patterns or to take an idea they are doing to experiment with it further in your own way. https://github.com/mrSkortch/MissionScriptingTools/blob/master/mist.lua#L103

I swear I've answered this before to one of your questions in the past, but env.mission is the mission file generated by the mission editor. The lua files within the .miz are loaded into the respective env.X in the scripting environment. Those files are basically just a big lua table anyway, thus if you know the formatting or want to iterate in pairs to look for stuff you can. Its how MIST, MOOSE, and others build unit databases or use other information from the mission file that aren't directly accessible. For instance trigger.misc.getUserZone doesn't return any properties you may have assigned nor does it give the vertices of quad zones. That data is in env.mission. Just grabbed a random mission and this table entry is within env.mission.coalition.blue.country[7] -- USA was at index 7 The carrier is unit Id 1 so the linkUnit and helipadId are set to 1 to correspond with that unit id. ["plane"] = { ["group"] = { [1] = { ["modulation"] = 0, ["tasks"] = { }, -- end of ["tasks"] ["radioSet"] = false, ["task"] = "CAP", ["uncontrolled"] = false, ["route"] = { ["points"] = { [1] = { ["alt"] = 0, ["action"] = "From Parking Area Hot", ["alt_type"] = "BARO", ["linkUnit"] = 1, ["properties"] = { ["addopt"] = { }, -- end of ["addopt"] }, -- end of ["properties"] ["helipadId"] = 1, ["speed"] = 138.88888888889, ["task"] = I cutoff a whole lot of extra stuff because it wasn't relevant. Anyway there is a lot of value in viewing the contents of the miz file simply because some answer for how something works is likely within. Need to figure out a task? Make a mission with that task and see how it is formatted. Likewise parsing the file during the mission has its own uses as stated above.

Gotta parse env.mission and see if linkUnit is present on a take-off waypoint for aircraft. IIRC that is only present when assigned to takeoff from a ship.

Don't know much about unit vectors, but there are two sure fire ways to do it. This is more or less copied from mist.vec.rotateVec2. You have a known offset, get the heading of the unit, and do some math. local offset = {x = 0.5, z = 1} local position = Unit.getByName( "Ground-1-1"):getPosition() local theta = math.atan2(position.x.z, position.x.x) local newPoint = {} newPoint.x = offset.x*math.cos(theta) - offset.z*math.sin(theta) + position.p.x newPoint.y = offset.x*math.sin(theta) + offset.z*math.cos(theta) + position.p.z The other way is similar, but would be done via storing the relative heading and distance from object center and projecting a point. local offset = {t = math.rad(70), d = 1.5} -- unit oriented north, offset position is 70 degrees and 1.5 meters local position = Unit.getByName( "Ground-1-1"):getPosition() local theta = math.atan2(position.x.z, position.x.x) + offset.t -- get the heading and add the offset local newPoint = {} newPoint.x = (math.cos(theta) * offset.d) + possition.p.x -- project the point and offset the position. newPoint.y = (math.sin(theta) * offset.d) + possition.p.z

Nope. There are some units that have "additional properties" that have specific animation values associated with it to display the unit differently. However there aren't many that use it. Think its mostly the Land Rovers and WW2 asset pack units. null

It doesn't take much to create and maintain a simple lookup table. Just use coalition.getGroups and iterate every group and unit to check Ids, add em to a table. Likewise use an event handler for birth events to add spawned groups and units. If it is replacing the existing objects then something isn't unique because that is the exact behavior that occurs. I guess post your code so fresh eyes might be able to pinpoint the problem.

You can have multiple radars within the same group for full coverage.

coalition.addGroup doesn't strictly need to have group and unit ids pre-generated when spawning a group. The game should come up with unique ids on its own. Outside of that if you mist or write your own code for it, you can check a lookup table of ids to know if a number is used. For example if not mist.DBs.unitsById[x] then -- that id is available

I guess my first question would be "how different is slightly different" ? Accessing the value via scripting by parsing env.mission is the mission file, its whats stored there. The editor UI does cut off the decimal digits, I'm not sure if it rounds them or not. Don't really have a great answer for you.

The mission task is more or less exactly whats in the mission file. https://wiki.hoggitworld.com/view/DCS_task_mission So to change the route you need to change the x, y, and alt values nested within route.points[index]. With the index numbers counting up from 1 and whatever the highest number being the last waypoint. Spans don't matter at all and are only used by the mission editor. Specifically the spans identify the lines used to draw the route in the editor. If you have an on road route with just two waypoints then there would be 2 values within route.points and depending on the length of the route potentially thousands of spans. There aren't many entries remaining in the miz that are only used by the editor, but spans are the most obvious one.

Yeahhhh I'm not sure that is meant to be live as the main tasks which allow you to create the tasks in the editor are hidden. But hey if you get it to work and it doesn't crash then more power to you.

The spawn behavior in that mission is extremely weird. Added F-18s for the sake of testing and because aircraft size sadly matters a whole lot. Single F-18 spawns. Pair F-18 delayed, but spawned after a few seconds. Single F-14 delay, never spawn. Pair F-14 delay, but spawned after a few seconds. Reported it.

After watching the track I am of the opinion it is fuel related. I added a script to display its fuel value, and though time acceleration changed the results of the track enough of the dogfight progressed for me to think it is fuel. For starters the Su-33 gets assigned 50% fuel so it can take off from the Kuznetzov short ramps, its gonna make it to bingo faster. First un-modified track it just gave up and flew to the last waypoint. Second run with the fuel output it got down to 20% fuel and shot you down after extending north. First track went on for a bit more so it is safe to assume it had somewhere less than 20% total fuel capacity. It helps the AI if it has a takeoff or landing base assigned as part of the flight plan. IIRC without an airbase assigned it doesn't know or think about where it can RTB to in an emergency until that happens. Think of it as the AI know they have a route of X distance, but ultimately know they are going to a specific destination that is Y distance from their current location. Giving it more fuel and adding a landing waypoint would help.

I believe some clarification is needed. The mission editor is written entirely in lua and can be modified. There are some things you can't change, specifically creating AI tasks and triggers, but that is more in line with how the game interprets the contents of a mission file. You could make some new AI task but the game would just crash or ignore it entirely. Case in point flags have supported using string values since the first iterations of the scripting engine, however until recently the mission editor UI was never modified to account for that. In several circumstances the editor is overly restrictive as a protection measure of sorts. Its why you can't set AI to attack a friendly unit or search for certain target attributes even though both can be done via scripting. The problem is its not really an API, its a UI that is the means to an end of modifying the giant lua tables within a .miz file. There are a ton of usability changes that can be modified in but you have to contend with modifying existing files that get updated/replaced when DCS itself gets updated, thus the mod breaks. Also its just a PITA because you have to constantly restart the game for changes to apply. I've done it a few times mostly out of self annoyance with the status quo because what you might think of as important enough to spend time on isn't necessarily what ED think. For instance editing the coalitions after the mission was created started out as a mod I made. Recently I dived back in because I wanted to easily apply default loadouts and weapon restrictions to aircraft within a group or all of that type in a large MP mission. I haven't gotten around to fixing it since 2.8 came out.

I don't think so, but yeah that would be a good QoL feature. Would be easy enough to mod in a command to set the value. To load a default value on group creation would take some more time and unfortunately require modding a few key files in the editor that change often. Thus the mod would most likely break every patch.

The Herc mod cheats because to the game each paratrooper is actually a "bomb" that is dropped by the aircraft. Actually anything you airdrop via the mod is a bomb, its just with paratroopers it drops 30 for how long it takes. Then with the scripting it tracks each dropped objects position, when low enough it effectively swaps the objects by deleting the bomb object and spawning the appropriate ground unit. Best you can do is fake it with something like spawning signal flares when it does a paradrop for the visual sense and then however you want to code it to spawn ground forces accordingly. The only thing you can spawn in air with a parachute is the illumination bomb. https://wiki.hoggitworld.com/view/DCS_func_illuminationBomb I don't remember if those still fall through the surface in MP for eternity or even if you could track it to know the altitude so you can spawn a ground unit when it reaches the ground. I think it falls at a fixed rate so its easy enough to do the math.

There is no native scripting function to re-arm AI. You either can "respawn" the group by spawning a new one with the exact units in the exact positions or you can spawn certain types of units and rely on the AI to re-arm themselves automatically. Usually most trucks can act as a ammo source, place one in the mission editor and if you see a black circle around the unit with a radius of 100m or so then that unit can rearm other AI. Depending on the unit type and amount of ammunition needing to be re-armed the time it can take has some extensive variation. Though infantry and mortars are pretty quick. The time becomes a factor with larger munitions like the SA-2 where it takes 45 minutes or SA-10 at 30 minutes per missile.

You can also use https://wiki.hoggitworld.com/view/DCS_func_get_player_list which should have the player name info available.

Within the .miz each of these are found in the mission file. Mission is basically a big lua table so you have different entries for what needs to be changed. date : if you want to change the day, month year weather : for changing the weather settings. It would be a good idea to make a mission with the weather you want, save it, and then copy the contents of that weather table. start_time : found within the first level of the table for defining the start. Its counted in seconds after midnight for the set day.

I would need the full log to diagnose further. Ensure that missionScripting.lua is up to date? Is the new scripts integrity check on or off?

You are ever so close. coalition.addGroup not coalition.addgroup Remove the nested table local CAS = { [1] = { groupTable It should just be: local CAS = { groupTable }

Would you kindly provide a test mission in your own time? The time is not important, only life. If it only works within airbases then I think that increases the likelihood that it was added by ED for something unreleased or for testing purposes.