As far as I know, the only way to rollback your game version is to either already have a backup of an older version or pirate an older version. The option to rollback doesn't seem to be available for this game on Steam. Correct me if I'm wrong.

I'll have to test this out later

Noted, and added.

It's been a while since I really played this game, but I recalled that 100% would require all of the quests, p-crystals, and completing the cabin. Maybe the Air Robo GP races could be included, but it still hasn't been decided.

If you have any suggestions for 100%, let me know.

Yes, even if you use a program like dxwnd to force the game to run in a window, it'll still be in it's native resolution.

So I've been doing some more reverse engineering to the game and I think I made some discoveries about the RNG for the game.

The RNG seed is a 4-byte global variable (I'm excluding its location in memory to prevent people from hacking it to cheat). This number, assuming that it's an unsigned integer, has a range of 0 to 4,294,967,295 inclusive. How the seed is determined is still uncertain, but one aspect of the function is known.

It's already known that the RNG is determined by the Windows kernal, but what in the kernal was unknown until now. After poking around the assembled code in RAM I found a several pointers to a function in a Windows .dll file with a name close to "get_tick_count" (I forgot to note the actual name of the function and the .dll file for this explanation). As the name suggests, the function returns how many "ticks" (it's either the amount of frames or cpu cycles since Windows has been booted, I couldn't find out which one it was but I assume it's the frame count). I know this is used in determining RNG because there's several instructions after this function is called that ultimately puts the new seed into the RNG seed address. Trying to find out what these instructions do is going to be a nightmare as there are over 100 instructions (I'm not too familiar with x86, my background is in ARM) and several instructions jump to other parts of RAM so keeping track of what does what is going to be difficult.

However, I can say this with 100% certainty. Manipulating RNG will NEVER be possible without the use of hacks. Even if you do the exact same inputs, like a TAS, on 2 different playthroughs, they will desync as the RNG will start on and change to different values. The only way one can manipulate RNG is if they start the game on an exact frame since they booted Windows and make no mistakes in their run. Good luck with that.

If I or anyone else discovers more information, I will make more posts in this thread.

tl;dr RNG cannot be manipulated because it's determined by how long your PC has been on for.

From my research, sticky keys CAN work in windowed mode, but it's not as consistent as full screen mode.

The main factor in getting sticky keys to work is most likely RAM. I have 16 gigs of RAM in my laptop and the only time I find sticky keys not working is when I have a bunch of Chrome tabs open for a long period of time. So what I think happens is that the glitch utilizes your RAM's cache, and when there's not a whole lot of it (or possibly your RAM speed is too low) it takes no advantage of it. This could explain why my only working fix is to reboot your computer as it properly clears your cache of any memory leaks and junk not being used.

Okay, so I've looked at the code for the door in the looping room and basically found this. The notes in the looping room are unnecessary, it only checks if you examined the door 3 times. The door's code works like this: -If the player presses "E"

Show the "locked" text Move door1_wait_trig to (0, 0) (this object is actually not present in this room, this may be a copy/paste mistake) Add 1 to the door's state variable (how many times you examined the door) If the state is 3, move the door trigger to its initial position (unneeded due to the copy/paste error) and change to a real door in 2 seconds Else, move the door trigger to its initial position (also unneeded) in 2 seconds

In a nutshell, the looping room does not have a glitch but an oversight from the developers.

(Very long post incoming. tl;dr will be at the end.)

This is in response to the guide by @Wolfii that attempts to explain this glitch. His guide can be found here: https://www.speedrun.com/sjsm/guide/n955g

If you don't know what this glitch is, you can watch my video on it below.

As of September 9, 2018, his explanation is only partially correct. The glitch can be triggered by interacting with a locked door then obtaining the key for said locked door. What causes it, however, is rather complex, but I think I found the reason. It's not what Wolfii describes in his guide.

Let's start with the objects that spawn when the gel room loads for the first time. The two main objects responsible are the locked door trigger (door1_wait_trig) and the note about Specimen 1 (note_sp1_obj).

