EtherealN

He did say code commonality, not hardware commonality. The latter obviously tends to give the former, but having the former does not mean you have it because of the latter. It all depends on exactly how things were handled originally in code; radars that are quite different could still work on largely the same code if the principles behind their operation is close enough to each other. An example of this would be Black Shark and P-51; they're nothing like each other, really, but if I remember right Yo-Yo stated that having the code for the rotors in Black Shark helped in setting up the propeller on the P-51. Basically, code doesn't always come in the discrete package of being one-off's for a given simulated component. Parts of code developed for one component in one aircraft might be useful in a different component of a different aircraft. (And it also might not, it all depends on how it was done and how it relates to the components in question.)

Verified this, we are looking into this and will give more information about it as soon as possible. Probably just a glitch in the update of the system.

Yeah, that was a bit funky. :P The problem I have uncovered is sort of obscure, it shouldn't affect any of you, but I need to make sure that is the case because if it does it wouldn't be fun. Not destructive, but extremely annoying - even more so than the subject of the thread. Hopefully (and most likely) the problem I saw is "only" down to all the various versions of everything I have, and nothing for you to worry about, but I need to make sure.

Actually, I have to doublecheck if my production install has failed to update. Might have gotten confused between all the versions I have. EDIT: Yeah, that appears to be the case. My apologies, I'll get back (if no-one else has) once this is complete. EDIT2: I think I just found a bug related to a legacy product messing up this stuff. So ehm, right, that's unfortunate, but I have to investigate this bug first becase it is serious.

See below:

Not entirely sure what you are asking. Using the SavedGames folder is a Microsoft-directed standard.

For each thread like this, my DCS: AT-802U gets one step closer... :D

Must... resist... followup... question...

YES! :D I still have fond memories of when I took the five deutschmarks I got for shopping when we visited my grandfather and bought a joystick. And would you believe the rediculous modernity of it - it was ANALOG! ZOMG! :D After having grown up with the TAC-2's, that was just soooo cool.

Regarding age spread, the youngest people I've aided in the support queue were around 13-14, the oldest was a retired professor at somewhere around 85. While I suspect the early teens are common for games, I somehow suspect that there's a shortage of 85 years old professors (and Vietnam Huey pilots too, for that matter) in the support queue of most games. :P As for me, 30, single, no kids (but a cat). Played sims since my older half-brother moved in with his Amiga 500 when I was 7. Prior to that I had mostly been playing Chessmaster on the IBM PC. The game that really turned flight sims into something "special" for me was Chuck Yeager's Air Combat, which came with the Soundblaster card purchased for the first-gen Pentium.

You could in theory control the pit without the mouse through using a headtracker, but it'll be hard to do "right"; you'd have to get some sort of bindings to make HOTAS buttons be "mouse buttons" (and a mouse wheel), and then just move your head over to the button you wish to manipulate. A note, if you are on a budget: if you already happen to have a webcam, you can try the FaceTrackNOIR software (available through sourceforge); it's free/open source software that does the same job simply with a webcam. Doesn't give the same refreshrate and precision as a "proper" headtracker does, but a lot of people swear buy it, and it's hard to compete with the low price of free. :)

You can see the hardware code through having selected the offline activation dialog in the activation window. However, this really shouldn't be necessary. If you have not previously used those codes on a different account, you should be able to simply just activate them and they'll become associated to the account you are using.

I'd say that's fine. Just explain (in a courteous manner) that this is causing you issues that you want them to review, but that you yourself are not in a good place to explain, but that you feel could be explained by the thread. I never tested BitDefender myself, so I have no clue how fast or eager they'd be to check this out, but my experience of the few times I've needed help from staff in similar companies would make me hopeful. Though obviously I haven't tested everyone... not even close. So maybe I was just lucky so far.

No. Due to obvious security concerns, Valve does not allow the couple thousand companies they work with direct access to their key database. Manual install of the download from our site unfortunately does not and will not (ever) work on Steam installs. This is because those installers are for our distribution from our website. Steam handles this through keys: when you register a key that they accept (which either happens automatically when you purchase on Steam, or through the manual activation dialog available in your Steam client), Steam itself handles download. Downloads from http://www.digitalcombatsimulator.com are not relevant.

Jim, the issue here is that the whitelist you are talking about is on user discretion. Most users don't know how this work, but upon seeing this flagged instead issue support tickets and other measures asking why ED is sending "viruses" to them, because BitDefender (or whichever vendor is the case) tells them something is a "danger". Since most protection systems use a heuristic on top of existing threat definitions, it is important to help them get a central whitelist for legitimate applications. Only way to make them add something to the whitelist is for their paying customers to tell them they have false positives that are causing problems. ...and of course, the people that are not computer savvy, are not able to tell them this information. therefore, those of you that are savvy enough, please help do this for the sake of those that aren't.

