JCTherik

And it will continue for years to come, since several years ago the community has decided to throw away scaling based on a bad experience with the then current implementation. The render distance of that dot needs to be reduced a lot, it shouldn't really exist past around 15 miles. For longer distances, an occasional sun glare should be the only way of spotting. At 10-15 miles, a dot would make sense, and in 3-10 miles the best solution would be a gentle scaling. Obviously the scaling shouldn't be applied to zoomed objects seen through a targeting pod.

For each their own, labels exist. I definitely don't want to see everything from far away and I'd like to stay away from labels. Currently i can see an airplane 20 miles away a lot easier than an airplane 5 miles away, especially against terrain. I'd dare to say that that seems pretty unacceptable. That said, i still prefer having those huge dots, knowing that people with 720p monitors have always had those huge dots. The spotting should be fair, with similar performances on different hardware and matching IRL performance. It is a tough nut to crack, and i think that by throwing away scaling we're throwing away one of the best tools to crack that nut. Perhaps the old implementation of scaling was very bad, but that's not a problem with scaling, that's a problem of implementation. Any technique could be the worst if it's done wrong enough. Btw why would random glints be bad? I'd say that random glints with reasonable frequency, duration and intensity would be much preferable over the long distance black dot. In fact, it could be very difficult to distinguish randomly generated glints from raytraced glints if the frequency, intensity and duration are set just right and varied based on distance, airplane type, weather, etc. Ofcourse proper glints would be better, but random glints may be dead easy to implement.

Labels are miles less realistic than scaling. I don't know why do people hate scaling so much, claiming that it's unrealistic and then suggesting using labels which are visible even through clouds or cockpit floors and do nothing to help read aspect at 3 miles distance on a shimmering cluster of pixels. You can't say that DCS has realistic spotting, ever, without also mentioning what hardware and what scenario you're talking about. Some hardware is grossly overperforning, other hardware is grossly underperforming.

