#Schrödinger's Environment – Stable Until Observed by Path B
24 messages · Page 1 of 1 (latest)
As far as "Godot 4.3 in linux doesn't like being reseeded constantly" goes, are you saying you saw that with the RandomNumberGenerator class, or did you mean when using the global RNG?
Because that should just work.
Hard to know exactly what's going on from the description, though, because it's no doubt something which needs examining up close. Can you just run the RNGs on their own to see if they're actually yielding appropriate results?
using seed(seed1) doing random things, seed(seed2) doing random things, about the time you reach seed5, Godot 4.3 stops listening to seed()
With RandomNumberGenerator? Those are supposed to all be separate, entirely independent objects.
I would recommend using those instead of the global RNG for anything which is supposed to be deterministic.
I find that very strange, because the code is the same on Linux.
At any rate, if you made your own thing, now you have to verify that that part is working correctly as well.
My initial thought is that you're using a single RNG run for a whole sequence of steps, but at some point there's at least a single case where an extra random number is drawn from the sequence, or a pair of items are drawn from the sequence in the opposite order.
That is, I suspect it's not the RNG, it's what you're doing with it.
When you say "randomland", do you mean you get random results each time, or that you get reproduceable, deterministic results, but not the ones you want from your A>B sequence?
So there's something order-dependent about what you're doing.
except in that moment, right before I start making the environment every single bit of variable that matters is identical right down to the hash checks of the variables.
This is all quite abstract at the moment. Why do you need to do this in reverse order sometimes, and what does it even mean to do it in reverse order?
Well, it has to hinge on the point where it starts to vary and I can only assume it's pulling random numbers from the sequence in a different order. How or why it's doing that depends on the actual code, of course. If you get the same wrong result every time, it's probably just that. If you get a different result every time… that'd be weird.
well, that's why it is so weird, I run A>B, here's my debug prints. one sec.
Is it different every time?
By the way, you realise that you have to include the code which generates and reproduces this sequence in the executable which you're giving to the player, so an enterprising hacker can just use your code to solve your file format puzzle?
Again, is the B>A sequence different every time, or always the same but wrong?
B>A is also the same, wrong, but the same each time.