Grimes

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.

Not the same thing as the other reports you posted on.

Think about the process involved with some of this stuff. Someone that matters has to see it, think it is a good idea, and add it to a list of features to implement. Someone that makes scheduling decisions assigns devs to it or assertive dev decides to do it on their own Development time which may or may not require other people/teams to contribute to the feature. For example a trigger can be added by a UI developer but the actual functionality needs to be done by someone else. Feature is implemented but needs to be merged to the next patch. Sometimes that can be the next patch after its implemented, or the one after that, or it could depend on something else and has to wait until that gets done first. This goes for all wishlist sections and from small changes to stuff that might take years to complete.

For anything using custom liveries that aren't installed locally that player simply sees whatever is the default livery for that country. Ever play online and see an F-18 with VFA-37 livery that has literally every single location for a tail number being used? That person is using a livery you don't have. The Green camo missing texture only shows up if absolutely no textures are found or the textures for the loaded livery can't be found. Hence its for missing textures.