The door1_wait_trig object has two events (Game Maker's version of functions); an Alarm (an event that can only be activated after a specified amount of frames) with an index of 0 (will be referred to as "Alarm 0" from here on), and a collision event for when the player touches the trigger. Alarm 0 returns door1_wait_trig to it's spawn point. The collision event goes like this: -If the player pressed "E"

Show the text that tells the player to look around the room Move door1_wait_trig to (0, 0) (basically far outside of the room to not retrigger the text) In 120 frames (~2 seconds), execute Alarm 0

The note_sp1_obj object has three events, but only two are necessary for this explanation. It uses a create event and a collision event for the player. The create event scales the note object by 1.5 and sets the variable "do_var" to 0. The collision event is similar to the fake door, but it's a little different. -If the player pressed "E", and do_var is 0

Move note_sp1_obj to (0, 0) Create the paper that the player sees on the screen Create the object sp1_text (the words on the paper) Set do_var to 1 (this is done to prevent the player from re-picking up the note

The glitch now begins with the sp1_text object. There are only two events in sp1_text; destroy, and draw. Destroy does the following:

Create gel_obj (Specimen 1) Change door1_wait_trig into door1_trig (the real door trigger) Draw just displays the text for Specimen 1.

This is only a theory, but I think the glitch is caused when door1_wait_trig gets changed into door1_trig. The door1_trig object also has an Alarm 0 event. This event is the one that sends the player to the next room. Basically, reading the note within 2 seconds of interacting with the fake door causes the real door to mistakenly execute its Alarm 0 once the 2 seconds are up.

If I find anything new, I will update this post at a later point.

tl;dr The locked door has a function with the same name as a function of the real door and it gets executed after picking up the note, all within 2 seconds.

EDIT: The version of this glitch in the looping room is actually not a glitch but an oversight by the developers. As my second post says, the door in this room doesn't check the notes you pick up, but rather checks how many times you examined the door. If you examine the door 4 times, it will always open (when I tested it, at least).

@Wolfii I wouldn't mind being a mod, but seeing as the last post in this thread was about 20 days ago probably shows how inactive I can be too :\

Edit: Looks like I'm a mod now lol

The problem with sticky keys is that it's inconsistent. Sometimes it works and sometimes it doesn't, the cause of it is practically unknown, there's no clear way to fix it, and now this.

Basically, sticky keys just speeds up the game by a lot because the window was switched without pausing, and Specimen 9 kills you if you go afk for a while. Other than that, there was nothing in the source code that I could find that would relate to this.

I vote for @starsmiley to be a mod, they seem to be very active in this community and knows way more about the game than me, and I reverse engineered the game.

I'm against this as the patched file wasn't meant for the English version. It doesn't feel right.

If Kouri allows them, then they are official in my opinion. The question is which version is faster?

I already made a guide that rules out the Japanese version here https://www.speedrun.com/ib/guide/id4u9 If the other versions have the same changes as vgperson's English patch, then I would assume that Chinese would be the fastest.

I've gone back to looking into this and while I haven't found anything conclusive I can give some suggestions.

Try running in fullscreen when possible, I always run fullscreen and have constant success with it.

Restart your computer to clear up RAM, I do this because the game will run incredibly slow when too much RAM is used.

Upgrade your CPU if you can. I'm not certain about this, but the glitch might not be possible on CPU's with low core/thread count or slow clock speeds. Can't 100% confirm this.

I remember seeing a Together Forever run back in like 2012 or 2013, at the time it was the fastest ending.

If you're running the Steam version, you need to turn of Steam cloud to prevent Steam from automatically restoring your saves.

I only run Windows 10 and have consistent success with the glitch, so I can't attest to Windows 8 and below or Mac.

My only other suggestion would be to try timing it differently. I usually launch sticky keys about 1 or 2 seconds after a cutscene begins.

The difficulty is the same as US Normal as far as I know.

What I do is that once the window is open I press the right arrow key to select the cancel option and hit enter.

Shift x5 -> Right -> Enter.