Grimes

https://github.com/mrSkortch/MissionScriptingTools/blob/development/mist_4_5_103.lua Development branch. I need to tidy a few things up and add documentation but I should be merging it to the main branch sooner or later.

Looks like the fact that the group gets activated is what is messing it up. Removing late activation and the group activate trigger the group that gets respawned will correctly bomb. I'm not entirely certain why that is a problem. If I changed it to clone then the cloned group would bomb normally. It is a combination of late activation, using group activate, and then respawning the same group. One thing of note is that Mist is ignoring the lateActivation value set in the editor, so if you respawn the group it just spawns in immediately instead of needing to be activated. I'm not sure if changing mist to spawn it late activated and then having to activate the group would also allow it to function as expected. Nor if that would be a good idea to change. No. Unfortunately they are tied directly to enumerator values and the game will choose the callsign that is appropriate for that unit type. https://wiki.hoggitworld.com/view/DCS_enum_callsigns Say you used this to change the callsign via : Group.getByName('whatever'):getController():setOption({ id = 'SetCallsign', params = { callname = 2, number = 1, } }) If the group was a tanker it'd be 'Arco', if its an AWACS it'd be Magic. etc. Fun part is if its a Russian aircraft it'd just be "21".

BTW I added a mist.groupIsDead function that is basically the if statement above. https://wiki.hoggitworld.com/view/MIST_groupIsDead

Running a mod? Ramat David doesn't have large spawn points for aircraft of that size and on my end it despawns shortly after landing automatically.

Should work with: https://wiki.hoggitworld.com/view/DCS_option_altitudeRestrictionMax I haven't actually tested those settings yet and it is missing from the main AI enumerator table, which may or may not matter. Assuming it does work then something like this would set the max engage altitude to 4000 meters. for i = 1, 2 do local allGroups = coalition.getGroups(i, 2) for j = 1, #allGroups do if string.find(allGroups[j]:getName(), 'AAA') then allGroups[j]:getController:setOption(29, 4000) end end end

If its a ground or ship group that you spawn without specifying to use a route then they will just sit there. Aircraft will RTB pretty much immediately on spawn. But as long as the route is assigned any task within that route will also be present.

A new track is not needed.

When you respawn it with the route it should keep every single task that was defined for it. I will test it to see if there is anything odd with it.

Assuming AI spawn at the same time I believe the order that they get placed in is based on what spots are open and possibly lowest groupId value. It shouldn't impact the triggers or spawning AI in later. What could have an impact is if multiple AI are set to start at different times but are blocked or delayed from moving to a catapult and the AI get into a "ready to taxi" state. It might have a different take-off sequence than you expected because it prioritizes shortest taxi distance first. For instance spawning a group at 1 second and another after 2 seconds, it is possible the 2nd group taxies first if that unit type has a faster startup time. AI should still land if no parking is available. I forget which happens but either the unit will despawn almost immediately after landing or the parked aircraft on the deck will despawn to free up space. AI also despawn automatically after about half an hour anyway so you'd have to manipulate where they go and land a bunch of aircraft to see it.

Uncontrolled is only available for aircraft that are set to "takeoff from ramp". If they are take-off from ramp hot or take-off from runway the option is not available. The miz file would help here with seeing how the uncontrolled, late activate, etc is setup to try and figure out what is going on with the spawning. As for landing it is difficult to say as it is entirely built on the whims of the AI. There generally is a lot of problems whenever AI are set to land and players or AI are on the base waiting to take-off. Bases get set in either "take-off" or "landing" mode and tend to allow and expect only one action to occur. If it is flying away it might just decide it can't land there and heads toward another base. Again examples would be helpful.

This is one of the lovely bugs where the behavior is different between open beta and the test version. That said it looks to be a combination of things working against the AI here. For starters they are given a task to attack the group which forces the AI to know where they are at and make a B-line for the group. The target group being above the helicopters in defilade causes the AI to need to climb quite a bit just to see the target. I'm not sure where you want them to go to shoot at the targets. Adding a basic route and keeping the CAS task while deleting the attack group task, thus allowing the AI to detect and engage the group after detection appears to yield slightly better results for the Apache. Doing the same for the KA-50 more or less has the same aggressive behavior. Actually increasing the altitude for the KA-50 allows it to detect earlier and the vikher to hit the turret rather than the hull of the tank which seems to increase the lethality of the missile. For instance it destroyed all 4 tanks in one pass on a test. From Taz's mission/track I made them only AI because that is how I like to test this stuff and there at least appears to be a difference in how the KA-50 attempts to attack targets compared to other helicopters. KA-50s would make very slow and seemingly bugged approaches. Other helicopters like Mi-24P, AH-64A, and Mi-28 were able to attack mostly without issues, but each attacked a little different. From this I reported 3 different bugs. Apache flight behavior difference in test build, KA-50 making drastic movements when approaching a target and just being bad at attacking, and Apache firing hellfire at bad angles.

