Grimes

What we got here is failure to communicate. Just a short breakdown. 1. The thread had a title with "this doesn't exist: URL to wiki". 2. I responded with image of said wiki page. 3. You clarified it wasn't the website, but something else. 4. I asked what that was. 5. You provided zero new information 6. I upon realizing it was basically 1 post-reply a day going nowhere said something sarcastic. 7. You were rude in response, but provided enough information. 8A. Another person chimes in with an answer 8B. I make an example showing radio existing in DCS, and be a little rude back. 9. You reveal the problem is with your IDE. Perhaps you could look past any opinions you have of me as a person and realize that I do try to answer your questions in good faith. I'll try to dial back the "matter of factness" of my answers and to be more inquisitive when the problem isn't made clear. I matched the tempo with my first reply and it never recovered. I'd be nice to think even as much as a second question could've resolved it sooner. Suppose you do got me on the arrogance bit with me thinking I don't need to plainly ask for a track in every bug report in order to figure out what is going on.

Examples were copy/pasted from a mission file. Depending on the group type and even the units within there are going to be some extra entries or non-standard entries. Payloads on weapons with fusing will have an entry for that while weapons that lack it won't. There are often entries that only the mission editor itself uses. Any route tasking with ["auto"] = true just means the editor added it automatically. However they don't really matter because unless the game is looking for a value it will just ignore anything extra in there. IIRC the items on the page that are listed as required are required. Anything in optional or not listed should be considered optional. Stuff like group and unit ids can be left out, but it is personal preference. I view it as a nice shortcut when I don't care what the Id is. If a required entry is missing then I'll add it because that is clearly important. Optional values is more of a "it depends". Yeah I need to add some of the group level options added in the last year or so. Additional properties for a Land Rover though isn't really important. As for route tasking you can spawn the AI with the route just fine, I personally prefer to do it that way for aircraft but not for ground/ships. The problems people had, and I'm not sure if it still causes issues or not, is when you spawn a group and assign a task in the same sequence like below. I never saw a reason why one would do that with a mission task because you could just add the mission table to the someGroup table. But hey, thats just me. IIRC you just need to wait a fraction of a second to assign the task anyway, but its still a hassle to schedule a function rather than just running it like that. local someGroup = {imagineAGroupTable} coalition.addGroup(1, 1, someGroup) Group.getByName(someGroup.name):getController():pushTask(whatever)

It is just the way it is. A raw text file that gets translated into multiple languages. Would be nice if it hooked into live game data but it doesn't.

It is an older missile so it was in Scripts/Database/ and subfolders, but that is no longer accessible. The encyclopedia cannot be relied upon to correlate precisely with in game performance. The encyclopedia says the BGM-109B has a range of 480 km, but it is actually limited to 1700 km. The best way to get approximate performance is via getAmmo() on a unit carrying the weapon or getDesc() on the weapon itself once it is shot. For example here is the range value for a Tomahawk via getAmmo() on an Arleigh Burke. https://github.com/mrSkortch/DCS-miscScripts/blob/master/ObjectDB/Ships/USS_Arleigh_Burke_IIa.lua#L195 There are plenty of caveats to this though. The rangeMaxAltMax and rangeMaxAltMin are more reliable with ground/sea launched munitions compared to A2A or A2G weapons. For example a KH-58 has the same value for both at 250000, admittedly this is a 4 year old file I'm looking at so it my have changed. Point is at minimal altitude a KH-58 is not going to make it 250km, nor detect a target to shoot at that range. A Su-24 at speed and altitude on the other hand could possibly launch one that far or at least over 150km. The encyclopedia for reference lists 70km as the range. Best to think of it as these are the max ranges that the AI are allowed to shoot at, but have other calculations that may force the range to go lower. If it is an aircraft then they will fly to get into range.

Its just a table with entries on the first level of it being units, task, route, groupId, name, etc. The group table is just like the examples linked on that page; https://wiki.hoggitworld.com/view/DCS_exam_group_ground I don't know where you are getting the idea of "mission" being required. Perhaps maybe the mission task that you can assign a group, but that is just like any other task where it is {id = "taskName", params = {actualTaskData}}

