TEMPEST.114

DIY Scripting or maybe CTLD will do it but again you'll need some scripting to set it up.

You’re most welcome; it was an entertaining if frustrating afternoon.

Okay, I've written a little script that goes through all the numbers and options to determine what the correct values are; the PDF is partially correct, but as with everything, ED have changed some stuff. The ID for the ADF is now 27 and the setting of the frequency knob is now: Code 3002, Value 1 = ADF Freq Range knob to 850/1750 Code 3002, Value 0 = ADF Freq Range knob to 400/850 Code 3002, Value -1 = ADF Freq Range knob to 190/400 HOWEVER, that's where the sanity ends. The rotation of the TUNE knob is in 0.03f increments, if you try and increment it by a set amount i.e. 0.03 x 50 to get a specific frequency - it doesn't work. It's literally just a tiny turn of the knob = an increase/decrease of the current value by 0.03f. The value has a lower limit of 0.1f but no fixed upper limit, it will just get to the end at some number of 0.03f increments, depending on how 'fast' they are inputted. (FACEPALM). So there is no 'value' that directly correlates to a specific frequency, regardless of the range knob's position. They haven't even coded it that the value range is a linear scale so depending on the freq range knobs position and the difference between it's upper and lower frequency numbers, then 30 inputs of 0.03 is a different delta-value of frequency from one range band to another. It's just insane. However, if you really want to interpolate for each of the range knob positions with its corresponding different value ranges for the tuning knob then it's all possible. Just a huge PITA. I've managed to get it to set the xponder codes quickly and easily and other radios and switches from script... but the TUNE / Freq / GAIN knobs are a PITA and there is no way to know what your starting point is so that you know (from testing/counting) that n number of 0.03f steps gets you to the right frequency, because you can't 'GET' a number from the back end that means anything. You could however, run a large number of decrements first to get it to the lowest setting and then count your specific number of increments but this will have to be based on trial and error. So it is possible from scripting, but it's not trivial and you will need trial and error calculations for every frequency you want.

I agree, the effort it takes to make a good mission, it should have much more replayability baked in.

Would save time and several unnecessary clicks.

No.

As I said... it's DCS. Expect the unexpected. Esp when the M.E. or AI is involved.

Uploaded an example mission file of the Huey with toggling the pitot heat on off - 1st via X commands in M.E. and then by scripting as described in my edited post above. I don't expect people to suddenly apologise for telling me I was wrong or for them saying it's not possible, but I've just proven it is.

I have no mods or anything else installed (as I'm doing some work for helping on the M.E. forums), however do YOU use MalwareBytes or a different protection application?

Don't have that ship; I've posted my Quarantine List

I have MalwareBytes installed. In the last week I've had a positive for malware on scripting.dll and a file in the Combined Arms add-on. However, despite daily scans of every drive (including the one DCS is installed on) saying they're clear, I'm getting MalwareBytes Quarantining DCS files. Anyone else?

You can for almost everything here you mentioned. It's just painfully protracted with lots of variables floating around and triggers for each one plus late activated groups for all your possibilities. If you don't create the random value flag at MISSION START though, it can go horribly wrong. What have you tried? You can also do more using the DO SCRIPT to add more lua code to make even more randomisation. However I'd love a much more nuanced 'within these ranges' randomisation for almost every thing, but esp for loadouts the UI would be awful.

It seems that in trying to be brief things have become confused. If you want to talk about the mission I uploaded and where your confusion what what I've said is, here's an invite to my personal discord server. Hope to hear from you: https://discord.gg/zcH3jeVA I tried to DM you but you have that turned off.

It's hard coded in a lua. It's a PITA. You have to hunt for it if you want to be able to access it. Personally, I just went into each map, noted the offset from zulu and made my own lua look up function with the hard coded values. Not great, but works.

No.. The file I gave you had the intermediate waypoint to get the climb completed BEFORE the orbit. I'm saying that if you go back to your original one, and fix the issue of the missing RaceTrack point B waypoint, from the START to the original point A point, there isn't enough time to climb so when it gets to Point A it will then begin the orbit and slowly climb UNTIL it hits 30000ft then it levels off. So my point was that if you set up the orbit properly but it doesn't reach the target alt before the orbit starts, it will slowly climb until it does - at a rate that *if it was a tanker* wouldn't throw the chicks off. This is the sentence you missed off from your quote. This is the context where I had it climbing in the orbit.

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?

Are you the same guy that ranted and raved about wanted a full refund from ED so that you could go back to war thunder? The same that I DM'd and offered you 1-1 training and you spat in my face and called me names? Your arguments are identical and your verbiage is too. If not, okay, but it's quite suspicious. A lot of those simplification options are useful for testing purposes, but not for missions/gameplay. If you learnt to make really long, complex and branching missions/campaigns, then some of those options can really speed up testing/diagnosing. However, since playing since 2013 I've never flown with *anyone* that's *ever* used or wanted them in-mission or even in practice. You can't say you can really ride a bike if it still has training wheels. If you spent the time spent moan and complaining it's not simplified enough, and put that into learning AAR, then you'd have it down by now. Really, that's the one thing you can't / won't do? You don't mind learning all the systems, all the weapon delivery methods, the OPFOR missile and platform performance specs, the ATC and formation stuff... but AAR is a bridge too far. <facepalm> Very apt 'callsign' though.

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.

No, and confirmed by ED, never going to happen. If learning a 'study level' sim is too much, then don't use it, use something easier. This is the only study-level type military flight sim in the world for the general public. There is so much wrong and broken with it as it is, asking for dev time to dumb it down doesn't help anyone. You can already make all AI aircraft have infinite fuel, this isn't a solution for anything.

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