Grimes

No it has pretty much been a problem since the beginning. AI won't land if another flight are set to take-off, which is why everyone orbits while the two aircraft on the deck get airborne. Once the airbase is clear for use the orbiting aircraft will land based on if an opening exists and the first aircraft to cross a given threshold to commence. Perhaps changes will occur whenever the ATC comms for airbases get updated.

Would need a mission file. Best guess is you have something set wrong in the task parameters as I loaded it with 8 bombs, set it to drop 2, and it only dropped 2. null

if not Group.getByName('R/QESHM/SA2/2') then There are a few problems and things you need to understand with scripting (triggers also) and that statement. First off it is checking if that group object exists. Unfortunately the state of a group object has changed over the years. It used to be if all of the units in the group were dead then the group object wouldn't exist and it was like that for a really long time. That may have changed, but the gist is that it isn't the surefire check to know if a group and the units within are alive or dead. However in this case it doesn't matter at all because groups set to "late activation" still exist. So that function will always return the group object. Likewise the trigger conditions Group Alive and Group Dead both see a late activated group as alive. Which is why you are finding that you need to deactivate the group in order for it to work. That said you can just call the respawn group function at anypoint without checking if the group is first dead and it'll respawn. If you are intent on checking the state of the group, especially if the units are dead to respawn it, then you can use mist.getGroupIsDead for the check. It does the getByName to see if the group can be accessed and it checks the size of the table returned by Group.getUnits to verify that at least 1 unit is alive. if mist.groupIsDead('R/QESHM/SA2/2') == true then mist.respawnGroup('R/QESHM/SA2/2', true) end

You scan the map via script then save that information for later use. https://wiki.hoggitworld.com/view/DCS_func_searchObjects If scanning the whole map I like to save the object type name and the coordinates since the object ID cannot be relied on. Depending on the object searched for your results may or may not be all that practical. I ripped this out of a rather complicated mission script where it had a number of different input values. Anyway I used this primarily to just find and more easily associate an object with the object typename. Just place an F10 mark panel on the map, edit the box to say "searchObj" and it will scan a 500m radius around that point. For everything it detects it draws a mark panel over it with the object typename as the text for it. Change the 500 to a larger value if you want. Just know it will take a while because most of the maps have several million objects on them and checking even a 10km radius can take several minutes. Not to mention the f10 map really doesn't like rendering tens of thousands of mark panels. local mId = 0 local eHandler = {} local function searchAreaForObjs(vars) if vars.coord then local newPoint = vars.coord newPoint.y = land.getHeight({x = vars.coord.x, y = vars.coord.z}) local volS = { id = world.VolumeType.SPHERE, params = {point = newPoint } } volS.params.radius = vars.radius or 500 local searchInclude = {} if vars.searchFor and vars.searchFor[1] then for i = 1, #vars.searchFor do searchInclude[vars.searchFor[i]] = true end else searchInclude = vars.searchFor end local objs = {} local function ifFound(obj) if searchInclude and searchInclude[obj:getTypeName()] or not searchInclude then table.insert(objs, obj) if vars.debug then mId = mId + 1 trigger.action.markToAll(mId, obj:getTypeName(), obj:getPoint()) end end end world.searchObjects(Object.Category.SCENERY, volS, ifFound) -- search area for objects return objs end end function eHandler:onEvent(event) if event.id == 26 then if event.text then local calVals = {coord = event.pos, debug = true} if string.find(event.text, 'radius') then calVals.radius = tonumber(string.format(event.text, '%d+')) end if string.find(event.text, 'searchObj') then searchAreaForObjs(calVals) end end end end world.addEventHandler(eHandler)

It was fixed in 2.7.4.9847

There actually is an addZone function in the simulator scripting engine, however I've never been told the syntax for it, thus it remains undocumented. That said it doesn't really matter because with scripting the things you'd use it for can be done with simple math for the coordinates and radius anyway.