See what happens when you use more than two words to describe a problem? It is possible to actually answer it. local m = {"radio"} for n, tbl in pairs(radio) do m[#m+1] = "\n " m[#m+1] = n if type(tbl) == 'table' then for n2V, n2T in pairs(tbl) do m[#m+1] = "\n " m[#m+1] = n2V m[#m+1] = " : " m[#m+1] = n2T end end end local msg = table.concat(m) env.info(msg) trigger.action.outText(msg, 20) You posit that radio does not exist. Allow me to retort. You're wrong.

I can't fix you.

A 3rd method is that nothing exists at mission start via group probability is set to 0%. Whenever needed you spawn each group in via scripting and it builds a group table based on information from the saveState. Works best with a bubble script or anything that conditionally spawns in groups so that absolutely everything isn't always active all the time.

Part of the example, it just prints whatever the values are to the log. It is showing how to access each value though. Table index[1] if the table is indexed numerically or by var.keyName if the table entries have keys.

Suppose the easiest way is to build the function you are calling to accept a table. function test(var) env.info(var[1]) env.info(var[2]) end timer.scheduleFunction(test, {"Hello", "World"}, timer.getTime() + 2) You can also name the variables. function test(var) env.info(var.groupName) env.info(var.groupSize) end timer.scheduleFunction(test, {groupName = "Whatever", groupSize = 47}, timer.getTime() + 2)

The thread literally has the URL of the page screenshotted in the thread name. You are going to have to be more specific.

Dead link on some other page? null

Try: FuelTotal = Unit.getByName('S-3'):getDesc().fuelMassMax The files on the objectDB github can contain multiple return values from functions. Think of it as this: local unit = {} unit.ammo = obj:getAmmo() unit.sensors = obj:getSensors() unit.desc = obj:getDesc()

The answer is literally in the reply to the thread you posted. And by answer it is still an unknown mystery.

Route needs the airdrome value and a type of takeoff from ramp. Then if you want them to spawn at specific parking spots set the parkingId for each unit. It will auto assign the spots if the parkingId is missing. Sometimes you can make it violate the rules for a given parking space by forcing an id. For instance spawning a B-52 inside a hangar meant for a fighter. Auto should follow the rules and never spawn aircraft on top of each other at the cost it possibly being a less than ideal starting location. Before you ask, no, there is no scripting function that gives useful information on the size limits of each parking spot at a given base. Assumptions based on terminal type from getParking can be more relied upon on Caucuses, but other maps not so much.

Looks like a mission editor bug of some sort where it inserts an extra point into the table. Possibly with double clicking. If you choose "Select" and move the line segment points then you should find the extra point overlapped with the initial point. Anyway origin in this case is relative to the origin of the shape. Its more of a vector art way of saving the data. Suppose it is just going about the calculations backwards from what something like how groups are placed. What I mean is you put a group of units down, each unit has coordinates relative to map origin, if you then move the group leader it'll add the +/- XY difference in coordinates to each unit to "move" them. While with shapes each point is XY relative to the first point. if you move the shape as a whole it just updates the mapX and mapY value saying where the shape starts at. Then the renderer takes that information and renders the shape as needed. A group with 10 units needs to update 10 sets of coordinates, a shape with 1 points needs to update 1 coordinate set.

nullYou can also force F10 settings in the mission itself. Though it is limited. IIRC there aren't any server callbacks if people hit fly from spectator.

It is rendering the smoke object not a trigger zone, but yeah it is weird. Looks like they fixed it for the the static objects of big smoke but not on the ones created via scripting/trigger.

Reported Sep 2021.

I think with any range the first and last value are always less likely, it depends on how many options there are and what they mean. If you had 5 groups and wanted to do math.random(5) to pick which one you wanted to spawn, then that would be a small range. The odds of getting options 1 and 5 would be lower than the other 3 and that is where the function shines at. With timing it can be less of an issue because you can use a smaller time value. math.random(10, 20) may end up with some pretty similar results, but math.random(600, 1200) would have some variation involved. That function sets a limit for how many table entries it will create to 50, so if you had more than 50 options it would effectively be the same as math.random(n). Worth noting I haven't tested the variation involved with math.random() and it spitting out decimal values. You might get decent results by doing that, multiply by 10, 100, or whatever, and using math.modf() to get the whole number as the random choice.

Suppose it depends on the range of the number you want to generate. If it is a relatively small range then doing it a lot of times can be one work around. I seem to remember that math.random, at least in DCS, had a tendency to select the first and last possible value less often than any other value. Run it 1000 times and a pattern emerges type of thing. To fix this I made a function for mist that tends to normalize the results. Basically it inserts each possible random value into a table repeatedly to a limit. {1, 2, 3, 4, 1, 2, 3, 4, etc} Then picks a random table index and returns that as the choice. function mist.random(firstNum, secondNum) -- no support for decimals local lowNum, highNum if not secondNum then highNum = firstNum lowNum = 1 else lowNum = firstNum highNum = secondNum end local total = 1 if math.abs(highNum - lowNum + 1) < 50 then -- if total values is less than 50 total = math.modf(50/math.abs(highNum - lowNum + 1)) -- make x copies required to be above 50 end local choices = {} for i = 1, total do -- iterate required number of times for x = lowNum, highNum do -- iterate between the range choices[#choices +1] = x -- add each entry to a table end end local rtnVal = math.random(#choices) -- will now do a math.random of at least 50 choices for i = 1, 10 do rtnVal = math.random(#choices) -- iterate a few times for giggles end return choices[rtnVal] end

If you are using trigger zones it is quite simple: local ref = trigger.misc.getZone("targetArea") trigger.action.circleToAll(-1 , 1, ref.point , ref.radius , {0, 0, 0, 0} , {1, 0, 0, .7} , 0 , true) Anything drawn in the editor is a little annoying because you have to iterate env.mission.drawings and the formats aren't easily plug and play with scripts.

Unfortunately the drawings in the mission editor are completely separate than what you can do via scripting. The best triggers can do is toggle on/off the different layers. If you wanted more flexibility you can use scripting at the downside of less options for stuff like text and line types. If you want to you can easily use trigger zones, drawings, or even group routes as a basis for what gets drawn via scripting.

If that waypoint is time locked then the AI will attempt to adjust their speed to reach that waypoint at the specified time. If they are speed locked then the ETA is a literal distance/speed for the assigned waypoint. The value in the editor ignores other factors like the time it takes to turn, climb, or built in tasks. For instance if you have a orbit task set to last for 5 minutes it doesn't add that 5 minutes to the ETA for the next waypoint. If it is time locked then the AI can only do so much if they are ahead of schedule, they will slow down as much as possible, but won't orbit/wait at that waypoint until the set time. They will continue on to the next waypoint and then follow the rules for that waypoint. Since you are assigning the task you know where it is, where the waypoint is, and how fast you told the AI to go there. As a result an estimated time of arrival can be calculated. Outside that, no there is no function to query when its going to get there.

Slight omission on my part. It is copying the group as defined in the editor, which means the group still has the "late activation" value applied to it. So it is spawning a group, but the group isn't activated. You have to remove that value. local gp = mist.getGroupTable("USAF") gp.clone = true gp.lateActivation = nil local rndAlt = math.random(4, 10) * 1000 for i = 1, #gp.route.points do gp.route.points[i].alt = rndAlt end mist.dynAdd(gp)