Only guess is to make sure you are using the Group controller. Ground vehicles don't have a unit controller. local controller = Group.getController() Ground and ship AI don't have a ton of capability when it comes to decision making and moving. They follow the route they are given. If they need to slow down, stop, or slightly re-orient the hull in order to shoot they will. They won't search and destroy, use cover, terrain, or anything else on their own. Really the only major pathfinding that AI do automatically is to use bridges or search for shallow points in a river to cross it. I don't think the ROE setting impacts the FAC task behavior.

It is odd that they would sometimes stop and sometimes not. I didn't run the test that many times nor did I look at every single track, but I think in mine they always stopped.

In the stats file that is created by slmod all of the stats are indexed by UCID. So open the lua file up in notepad++ or your text editor of choice and search for your user name. It is in a pretty basic table format of: [ucid] = { ["times"] = { --- aircraft specific stats here }, {"names"] = { -- any user name the player has connected to the server with. Largest value is most recent. If a value is re-used it gets moved in the list to highest value. }, ["id"] = 30 --- unique player index in the order in which they were created }

It doesn't return any value but assuming it doesn't error it will exit like any other lua function.

Use AI Task Push and not AI task Set when changing options. Or really everything else unless you want the AI to completely stop their current tasking. Basically when you set the task, no matter what it is, assigns that one and only task to the AI and deletes any other task they were assigned to do. Their route is one such task. When you do it with commands and options the task is executed immediately and the AI just stop because they now have no route. When you use task push it puts the assigned task at the top of their task queue and when complete they continue on with whatever else they were doing.

The type 71 has the same HP value as an aircraft carrier. This should be in the Deka Chinese Asset pack sub-forum as it is their asset.

Group.getCategory should work just fine since it is not a subclass of the Object hierarchy.

function myStopRoute(_par) if Group.getByName(_par[1]) ~= nil then Group.getByName(_par[1]):getController():setCommand({ id = 'StopRoute', params = {value = true} })) else trigger.action.outText(_par[1].." does not exist!!", 15) return end end You weren't setting the "value" table entry to true. params = {value = true} There is no function that returns whether the AI is on or off. Just gotta save it for reference when you change it.

The hit value depends on whether that weapon is still being tracked by slmod. If it is then it will +1 to the hits, if not it ignores it. Unfortunately with DCS it is a bit sporadic whether or not the weapon is still accessible on hit events. More often than not it isn't accessible and is something that may need to be addressed.

numHits is the number of hit events within a short timespan that the weapon registers. hits is then for each unique hit event for that weapon. In the past there were instances where multiple hit events from the same weapon could occur on the same object. Say that generated 10 hit events. The events code in slmod would match those 10 events and add + 1 to hits and +10 to numHits.

That specific mission uses the scenery destruction trigger action. Even though it is over a relatively small area it is still setting a good 18,000+ unique objects to a destroyed state. Just modifying the trigger slightly to make it destroy the objects in mission rather than during loading it pauses my PC around 10 seconds to processes all of that. In terms of triggers and AI tasking causing lag it has generally been the case in the past with certain things take place. For instance spawning objects in, especially if that object isn't already on the map can cause a slight pause as the model and textures get loaded for it. AI tasks for the most part shouldn't cause lag on creation. The only time that comes to mind when it can is when a ground group is given a route to follow. You can see that in the editor where it might take a second or so when placing a really long on road route. The same thing can happen in game because it is finding the shortest path available.

There might be a fundamental misunderstanding of what does what. units = The targets you want to display where they are ref = The reference point from which the bearing will be based on. msgFor = who gets to see that message. As you figured out it is taking the average position of the two groups and any unit within those groups. Which you correctly removed in the next try but... You are getting the BRA from igor to igor. I am not actually sure why the bearing would return as the expected value because the two points used should be identical. You want to get the bearing from the reference (snake) to the target (igor). mist.msgBRA({ units = 'Igor', ref = 'Snake', metric= false, text="BRA ", displayTime = 30, msgFor = {units={'Snake'}} }) Its the average position of the targets to be vectored to. If you add in the reference point then it is gonna throw some things off. Granted BRA for average aircraft position, especially if you did multiple groups might not be the most useful thing in the world. I think it depends more on what the AI are doing, if it is a big WW2 formation of B-17s its fine however if it is 4 different groups of fighters then the value can easily lose clarity. The averaging is mostly to make the behavior the same as the msgLL and msgMGRS functions. If you want to use a single point then pass a single unit, when there are multiple then average it out. Hope this helps.

Static Objects and in the Ground Vehicle subcategory. They are scattered throughout that a little bit though. Loco, passenger car, tank, well car, etc.

Map objects are stored differently than normal .edm files and are generally considered to be protected within files for a give map. Install/mods/terrains/<terrainName>/models is the place to look. There are "preview" files that are a zip of really small images that show the models stored within a given file set. In the past I've exported a list of object names and in some cases saved all of the coordinates for one type to a .kml file to open in google earth. Suffice to say some objects have tens of thousands of copies on the map. You can get the object names relatively easily by right clicking it in the F10 map and "assign as". You can also use world.searchObjects over a given area to display a F10 marker over each object with the typename as the text to get a better idea in game which object is which.