If the group was placed in the editor you can use mist.getGroupTable which returns the entire table for that group as saved in the mission file. Frequency and other stuff are added in where available to the databases and get grabbed via getGroupData. However its more of a curated list of info and I do need to go in and add values that I missed from time to time. Looking through the DB examples the frequency value seems to be a little inconsistently present.

Not directly. At the moment only objects drawn by the scripting engine are allowed to be edited in real time. Everything placed in the editor cannot be changed. Annoyingly some of the functionality in the editor isn't part of the scripting functions either. Scripting lacks the ability to rotate a text box along with some of the outlines. It is easier to do than it looks... Make a trigger zone where you want the text to be. This is using : https://wiki.hoggitworld.com/view/DCS_func_textToAll local point = trigger.misc.getZone("cap1").point trigger.action.textToAll(-1 , 1, point , {1, 0, 0, 1} , {0, 0, 0, 0} , 24 , true , "Capture Point 1" ) Then if you wanted to change the color of it you can call this, which edits the object with id 1 and changes the color to green. trigger.action.setMarkupColor(1 , {0, 1, 0, 1}) To remove it you'd simply call: https://wiki.hoggitworld.com/view/DCS_func_removeMark trigger.action.removeMark(1)

You would need to also use either offsetRoute or offsetWP1. It has to do with how aircraft AI function. If they just have an initial waypoint and no other points they reach the end of their route and will try to RTB immediately. Once AI get into this state they can't be assigned new tasks or attack targets on their own. So they still have their task but they have no route when they get teleported. Both of those options give the AI a route back.

There was a typo/omission on my part within the function that prevented it from working. That said the function is overloaded to accept type, typeName, or typename as the passed values. I've updated mist on the development branch. https://github.com/mrSkortch/MissionScriptingTools/tree/development ADDED: coalitionId to databases for everything placed in the editor. FIXED: Bug in getUnitesByAttribute not working when passed a type value FIXED: Bug in getGroupsByAttribute not working when passed a type value ADDED: getDeadMapObjectsFromPoint function MODIFIED: getDeadObjsInZones to call getDeadMapObjectsFromPoint FIXED: getPointOnSegment doing math on the wrong value FIXED: getWindBearingAndVel using the wrong math function ADDED: mist.pointInZone function. Is passed a point and a zone or a zone name. ADDED: echo to logger class. When called this will print a message to the DCS.log file and display a message via trigger.action.outText for 30 seconds.

local totalTime = 14400 local interval = 1800 local function printTimeLeft() local timeRemain = totalTime - timer.getTime() trigger.action.outText(timeRemain/3600 .. " hours remain", 30) end local iter = totalTime/interval for i = 1, iter do timer.scheduleFunction(printTimeLeft, {}, timer.getTime() + (i* iter)) end Something like that. Just run it once because it reschedules the function to run however many times. In this example 8 total and every 30 minutes with a 4 hour run time. You can also do some fun stuff with the message formatting to get it in a more readable format because you will likely see a message with several decimal places used which isn't all that useful.

Unit:FindByName is a moose construct. Really you don't need to use mist or moose to do such a thing. Assuming you know the names of the units/groups its pretty straight forward with directly using the scripting engine function calls. This gives the group "whatever" a follow task to a group named "leader." local mainGP = Group.getByName("leader") local gp = Group.getByName("whatever") gp:getController():pushTask({ id = 'FollowBigFormation', params = { groupId = mainGP:getID(), pos = {x = 200, y = 0, z = -200}, lastWptIndexFlag = false, })

Hard to say. Its happened a few times where ED adds a feature to the editor that isn't quite functional yet. Think of it as one person creates the values that adds it to the editor while waiting on another person to complete the feature. It makes zero sense to me why a static deactivate couldn't already be added because the same functionality exists in script form as: StaticOjbect.getByName('objName'):destroy()

Not directly. If you call Unit.getFuel() and the value is above 1.0 then you know that aircraft has at least one external fuel tank. I don't recall if jettisoning fuel tanks is part of the shot event or not.

Reported. As a reminder please remove any mods when reporting bugs. And frankly removing most everything else in the mission is also appreciated. This just needs a boat and some statics to spawn on it.

