JCTherik

You've been saying this twice a week, but the only thing people here keep howling about is when one group of people see airplanes at vastly different distances than another group. We all agree that we want a realistic spotting that is independent of hardware, no advantage for low res, only eye candy and immersion advantage for high spec, with as few game-ish tricks as possible. We just can't seem to agree on how to do it. Here is the full list of requirements: 1. Spotting realistic 2. Spotting fair That's it. The devil's in the details. It may be more productive if we all stop accusing each other of trying to score advantage for ourselves, because this is a genuinely hard problem to solve. We can talk about the specific parameters and specific implementatios of spotting systems. Parameters: 1. What airplane are we using as an example 2. What distances should the airplane fully stop rendering on all hardware 3. What distance should it be reliably visible as a dot on all hardware 4. How does aspect and colour and environment affect points 2. and 3. 5. What distance should aspect and model be readable 6. How far should glints be visible And independently of those, we can talk about specific spotting implementations: 1. LOD 2. Dots vs no dots 3. Scaling? 4. Labels 5. Glints? (pretty please) Here's my opinion: 1. First, I don't care about the exact distances, make an airliner completely disappear past 3 miles for all I care, plenty of pilots and ATCs here know better than me. But whatever the distance we choose, make it disappear for everybody equally. 2. It should depend on aspect and airframe shape and size. So, if we're using dots, the dot visibility should adjust to aspect. 3. The dot should fade out relatively quickly, none of those 10 mile long gradual fadeouts we have now. (still, it's better than the 40 mile slow fadeout we used to have) The dot should either be bleeding obvious on all hardware or non-existent on all hardware, for the sake of fairness. For example, go from full size dot spawn to limit of dot rendering within 2 miles or so, to minimize hardware differences. 4. Dot should never be easier to see than the 3D model. That's just bad. 5. Low dot visibility distance absolutely ruins fun for WW2, so please, add in glints and reflections based on sun-bandit-eyeball angle and bandit aspect. The values for those reflection angles can be easily precalculated from full scale models using Blender or something, to minimize performance hit. We are currently abusing dots for what should be glint-only distances. 6. Please, please, PLEASE, add proper scaling, at least between 0.5-2.5 miles. Put it on a hotkey toggle to keep the screenshot folk happy. But things like aspect, vapour trails or missile smoke should be equally visible by everyone in dogfights. For those who are religiously opposed to scaling, please consider that a sufficiently advanced dot system is indistinguishable from scaling. 7. Dots and glints should ALWAYS be exempted from anti-aliasing or DLSS, and perhaps LOD models too. Antialiasing is needed to stop the terrain from looking like a pile of glitter that a bandit gets lost in. But enabling anti aliasing makes the bandit turn to glitter instead. D'oh.

Oh gosh, I'd pay for a model scaling, or some stabilized smooth VR zoom, or ANYTHING that allows me to see the enemy. Nothing more infuriating than reading BFM tutorials telling you how to keep tally, react to enemy aspect, how to estimate his AOA based on vapor trails.... In an offset 2 circle, I CAN'T SEE THE GODDAMN AIRPLANE !!! What the bandit is doing is a complete mystery, since his airplane just isn't there! All i can see is a red or blue label chevron, and next to it, THERE'S NOTHING THERE! Sadly, some people here will fight this tooth and nail because they want to keep their unfair trackIR advantages.

The huey got lot of FM updates last year. There is a real cost to context switching in development, and it's a lot bigger than people realise. It's a lot easier and faster to focus on one thing at a time. It makes more sense to focus on a mod for a month and do a bunch of fixes at once and then move to another one, you get a lot more done in the same time. I would still like it if old small bugs got fixed sooner though, like the huey slip ball that's been offset for years for example.

Yes. Add in, "assign gear down binding across all modules."

I personally hate subscriptions, but it's important to say that it's not the subscription itself that's at fault, because it does make a logical sense to pay an ongoing fee for an ongoing service. What's really causing prime, netflix, uber, apple and other services to become crap is when the companies change the rules of the contract after you make a purchase, when they abuse their market position, sell their services below cost to push out competitors, monopolistically increase prices once they corner the market, remotely brick people's devices, block user repairs, obfuscate the terms and conditions, make exclusive deals with movie producers, etc. Most of those behaviours are either a grey area, unlawful or straight up illegal, but most of them are also largerly unenforced. It's a regulation problem for the most part. For DCS, subscriptions would make little logical sense, because ED isn't providing an ongoing service, you either fly offline or on community backed servers, the only ongoing service ED is providing is the multiplayer server list. You could say that providing updates and fixing bugs is an ongoing service, but most modules are sold early access, with fairly defined end goal, with a promise that they will be finished in the future, so it's not an ongoing service, it's just keeping up with the promise they made earlier. Once a module is considered finished it rarely gets free updates until a big overhaul is brought in, but the overhaul is usually not free. Fixing the base game is an ongoing cost for ED, but the base game is just a bunch of code that's shared by all of the modules. The modules wouldn't work without the base game. A bug in the base game is quite literally a bug in all of the modules, so it makes sense to have the base game included in the price of the modules.

