Grimes

Its never been a feature of MP. Triggers that set failures or do anything with the cockpit only work on the "player" aircraft of which there can be only one and it only works in SP.

Not really. Maybe setting unit emissions on/off could micro manage that, but I'm not 100% certain it will work. There might be different results with different types of sams, but I'd think if one launcher was significantly closer to a target compared to the others then it'd fire first.

I probably should have double checked the version number before testing it, but the version of slmod you have installed is quite old. Slmodv7_5_090 compared to the current versions: Current main branch build is 7_5_128 and develop branch is on 7_6_147 I tested the mission with both of those versions installed and stats did record. Though in my laziness of not wanting to plug in my joystick I added an A-10A to kill stuff with instead of trying to mouse and keyboard a huey. That unit name thing is more a general MP client sync with the UI issue than anything. You can't spawn units in DCS if they don't have names. They simply wouldn't spawn if you tried. However the library scripts like mist, moose, or whatever else typically will generate a name if none was provided when spawning through their functions.

Unfortunately no that isn't currently a feature in DCS. You can modify the miz file itself. Within it the radios are stored on a per aircraft basis and are generally in a format like below. You can manually go in and edit the presets or write some code to do it for you. ["Radio"] = { [1] = { ["modulations"] = { [1] = 0, [2] = 0, [4] = 0, [8] = 0, [16] = 0, [17] = 0, [9] = 0, [18] = 0, [5] = 0, [10] = 0, [20] = 0, [21] = 0, [11] = 0, [22] = 0, [3] = 0, [6] = 0, [12] = 0, [24] = 0, [25] = 0, [13] = 0, [26] = 0, [7] = 0, [14] = 0, [15] = 0, [19] = 0, [23] = 0, }, -- end of ["modulations"] ["channels"] = { [1] = 243, [2] = 264, [4] = 256, [8] = 257, [16] = 261, [17] = 267, [9] = 255, [18] = 251, [5] = 254, [10] = 262, [20] = 266, [21] = 133, [11] = 259, [22] = 257.8, [3] = 265, [6] = 250, [12] = 268, [24] = 123.3, [25] = 344, [13] = 269, [26] = 385, [7] = 270, [14] = 260, [15] = 263, [19] = 253, [23] = 122.1, }, -- end of ["channels"] }, -- end of [1]

If you make that test mission and its not recording the stats then please post it here so I can run it locally and try to figure out what is going on.

I try to keep the scripting engine documentation on the Hoggit wiki as up to date as possible. What you see in the functions category is what exists for the scripting engine. The same applies to tasks in terms of what AI can be assigned to do. It applies to "class" functions where the first value that would be passed is the object. Its easiest to understand if the function has multiple input values. local gp= Group.getByName('whatever') Group.getUnit(gp, 3) and gp:getUnit(3) are the same thing.

Yes, still broken.

Slmod monitors for birth events and populates a lookup table that it uses for stats and if that object isn't found it spits out that error. The error text was never updated to reflect that it can know about stuff spawned via script. It is also common for that error to occur when map objects are hit, which is also something that is much more likely to happen on the new maps. Is it any particular types of objects that are being spawned and not being counted when killed? You can check your main dcs.log and DCS in MP will list events as they occur along with slmod's log messages. Part of the logs that DCS generates for events has an initiator and target identifier, as long as both are populated slmod should be able to record the stat.

That is a error in the guide. Attack unit is only available in CAS, CAP, Intercept, SEAD, and Anti-ship roles just like the "Attack Group" task. Since static targets can't move you can use the bombing task to accomplish the same result. The difference being the AI will keep attacking until the target is dead when you use Attack Unit and the AI will keep attacking the point assigned with the bombing task with however it is setup.

It means that task was assigned at a previous waypoint and is still active. So if there was a stop condition at a certain waypoint was setup then after that waypoint the task will disappear. Worth noting that if you have a "search and engage in zone" and a "sead" task active then the AI will do both. Depending on what was assigned first will be used as the priority. So it would be possible for AI to detect sams outside the preferred engagement zone and attack that first then run out of weapons and totally ignore what you actually wanted them to focus on.

There is no "current player" type of parameter. I assume you are using mission commands to query the distance. Annoyingly the smallest those go is at a group level, so you have two options. 1. Make each client their own group, and create mission commands for each group passing the groupId that called it to the function for checking the distance. 2.Add a submenu for each client to correspond with whatever commands you want.

Suppose it might be an issue with the weapons the aircraft are armed with and what they are attacking.

