I am really starting to develop a strong distaste for the Russian way of doing things. Every four or five months DCS is rendered practically useless due to an error code. This one is new to me. Every time I boot I am asked to enter the Serial Numbers for all 30+ modules I “own”. Some numbers work. Some numbers cannot be found in my profile. And others are there, but don’t work. In any case none work past that one-time boot. Once I exit and restart I must enter all 30 again.
The top level generic ‘Server Error’ internet HTTP code is 500. No idea if that’s the case here but the lazy way would be to pass on that code. Basically their servers have a bug or are crashing, so retry. It’s pointing to an issue on their side rather than the client you’ve installed.
They are meant to return 410 GONE for that, as a version issue. No-one really uses the HTTP codes property really, other than 500 ‘bad thing happened’, 404 ‘not found’ and 301 ‘moved here’.
One day I wish to get back the space in my brain this stuff takes up.
I wouldn’t say it’s a “russian” way of doing things. Just bad practices… which are spread worldwide. As an example… every time there is a new X-Plane update (no matter how small it is), you have to re-activate every third party module you have manually with the relevant activation keys. Quite the pain, even if I really like Austin’s bunch.
My “Russian” comment was a unfortunate. Because it turns out that @komemiute was correct. The issue was with my PC’s bad clock, not ED’s piracy protections–at least not directly. But regarding X-Plane, I don’t have that problem. Well maybe I do recall it with Flight Factor’s B757/767, but nothing else asks anything of me after an update.
I get that on X-Plane as well, and ended up getting them to update my original key because it got old fast.
Ideally for the DCS issue rather than the server crash with an error they could show a message to say ‘Time not in sync - please update your clock’ as what’s happening is that they are sending you a unique code per your PC and a timestamp is part of the encryption algorithm (because the license is time period locked).
Should the hour shift really drive it off?
If they used UTC time, then the time change wouldn’t matter and the only problem would be minor clock drift.
Yeah, good point - but it’s probably correlated, in that if the clock wasn’t internet sync’d (so the DST thing didn’t happen) then a lot of PC clocks tend to drift pretty quick anyway for their UTC. Depending on how they do their own custom encryption of the license it could to the minute or even second sync up.