TEMPEST.114

Okay, so just so you know, when I was editing your mission to fix it, I was able to have the aircraft climb WHILST orbiting, still at the same speed (450 I thinkt put in an intermediate waypoint because of how the AI interpolates it's manoeuvres. So I'm either confused about the problem or I'm not seeing it as you are. I had your Flanker climb from 20000ft to 30000ft at 450 knots whilst doing a racetrack orbit between point A and point B. I'm not seeing or understanding the bug. Sorry. ETA: The reason is climbs SLOWER in the orbit is because the orbit, I believe, makes the assumption that it's either being a refueller or loitering so it's being more gentle in it's manoeuvres. I'm not trying to seem like I'm being contrary; I'm just not seeing the 'bug' per se, other than a more global 'wouldn't it be nice if the AI was smarter' thing. The intermediary waypoints are kind of required because a) programming a GENERAL AI that can interpret context for any situation is VERY, VERY hard and b) At the end of the day, it will always be an interpolation between fixed known points.

Glad you got what you needed. Sometimes the search on this site isn't great, it helps to go to google and do a site search from there. The ADF is probably the easiest radio to tune, so it might be a better idea to use this as a teachable moment to 'introduce' radios at the same time.

I admit I never use Russian aircraft unless they're targets, but does this 'bug' apply to blue aircraft? If it does then I agree it's more likely an AI bug, but if you use the waypoints and micro-manage it a little more - just as I did in the 'fix' example, then I don't see any problems. What am I missing?

Sure but like the South Atlantic map, if you aren't in the centre then things get crazy, however if you use scripting and some maths, you can get it to within 1 degree for any date and time.

If the map and date are known, just do a web lookup for the correct value. No?

This is why checking with the manual addresses so many of the issues posted. It's just a shame that the manual won't get pinned to the forum's front page.

Remember that the AI is generic and not clever, in fact its really quite dumb. So whilst the ship and a human could make those changes, the AI can't/won't, unless you micro-manager the crap out of it with excessive waypoints / stepped climbs / or excessive params - just as you've found out. Like i said, it will always try and interpolate an action from the previous waypoint to the next waypoint, but it will not max out the performance of the aircraft because the AI isn't really that specific. You can see this with the way vehicles drive; it doesn't matter what vehicles you have in the convoy or leading the convoy, they will always drive the same way. Same for aircraft too. If you want to argue that it's crap and should be a lot better, and you can micro-manage it to get what you want, but it's a huge pita to do so, then I can whole-heartedly get behind that. Like most things in DCS it's half-baked at best. But I don't agree it's a bug with orbiting or even waypoints; it's just highlighting how poor the AI systems are, but I'm glad you're getting what you need from it now.

Okay, so I know from scripting that it is possible; there's nothing in DCS that will prevent this. In my Superscript I have complete control over all aircraft at all times. I'll d'load this and take a look. ETA: Okay, you might want to read the manual again. This is a misunderstanding of how Race Tracks work (it's not obvious) + a possible M.E. Gotcha. When you designate a waypoint as the orbit point for a CIRCULAR orbit, it will orbit THAT WAYPOINT in a circle, flying over it each lap. When you designate a waypoint as a RACE TRACK orbit, that is the 'A' point of the race track, the direction and distance for the loop back point - the 'B' point - is the NEXT WAYPOINT you have specified. In this case it was your 'END' waypoint. So you needed at least one more waypoint between the A point and the END. The M.E. Gotcha is that when you specify an altitude and speed for an orbit, make sure that it matches the altitude and speed for the waypoint; so waypoint alt / spd == orbit task alt/spd. If you want your ship to be at alt before the orbit takes place, then you need an intermediate waypoint, same for the descent when leaving. If you don't and it arrives at the orbit point before reaching the altitude, then it will increase whilst it's orbiting. Otherwise it just interpolates between where it is and what it needs to be AT the next waypoint. Also, in your example the distances between everything were too small for the AI to cope with well. Attached is a fixed version with a timer that stops the orbit. If you view it on the F10 map and increase time compression you can watch it fly to your race track, orbit a few times and then go to the end and arrive at 20k as you wanted. Hope that helps. PS - This isn't a bug. FixedRockingHorseOrbit.miz