I think there are several issues here that should really be considered independent of each other. No single solution is going to fix them all. The spotting strongly depends on the range and also on what's behind the airplane. Range: Up close <1 miles Short range ~1-5 miles Medium range Long range 15+ miles Very long range 40+ miles (nonexistent in DCS) Backdrop: Sky Clouds Terrain Display: VR Pancake (flat screen) Resolution Lowres Highres From now on, if I type for example Short, i mean spotting in short range of 2-5 miles against any backdrop and on any type of display, Short/Cloud/Pancake/Highres means spotting at short range against clouds on a high resolution flat screen, Short+Medium/Sky+Cloud means spotting at short or medium distances against a sky or cloud, etc. Ideally, we would have a realistic way of spotting things. Note for @draconus: by realistic I mean realistic in terms of performance. As in, an average DCS player should have the same chance at spotting an airplane at a certain distance against a certain backdrop as an average pilot IRL in the same situation. That doesn't necessarily mean that the angular size of the airplane at that distance must be the same as in IRL. It would be great if it was, and there's no reason for it not to be up close, but following such a simplistic algorithm into medium and long ranges results in a spotting system that is both unrealistically hard on some hardware and unrealistically easy on another, which then necessitates the use of labels, which is by far the least realistic option of them all. In real life, our view is not split into flat matrix of pixels, thus we need to take some compromises and tradeoffs. I know you want realism, we all do, but naively following simple physics equations does not lead to realism when you don't account for that solution being squeezed through a mesh of pixels. Main issues: Up close - looks great on most hardware Short/VR+Pancake/Lowres - losing aspect information due to low resolution, unless zooming in Short/VR/Highres - losing aspect information due to shimmer from fresnel lenses and oversampling Short/VR - hard to scan a large FOV at once due to somewhat limited FOV of headsets and inability to zoom out Short/Pancake - virtually impossible to keep an airplane in view in trackIR when highly zoomed on it, except when in a 2circle, due to trackIR being imprecise, and bearings and altitudes changing quickly in a dogfight Short+Medium/Terrain - hard to track an airplane if the airplane is in the same distance as the grass/tree/object rendering distance, or the distance where detail quality of ground objects is changing. You're looking for a handful of moving pixels in a sea of a million pixels of trees suddenly growing into existence Short+Medium/Terrain/VR/Highres - extremely difficult to spot due to terrain and aiplane both shimmering from fresnel lenses and oversampling. It gets worse with increasing range to the point that even just keeping a tally against terrain becomes impossible past a few miles, especially when combined with the rendering distance issue above Short+Medium/Clouds/VR/Highres - has similar issue as above due to fresnel/oversampling shimmering and due to smoke and clouds still doing that weird movement when turning head on a roll axis Medium - closing airplane is a big obvious dot (since improved dots), but as it gets close the dot suddeny disappears and gets replaced by an object that's much harder to see, creating a discontinuity and a strange situation in which you have to get further away to see them better Long - too easy at the moment since the improved dots, but at least it's a huge improvement because it's now a lot more fair, since it's similar to how easy it was on low res flat screens Long/Terrain - dot is sometimes visible, I don't think it should be possible to spot a plane against terrain from 15+ miles Medium/Long/Very - should produce an occasional glint of from the airplane based on aspect and sky/sun/moon/water reflection positions for realistic spotting at long distances. At long enough distances, no black dot should be there at all Summary Problems 2 and 3 are not solvable unless some form of scaling is present or the zoom function can also auto-lock a camera onto a target Problems 4 and 5 are just the limitations of crutches that we use. It makes sense to zoom out to get a bigger FOV and it makes sense to zoom in based on resolution, so that everyone is able to zoom in to see the same amount of detail. VR has a lack of smooth zoom-in and a complete lack of a zoom-out, but a much bigger issue is in Pancake, that's the assumption that you can keep the bandit both zoomed in and reliably in your view with trackIR. Problem 6 - I don't know what to do with it apart from model scaling again or increase contrast of the airplane in those distances, or perhaps limit how the ground objects behind the airplane change or blur the background behind them? Problem 7 - again, either scaling or contrast increase or bluring the terrain behind the airplane? Problem 8 - Cloud and smoke sprites shouldn't be following you when turning your head, this isn't Wolf3D. It's generally a lot less of an issue than problem 7 I'd say. Problem 9 - The distant dot shouldn't be bigger than the airplane that is closer. The airplane becomes single pixel a lot earlier on Lowres but on Highres the airplane keeps shrinking and shrinking until it hits the limit where it becomes that big black dot. Again, scaling would make sense. We cannot make the dot smaller, that is impossible to do on Lowres. The alternative is to make the dot appear a lot earlier on every display, at the same distance where Lowres would start rendering the airplane as a single pixel. That would be annoying on Highres but fair. Problem 10 - some adjustment needed, it shouldn't be possible to spot an airplane as a dot from 40 miles. Problem 11 - I think the dot should entirely disappear if the backdrop isn't a sky Problem 12 - If long range glints were implemented that would be great Scaling There's plenty of ways to do it that have been described a thousand times and every form of scaling is going to be a tradeoff, because it makes some parts of the game ugly - tanks bigger than houses etc, which doesn't feel realistic. It doesn't have to be that way though. If the scaling is only temporary, bound to a Hold-to-scale button. If you hold the button, objects are visually scaled to a bigger size. Once you release the button, they get back to normal. You could imagine as the pilot forcing his eyes to focus in a distance more. For an added realism, some sort of eye-fatigue could set in if people just hold the button indiscriminately, reducing the scaling after several seconds or something. Maybe add a few seconds of in-cockpit blur as the pilot readjusts to a close range vision after a session of long range spotting or something. I think there are plenty of artistic ways to make this feel realistic in addition to the spotting performance of the virtual piloit to be realistic. For an added effect, the objects could scale proportionally to how close they are to the center of the screen, that would force people to move their view left and right and up and down to actually scan the sky effectively, again somewhat simulating IRL spotting. I don't think that the question of scaling is whether scaling yes or scaling no, but rather of scaling how. We do already have scaling in DCS. First, the dots are a form of scaling, and then the zoom is a form of scaling that scales the entire world! The side effect of the current zoom system is the massive FOV limitation and the uncomfortably high sensitivity of TrackIR and VR when zoomed. The question is if this form of scaling is the best form of scaling. It definitely has an advantage of simplicity and making the size of objects always match the size of the terrain, but the disadvantages are making its usefulness very limited. Ideally, I'd like to see a set of options, perhaps an experimental release with several different implementations to compare. Contrast As an alternative to scaling in certain situations, particularly against a terrain, lightly bluring the background behind an airplane and/or artificially increasing the contrast could help to keep things realistically visible. Long+Very long range glints I believe this should be implemented. It could be a set of maps of airplane aspects and light source angles to be compared against the angles of the big light sources (sun/brightly illuminated clouds/reflecting snow/reflecting water/moon). It is effectively an implementation of path tracing, but the angles of shiny surfaces of airplanes can be precomputed and low res and only few rays per airplane in view need to be sent, thus the performance hit should be very small. A solution for glints from sun, moon and sea reflections should be doable in O(1) time per airplane in view. Accurate solutions that account for snow, cloud cover, illuminated clouds and water surfaces which are not on sea level would depend on how easy it is to cast and intersect a ray with a terrain or cloud in DCS. Also it doesn't need check every frame. And for a zero effort - zero performance impact simulation, just produce those glints randomly every now and then. Slightly less lazy solution would adjust the chances based on weather, date and time. The issue of VR with fresnel lenses (almost all headsets) Due to the fresnel lenses producing an extreme amount of aliasing, the VR headsets ask to render in higher resolution and then downsample, effectively running a built in SSAA, meaning not every pixel which DCS renders is shown to the user if the VR headset is ran at full res, and the extra pixels are only used to slightly change the colour of the shown pixels. This lead to the flickering or disappearing of the single pixel dot in Meadium+Long/Sky+Clouds before Improved Dots were a thing, and pixels are missing or shimmering on an airplane on the distant end of Short making it very difficult to read aspect. Same effect also happens with the edges of trees and other ground objects, and when moving over an area, lot of ground stuff tends to shimmer slightly. That's not usually a problem, as it's still much preferable over flickering jagged edges but it does mean that the ground is constantly full of faint pixels coming in and out of existence. That plus the fact that pixels in the airplane also tend to shimmer an come in and out of existence makes distinguishing the airplane pixels from terrain pixels pretty much impossible. This affects Short+Medium/Terrain/VR. I think that Long/Terrain should pretty much be impossible to do IRL. Spotting Short+Medium/Terrain airplane should be hard IRL too, but I believe it should not be that difficult to keep track of that airplane once spotted. But due to the effect of the fresnel lenses and necessary overrendering for full resolution, even just following an already spotted airplane is very difficult even in Short+Terrain/VR

