Grimes

If you want to check for clients you can just use the built in DB table for them. for uName, uData in pairs(mist.DBs.humansByName) do if Unit.getByName(uName) then -- unit is alive and exists local nickname = Unit.getByName(uName):getPlayerName() trigger.action.outText(nickname, 100) end end if Unit.getByName(whatever) is required because both the humansByName table and makeUnitsTable function just contain a static table of what the unit names within a given mission and don't keep track if anything is alive. Think of it as a list of units that fit the parameters. humansByName being something that is created by mist with a bunch of other data in there as well like coalition, country, unit type, etc. On the other hand what gets returned by mist.makeUnitsTable is just that, a list of unit names indexed numerically. From your code the " local nickname = Unit.getByName(units[i]):getPlayerName()-- this is 35th line where error is " can fail because Unit.getByName(units[i]) can return a nil value if that unit isn't alive which in turn causes an error because it is effectively nil:getPlayerName().

Not dead, but certainly slowed down. I'm rather content with it being the lightweight option and have always preferred adding other scripts that use it to handle specific things like CTLD, my old IADScript, and others. Doesn't help that DCS patches aren't exactly a treasure trove of new scripting functions, so there isn't a constant need to add functionality. I'll typically add stuff whenever I delve into mission making as I'll end up making something useful that could be adapted for mist. The functions added back in November are a result of that for example. I also have a habit of only using the development branch on github and only merge it to the main branch rarely.

Just to add to what dark_wood said because it is a pretty important distinction. It is the probability that the group will exist in a mission. Anything that doesn't spawn with that value is effectively deactivated and not accessible via triggers to spawn it. This is good for a quick and dumb way to spawn random threats that aren't objectives where the logic of what spawns is not important. It is also very useful for the scripting engine because the data about that group is still in the mission file. So I often use it as a way to define units that make up a template or to force spawn it back in via scripting at a later time.

There are a few things wrong there. The units table is a list of unit names. So you already have that information. units[i] is a specific unit name from that table. Unit.getByName(units[i]).unitName is a nil value. That entry simply doesn't exist since Unit.getByName returns a unit object. The equivalent would be Unit.getByName(units[i]):getName(). However that is kind of pointless since you already have the name. If the "u" value was the unit object its not something that can be directly output via outText since its not a string or number. It looks like a table but its a little more complicated than that. I'm guessing you want something more like local u = Unit.getByName(units[i]):getPlayerName()

Ah crap. I apparently forgot to update the documentation. mist.getRandPointInCircle has the ability to limit the range of angles used to generate a point since 2017. So you can make the possible area pacman shaped if you wanted to. Should be something like this. local u = Unit.getByName('whatever') local heading = mist.getHeading(u, true) local headingDeg = math.deg(heading) local newPoint = mist.getRandPointInCircle(u:getPoint(), 20000, 10000, headingDeg +90, headingDeg - 90) Might have to switch the headingDeg values since I kinda forgot how its supposed to work. Big oof. Edit; updated the wiki documentation and confirmed that the above example is correct.

The sample on that wiki page literally passes the groupName to the function that the command calls. local function imLost(gName) if Group.getByName(gName) then -- gotta be paranoid local units = Group.getByName(gName):getUnits() -- do whatever you want with that table of units because I cant think of a good example at the moment end end Another way to write it might be more like: missionCommands.addCommandForGroup(groupId, 'Halp', nil , imLost, "someGroupName") However I would try to do everything in the function itself because by having to check flag values by triggers kind of defeats the purpose. You could certainly check the flag value in the script if you made some list that associated a flag to a group with a list, but writing the whole action in the function will simplify things.

It is also a ramification of ED hiding most the database files where you could go in and look up CLSID values for weapons and the like. I suppose more example tables could be provided on the wiki, especially for different group types. That said I'm not going to do it for everything. I try to update the ObjectDB on github for that whenever something gets added or after major patches. Maybe I can make a very simplified list that goes on the wiki but that would be the extent of it.

https://wiki.hoggitworld.com/view/DCS_func_addCommandForGroup You have to add the command to the group, pass some identifier of that group to the function called, and then use that identifier to do with as you please. Sadly we don't have addCommandForUnit so either make an educated guess who sent it, have only one player per group, or make a specialized radio command for each member of the group via sub-menues and hope they choose the correct one.

It is just a behavior difference with how AI spawn on the runway vs spawn on the ramp then taxi to the runway one at a time. There is no way to control this behavior at present.

The fun and annoying thing about a function like getCategory() is it should be conditional on where and how it is called. The annoying thing is it is bugged at the moment. At least it is bugged so it is still useful. Let me explain. Object.getCategory() would return the main architype for a given object. So the following values would correspond with each other. UNIT 1 WEAPON 2 STATIC 3 BASE 4 SCENERY 5 Cargo 6 Unit.getCategory() would return the type of unit. AIRPLANE = 0, HELICOPTER = 1, GROUND_UNIT = 2, SHIP = 3, STRUCTURE = 4 Airbase.getCategory() would return the category of airbases. AIRDROME = 0, HELIPAD = 1, SHIP = 2, In practice it could look something like this: local cv = Unit.getByName("Stannis") Object.getCategory(cv) -- 1 Unit.getCategory(cv) -- 3 Airbase.getCategory(cv) -- 2 However in practice as stated above that aspect of it is annoyingly bugged. Only the Object.getCategory() works correctly. For the others you have to use getDesc() and check the category in there.

