Grimes

Delete the CAP task and move the orbit task to the bottom of the list. The order of tasks matters for anything from the "perform task" type, which is what orbit is. Basically CAP tells the AI they are allowed to attack any aircraft and orbit that they have to complete that task before moving on to others. As a result the 3 options and search and engage task never get executed. Also applies to your tanker aircraft, their TACAN task is after orbit, thus TACAN is never activated.

Outright converting it is possible but I don't know if anyone has created code to do that. However in terms of making lua that basically replaces triggers, oh hell yeah it is possible. Some don't exist, but for all of the common stuff like setting flags, checking units/groups, etc all exist in lua. For something like simple slot block you can have some code that iterates client groups, figures out where they start at, and then sets a flag if the base was captured.

Appears to be fine if you save the mission after the copy and paste. However before then it looks to show the minimum altitude in MSL. If you switch to MSL it screws up even more, so don't do that. Anyway reported it.

They should wait until you've moved before beginning to taxi. Would be helpful to have a sample mission. That way its easy to know the aircraft type and parking location at an airbase. For what it is worth if the player isn't blocking the AI then they will just keep taxiing and I observed that they will immediately want to land after take-off. However I did take-off soon enough that they were able to rejoin.

With how carriers are currently implemented that is not likely to be addressed until that changes. Simply put the navigation used for spawn to catapult and landing to parking are not connected.

While I'm not sure if was stated anywhere as the actual reason, I think it is there as an anti-griefing/safety measure. Your average SP scenario generally doesn't see a lot of aircraft constantly spawn and take-off over a large number of hours like it can in MP. By forcing everything to the ramp when spawned it prevents aircraft from spawning on the runway which is more likely to have other players or aircraft using it in MP. There is a smidge of irony to this due to how terrible AI use bases for a flight sim that its often avoided entirely to remove the airbase from the equation of things that can go wrong. You occasionally see the problems this can cause in MP when someone gets spawned on a catapult on the carrier rather than a ramp start. That catapult is effectively offline until they despawn or get the engines started and move off of it. Simply spawning someplace where people need to go will cause more problems than spawning where people expect aircraft to spawn. As I said though, if it fails to move AI to a correct location then that part of it is a bug. But also a workaround could be to switch it to take-off from ramp hot to avoid the automatic assigning and it'll often fix it. Problem area being if the base doesn't support that aircraft or you need to spawn more aircraft than ramp spots.

This is not a bug. It is to prevent players or AI spawning at inopportune times at the most common place for another aircraft to be at. Though if it fails to move the AI to an acceptable spawnpoint then that aspect of it would be considered a bug. Nope, it has been like this for a long time.

Think he means having ambient tracers in a given area similar to what plenty of FPS games do with skyboxes or in a 3d space. Its not actual AI units that aim and shoot at specific targets, but rather virtual tracers that make it look like a battle is occurring in the distance or someplace else that doesn't matter to your actual mission.

It was fixed in 4.4.91 and is a bit of a casualty of me being bad at pushing stuff from develop to the main branch. In the 4.1.61 version of the file it checked to see if the values were labeled red or blue. Because I knew the neutral coalition got added and just in an effort to future proof it I decided to remove the red/blue check. At some point in time another entry to that table was added where it stored a string and thus the error. Using the latest development branch of mist should fix it.

Buildings yes, trees no*. You have to use world.searchObjects to find the buildings. Unfortunately there isn't really any data on the area of the building aside for the "box" entry returned via getDesc(). It'll only tell you the total space it takes up and you'd have to do the math to offset the points to figure out a no place zone relative to a specific object. Alternatively you can manually catalog useful info about a given object. For instance I've done that on a few objects on Syria so I can dynamically place vehicles in the defensive burms scattered throughout the map. *Every object on the map has a unqiue id even if it can't directly be queried via world.searchObjects, thus if you have the id specific trees can technically be accessed. Only reason I figured this out was in testing the annoying aspect of the object Ids for everything change when a map was updated. Anyhow I had some Ids stored from an early Syria release and the objects representing a given id changed from a couple of bunkers next to each other to trees halfway across the map.