Are there any plans to sort out the mid range? I can currently see airplanes as dots at 10 miles really quite clearly, often even against terrain. I'd say it's unrealistically clear. Airliners at 8 mile altitude are a bit harder to pick up IRL I'd say, if they weren't tracing. But once the 3D model kicks in the plane still disappears and is functionally invisible even against a clear blue sky until it gets to around 2 miles, when enough pixels become consistently grey enough for long enough that if I randomly happen to look directly at them in the middle of the sweet spot, they will make me pause and consider that there may be something fishy going on in that part of the sky. Still need radar to verify though. It could be an airplane, it could be some weird sky banding that happens to be aliasing, a DLSS artifact, small high altitude cloud or an eyelash. Luckily I still have 7 seconds until merge to figure it out.

As it is now, zooming to a distance makes the view very shaky in VR. It makes sense, that's just how the geometry works. Spyglass zoom is ofcourse worse than regular VR zoom. I think anyone who doesn't throw up while using the zoom in the first place would probably be OK with a slightly delayed head tracking when the advantage would be a more stable view.

It would be really interesting to have DCS straight up integrated with Arma. Two completely separate games but sharing the same map and environment and mirroring the movements of units. The ground units in DCS could still be fully DCS units in every way, but their behavior mirroring whatever's happening in some Arma match, and vice versa. That way if you pick up a bunch of ground guys in Huey in DCS, your friend in Arma could hop into a Huey in Arma, you'd fly him somewhere else and drop him off. The hard part would be to make the maps be the same topology and shape, the buildings, trees and other obstacles would have to match closely.

I think rather than trying to allocate more money to the core game, it may be worth considering releasing releasing parts of the source code as opensource, even temporarily. Not under GPL or MIT license and not the whole game, the game should still be shipped as binary, otherwise people would just compile custom hacked clients. But for example, while working on the vulcan and render pipelines, having the render code temporarily public would allow some useful comments and help from knowledgeable community members. Throw in enough scaffolding to be able to compile it and render a trackfile, but not enough code to actually play the game, that might uncover bugs early, compare things on more hardware, show off the progress and perhaps get some usefull pull requests from the community here and there.

Interesting. Does the stick have to be perfectly centered or something? I have less than 5 degree bank, all SAS on, Ap on, hdg forward, no effect outside of regular attitude hold.

Not really a bug, but I can't find the wishlist for bindings. Could we get directional Up/Down bindings for 3-position switches, for example the HDG/GT hold for the autopilot? Currently we have HDG on and off, GT on and off, HDG on else off and every permutation of that, but one common way of handling those bindings in other modules is missing. Example from another module would be the autopilot switches in F16. Example in F14: Heading Hold Forward: Move the switch one step forward. If GT is on, put it off. If it's on Off put HDG hold on. If HDG hold is on, do nothing. ie. cycle (GT)->off->HDG hold. Heading Hold Down: cycle (HDG)->off->GT and do nothing if already in GT Antiskid Down: (Both)->off->antiskid Antiskid Up: (Antiskid)->off->Both Engine starter move Left: (right)->off->left etc, you get the point. There are few more switches that could benefit from this, launch bar, refueling probe, probably some others. This is especially useful with two-way momentary switches. Cheers.

I don't know if I'm using it wrong, but I put the airplane in a slight bank, 1-2 degrees, barely two pixels off of the center on the VSI. I engage heading hold, engage autopilot and I'd expect the airplane to roll out. Nothing happens, no AP/Ref light, just the attitude hold from a basic AP. I tried in different ways, HDG hold first, AP first, together with altitude hold, I never managed the airplane to roll out and hold a heading. It keeps the slight bank and makes a very slow turn of few degrees per minute. Ground track works fine, it illuminates the AP/Ref, and clicking the NWS rolls out the airplane. I didn't check whether it actually tracks ground, but it goes wings level in calm wind. Tested in F14B, on MT.

huh?

VR is officially supported. I'm running one of the common headsets on default resolution. And your suggested solution to my poor default visibility on default resolution is unironically to make a choice between an ugly game or a crippling disadvantage, which is the exact same thing that you yourself complained about when you perceived that the same dilemma was forced on you merely few hours ago. The fact that you keep repeating that this is due to low resolution shows that despite the two days long debate we all participated in, you still lack even a rudimentary understanding of the problem. I don't see any point in continuing the debate for as long as you make zero effort to understand my comments. I find it hilariously sad that you recommend the same kind of solution which you complain about when it's being recommended to you. I honestly don't know if you have such a high lack of self awareness, if you're intentionally and knowingly abusing dishonest arguing strategies like gish gallop, or if you just straight up don't read my comments at all.

if the default visibility isn't realistic on my setup. FTFY