Grimes

It is in plain text. Just load it in the editor and copy the text out of the do script box.

It is certainly possible. I had to fiddle with it a bit since it appears some of the AI behavior had changed after I wrote the initial code. Plus I haven't done a ton of generating AI flight plans, tasking, and then sub-dividing the tasks ever since I was experimenting with this. The AI still do some weird things that warrant further investigating. But this might give you an idea of what is needed. PAI_mult_JDAM_tasking_within_group.miz

For what its worth I liked seeing the most recent post of a given sub-forum. If I saw something odd it gave reason to see what it was about. Especially in the sections I don't read much. If it was customizable it'd be great. All I wanna see are the latest posts in the main bug section and the DCS World Topics. But I guess rep is back now? So thats neat.

Color pallet is better than default, but the font still looks off.

Upload C:\Users\<username>\Saved Games\DCS\Logs\DCS.log so it'll be easier to check if a lua error occurred with the editor.

Reported. I recreated it with my own setup to try and reproduce it, but was initially unsuccessful and had to check out your track. If you move the egress point east a bit it will *mostly* just do a 180 to that waypoint. I think you are correct with it flying a new waypoint segment, but it tries to go to the closest part of that route. For example if you moved the egress east a bit it will turn toward its waypoint, but it over-shoots and has to compensate a little. Based on the angles and route it is taking from changing the waypoints, it appears to be aligned with the next waypoint and the approx drop point.

Guess it was missed before. It is now reported. Seems similar to an issue with amphibious units where if you set the speed they can't go on the water, the group will give up eventually.

Reported. It applies to the other WW2 aircraft also.