It is dependent on DCS scripting capability and uses this function. https://wiki.hoggitworld.com/view/DCS_func_addGroup "Function can NOT spawn new aircraft with a skill level of "client". However in single player a group can be spawned with the skill level of "Player". When this occurs the existing player aircraft will be destroyed." So no you cannot use it in multiplayer on client aircraft. However client aircraft don't need it because they can respawn at any point as long as they can still access the slot.

Its been an on and off again issue where the object is identified by its unique Id instead of the typename. As far as I am aware it always occurs with scenery objects. You can get a number of them from just having AI drive around a town, but traditionally blowing things up will also produce it.

parking_id is just the value stored that is visually associated with the index. No clue why it is saved in the miz. It doesn't really have any bearing on what the actual parking index is. The printed values are the terminal index. At some bases like Beirut International they are labeled with the ramp area and a number (G20) for example, while others are just numbered. Point is those aren't the actual parking values and it is just for display. I am not certain if any of them are accurate to the actual ["parking"] = x, The unknown type: I could not replicate that at all. Though I did notice that parking indexes started at 0, but that value consistently belonged to a runway. Spent a bit of time and other variations trying to figure out why you got that result when I didn't. As for spawning it appears to be related to what was occurring in my test script/screenshots. It more or less comes down to the fact that each spawn point has certain dimensions for length, height, and width to limit what is allowed to spawn there. The type also limits helicopters from spawning in bunkers. Unexpected results occurred simply based on how you load the mission and what you spawned. I used Frequent Brother for my test. Loading into the editor it looks "fine" however loading into game and also selecting the units it changed the initial waypoint type for several units. In fact it changed them for every unit that the editor deemed was placed at a parking spot it shouldn't be allowed to park at. The A-10s, B-52, E-2, and E-3 were the main units that were automatically moved to airspawns. Loading directly into the mission via Mission on the main menu the units get shuffled around as per your bug report. It looks like every unit that got moved exceeded the limit and possibly caused others like the AH-1 to be moved. Now here is the kicker and when things got really weird. I used my code that was spawning the aircraft to spawn E-3s. Remember that some of the A-10s were moved onto the same spot simply because it ran out of room. None of the E-3s were moved on spawn. My working theory is that since there are no spawn points of the correct size at Ramat David for the E-3 that it didn't know what to do and just allowed it to happen. I suppose it can be described as a Scripting problem and a spawn/map problem, with a tiny bit of a you problem. Scripting because we don't have the tools to get exact dimensions or are able to check if certain unit types are actually capable of spawning there. Outside of manually cataloging every single parking spot for what could be accepted there isn't a whole lot of recourse available until ED realize how dire we need certain API and add it. A spawn/map problem because the strict dimensions dictate where things can spawn at even though there may be ample ramp space with nothing physically blocking an aircraft from getting to the runway. According to the editor there are no spawn points on Syria that support a B-52. I think it is fair to say that Caucuses has more uniform spawn points and a majority of the bases could spawn a KC-135 sized aircraft. On Syria 8 of the ~60 bases support a KC-135. A you problem because you have done a great job making a mission generator, but that generator can build missions outside the rules of DCS. Sometimes thats great because the rules of DCS and the editor can work against you in terms of flexibility, but some of those rules have a purpose. I think you might have to just make exceptions for certain areas of a given map and just airspawn certain aircraft. However at least with spawning via script I was able to spawn B-52s at Incirlik on a few key spawn points and it worked. Whether saving them to spawn there in a miz and loading said miz would work, I couldn't say.

All of the getParking spots returned seems to indicate they are correctly positioned. There is a size limitation with a lot of these and apparently spawning via script it ignores some of the restrictions causing issues. Spawning an F-16 at every spot works while using an A-10 can be problematic. Some A-10s spawned in locations to small and others were occupying the same space. Probably needs some of the spawning logic used on the carrier where it will delay aircraft from spawning if a valid parking isn't available. I made a feature request a while back to add a parameter to pass the aircraft you want to get valid spots for since Term_Type isn't as descriptive or standard as it needs to be.