That isn't a bug and is something you have to code around. Scenery objects simply do not belong to a coalition. This is the same for some fence around an airbase and some fence in the middle of nowhere that got destroyed due to a falling air to air missile. The class hierarchy is basically: Object>Scenery Object>Coalition>Unit, Weapon, Airbase, StaticObject So they all inherit the object class, but weapons, units, airbase, etc also inherit the coalition class. While scenery objects just inherit the object class. Should be able to check event.initiator:getCategory() to filter out Scenery objects and everything else.

And comparing what a 3rd party DLC for another game added in terms of scripting functions vs the total of what is in DCS is crushing mine. ^_^

Might have to ask Heatblur for specifics but I think this is done on purpose. Unsure if it'll change whenever they make a proper Iranian F-14A variant. But from what I recall it has to do with not assuming or knowing if Iran made a datalink avionics that is compatible with the A-50 or EWRs. Additionally what that looks like, how it functions, cockpit controls, etc are also unknown. Maybe an editor option could be added to disable a restriction. Its more or less the same reason why F-18 and F-16 can't get datalink info from the A-50.

Not really. I know in the F-14 there is a "failure" that you can force that corresponds to the RIO. But that is for single player only and it isn't a common to every aircraft.

Its been like that for a while now and its been done on purpose. I'll re-raise the bug report in hopes they might change it back. There is a workaround that kinda shows how pointless it is to limit the weapons. On the payload screen you can select one of the presets with A2A missiles you want on the fuselage. Then edit the payload on the "mission payload" bar. Edit to your heart's content. When finished with the mission payload highlighted, press the "copy" button at the bottom to save it as a preset. The downside being you might have to first select "CAP" as the task, select the payload you want, switch it to the task you want the AI do to, then save a copy of that A2A payload. When switching tasks for the AI it should keep the mission payload the same. As you can see in my attached screenshot I can't manually put AIM-7s on that loadout, but by doing what I said above I was able to create that preset.

Thanks, reported.

Nope. The events don't really do anything other than limit whenever a condition can be evaluated. However the group a specific unit belongs to can't change anyway. Since you are adding a trigger for that specific unit then you know that it belongs to a specific group to do whatever you want with it. The question seems to be more phrased in terms of how the scripting engine does events where its just an object that causes a given event and it could be almost anything in the game where you might have to figure out the object type and group to do something specific.

Fixed! https://github.com/mrSkortch/DCS-SLmod/commit/49742962b2fe636c9ddc070df5ac3a22e7debe14 Basically the way gun events work is really weird and often list the weapon name as being what was shot and the shell type for hits. Usually both are the names as used in the actual game files. So GAU_8 instead of GAU-8 would be an example. Anyway to get around this there is a little hack of sorts to look at another event list that has the corrected names but isn't that useful for anything else. I had a really basic check that the event type and time the event occurred at was the same to use the correct weapon value. Well it turns out ED changed the time value in one of those event tables thus they'd never be the same and the corrected name value that slmod uses wasn't ever assigned. Having kills, shot, numhits, and hits within the weapon table directly is another bug that I'll have to fix at some other time. I'd recommend going through and deleting those entries as it might screw up the stats display.

Thanks for the heads up. Reproduced it and investigating specifically what changed. It at least appears to be ok in terms of bombs, missiles, etc. However its the gun stats that are being messed up by this. I think a variable name might have either changed or is missing. If it was changed then that should be a quick fix, if its missing it might be a bug or something annoying to work-around.

You have historical mode on. Its a filter that limits the available units for a given country based on the year. Combined Task Forces don't have dates setup for any unit, thus it is empty except for the unit you placed. Click the watch icon at the bottom to turn off historical mode.

Yeah its off by 1. So the percentage changes with the unit type. EDIT; Turns out its an issue with getLife, not getLife(). getLife0 and getDesc().life are the same value and is the correct value stored in the hidden database files.

There is no scripting function for that.

Sadly no. Its been requested.

String concatination in lua is two periods. If you use + it is assuming it is adding two numerical values. net.log('[DCS Exporter] onMissionLoadBegin ' .. DCS.getMissionFilename())

The scripting engine isn't limited to the "role" that different aircraft are assigned to. The limitation is more to do with whatever attributes a given group has. The same goes tasks like "Search and Engage" where the editor limits what you are able to assign to it, but the task is still the same thing. Here are a couple of examples. -- A CAS task local cas = { id = 'EngageTargets', params = { targetTypes = {'Ground Units'}, priority = 1, } } -- SEAD local sead = { id = 'EngageTargets', params = { targetTypes = {'SAM'}, priority = 1, } } -- This would allow the AI to attack any fighters, sams, or tanks that they find. local combo = { id = 'EngageTargets', params = { targetTypes = {'Fighters', 'SAM', 'Tanks'}, priority = 1, } } So you can either set a new mission task or assign directly via pushTask or setTask.