The hud is a very odd place to compensate for lack of motion feedback. Especially on the VSI, there's no physical feedback in IRL airplane that will tell you VSI. G, shake and acceleration, yes, but not VSI.

There is a thing to be said about the FPM. Regardless of where it is, it does drift up/down as a response to power changes a bit quicker than other visual clues. IRL you'd also feel that change in vertical velocity, in sim you don't. The closest you get to that quick of a feedback in the sim is the subtle FPM movements in your periferal vision. So it is a bit cheaty to leave it on, because it still gives you an info you'd otherwise not have in the sim, but it's also just overcoming the lack of chair feedback. It would be great if the G head-bob got a bit more pronounced to show those subtle changes.

I find the AOA tape a lot better than the E-bracket, it tells you a lot more precisely how far you are from on-speed

That's what I meant, I fly the ball and ignore the FPM in groove, or even switch off the HUD in groove I'm talking about the entire pattern, marshall, initial, break, downwind, etc. Say you're flying on-speed in landing config, downwind straight and level at 600ft. You have 4 options to keep altitude I can think of: 1. mk1 eyeball it I don't think this is the way. I am in VR but I can't see a difference between 650ft and 550ft visually above the sea. Chair-of-the-sweatpants feedback doesn't help either, Maybe I can see the difference between 300ft and 1000ft, but the sea can be very deceiving. I am personally doubtful that it's possible to fly 600+/-50ft over the sea in sim or IRL without looking at the altitude at all, but I'd be very happy to be shown otherwise. 2. Baro alt/Radar alt steamgauges They work, but I gotta keep staring at them if I want to catch slow and subtle deviations early, which means I'm head down in the cockpit and not looking out for traffic. 3. Baro alt/Radar alt + vertical velocity steamgauge This would be great if it worked, I could put the airplane on 600ft and then zero out the vertical velocity. It doesn't work though, the vertical velocity needle has 4-5 seconds delay. It doesn't help to know that I was on 300ft/minute climb 5 seconds ago, I want to know what's my VV now. The confusing delay in the needle makes this almost worse than just radar/baro alt alone 4. Baro alt/radar alt + HUD VV I mean the vertical velocity on the left of the HUD that appears in takeoff and landing modes. I'm not talking about the FPM, screw the FPM. You called it the HUD VIS repeater. The HUD VV has a lot faster response than the steamgauge VV, I'd say it's pretty much instant. Plus it's right there where I also want to look at traffic, plus it has a rather nifty radar alt repeater on the right of the HUD too. I'm not saying that this is the right way, I'm saying that the HUD instruments in DCS are objectively a lot more useful than the steamgauge ones. I've seen the FPM pegged to the side, but there seems to be a reliable instant vertical velocity in the HUD in landing and takeoff modes. And yet IRL pilots are saying that they weren't using it, Victory here is saying that it used to jitter, lag and break all the time, even the HUD VSI. I think that's something that should be implemented then. If the real hud used to be useless, I don't get why we should get such a perfect instrument. Could you explain that again? Also, was the vertical velocity steamgauge as delayed IRL as it is in DCS?