Actually @kitten40 if the CLIENT is also the HOST, then it WILL work on a MP server. For clarity, when I say the client is also the host, I mean, you don't have to have any aircraft set as player, they can all be client, but if the player who is hosting the mission on their PC uses a CLIENT skilled aircraft, then yes, these commands WILL work. I thought that was obvious, but from what I've been told, it wasn't. So, yes it is possible. You just have to find the magic X number. Unfortunately it's either trial and error as they are never revealed OR you can search the forums for someone who has already found it and shared it. I think @Rudel_chw has played with this sort of stuff. If you search the forums, I think you'll find a post from the 8th of May, 2015 with a PDF of all the Huey X commands, including the ADF freq setting. ETA: It's been pointed out that you specifically asked for a scripting solution, rather than the simpler M.E. solution - which I provided because it was quicker and doesn't require scripting. It was also pointed out that I was wrong, claiming that it's possible via scripting. It is possible. However, if you do want to do this in scripting you have to use an unpublished command 'a_cockpit_perform_clickable_action' via the net.dostring_in function. E.G. net.dostring_in('mission', "_G.a_cockpit_perform_clickable_action(<PARAMS>) Where <PARAMS> is replaced by the settings and structure you'd find from reading the mission file in the .miz file with the X clickable cockpit command setup. (The command ID number, the number of the control and finally the value you want to set it to). Here's an example mission showing the scripting control of the X commands working: scriptingXCommands.miz

I wrote my own, with more features & easier to use, especially from the M.E. And I can confirm, default DCs sounds play all at once making a cacophony if you SOUND TO with many items.

You *could* do this whilst they're shutting down their jets - assuming they do shut them down and don't just quit.

There is no mechanism for interaction post mission.

That's normal; it shows you what the ME created vs your own. It's always been that way since I've been using DCS. Maybe your monitor contrast/brightness has changed? Your photo upload hasn't worked so we can't see what you're seeing. If you have more than 7 total, then you need to put yours in above the 7th spot for them to work (hugely annoying long time bug that's never been fixed) or split them into two waypoints rather than one.

None of the tankers in dcs have a ceiling so low. This can’t be an option.

You can always have a dedicated trigger for UNIT DEAD with an action of FLAG ON if you really want to be sure to trap that specific unit's death. That way, even if the back end deleted the unit before you get to do some introspection on the event via LUA, you can be assured you'll get the value of the flag as the ME triggers are processed every second whilst the units are still in the back end. When it comes to the Mission Editor / Scripting Engine, the 'belt and braces' approach wins out more often that I would like.

...it's DCS.

First of all, as mentioned in other audio related comments, sound playback in DCS is NOT sequential; your ACTIONS list gets processed all at once, so both sounds will play at the same time unless START DELAY is used. If you want the 2nd sound to play after the first, you have to delay the start by the duration of the first sound + gap if required or play it using another trigger/flag that gets set after the first sound playback has been started and timed out (duration of the first sound i.e. TIME AFTER FLAG). Do both text messages display? And at the right times?

Note: This isn't really a 'wish list' feature for DCS (which is the point of this forum). I think your question would best have been asked in the main Mission Editor section. This is supposed to be a forum channel for things we WISH were in the M.E. / Scripting Engine. Audio playback in DCS is virtually useless. The few meagre options we've been given (in the ME and scripting) i.e. SOUND TO xxxx are terrible and very limited in use. They've been designed as a barebones as possible and are very inflexible. There are lots of options you have. Only one is really worth the effort IMHO. I believe if you want to go 3rd party route, that the new freeware SRS has a the ability to playback media on a specified frequency and have playlists / shuffle etc. You could check that, but like almost all 3rd party option, all your clients will need to have it setup (not always easy with SRS) to make it work. You could (as I have done) ignore all of ED's sound playback and write your own using LUA scripting and metadata and have that included in the mission. That will give you the most flexibilities but it does mean every possible audio file will have to be loaded into the mission on MISSION START as a SOUND TO COALITION NEUTRAL to get them into the .miz - the ability for us to manually insert into the .miz has unfortunately been removed by ED for some reason. One thought about your 'random flag value' option, is how are you playing the playlist now? How many possible tracks do you need to shuffle? Because ED didn't bother to make playing multiple audio files SEQUENTIAL and instead, unhelpfully, plays them all at once, the only way to make a 'playlist' in the ME is to know the audio length of each track and delay the next one by the total time elapsed before that track should play. Therefore, if you want a random shuffle (which I *think* is what you're asking for) and for example lets say you have 10 songs, you're going to need 3,628,800 playlists - manually created in the Mission Editor to cover all shuffled possibilities with each playlist having tracks in a unique order and you have to work out all the possible time delays for each track yourself - that you would spend the rest of your life making them. Needless to say, that's not the solution, unless you hate life. You could have a choice of say 3 songs for the FIRST song in the playlist, but all 3 songs would need to be the same song length so it wouldn't screw up the timings for all the subsequent tracks. You could then use your random variable to pick from the 3 before the same 'rest' of the songs would play. If people are only listening to music pre taxi, then maybe it's not worth all this effort and they can just play music on their own iPad / other device with their mics off? Or simplify it, and duplicate your currently (working?) ME triggers and just have the random variable pick from one of a small number say 3, so it cuts down the workload. That's all I can think of right now, good luck.

For my 2p, I'll say that I've raised a bug about something related to this. On certain events (DEAD is an ideal one) the back end has DELETED the unit BEFORE it sends the event to the DCS Scripting Engine. When you try and do some introspection on the Unit to get it's ID or coalition, you get an error/crash because - yup - the object in question has been removed from the back end. Needless to say my bug report didn't get any traction as to fix all this you have to do a major change to the architecture for events and stuff. However, I was able to get around it by having my own copy of the object params in a table that I could refer to even if the object was gone. I'm not sure what you mean by classes and objects in LUA as LUA has no understanding of OOP, it's just tables and tables in a global table. If you are referring to a table as an 'object' then okay, but really that might muddy the waters (https://www.lua.org/pil/16.1.html#:~:text=Lua does not have the,languages%2C objects have no classes.) Now, from what I'm understanding and correct me if I'm wrong, you have a unique table, with it's own event handler, for each of your seven 'target' aircraft right? Because parallelisation isn't a thing in LUA without additional libraries (Lua Lanes, Parallel Lua etc) then are you referring to coroutines? Either way, it's not like a C based language with true parallelisation. Perhaps it might be cleaner if you have a table of your 'targets' and just one lua script that handles events, and you then iterate through the table of targets, passing in the event as part of a for loop. It means there is ONE SOURCE OF TRUTH (the event handler and the event) and it's much easier to debug. Good luck. Sounds like you're making really good progress with all this.

I used your screenshots above.

As you never mentioned to whom I should address feedback, I'll post it here. 1. The FIELD label and the TEXT BOX should be on the same line, this stacking is pointless with so much wasted space on the end of the text box, the indentation doesn't help. 2. Grey text on that vibrant blue is NOT READABLE. Think about using only White and Black and high contrast colours if you need to. Learn to use the Colour Wheel theories and not just what you think 'looks cool'. https://www.canva.com/colors/color-wheel/ 3. Again, like I mentioned in : https://www.wired.com/2016/10/how-the-web-became-unreadable/ enough with the light and mid greys. Make it READABLE. That's the whole point of a the kneeboard, instant, clear, easy to read reference when you're flying. This too should apply to the application. There shouldn't be low contrast colours side by side. 4. These are labels, make the human readable with colour, capitalisation and spacing. The actual name of the variable behind the scenes is irrelevant. 5. Full white text here would be better, but again USE THE COLOUR WHEEL THEORY. Baseline is off again. 6. The FONT BASELINE and spacing are wrong, you have too much space at the bottom and not enough at the top of sides, make it centred to the text box. 7. Yet again, poor colour contrast choice. Make all text solid white where you can, or solid black and use bold and italics and font weight/size to denote headings and paragraph text, not poorly readable shades of grey. I don't know what that example is - whether it's Modern Bright or Table layout but you'd need a night version for it too. This would be more readable if you used full white text AND you changed the font to something a lot clearer and less stylised. As for your other examples, I cannot for the life of me understand why you're using faded fonts and very light coloured fonts against a coloured background. READABILITY MATTERS. Same for busy images behind all the text. It doesn't mean anything. It's not helping the readability, it only hurts it. Next panel: 1. Baseline misalignment again. 2 + 3. Bounding coloured box not aligned with other boxes/buttons. Come on, this is basic design stuff... 4. Tick boxes not aligned with Labels. 5. Multiple fonts FOR NO REASON. Labels here don't have a colon, but on the other panel they do. Have some CONSITENCY in DESIGN... Pick a font, make it bright white (OR black as required unless colour wheel theory dictates a more readable one) and stick with it unless you have to communicate something different. You're not communicating anything different here but this panel has a font for it's labels that's different to the other panels font for it's labels.

Are you going to provide the option to remove the unnecessary background images and overly stylised fonts that don’t increase readability? I don’t see the value of picture behind text just for the sake of it. Especially when things get busy. And who’s doing your UI design? You’ve got misalignments, wasted space, unnecessary line breaks and multiple fonts just for the sake of it. Who can I talk to about this stuff? And let’s not mention the #1 rule of poor web designers everywhere - pale grey text over pale backgrounds: https://www.wired.com/2016/10/how-the-web-became-unreadable/

You will need to use scripting for this if you want it to cover all possibilities easily. https://wiki.hoggitworld.com/view/DCS_func_isTargetDetected If you want a lesson or two, let me know via DM's. I helped @markturner1960 with scripting stuff, you can ask him. For the mission editor you're much more restricted. You can fake it by detecting if every unit busts a hard-set altitude and then release all your QRF groups. You can use SEARCH IN ZONE for units to 'hunt' for specified groups but it's less flexible than scripting. You can have SAMS look for targets, and if found, set a flag that you can use to release all your QRF groups etc... It depends what the minimum is that you need.

Wow, if there was a way to be able to create hand gestures for formation work and for interacting with other players/AI signals for interceptions.... wow, that would be so amazing. Especially if they could be bound to a joystick or hat... This is amazing. Thank you for doing what ED wont - female pilots. Are these able to be used outside of aircraft and make them walk/run etc or are they just for the cockpit? I can't wait to test them!

Have you looked at MODS? The Civilian Ship mods have oil platforms with a built in FARP I believe.