They will be available as insurgents and probably a few others but they aren't currently in game. ED like to tease upcoming objects in videos from time to time. Just gotta wait.

All it does is it searches mist.DBs.deadObjects table for the category to see if an object represents a map object and then checks the distance from a given point. This is the code it ultimately uses. Just replace the bit of code where it references zones, though its not a flag function, so you have to manually call it whenever you want it to do the check and set a flag or do whatever action once the conditions are met. Realized it'd be a good idea to have a function that works with point so I'm adding a mist.getDeadMapObjectsFromPoint function now. As is life with DCS I decided to add an object filter to look for certain object types but the results are not what I expected and is a possible DCS bug. local map_objs = {} local zones = {} for i = 1, #zone_names do if mist.DBs.zonesByName[zone_names[i]] then zones[#zones + 1] = mist.DBs.zonesByName[zone_names[i]] end end for obj_id, obj in pairs(mist.DBs.deadObjects) do if obj.objectType and obj.objectType == 'building' then --dead map object for i = 1, #zones do if ((zones[i].point.x - obj.objectPos.x)^2 + (zones[i].point.z - obj.objectPos.z)^2)^0.5 <= zones[i].radius then map_objs[#map_objs + 1] = mist.utils.deepCopy(obj) end end end end return map_objs

AI in DCS don't like to do mixed take-off and landing operations even when they should easily be able to do so on an airbase, especially one with multiple runways. I haven't tested it specifically with the updated carrier behaviors, but as long as the other flights are set to uncontrolled and nothing else is actively trying to take-off I would think the landing aircraft should make an approach. There is the likelihood that the waypoints are a little too close for the landing aircraft to the ship. It can be like giving AI a task to bomb something while close to the target. The AI has predefined limits and it may be within those limits when given a task, thus it extends. At least with an airbase if you place it roughly in the right position, speed, and altitude the AI can do a direct approach. With the updated carrier pattern I think the AI pretty much have to go into the landing stack, be cleared, then line up for the initial, etc. Try working backwards, get the E-2 landing best how you want it and then add the other AI and see how it may or may not change the behavior.

Mist is meant to supplement the base scripting engine where the majority of the functions are related to getting and organizing data in a useful way but still relies on you using the base functions within the script. There are a few functions that try to simplify complex functionality like mist.respawnGroup and some of the flagFuncs. There are functions in mist that have scripting counterparts where it really doesn't matter which one you use, while there are others where things are executed a little differently. For instance math.deg and mist.utils.toDegree are identical, the mist version exists because I was adding a bunch of converters and figured it should exist. On the other side of the spectrum the differences between mist.dynAdd and coalition.addGroup are quite extensive. Simply put mist.dynAdd is overloaded to populate any missing data other than coordinates and unit type. It'll generate new ids, names, heading, etc and it'll save that data to be added directly to the mist DBs because there is some data for dynamic groups that isn't accessible. Statistically math.random has a tendency to choose the first and last possible values less often. I'd argue that it is a use case question because depending on what you are doing it could be more noticeable. Picking a random number between 1 and 10000 to add a randomized distance or altitude for a flight wouldn't cause much of a problem. Picking a random number to spawn a given task that are always in the same order then yeah maybe you spent the most time on the first task and wonder why it gets picked less often. See the screenshot, both tests called the respective .random function 1000 times and it shows the distribution. The message is formatted as the number and how many each function returned that value; "Number : math.random : mist.random". Anyway the distribution bothered me even though it isn't likely to be that big a deal and I wrote some code to try and balance the result. Moose takes the object oriented programming approach where literally everything becomes an object with its own set of sub-classes. You could probably write a script that exclusively just makes moose calls without directly calling any function from the DCS scripting engine yourself. Moose in the end would use Unit.getPoint or whatever but you wouldn't need to.

You might be able to but it'll only work for the host. Might be best to use the Add Other Command and have your trigger respond to the flag that gets set with that.

It is setting the value, its not adding or subtracting at all. You set the weight back to zero if you want there to be no cargo weight. It also sets in gradually over a second or so.