sobek

I find that PR ... silly for a lack of a better word. ;) If the concerns are as silly as you want us to believe, it should be easy enough to counter them with arguments. Calling them silly is *not* an argument. If people have the decency to voice an honest concern instead of throwing a tantrum, what they can reasonably expect is to have that concern taken away by being reassured, not called silly.

I think the 3d model is exactly the same, probably a shader changed or is on the fritz.

I find it extremely bad form to label warranted customer concerns as silly. It is not unreasonable for people to ask where ED is going with their business model. That is nothing untoward.

Hmm interesting, didn't the Facebook post say it would come out late April. The announcement says late May. Any info on which of the two it will be?

That's what kept me from being mundane? LOL!

Community members can give you positive or negative reputation based on their reception of your posts. The more positive rep you have, the more points you give or deduce when you pos/neg rep somebody.

Physically no, but misanthropy wise i'll take on any of you old geezers. :P

I see, thanks.

Can anybody point me at performance per Watt comparisons between Ryzen and Intel chips?

This. And don't open any links in mails that could be phish.

We would also need a shrapnel model for that.

Also, mission complexity should have no influence on what is recorded (in single player).

Was there any turbulence?

No, not the random number. You save the seed of the rng at simulation start. At track replay, you reset the seed of the rng to the saved seed. After that it will put out the same pseudorandom series of numbers it did the first time. Of course the program execution flow must be absolutely identical to the first time. But your other point is indeed valid. If EFM programmers use other sources of pseudorandomness, then this would once again be a possible cause for a track to break. On the other hand, the randomness really should be in the atmospheric model, not in the EFM. The EFM should be deterministic. So maybe this isn't even a problem.

Ok, but that would all the more speak for saving the seed of any pseudorandom number generators used in the sim to be able to reset them before track playback. Then it'd be deterministic again. You can't have real random processes on a computer (unless you sample a real source of randomness).

Let me rephrase, that could lead to units dying (erroneously) and suddenly being resurrected (in the subsequent sync frame). Actually in SP, there aren't that many variables to be tracked. The only input to the system is the input from the HIDs, so a bunch of axis inputs and button clicks. The rest is "just" the sim engine doing what it does. I can hardly believe that this is an issue as trivial as recording user input, because in that case, ED would have long fixed it. The thing with version incompatibility is practically a given with this system, that much is understandable. On the other hand, it must be possible to make the sim react the same twice to the perfectly same conditions. IIRC the simulation core is programmed to be real time in a very strict sense. My guess is that at least some of the breakage comes from core frames not meeting their deadline, but this is pure guesswork, as i don't know if that is even possible without the sim crashing. Dunno, i doubt anything we can dispense in this thread short of doing research on what breaks trk files brings the devs any closer to fixing this issue. :dunno:

None of that is done. The trk system hinges on the deterministic nature of the sim. Same input-same output. A trk is simply a mission file (the initial positions of all entities) with the user input baked in. The rest is the simulation running by itself without any further interference. The problem seems to be that under some circumstances, the deterministic behavior does not hold true. Anyways, i guess all this rambling defeats the purpose of the bug forum.

That could potentially lead to dead entities reappearing, etc. It still begs the question why sometimes the simulation engine behaves non-deterministically during playback. Fixing those problems is the prudent solution. That's not to say that that is not a hard task (especially in MP, where this might actually be prohibitively hard).

You don't need lossy compression for track files. You have a few tens of max 32bit integer time series compared to 1920x1080=2073600 of 24(?)bit pixels per single video frame for full HD video. I don't know what the actual problem is with playback, but that seems unlikely.

I didn't say that... :doh: It certainly wouldn't hurt to incorporate that though. The problem with tracks breaking isn't exclusive to missions with dynamic weather however.

That would have been somewhat acausal, given that the dynamic weather generator came around much later. ;)

I think you have some things confused here. The term seed is used to describe the state of a pseudorandom number generator. Every time the generator is "rolled", it generates a number from the seed via an algorithm, then modifies the seed with a different algorithm. The algorithms themselves are deterministic however, so if you know the seed, you can reproduce the pseudorandom numbers that the generator will yield with each subsequent roll. The dynamic wheather is indeed different, but not because the generation process is non-deterministic but instead the starting condition is randomized (with a pseudorandom number generator, presumably).

How do you achieve any kind of randomness without a pseudorandom number generator?

Say what now? What does calculation precision have to do with it, as long as errors are deterministic?

Isn't that a BIOS/EFI thing?