The unit name table is just a table indexed numerically. table.insert(tbl, unitName) or tbl[#tbl+1] = unitName would work.

DCS World\Doc\User Manual 2020.pdf https://wiki.hoggitworld.com/view/DCS_editor_actions Has some but the wiki is more geared toward the scripting engine than maintaining editor documentation.

If you have a small sample mission it would be helpful. Best guess is they aren't getting added to the DB for one reason or another.

From the description it sounds like the "X: Start wait user response" trigger. Which only works in singleplayer or for the host.

If you want to use it more as a slot management then I'd recommend using the gameGUI API. If its more for combined arms and knowing which vehicles players are in then you are pretty much out of luck unless this and another bug get attention. A tiny bit of background for why it might not be fixed. It is considered a "local" event that is used to send an event to the debriefing/logbook code for each player. For example the following is a section of what is added to the debrief.log for the server and a client in the same test. Server: [2] = { t = 30611.734, type = "birth", initiatorMissionID = "2293", }, -- end of [2] [3] = { type = "start shooting", weapon = "KPVT", target = "A-10A", t = 30621.811, initiatorMissionID = "2296", targetMissionID = "2293", }, -- end of [3] Client [213] = { type = "under control", initiatorPilotName = "New callsign", target = "Aerial-1-1", t = 30610.641, targetMissionID = "2293", }, -- end of [213] [214] = { t = 30610.641, type = "engine startup", initiatorMissionID = "2293", }, -- end of [214] [215] = { t = 30610.641, type = "birth", initiatorMissionID = "2293", }, -- end of [215] [216] = { type = "start shooting", weapon = "KPVT", target = "A-10A", t = 30621.846, initiatorMissionID = "2296", targetMissionID = "2293", }, -- end of [216] Worth noting the timings don't match perfectly. Could be any combination of testing locally on the same PC and the server had slmod running which hijacks the events a bit which could delay it. Aside for the timing there are two main differences. 1. The client has different events for when they spawn, it has the under control (which is enter_unit) and engine startup. Where-as the server just sees the birth event. 2. Client also has a bunch of birth events that occur while connecting for every unit in the mission. Hence for the server the player spawning occurs at event 2 while for the client it was 213. There is also a bug related to "leave_unit" event where the event occurs on the server whenever someone just selects different slots in the MP ui. You don't even need to have spawned into a unit for that event to occur.

1 and 3. Just looking at the normal carrier SP version of those missions all of the spawn points are accounted for. If you are using the super carrier and statics are placed at the same locations there should be an available spawn point or 2 on the patio section. Most likely there are no spawns available due to being blocked by static objects. Removing some of them should help. See this page for details: https://wiki.hoggitworld.com/view/DCS_editor_carrier_spawns 2. There is a known bug where those static placed deck crew have collisions.

You have to add an event handler and check for data based with that event. For example with the crash event: https://wiki.hoggitworld.com/view/DCS_event_crash local function eHandle(event) if event.id == 5 then if event.initiator and event.initiator:getName() then if mist.DBs.clientsByName[event.initiator:getName()] then --that client crashed. end end end end mist.addEventHandler(eHandle) Or reverse that slightly, check if there is an initiator and then check if that initiator was a client, then check the event type to do whatever it is you want to do. Its really important with event handlers to check if the objects and different values exist. There are situations where they won't be returned or accessible still.

Nope.

If its not working check dcs.log and make sure slmod is loading fully and isn't spamming errors. Easiest way to know if it is adding to the stats is to look at the file or check your stats, remember what some entry was saved as, go do stuff, and see if the numbers changed. Also could enable mission stats, it'll be everything that the stats recorded for a given mission, if its not blank the it is working. It is all in the autoAdmin table section. autoAdmin.autoBanEnabled, autoAdmin.autoKickEnabled, and autoAdmin.autoSpecEnabled set to true if you want it on. The next important bit of the setup are the levels, starting with: autoAdmin.autoBanLevel = 89 Its the point value that if a player gets above then that action will be executed on their next offense. It gets a bit more complicated in the penalty type rules starting at for each penalty type based on the values in autoAdmin.flightHoursWeightFunction and each penalty type's decay function. autoAdmin.teamHit.decayFunction = { [1] = {time = 0, weight = 1, }, [2] = {time = 3, weight = 0.75, }, [3] = {time = 30, weight = 0.25, }, [4] = {time = 60, weight = 0, }, } The simple explanation is that slmod stores the time when a penalty occurred. Based on the number of days since a given penalty it will modify the actual score. Say you hit a human player which gives 12 penalty points. After 3 days that value will be at 75% of the initial value (9) and after 30 days it'll be 3. The flightHoursWeightFunction applies the same rules, but acts as a multiplier that takes how long someone has flow in the server into account.

Its fairly straight forward in that you have to iterate the table. Suppose most of the choice is down to how you want to determine if there are mavs or not. There are basically two main ways go about doing it, searching the string of the typename or display name, and using other values in the desc sub-table to figure out the approximate use of a given weapon. The first is quite simple. Make a table list of the type name or display names, iterate through ammo table, if that entry exists then do whatever it is you want to do for a given check... local mav = {['AGM-65D'] =0, ['AGM-65H'] = 0} local totMavs = 0 local ammo = Unit.getAmmo(whatever) if ammo and #ammo > 0 then for i = 1, # ammo do if mav[ammo[i].desc.displayName] then mav[ammo[i].desc.displayName] = ammo[i].count totMavs = totMavs + ammo[i].count end end end That will populate your mav table with however many missiles it has and add to a totMavs number value. A slightly different way would be to search for part of a string value, this is most useful if you want to broadly categorize a certain type of missile. Could even break it down to being more generalized by searching for just 'AGM'. local totMavs = 0 local ammo = Unit.getAmmo(whatever) if ammo and #ammo > 0 then for i = 1, # ammo do if string.find(ammo[i].desc.displayName, 'AGM-65') then totMavs = totMavs + ammo[i].count end end end The other option is more of a generalization for if you had certain rules for AI based on the weapons they have without making a full itemized list of every single weapon. For reference: https://wiki.hoggitworld.com/view/DCS_Class_Weapon desc.category = 1 -- it is a missile desc.missileCategory = 6 -- it is an a2g weapon desc.rangeMaxAltMax = whatever -- gives you an idea of max range desc.rangeMaxAltMin = whatever2 -- lets you know its not a super long range weapon desc.guidance = 1 or 6 -- its an ir or tv seeker, so lock range is also limited by that. tv limited by light conditions desc.box = {} - gives an idea of the physical size of the weapon desc.warhead -- gives an idea of how much boom boom it can do. With that information at hand you can iterate through and get a rough idea of the type of weapons an aircraft has on board and their use.

Not explicitly. Gotta check the player via Unit.getAmmo(), if they have something that isn't allowed or have it above a certain quantity then you gotta start the enforcement. Either displaying a message with warnings, eventually creating an explosion, or adding mass to the aircraft as a penalty.

I believe it is classed similar to a FARP object and therefore doesn't despawn like normal objects can.

This is a long reported bug going back to 2014. I am under the impression that it will not be fixed.

For the most part yes it is the same. See this thread: https://forums.eagle.ru/showthread.php?t=287905

What I was saying is there were several ways a setting was applied previously. -Enforced in the mission file: Has always worked and always takes priority. -Settings used by whoever saved it last: Can be enforced depending on the setting. Like if you had saved using game mode then that would be enforced. -Settings used by the server with "use these settings for all missions": As far as I can tell this no longer applies.

Looks like you might be miss-reading the documentation a bit. This page might help: https://wiki.hoggitworld.com/view/Scripting_Documentation_Guide Its formatted like this. What is returned the function name(any required input value, any optional input value) So with cloneInZone you might have it be something like... local newGroup = mist.cloneInZone ('Group B', 'First') Now its important to remember that the input values have to be in the correct format, from my example above I put Group B and First into quotes. This makes them a string. To use as you did with your example you'd have to declare them as a variable. local First = trigger.misc.getZone('First') local Group_B = 'Group B' So this is somewhat of a problem due to how moving zones are handled by the game. At least last I checked the zone doesn't actually move, it just uses the radius as a reference to check to see if something is within a given radius of that unit. What you can do is use another function, the one that cloneInZone uses, to do it. local vars = {clone = true, groupName = 'Group B', radius = 1000} vars.point = mist.getAvgPos(Group.getByName('Group A'):getUnits()) local newGroup = mist.teleportToPoint(vars) If you look carefully at my above example I use mist.getAvgPos which does the same basic thing as getAvgPoint. The difference is getAvgPos accepts a table of unit objects where-as getAvgPoint is a table of points. To get the same value via getAvgPoint the code would look like this: local gp = Group.getByName('Group A'):getUnits() local points = {} for i = 1, #gp do table.insert(points, Unit.getPoint(gp[i])) end local avg = mist.getAvgPoint(points) 3.-To get Group B to move to the point i got at #2 table mist.groupToPoint (??? group, ??? point, string form, number heading, number speed, boolean useRoads) [/quote] Kind of an oversight on my part is that this function is only meant to be used with ground groups and not ships. But building a ship waypoint is rather simple.. [code] local vars = {clone = true, groupName = 'Group B', radius = 1000} vars.point = mist.getAvgPos(Group.getByName('Group A'):getUnits()) local newGroup = mist.teleportToPoint(vars) local points = {} local startPos = {action = "Turning Point", type = "Turning Point", speed = mist.utils.knotsToMps(30)} local leadPos = mist.getLeadPos(newGroup.name) startPos.x = leadPos.x startPos.y = leadPos.z -- table.insert(points, startPos) local dest = {action = "Turning Point", type = "Turning Point", speed = mist.utils.knotsToMps(30)} -- define dest.x and dest.y however you want table.insert(points, dest) mist.goRoute(newGroup.name, points)

You'd have a trigger for each group being dropped off. Once>Part of Group 1 In Zone>Flag 5 increase value by 20 Once>Part of Group 2 In Zone>Flag 5 increase value by 20 Once>Part of Group 3 In Zone>Flag 5 increase value by 20 Once>Part of Group 4 In Zone>Flag 5 increase value by 20 Then you turn some flag on when you want to check the success rate. Call it flag 10. Once> Flag 10 True and Flag 5 equals 20 and random 20%> Do action Once> Flag 10 True and Flag 5 equals 40 and random 40%> Do action Once> Flag 10 True and Flag 5 equals 60 and random 60%> Do action Once> Flag 10 True and Flag 5 equals 80 and random 80%> Do action However due to how random is evaluated you must have another trigger to remove the condition. Once> Time since Flag 10 is 1 second> Flag 10 Off. Alternatively you can use a simple script when evaluating the success. Do Script local val = trigger.misc.getUserFlag('5') if math.random(100) < val then trigger.action.setUserFlag('1', true) end Once> Flag 1 is true > Success!