Forum threads are not, in general, the right place to handle this. Support tickets go directly to both our general tech support staff, and also devs/sysadmins when necessary. We recommend issuing a ticket when you want to get into contact with us directly. (In part also because the ticket system is hooked directly to the account system, which the forum is not, meaning we can "check you out" and thus do health checks in the system itself without having to ask questions etcetera - think of it like when being in contact with your bank; when on the forum, it is a different account and we have to ask questions, when on the ticket system, it's in our system and we "know everything", which helps when checking out something like this.) Nevertheless, thankyou for bringing this to our attention. If there is a problem ongoing, we will obviously fix it as a priority.

The Ka-50 keys (assuming they are BlackShark 2, the current version - not the "old" one from 2008/2009) should be active very shortly. We have already transmitted the database dump for these keys and they should work within Steam very shortly. But unfortunately, we do not know whether this means "hours" or "one or two days", this depends on the specific workload Steam admins have at the time.

Greetings, Up until this very day, Flaming Cliffs 3 was not avaialable through Steam due to previous contractual obligations relating to the product. It has previously been avaialable through Steam in Russia and the CIS countries. This very recent change might be what is causing the issue. Also note that for sales through the DCS website, serial number database transfer has to be done manually towards Steam, which typically happens once a month. Due to the very recent ability to sell FC3 through Steam outside the CIS, it is likely that your key simply has not been integrated yet.

Yeah, if "stunts" like that get common, it'll be interesting to see what Google does about it.

We are sorry action was delayed. (It was a 17 day delay though, but we agree is way too much and can only ask you to accept our sincere apologies.) We take great happiness in the fact that we have after some struggles managed to reduce most ticket action times back under a single day, however yours slipped through the cracks. For this we are very sorry. Please do note that your will be adviced on all actions on a ticket by the registered e-mail, unless your ISP blocks said e-mails. (Which is, unfortaintely, something that does happen.)

This is a difference that should not be forgotten, yeah. Console manufacturers typically charge a hefty license fee on each sale - and typically sell the consoles at a loss in the first half of the console life cycle. This loss is "fine" since the customer is then "locked in" to that console, and each game they purchase will often grant more money to the console manufacturer than they do royalties to the developer. (Though this last bit is getting increasingly irrelevant, since such a large portion of developers are now part of one of the big publishers.) Can be compared a bit to how Google doesn't charge a dime from Samsung when Samsung sells a phone that runs Android. But Google gets a percentage from app sales on Play Store... Basic point is: always be careful with comparing sales-point prices for hardware. Business models can be more ingenious than just to sell the hardware. However, on the PC - for most manufacturers, the only revenue they get is from the hardware sale. (Incidentally, many laptop makers actually get a surprising portion of their revenue through bundling deals from Norton etcetera...)

Roger, then it is indeed relatively fair.

Well Skate, while you are correct in the conclusion, be careful about direct comparisons of core-counts and clock speeds. There's so much hidden below that - for example I haven't checked if the PS4 har FPU's on each core - which your FX does not. (Though not like there are many games that would have use for 8 FPU's.)

Do you have a source there? Asking, because I think you are mixing things up a bit. John has talked about two aspects; "middleware" overhead - things like how DirectX doesn't give you direct access to a GPU's compute resources, leading to inefficiensies since it uses all kinds of abstraction to ensure the same code will be compatible with widely disparate hardware. The cost is substantial, but if memory serves me right we're talking at maximum 10-20%; not 100 000%. It goes up a bit more if you compare code that was tailored for a specific hardware component with one that was not, but again not even close to what you are talking about there. What I think you are talking about is latencies, from his discussion about streamed gaming and the latencies involved there, where he pointed out that due to how a lot of components are engineered - including our monitors themselves - there is a considerable latency between when a frame is completed and issued to the output buffer to when the screen actually shows it. Indeed, this delay can often be just as long as the latency you get from a well-designed game streaming platform (assuming your own connection is really good, ofc). This was compared to "laboraty" tests he did himself where he was able to reduce this latency to almost nothing. However, here we should note that this affects PC's and consoles equally. Indeed, depending on the TV/monitor you have your console hooked up to, it can easily be way worse for the console since many TV's don't consider interactive content display in their design. My brother used to work in that field programming the firmware for consumer TV's, and explained that on the "gaming-oriented" units they would implement a "gaming mode" that completely bypasses a lot of post-processing and handling that happens in the TV itself, and we're seeing the same thing on computer monitors - for example some monitors offer a mode that disables the picture scaling functions (the things that allow you to run a non-"native" resolution) to reduce latencies. On most common-priced units this function will be on, and will incur latency, even when you are running at native - and disatrously they don't offer you the ability to disable the function. (EDIT2: funnily enough, this is an oversight from the big manufacturers that would be easy for them to "fix", but through them not doing so offers other specialized vendors to gain a huge markup on units that do have this relatively cheap-to-implement feature.) In THAT case the slowdown is radical measured in orders of magnitude, but we are not talking about graphics computation throughput - that is unchanged - we are talking about the time from each frame being "complete" and issued in the graphics card output to it being displayed on the screen. EDIT3: Another way to illustrate the difference: Case 1: Compare a gun that fires one round per minute with one that fires 1000 rounds per minute. Case 2: Compare a gun that fires 1000 rounds per minute at a target 1 second's flight time away with the same gun firing the same amount of rounds at a target 1000 second's flight time away.

Easiest solution if you don't want to remember keystrokes is to map things onto your HOTAS.