Gotta use a controller to set a command. https://wiki.hoggitworld.com/view/DCS_command_smoke_on_off

I think it might be setup that way primarily for "civilian traffic" that is baked onto the map. You have some highway where the roads are separated enough that you can't do it as one big road spline, so it needs two distinct roads to draw it. By default the roads would be bi-directional, thus with civilian traffic enabled there would be two roads next to each other with traffic going in both directions on each. Its not quite realistic and all that so they make a given road go in one direction at the consequence of actual AI units pathfinding. There have been a few bugs like this when there were no alternate roads available. I would say that based on your screenshot if the other road didn't allow for the north to south travel that this instance would be a bug.

No. These is nothing within the lua predicate trigger condition that refers to how it was activated or anything like that. You have to add an event handler via do script to check for what you want.

There are no triggers or scripting functions that have access to any of it. The best you can do is make guesses based on the rules of the system. An aircraft spawns that is -1 from that warehouse for a given aircraft type. Using getAmmo you can know some of what they have loaded on board.

Yes, you can use the warehouse system to set how many exist. However the resupply can't really be triggered. Suppose with the settings for it you could get it to resupply on a timer of sorts. The rules are basically if the supply of some object is below the limit then send the supplies up to a given size. There arent triggers for resupplying warehouses, but it can be cheated if you use AI. Not that you can read the current warehouse value via triggers anyway, but if a base has 5 F-18s at the base and you spawn AI in air, that then land, park, and despawn, then the aircraft and whatever they have onboard will be added to the warehouse.

It impacts the time it takes for an AI MLRS unit to begin a salvo. Without this unit in the group it takes about 3 minutes to filre, while with it the group takes about a 1 minute to fire.

By the way for anyone curious this is related to the units being immortal. The hit event works as expected if the clients aren't set to immortal.

Sorry didn't have the time to look into this until just now. Yeah I did forget a () in there. However there also appears to be a bug with how DCS does the start and stop condition scripts. So that method is out for checking. The ... in the script is like a special way to write "self" for that group. It only works in scripts run as part of a group's task. Normally you would need to do local gp = Group.getByName('whatever') However within that group task it can just be: local gp = ... Its like a shortcut. You can write the same bit of code and copy it into a bunch of groups do script tasks without having to change anything. I've changed it to run that code on a do script in the triggers. Also changed the stop condition of that task from the script to just a flag value. me Bandar Abbastest_modf.miz

mist and moose are scripting libraries that you load via do script file that simplify and add functionality to the scripting engine to make certain things easier. Both are limited to what the scripting engine itself can do. An example of that would be to package the sample of code below into a function and save it in a file. Then whenever whenever you want to use it instead of copy pasting it each time, you just load the file its in and can load at any point. So to answer your question you can do a mix of flags and scripting to accomplish it. There is no trigger to see how much or of what type of weapons a given aircraft has on board. Thus you will need to use the scripting engine to check it for the F-18 flight and then to order them to go to a WP to refuel before RTB via setting a flag. The setup would be something like this. F-18 Search and Engage sams task> Stop condition script local gp = ... local harms = 0 for i, unit in pairs(gp:getUnits) do local ammo = unit:getAmmo() if ammo and #ammo > 0 and harms == 0 then for j = 1, #ammo do if ammo[j].desc.displayName == 'AGM-88C' then harms = harms + ammo[j].count end end end end if harms == 0 then trigger.action.setUserFlag(20, true) return true end This would set flag 20 to true and would stop the AI's task to engage sams. Then you can setup triggered actions for each group to switch waypoint and set the stop condition for the F-15 escort task to be if flag 20 is true. Now create a trigger for flag 20 is true with the actions for AI Push Task (F-18 switch WP). I'd set the AI to refuel at that waypoint that way they will do it even if they dont run out of HARMs.

Group.getCategory should always work because the group object is its own thing. The problem with the others is that weapons, units, etc extend the object class. So its basically the same function but its supposed to be modified slightly. A workaround is to check the category value stored in getDesc() for a given object.

Hey Druid, long time no see, hope all is well. I've reported this. Actually found some interesting results regarding some of the aircraft types take really really bad shots. I did discover that the skill level greatly impacts the behavior. For instance with a Su-25T armed with R-73 the degrees off boresight it shot at was basically: Rookie/Trained at < 5 degrees, and the AI had to spend several seconds following their target before firing. Veteran: 35 degrees Ace: 40 degrees.

Yes. Fuel tanks matter.

Its reported.