Grimes

Tangentially related; if you spawn a new group and re-use a unit name and unit id then the unit from the existing group will be despawned. This is useful if you want that unit to go off and do their own task. Sadly we cannot join/split groups without spawning a new group. Nor give individual orders to individual ground units.

It doesn't change where they spawn at, it changes the altitude a "live" aircraft is flying at. If the group was spawned in they will be flying their route at whatever altitude was set to, then upon being given the task the AI will ascend or descend as needed. If you want to change the altitude a group spawns at then its best to use the group as a template of sorts, modify the properties as needed, and then spawn it. Using mist this can be done with something like the following: local gp = mist.getGroupTable("USAF") gp.clone = true local rndAlt = math.random(4, 10) * 1000 for i = 1, #gp.route.points do gp.route.points[i].alt = rndAlt end mist.dynAdd(gp) Also the units of measurement are in meters. You'd tell the aircraft to go to a random altitude between 49,000 feet and 98,000 feet.

IIRC there is a bug where event.initiator on the mark events is missing in single player but it works just fine in multiplayer.

It is definitely possible because I wrote the exact functionality into Grayflag. From your code and the the MRPS submenu I was able to set the altitude just fine. Relative altitude requires you to just do Unit.getPoint() on the aircraft, then add or subtract the desired relative change from that value, and pass that to setAltitude. Speed is the same thing but you need to use getVelocity then some math on the unit vector returned to get the speed in m/s. Basically: local tanker = Unit.getByName("tankerUnit") local vec = tanker:getVelocity() local speed = (vec.x^2 + vec.y^2 + vec.z^2)^0.5

You could always measure how long it takes a script to execute by printing timer.getTime(), run the script, and then print another timer.getTime(). The need to stagger any scripts is more of a question of the context that they are run in. For a script running on a server I think it is perfectly fine for it to execute everything at the same time near mission start. If it takes several seconds to do everything it needs to do then clients aren't really going to experience any server hangs due to the script being done well before someone even finishes connecting. Having a long pause due to a bunch of scripts executing in single player however is less than ideal.

It might be a bug with mist that it doesn't work if link is checked, I'll have to test. However last I remember a moving trigger zone doesn't actually move, it just uses information about that zone and applies it to the unit it is "attached" to. Mist doesn't At one point I think the zone was still active where-ever it was on the map, but I digress. To answer your question you can directly just call mist.teleportToPoint directly. Its actually what mist.teleportInZone uses to do the teleporting, it just fills in the values as needed. local vars = {} vars.gpName = 'group1' vars.action = 'teleport' vars.point = Unit.getByName("UnitNameYouWantToTeleportNear"):getPoint() vars.radius = 20 -- match the radius of the zone you have set. mist.teleportToPoint(vars) Persistence is all about saving data to a file and then reading that file on the next load. As a result you end up needing to allow io and lfs to exist via modifying MissionScripting.lua. io for opening and writing files. lfs because its useful to get your saved games folder without hard-coding the file path in. I do use mist when it comes to writing the data. Either mist.utils.oneLineSerialize or mist.utils.serialize are most useful in this regard. If I'm being lazy and just want to write a whole table on each go I'll use mist.debug.writeData.

Are you asking about the new fuses? As far as I am aware there are no new scripting functions to describe the current fuse on a bomb. Anything it getDesc will be the default and legacy values.

Select the develop branch on github. I remain terrible at adding to one version and pushing the commits to the other.

Nope. That is not the case and I have no idea where they got that idea.

Its done by the score applied at the end of a mission. To advance a stage the score needs to be anywhere from 51 to 100. If you have multiple missions per stage then the campaign UI will pick a mission at random within the score range set for each mission within the stage. Lets say you have 5 missions and for each their range is 50-100. Then each time you played a mission on that stage it picks one at random. You could modify the conditions to cover a unique range of values. 50-60, 60-70, 70-80, etc. Then on the mission in the previous stage you could setup 5 mission goals that award 5, 15, 25, 35, 45 points each. Most of the story campaigns that don't allow you to go backwards award 50 points right a mission start. So whenever the mission is deemed "complete" they use trigger logic to decide how many points to give you, which in turn results in which of the 5 missions in the next stage the campaign is allowed to load.

The AI doing the JTAC task will only lase ground targets. Using a script to create a laser is extremely easy. https://wiki.hoggitworld.com/view/DCS_func_createLaser

Speed directly impacts the size of the orbit. White is at 500kmph while cyan is at 600 kmph. As long as they aren't refueling then their orbit should stay relatively stable. When they do refuel though it throws a bit of a wrench into things. Here both are set to the same speed but a B-1 came to refuel off of the tanker with the white track. The tanker shallows its bank angle for the turn and ends up doing a much wider turn as a result. Then when it is finished refueling the B-1 it returns to the normal bank angle when it reaches the end of the track, but it offsets its final heading slightly to get back to where it needs to be. It always turns once parallel with the start/end points of the track, but only offsets, IIRC, during the opposite track where it stopped refueling.