cloneInZone and the other InZone functions are more meant for stationary groups to get randomization without a ton of input values. I've always viewed it as something where it'd be pointless to randomize the start position and then re-use the exact same route. Perhaps offset every point in the route makes more sense, but only to a degree since it'd be more or less fine with aircraft but create who knows what kind of route for ground groups. At a certain point you can make your own function to achieve the results you desire. local gp = mist.getGroupData('whatever', true) gp.clone = true local rndZone = trigger.misc.getZone('someZone') local rnd = mist.getRandPointInCircle(rndZone.point ,rndZone.radius) local offset = {x = gp.units[1].x - rnd.x, y = gp.units[1].y = rnd.y} for i = 1, #gp.units do gp.units[i].x = gp.units[i].x + offset.x gp.units[i].y = gp.units[i].y + offset.y end for i = 1, #gp.route do gp.route[i].x = gp.route[i].x + offset.x gp.route[i].y = gp.route[i].y + offset.y end mist.dynAdd(gp) The main difference being that the code above lacks the extra checks that teleportToPoint does to verify you aren't spawning ships on ground or aircraft under terrain. But you do have the added flexibility of ignoring whatever rules that teleportToPoint forces to occur. Again its meant as a relatively small amount of code to get easy randomization within a narrow scope. If you need to do something beyond that scope its relatively easy to use a few of mist's built in functions or the game's scripting functions to achieve the desired results with minimal extra coding. Hope that makes sense.

Set the rounds expend value to 1. This makes it so the task 1 is complete and it moves on to the next task once the missile has been launched.

Make the lua file posted earlier execute as a do script file trigger. After it executes put this in a do script block that runs and it'll iterate the entries and place the marks. local mId = 0 for i, data in pairs(objects) do mId = mId + 1 trigger.action.markToAll(mId, data.typeName, data.point) end Adding buildings that have helipads built into them isn't difficult, just gotta know the typenames.

With the editor you don't. That was a static list that in a mission I used to iterate through and create mark panels. The static list itself was generated via using world.searchObjects and just scanning the entire map for specific object types which takes a good 15 minutes. I modified the script to output a format that I copied into a miz that uses ingress points to mark it. Maybe that will be more useful for those not keen on using the scripting engine. Syria_heliports_as_IP.miz

The version of the map in 2.7.2 has 153 helipads. Attached screenshot showing their locations in addition to a lua file with precise coordinates. Use this information as you wish. Syria_helipads.lua

They renamed it. Anyway it is in the triggers menu and the zones will show up in the list.

Step 1: right click building and assign as. Step 2: Create trigger condition for "map object is dead" or something like that. Step 3: Set whatever action you want. There is something that is EXTREMELY important for anyone in the future that might find this thread and wonder why it might have stopped working. The id CANNOT be completely trusted. Each time a certain map file is updated the id used for every single object will likely change. The id will either represent an entirely different object or will simply not exist. As far as I can tell the trigger condition is not impacted by this, but a script checking if the initiator.id_ is a specific number will be. Again it depends on the map being updated.

It is an option when launching a server in the advanced options. It can be set to resume manual, resume on load, and resume when a client joins. You'd want to set it to resume manual and you will have to use the server UI to resume the mission whenever you want.

IIRC it is not actually implemented yet. Closest you can do is to spawn in a new object via script, which works just fine.

If you wanted something a bit more all encompassing you could just save the time spent over each surface type. Then do the math whenever you need to evaluate the data. For those time trial missions I just used the water as the only thing that mattered to differentiate the times for. local sType = land.getSurfaceType({x = pos.x, y = pos.z}) then if not stats[sType] then stats[sType] = 0 end stats[sType] = stats[sType] + timeDif

Having an orbit task and setting a stop condition to occur after a given time or flag value is one way to sync it. The time value for a waypoint will force the AI to try and reach that waypoint at the specified time. It is one of the easier ways to get AI to sync up their routes. Though it can be kind of finicky if you have built in delays like having to take-off and orbit tasks.

Probably a combination of no animation for it and not every component of the site has a way to be mobile. Who knows if it'll change in the future.

Yeah I don't know why its named Flag on/off when its setting the value to 1 (true) or 0 (false). Flag increase, decrease, and set random value all just change the flags value to however it was changed. There isn't actually a whole lot of capability to detect specific damage* that can occur to a unit. The most you can do via strictly using simply triggers is checking if unit is damaged is true. But that requires it to not be damaged before landing because it gives no information at all for how damaged it is. Using the scripting engine you can use Unit.getLife() and see if the value changes from whenever it was airborne to whenever it landed. But its just a number value that gives no specifics and to be honest I haven't tested it a ton with crash landings to know if there is an appreciable change. * There are the triggers for X: Cockpit someCondition which are mainly used for training missions and the like. It would have to be a single player only mission because these only work in single player and on the "Player" aircraft. However the correct values for these are not at all obvious and difficult to figure out.

Please remove any mods from the mission before posting track files in the future. I reproduced and reported the issue.

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().