QuébecIs everyone unable to find the fifth boo in 25529 or is it just me ? It's the first time it happened to me. Go to BOB which leads to JRB which leads to BBH.
One on each roofs (mansion and 'shed'), one in basement's shallow waters and one 'guarding' the blue coins switch... where's the other one ?!?
FML, seriously -_-
Here's seed 14527 for you: https://imgur.com/hBPP3Mx
Discovered only AFTER collecting 110 stars >.<
I'm pissed ! See attached ! https://imgur.com/8t6kXEE https://imgur.com/PTZROCc That goddamn star is behind the 'seemless' loading portal. The first time ever and it happened during one of my best performances EVER !
And guess what happened mere SECONDS after I stopped the timer !!! I started messing around with a savestate and after crossing quickly the loading boundary back and forth... https://imgur.com/oqbY2CK https://imgur.com/wXXp44U RESHUFFLING HAPPENED AND THE STAR WAS NOW ACCESSIBLE ! I COULD'VE SAVED IT ! I'M DOUBLY PISSED ! I don't know how to reproduce it. Is it still considered possible because of reshuffling ?
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 !
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.
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 !
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 got screwed by a seed (35593) a couple of days ago in a particularly original and surprising way: https://imgur.com/dXnsUSb https://imgur.com/Zt5dfF2
There is a red coin in the "cage thingy" in the corner opposite to the entrance tunnel. I though I could use the vanish cap that I activated earlier until I realized that both vanish cap blocks were well below the height of the lowest water level switch !
This is for 0.5.1 btw.
I'm not sure I understand what you mean by "registrations" but in any case, [Update] I'm no longer mad because I'm on absolute FIRE: Not even 12 hours after this incident described in my original post I succeeded in beating my own unrecorded record by a couple of minutes. And this time, I have a full video of it being processed right now on YT :))))))))))))
There is no indication that the risk of recording issues killing a run went away but let me tell you, I AM LOOKING VERY OFTEN AT THAT RECORDING ICON. Anyway, I will submit my run now.
What do you mean by "most of the time" ? What happens exactly when it doesn't work "perfectly fine" ?
Also, you realize I can just say the very same thing about Radeon ReLive ? (I didn't use it in many contexts tho)
Because of my absolutely dismal luck with video games and games in general (case in point -> the reason for this fucking thread), I want and probably need a solution that only a power outage (or a BSoD) can fk up.
Here I want to discuss solutions so that this sh** doesn't happen again and I'd like to have some advice:
I was using Radeon ReLive because it was convenient and the performance was great. This one, however... FUCKED ME !!! AFTER JUST 1 1/2 MINUTE OF RECORDING WITHOUT NOTICE. Now I've beaten my PB by a solid 8 minutes but have no evidence of it. I would have passed hunterico just above me in the leaderboard if I did.
So... What are you guys using that does and DOESN'T stop recording for no reason ?
Would it be a problem to use two recording software simultaneously and hope they DON'T SIMULTANEOUSLY FAIL IN THE SAME RUN !? Also, what is the minimum resolution and video quality acceptable for this leaderboard ? I intend to put the backup recording software on minimum settings if I go for this solution.
Thank you all, I'll remember that from now on. Edit: it's already there :)
All in the title. I've been waiting for over 48 hours for my submission to appear on the leaderboard and I've received no news about it.
The first time it took... I don't even know, an hour ? ... for my first submission to get rejected (Youtube upload issues and bull****). I submitted late at night and woke up with an anouncement that it was rejected in the early morning.
But my second time with which I made sure my video upload was successful appears to have been completely ignored so far. In the light of how quick I received the rejection on the first submission, no response in 52+ hours looks abnormal.
I don't think it does since the discord server listed TTC as one of the levels for which OOB stuff was fixed. "- Fixed various OoB spawns in WDW, TTC, and Tippy."
I don't have the time to try it this week, month or even year for now... I'm very busy but I will try it once I find the time.
That's nice but the rules state "Beta versions of the randomizer (e.g. beta testers on discord or otherwise) are not permitted. Only official releases are allowed."
Is v0.51 considered an official release yet ? Seems to me that if it's supposed to be a release (that IS ready), there should be some announcement or update somewhere and Speedrun.com should have the v0.51 option available in their dropdown menu.
So there is an upcoming version ?! I'm curious what changes will be introduced. Are you sure Arthur will fix this ? Can you please pass the message in case he isn't aware of how much of an unbearable time-wasting record-ruining issue the OOB reds/stars in TTC are ?
When should I expect a v0.51 or v0.6 ?
Even if it goes against the officially written rules ? I would very much like to make my future runs with Project 64 v2.x as the joystick reading is much better (I don't need some calibration trickery to make Mario run full speed in diagonal directions).
In the 'rules' pop-up, it says "Additional 120 / 70 star rules apply." at the end which I interpreted to mean that the rules applying to the original game 120 / 70 star runs but are NOT SPECIFIC to 120 / 70 star runs also apply and in those it says all Project64 versions are forbidden except 1.6.
So... If I post a run with Project64 v2.3 to the leaderboard, do I run the risk of getting screwed or do I have your word that my run will not get yeeted !?
Come on, Arthur. You must've seen this. I can see infos on your profile saying that you were last online only one day ago and you only moderate two games (both ROM hacks)...
Question to any mod.: I want to know how a newer version of this ROM hack gets "recognized" as valid and within the rules to make it into the leaderboard. Is it just de facto consensus between mods ? Do we absolutely need Arthur's input in this ? If I have to make that change myself, can I get the change to be adopted by speedrun.com and if yes, what do I need ?