getFuel() * getDesc().desc.fuelMassMax gives the weight in kg. https://github.com/mrSkortch/DCS-miscScripts/blob/master/ObjectDB/Aircraft/KC-135.lua#L29 I've only "calculated" fuel flow with regard to testing whether or not AI are getting fuel during AAR correctly. All that consisted of was comparing the difference of getFuel every few seconds to get the flow. I haven't tried to estimate fuel consumption during normal flight at different speeds and altitudes. Hence the general cutoff of % fuel remaining that in most cases is well above bingo and "auto AAR" thresholds.

Can you post a simple track showing that?

The fuel available to the tanker to refuel other aircraft is the same fuel pool used to fly the aircraft. A KC-135 can be in the air for better part of half a day if it doesn't need to refuel anyone. The RTB threshold depends on how far away the AI is from the airbase they are set to land at. As a result it varies with no hard number. I like to send them back at roughly 15% fuel because that is usually plenty to get back and the automatic RTB behavior often leaves very little wiggle room. In testing I had an E-2 do a case 3 approach and landed with a getFuel value of 0.0015. Also you can't give orders to the AI when they RTB automatically so any flexibility is lost.

Last I remember none of them work on trains anyway. But I am getting mission editor lua errors when looking at the tasks with a train group selected.

Track contains code looking for a moose that isn't there. He must have gotten loose. 2023-01-28 04:41:15.579 INFO SCRIPTING (Main): *** MOOSE DYNAMIC INCLUDE START *** 2023-01-28 04:41:15.579 ERROR SCRIPTING (Main): Mission script error: [string "C:\Users\ME\AppData\Local\Temp\DCS\/~mis00006A56.lua"]:10: can't open 'Scripts/Moose_Dev/Moose/Modules.lua' stack traceback: [C]: ? [C]: in function 'assert' [string "C:\Users\ME\AppData\Local\Temp\DCS\/~mis00006A56.lua"]:10: in function 'Include' [string "C:\Users\ME\AppData\Local\Temp\DCS\/~mis00006A56.lua"]:22: in main chunk 2023-01-28 04:41:33.083 ERROR SCRIPTING (Main): Mission script error: [string "C:\Users\ME\AppData\Local\Temp\DCS\/~mis00004BF3.lua"]:1: attempt to index global 'SPAWN' (a nil value) stack traceback: [C]: ? [string "C:\Users\ME\AppData\Local\Temp\DCS\/~mis00004BF3.lua"]:1: in main chunk Appears to have been able to reproduce it without scripting though. Reporting. Bombing at coordinates appears to work though.

With scripts would be the only way to do it by spawning objects in during the mission. it would be pretty straight forward to take a shape or path and populate objects along it. Though you might get some ugly results due to the fact it is placing individual objects and "perfect" corners isn't all that practical. Its still going to be individual objects and not a procedurally generated object following a path.

You might be the first person I recall asking about the GUI callbacks within gameGUI, at least within the mission editor section, perhaps its been asked about in the modding sections. I don't know how to teach "gotchas" with regard to scripting. Everyone has their own goals, approaches, and time they can spend on this stuff. Sure there is some intuition on how to solve typical problems, but there is also plenty of "wait a minute did that change?" that occurs in my own scripting projects. And it kinda sucks being just about the sole arbiter of the documentation. If you want to be my guest and rely only on what ED provide. null I answered in the context of accessing shapes and probably recent other questions of yours that had similar answers. Forgive me on forgetting about one of the few exceptions to the rule that had nothing to do with what the question was about.

You didn't miss it, the distinction isn't there other than stating it gets loaded when its located in a specific folder in a user's saved games folder. How were you do know? Did you try testing it? There are a few things in there that I know how they work and how it works when run on a server, but there are others that I'd have to do a quick test to know for certain how or what it does as a client connected to a server.

Tankers are sorted in the radio menu by whichever is closes to you when you open the menu.

For the GUI callbacks yes.

Via scripting I suppose you don't. Though if you know the filenames like with audio then you can hardcode it into some script because they will always be in the l10n\default folder. For example with this I knew the audio files for use with a speech construction script. local sFiles = {} -- Tusk sFiles[#sFiles + 1] = {file = 'tusk_complete.wav', len = 0.6, text = 'complete', voice = 'tusk'} sFiles[#sFiles + 1] = {file = 'tusk_out.wav', len = 0.9, text = 'out', voice = 'tusk'} sFiles[#sFiles + 1] = {file = 'tusk_Over.wav', len = 1.5, text = 'over', voice = 'tusk'} sFiles[#sFiles + 1] = {file = 'tusk_requestPicture.wav', len = 1.2, text = 'request picture', voice = 'tusk'}

The score differentiator is 50 not 55. 0-49 pushes a stage backward. 50 exactly remains on the same stage, and 51-100 advances a stage. For single missions it still shows up on the debrief screen and some people may use it as an indication of success or failure. Outside that it serves no purpose.

Ehhhhhhhhhhhh yes and no. Yes because perhaps someone saw posts about it and it aided a push to implement it. No because text, sound, and commands to units have been requested on the actual tracker since 2015 which is around the time that we could have multiple clients in a group. To be fair there are a ton of ideas that could improve the editor and scripting engine, some exist on the tracker while others don't.