Howbout scanning the winning stache and adding it to the phantom as an option?

Completely intentional. Move it back as far as it goes, look at your warning lights, hz tail auth will be illuminated. After 15 seconds the light extinguishes and you can move it all the way back. Sometimes it bugs a little if you move it back with flaps down and then raise flaps, sometimes the light doesn't illuminate. It will possibly still go all the way back after 15 seconds. edit: yea i thought you're talking about oversweep

I tried some breaks and landings and you're right, watching the horizon in peripheral vision makes the climbs and descends when on-speed pretty noticable, i guess i just never really paid any attention to them. That definitely makes it doable without a hud. I tried it a long time ago and i couldn't even hold a level flight, but i was mainly following the VSI. Level break still seems pretty tricky without the hud. I'm mainly focused on baro alt and steam vsi since it's hard to judge climb/descent visually while in a bank and dirtying the airplane. The steamgauge VSI has a noticable delay of several seconds, especially in rapid changes. It's as if the needle had inertia. The VSI seems reliable only if the needle isn't moving. And yet, the baro alt seems to have a quick response, which is another thing that i never noticed. So i guess i should mainly use baro alt and then vsi only to finetune when the baroalt seems stable? For some reason the VSI on the left of the hud has pretty much an instant response compared to the steam gauge VSI. I don't know if that's realistic, but the truth is the HUD VSI in DCS is objectively a lot more accurate. I get that landing with HUD creates a risk that people will be planting the FPM in the wires and then end up drifting left and low as a result. But if the HUD VSI is realistic, we should probably use it. And if it isn't then maybe it should be a bug report?

Ideally the harrier, M2k or L39, but I'm not too picky. If you're looking for a pilot for your group or if you just occasionally want to fly formations, please message me.

That's 4.72G of acceleration. The airplane has TWR of 1.15, or 1.66 when empty, which means it's impossible to make it accelerate at higher than 1.66G even if you could magically turn off drag. Theoretically you could do 2.66 going straight down, but that's really an accelerated fall rather than flight, and you'd still be far from 4.72G. You have the numbers everywhere, you can look at them yourselves. Who do you trust more, one guy doing an interview about how cool his job is or thousands of documents from testers, specifications and maintenance crew about the approximate performance of the engines? Funny thing is, if you go to a modern f22 or f35 pilot and ask them how far does some modern missile go (don't do it, it's very impolite) some of them may tell you that modern amraams can reach the moon, but others may tell you that they'll hit a target on a radar 500 miles away or fly at mach 10 or some other bonkers far fetched but not quite completely unbelievable number which will satisfy the person asking, make the pilot seem really badass and yet reveal absolutely no classified information what so ever. It's a way to shut down people who ask inappropriate questions and stroke your ego in one swoop. I guess some pilots may get a little stuck in that mindset even for info that's not actually a secret.

The thing is, the vsi in the hud has much faster response than the steam gauge one.

It's zeroing itself slowly in straight level flights, but you can speed it up by pressing the button on the right, in front of the icls frequency knob, left of the compass slave knob. It's quite small, white, round and it can be scrolled or pressed. Bind the press on it. You have to be in a level flight with constant speed for it to start working, and if your wings aren't perfectly level, it will put your compass onto a wrong value. Especially the constant speed is tricky, it has some quite tight margins and there doesn't seem to be an indicator whether you're accelerating or deccelerating. Luckily, you don't need to stay on constant speed, you just have to cross through it slowly. I usually hold the button and rock the wings slightly and either push little more power until i see my speed climb and then slowly reduce it until the compass starts responding to the rocking wings, or the other way around - decrease power and once speed is visibly dropping on the dial, increase slowly. Right at the moment the speed is constant, the compass will respond wildly to your bank inputs, that's why i rock the wings, to find the moment of constant speed. When the compass is responding to bank inputs, put wings level and let go of the button. I have no idea if this is the right way to do it, but it does put the compass reasonably straight, +- few degrees. That's usually a huge improvement, since after few slow orbits around a boat or an airfield, the compass is easily 30 degrees off, which makes it worse than useless. Compass can also read wrong near big metal ships, heatblur wouldn't surprise me if they simulated that too, but i haven't tested it.

