I had my suspicions for a couple of months that the layout randomizing algorithm might have been... "half-assed". Ever since I found multiple times IN THE SAME DAY that the THI star [!] appear at the exact same unreachable coordinates (high above the top of the very steep slope that tops the white rock wall delimiting the starting yard) I felt something wasn't done right algorithmically to randomize objects placement. I also happen to have stumbled upon a 0.5.1 seed in which the CCM layout was identical to the CCM layout that I saw (the very same day again) in the video of one of the previous 120-stars WR from 360Chrism. I chose to dismiss it because this was between two different versions of the hack (0.5 for the WR). A week ago, HOWEVER, ONLY A COUPLE OF ATTEMPS APART FROM EACHOTHER (the same day). I did stumble on two seeds where the layout of Rainbow Ride is identical down to the very last coin as far as I recall.
Seed 22967: Vanish cap leads to aquarium that then leads to Rainbow Ride Seed 26095: Vanish cap leads to HMC that then leads to Rainbow Ride
In between those seeds, the layout of Rainbow Ride is IDENTICAL, from the [!] box pierced by the pole near the start like it's a piece of kebab chicken just about to fall off to the goddamn star AND red coin both hovering over the "handle" of the second blue lego swinging platform.
Something should be done now, I'm sure of it. The randomizing algorithm needs to be reworked. I also wonder what it would cost to change the seed for a 32-bit value.
I think that just because one of the courses have almost the same layout in other seeds,the hack itself shouldn't necessary be reworked!
Um... Actually, yes. It should be fixed. The point of randomization is that the player can't know beforehand where everything is and I only had to see the layout of two "platforms" of RR to realize that the layout was probably identical and therefore, where everything else is without having to discover it again. Defeats the purpose of randomization if you ask me. Also, the problem that the number of possible layouts is so limited (now that we know it to be far less than 2^16) means that a lot of the stars, coins, etc. will never be found in specific locations.
F*** it ! Go straight to a 64-bit seed and 64-bit RNG and stuff... give it a good reason for the console to be 64-bit capable !
Well guess what... guess what happened just today !
Seed 15394: Vanish cap -> BOB -> aquarium -> DDD Seed 42725: Vanish cap -> Snowman -> metal cap -> Wing mario -> RR -> BitDW -> DDD
Not everything is laid out exactly the same but chests 2, 3 and 4 all have the exact same position and rotation. No doubt this is not as egregious as the event that drove me to start this thread but it does demonstrate this is a recurring problem.
I've formulated quite a few hypotheses about how Arthurtilly might have designed his RNG and the layout algorithm that goes along with it. I do think that part of the problem comes from using a 16-bit RNG state (probably what is being used right now given that the seed itself is 16 bits long): because every RNG basically works like an LFSR insofar as it is producing a deterministic sequence of 16-bit values that can AT MOST be as long as 2^16-1, a value "A" produced by the RNG is ALWAYS followed by value"B" which is always followed by value "C" and so on until it wraps around (65535 values later). In this case, if I decide that the position coordinates of a object are to be determined with a 16 bits precision, I need to pump three values out of the RNG to fill all three coordinates X, Y and Z. Thus, I have to pump them out sequentially which means if coordinate X = "A", then Y NECESSARILY is going to = "B" and Z = "C". The problem further compounds with the need to randomize the rotation as well but especially when most of the coordinates have to be rejected because it would put the object out of bounds, above the void, lava or at an otherwise unreachable location... it doesn't leave all that many positions available ESPECIALLY in hollowed out levels like both lava levels and... you already thought of it... Rainbow Ride !
If however the RNG state is 64 bits wide, one value pumped out of that RNG can be split in three INDEPENDENT and UNCORRELATED 16-bit values for the location coordinates of an object and do what you want with the remaining 16-bit; use it to define the rotation or whatever else there is to randomize. Not only would that make the amount of possible locations grow to something like 2^64 = 18446744073709551616 by making X mutually independent from Y, Z and the rotation, it would likely IMPROVE performance because N64 processors are 64-bit anyway and you would only have to produce one randomized value for each object placement attempt instead of 3 or 4 if you count the rotation.
Anyway, food for thoughts... AND Arthur !