Are you iddle and boards out on entry to the break? You shouldn't be coming out of the break too fast, in fact, you'd normally need some power at the end of the break in order not to get too slow. This is how I do it: Enter on perfect trim, wings back, 350kn, 800ft. On entry, iddle + boards out + left bank ~50 degrees. Pull for 0 vertical velocity (left indicator in the hud and FPM across the horizon), pull needs steadily increasing as the speed drops. 300kn: wings auto, 250 drop gear, around this time the gear pushes your nose up and the wings get open enough that you need to suddenly decrease the pull quite a bit, but then immediatelly start increasing again. 210-200 flaps down. Below 200kn pull now needs increasing quite a bit faster (assuming 0 pitch curves) due to low speed. About 20-30 degrees of turn to go, the pull is becoming too much, I hold nose up trim for 4 seconds - say 1 potato 2 potato 3 potato 4 potato, then let go of trim. You'll have to reduce the pull a lot at the same time to stay level ofcourse. 160kn at around 15 degrees to go, start putting power back in. When facing downwind tap right rudder a little to initiate smooth rollout, put wings level and let go of the last bit of the pull. When wings level, dlc open to initiate the descend to 600, arrest the descend with additional power. 50 ish degrees of bank should put you on track to get to 1.2 - 1.4 miles abeam, and with 4 potatoes of trim, you'll be pretty much on speed when you roll out of the break, you may just need few clicks to fine tune. Some people like constant pull and adjusting bank for altitude, i do constant 50 degree bank (horizon touching just above the bottom right corner of the hud) and adjust pull for altitude, so if you want to do constant pull instead, you'll have to do some experiments to find how much AOA to pull, and you'd be ofcourse moving bank instead of pull to keep level. Don't trim it continuously during the break though, fly the stick, then trim it when the pull is too much. You can trim for 2 seconds in the middle of the break and 2 seconds towards the end if you don't want to hold so much pull, or 4 seconds all towards the end, or fully wait until you get out of the break and then trim it, it doesn't matter, but don't trim it for hands-off flight while in the break, that would be way too much nose up trim once you roll out. About 4 seconds of nose up trim is the difference between wings-back 350kn and landing config on speed, so count 4 potatoes of trim, then you can fine tune once on downwind. (note, it's 4 seconds trim since the change in the tomcat trim in beta. It used to be 3 seconds, i'm not sure if that change is in DCS stable already.) For practice, you can set a tacan over an airport, put a course line to whichever way you're flying, overfly the tacan beacon as if it was initial and do a case 1 break almost immediatelly, then check your distance when the beacon is on your 9 oclock. Then adjust how much you pull/bank to aim for about 1.3 miles. Keep in mind that the tomcat compass goes out of sync with the planet every time you even think of turning, so zero the compass after every break. I always zero it on initial, otherwise my downwind is at an angle and my abeam distance is off.

150 and 610 kcas at 10k is 174 and 685ktas respectively, assumig 0 degrees C at sea level, that's 511kn or 263m/s of difference. 263m/s in 9.7 seconds makes 27.1m/s^2 or 2.76G of average forward acceleration. Yea, that guy is absolutely full of it. 19838 kg (dry tomcat) * 9.8m/s gives 194kN of thrust required for 1G. For 2.76G, 194*2.76 = 535kN required, but each tomcat engine can only do 120kN. And that's just inertia of the bone dry cat, and he's claiming that he went from way behind the power curve into transsonic in under 10 seconds. Meanwhile in reality, he spent half that time waiting for the engine to spool up and the other half waiting for the flaps to move, because you can't accelerate at 50kn per second and not overspeed the flaps.

I got it on axis, one of the two axis dial knobs on the virpil panel 1. Seems to work fine, I move it all the way back in one go, it stops against the oversweep detent, 15 seconds later, i jiggle the axis again and that moves it to oversweep.

The_Tau posted above about missiles just flying by the target.

There's plenty of problems with the phoenix, but arguably the most annoying for the last year was that the phoenix doesn't reacquire target after notching. Two years ago that didn't really matter, since the kinetics of phoenix were so out of whack that it would often get to target way before the target had a chance to notch, or even saw the tomcat on the radar. Now with slower phoenix, the other aspects are showing up more. When the phoenix loses track, it used to suddenly pitch up, lose all the speed and get trashed, so everyone just assumed that the pitch-up is the problem. Since it suddenly pitches up, it's no longer looking to where the bandit is, so it's obvious that it can't reacquire the target. Seeing the comments here saying that the pitch-up, which everyone was complaining about, is finally fixed, and yet it's still not reacquiring the target, it is just so disappointing. We were under the wrong assumption that fixing the pitch-up is going to fix the reacquire, which apparently, it didn't. So, back to square one and another year of waiting I guess? The phoenix has been nerfed into oblivion in a very unfortunate interaction of heatblur and ED. And yes, I mean nerfed, as in a gamified sense, because what's happening just isn't any more realistic than what the phoenix was in 2 years ago, it just went from grossly overperforming to grossly underperforming. Heatblur insists on having phoenix having as realistic performance as possible, and they do that by providing the most accurate values for things like the missile thrust, aerodynamics, nozzle area, exhaust mass, weight, etc. Something like that, but i don't know the details about it. But ED is the one who actually writes the code that controls all the missiles, since ED controls all DCS missiles once they leave the rail. And ED's missile code is nowhere near as realistic as heatblur (or many players) would want it, thus no matter how accurate the performance values are being assigned to the phoenix by Heatblur, the actual DCS performance is then gamified by the crappy ED missile code. This gets doubly important in case of the phoenix, since the phoenix should be guided by datalink from the tomcat radar for the majority of its journey. But the radar code and the RIO cockpit buttons are the domain of heatblur, yet the missile performance, aerodynamics, guidance and general behaviour are ED's code, out of heatblur's control. There are buttons in the RIO cockpit in DCS that don't do what they should because their purpose is to affect the phoenix while in-flight, but ED's missile code just doesn't take those into account. Heatblur is here at the full mercy of ED being willing to implement any special interaction which heatblur wants to implement between the phoenix and the tomcat, and any interaction that ED is willing to implement is usually fairly simplistic, plus the inevitable bugs end up being nigh impossible to resolve, since there's a tendency from Heatblur to blame ED's crappy missile code for the bugs, and for ED to blame Heatblur's uncompromizing approach to realism, the bug reports just sit here and disgruntled players who report those bugs are sent on endless bounces between the two companies. Finally, one more but very important reason why the Phoenix is crap is the obvious fact that the true performance of missiles in DCS doesn't actually matter. What matters more is relative performance compared to other missiles and airplanes. And since good modules with powerful A/A combat sell more, there's inevitably going to be some incentive for performance inflation caused by this conflict of interest. "Shall we make a realistic module that people wouldn't play, or shall we make an overpowered module that will sell more?" Sadly, while all the devs are highly committed to realism, some are still more committed than others. And while extreme realism sells lot of modules, sneaking in a little extra unrealistic performance into your module here and there also sells a lot of modules, but for much less effort. I don't think it's very controversial to say that many modules and missiles are overperforming compared to real life. In my personal, poorly researched and very limited opinion, the biggest offender in terms of flight model was definitely the old gazelle (fixed recently, thank you Polychop!), and one of the biggest and most important current offender is probably (don't hurt me) the hornet and amraam. Interestingly, the viper from the same company seems to be strangely underperforming, so I wouldn't assume too much malice from ED for the overpowered hornet. Heatblur is uncompromizingly focused on realism, arguably more than most other developers, which is probably one of the reasons why loading into the tomcat always heatshrinks my PC a little. Heatblur's approach is to make the module so damn realistic that people will want to play it even if it loses in an engagement more often than not. I like that approach, and I wish all of the companies took the same approach. I like ED as a company, they care about realism a lot, they're just getting completely outshined by heatblur, but ironically, it's the heatblur's module that suffers a lot due to it. So, the best thing we can do that I can think of would be to convince ED to raise realism standards for themselves and all the third parties, to at least match the current standards of heatblur. It's gonna be a long fight though, and a long list of bugs.

Tested in caucasus near kobuleti, makes landing a bit tricky and autorotation pretty deadly

Yep, I spent an entire weekend talking to it, then it always worked for 5 minutes, but if I didn't say anything for a while, it broke again and I couldn't even call Jester.

Add the option to turn on ILS.

I'm not a native english speaker, and I don't live in US, so I could never make voiceattack work reliably. Sometimes it would pick everything instantly, 5 minutes later I had to repeat "Jester" 30 times just to get to the jester menu.

Yayy, more performance!