So I was going to just message RHS and ask him about this at first, then ultimately decided, YOU KNOW WHAT? I want to try to do this on my own... (I'm an admitted ASM noob, so while this sounds like a very simple fix to you, it feels like a great accomplishment to me. Looking back, I even realize how simple it is... but I don't give a damn. I still feel proud. Baby steps...) So, today, in my first ever KoH hacking guide, I'm going to show you how to stop objects from freezing when you die! I saw this in the new Sonic CD re-release (If you haven't bought it yet, go get it you freeloaders... its well worth it!) and thought... hmm, you know, that just looks so much better than when EVERYTHING just STOPS. Let's do that! To do this for Sonic 2, and I AM using the SVN/HG/Mercurial disassembly, search for RunObjects: You will see this. Code (Text): ; ------------------------------------------------------------------------------- ; This runs the code of all the objects that are in Object_RAM ; ------------------------------------------------------------------------------- ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| ; sub_15F9C: ObjectsLoad: RunObjects: tst.b (Teleport_flag).w bne.s RunObjects_End ; rts lea (Object_RAM).w,a0 ; a0=object moveq #(Dynamic_Object_RAM_End-Object_RAM)/object_size-1,d7 ; run the first $80 objects out of levels moveq #0,d0 cmpi.b #GameModeID_Demo,(Game_Mode).w ; demo mode? beq.s + ; if in a level in a demo, branch cmpi.b #GameModeID_Level,(Game_Mode).w ; regular level mode? bne.s RunObject ; if not in a level, branch to RunObject + move.w #(LevelOnly_Object_RAM_End-Object_RAM)/object_size-1,d7 ; run the first $90 objects in levels tst.w (Two_player_mode).w ; Are we in 2P Competition mode? <-COMMENT OR DELETE bne.s RunObject ; If yes, branch to RunObject <-COMMENT OR DELETE cmpi.b #6,(MainCharacter+routine).w ; If no, then we are in 1P mode. Now, is your main character dead? <-COMMENT OR DELETE bhs.s RunObjectsWhenPlayerIsDead ; if yes, branch <-COMMENT OR DELETE NOTE: I added the extra comments at the end of a couple lines, so you won't see those. Now. What I want you to do, is go ahead and comment out the last 4 lines. What those do, is they check what mode you are running. (1P or 2P). If running 2P, it branches to the routine JUST BELOW IT. if we are running 1P, it checks if the player's status is 6 (AKA dead). That leads to a branch to the routine we are getting rid of, so obviously we need to axe it. But why the one above? Well, you will receive an error since it's jumping to the next active line just below it. In other words, you don't need to branch anymore. The only purpose of the branch was that the object freeze function only happened in 1P mode, and not 2P mode, you see? Anyway... now I want you to go to RunObjectsWhenPlayerIsDead. It's just below RunObjects... just scroll down a few lines, its very close. Now, go ahead and get rid of (preferably comment) it. Now build and run, and go kill yourself. Tada. PS Sorry for the over-excitement... again, this is my first time doing an ASM fix on my own... and it actually working. (Unless you count me fixing my Sonic 1 to always give 50,000 pts for an extra life... but that was an easy change to remove a revision check so that doesn't really count, I don't think... or maybe it does.) I've looked, and am BACK! With an equivalent fix for Sonic 1 (SVN disassembly) Go to ExecuteObjects:. You will find this: Code (Text): ExecuteObjects: ; XREF: GM_Title; et al lea (v_objspace).w,a0 ; set address for object RAM moveq #$7F,d7 moveq #0,d0 cmpi.b #6,(v_player+obRoutine).w ;<- COMMENT/REMOVE THIS LINE bhs.s loc_D362 ;<- COMMENT/REMOVE THIS LINE The lines I am asking you to remove branch to S1's equivalent of RunObjectsWhenPlayerIsDead, IF the player has died. Now, go to "loc_D362", and just as before, comment it out. Build and run, and go run into a few more spikes to test it out. This is my first ever guide, so if there are any errors, please lemme know, and if you can, please help me fix them. Much thanks!
Double Post. I found an error with this. Nothing serious, actually minor. In Sonic 2 Metropolis Zone, die near a floating platform. The platform, if it normally moves, will no longer move when you die. If anyone can help with this, would be grand. EDIT: This also happens when crushed by the solid platforms in Aquatic Ruins Zone.
Perhaps someone might be able to fix up this game-stopping glitch which sometimes happens when destroying this boss: http://www.youtube.com/watch?v=HDb4oGAnL1s&feature=related
Not a bug. Almost all objects freeze when you die (except Sonic/Tails, HUD, Game over, etc) A very similar bug occurs in the ARZ boss. Been meaning to look into the ARZ boss bug, but never noticed it here. May look at the weekend and see if I can come up with anything. Do you mean me or... eh?
I understand that... but my guide is supposed to prevent these objects from freezing, opting to go in the Sonic CD 2011 route. BUT, I was pointing out that while my fix works, it still doesn't work on certain platforms. I wanna know... why does it still not work on these objects, if I removed the routine? It happens in Sonic 1 and 2 REV C. I think I implemented the change in the build I sent you... go to some kind of platform that moves (MZ platforms in lava, GHZ tall platforms, MZ floating blocks, etc.) There are still plenty of moving objects that keep freezing. So... in the context of what I'm trying to do, it IS indeed a bug... do I need to go directly into object code to fix this? I think flamewing took care of at least the ARZ boss... if its the same bug as the one you are thinking of. If so, I recall seeing him also post the fix somewhere in the thread. It was a while back though, early/mid 2011 IIRC. I could be completely mistaken about it being the correct bug you are referring to though, but its worth checking out. If I can find it, I'll quote it and come back. I didn't need to comment on this, but since I did for the last two already, what the hell... We all mean you! Again, it's about god damned time! Congrats!
I beg your pardon, I should have noticed you were relating to that. Okay, here is the fix (SVN disassembly as that is what you're using). Go to "OscillateNumDo:" and you'll see: Code (ASM): OscillateNumDo: tst.w (Two_player_mode).w bne.s + cmpi.b #6,(MainCharacter+routine).w bhs.s OscillateNumDo_Return + Get rid of it. No longer needed. So you'll have: Code (ASM): OscillateNumDo: lea (Oscillating_Numbers).w,a1 lea (Osc_Data2).l,a2 move.w (a1)+,d3 moveq #bytesToLcnt(Osc_Data2_End-Osc_Data2),d1 ; etc... Just making sure! Thanks to you both =P
I just tried this and noticed something was still a little off. The stars scroll at different rates for both screens. After a little tinkering I seem to have found the real source of the bug. The bottom screen's scrolling starts at the wrong line! Let's look at the original code: Code (ASM): SwScrl_CNZ_2P: (...) lea (Horiz_Scroll_Buf+$1B0).w,a1 move.w (Camera_BG_Y_pos_P2).w,d1 moveq #0,d0 move.w (Camera_X_pos_P2).w,d0 move.w #bytesToLcnt($1D0),d2 lea (byte_D270+1).l,a3 At the very first line we assume the bottom screen to start at line 108, even though it doesn't start until 112. So, what we do, is change the $1B0 to $1C0, or 112*2*2 (112 for the bottom half of the screen, *2 because each horizontal offset is a word long and again *2 for both FG and BG). Next, we change the second to last line to use $1C0, as well, since we'd otherwise set the loop counter too long. Finally, in the last line, we change the +1 to +2, since we want to use the same data, as the top screen. This should leave us with this: Code (ASM): lea (Horiz_Scroll_Buf+112*2*2).w,a1 move.w (Camera_BG_Y_pos_P2).w,d1 moveq #0,d0 move.w (Camera_X_pos_P2).w,d0 move.w #bytesToLcnt(112*2*2),d2 lea (byte_D270+2).l,a3
Okay, here's another short tip. You know them yellow springs in MTZ? There's a bug with them. If you roll on the floor, then jump from rolling into the yellow springs, you cannot control Sonic. And you could get stuck at the top of the springs indefinatly jumping side-to-side if didn't jump so high. To fix it, very easy, go to "loc_27104:" and just add this "bclr #4,status(a1)" so you have: Code (ASM): loc_27104: bclr #4,status(a1) bclr #5,status(a0) bclr #6,status(a0) bclr #5,status(a1) move.w #$CC,d0 jmp (PlaySound).l
This fix causes a bug with 2P mode, where Tails cannot run on the spiral. to fix this, change the code to this: Code (ASM): Obj06_Spiral: lea (MainCharacter).w,a1 ; a1=character moveq #p1_standing_bit,d6 bsr.s + lea (Sidekick).w,a1 ; a1=character addq.b #1,d6 tst.w (Two_player_mode).w ; is it two player mode? bne.s + ; if so, branch to + to skip this code and prevent a bug cmpi.w #4,(Tails_CPU_routine).w bgt.s + rts + This adds a check for 2 player mode, and if you are playing 2 player mode, the last part that flamewing added will be skipped, thus preventing the bug and allowing Tails to run on the spiral.
RHS, have you considered writing tutorials, in your awesome style, on how to fix the "Super Sonic bug" at the end of levels for completeness sake for both the SVN and XenoWhirl disassembles? :D
Not really. There's already Super Sonic fixes here. I'm sure it won't be hard to get it to work with both disassemblies.
I can second this. The fixes work fine for both disassemblies. If I get any time, I could put some notes for both disassemblies, but there are not many differences to be had.
I'm double posting as I have a question about a bug reported early on in the Sonic Classic Heroes thread regarding the MCZ vines. Apparantly there is a bug regarding 2P Tails and jumping off of the vine, in that it doesn't work... or something? I've never encountered this bug... or at least, I don't think I have... and I sure as shit don't really understand it. The bug in question is reported on this post: Flamewing's response to OP about bug I'll just repost what was said for those who don't feel like looking back... flamewing: It is indeed a but inherited from the Sonic 2 code. Basically, they checked the real controller input for Sonic and 1p Tails, and the logical controller input for 2p Tails. The problem was that the vine sets object control flag, hence the logical controller never gets set to the real input. I fixed it by reading the real input for human players and the logical input for CPU players. Now, my question is... what bug is this? Unless I unknowingly fixed this already, I don't recall seeing this bug in my disassembly or in the original. Can someone help me point this out? Unless this bug in question is CPU Tails not being able to jump off the vine on his own... then I noticed that. My understanding was that apparantly 2P Tails couldn't jump off... which I don't believe is true.
All I could find is that if you're in the main game and have Tails following you, when Tails jumps on the vine, he will never jump off. ALTHOUGH, you can make Tails jump off yourself if you make him jump with controller 2. There's also a bug with both characters as player 1 or 2, CPU controlled or not, with both vines, that if you were rolling then jump from the roll onto the vine, you could only jump off downwards (it's rare to jump off to the side but if you do, you hardly jump far). If you were not holding a directional button when jumping downwards, you'd land back on the vine, so this could be a pain. So, I can show you how to fix both of these bugs. Code (Text): ; ---------------------------------------------------------------------------- ; Object 7F - Vine switch that you hang off in MCZ (Stationary) ; ---------------------------------------------------------------------------- Go to "loc_2981E:" (Obj7F_Main and change: Code (ASM): move.w (Ctrl_2).w,d0 to Code (ASM): move.w (Ctrl_2_Held_Logical).w,d0 ; Let CPU jump off as well This will make Tails as the CPU jump off the stationary vine when you do. You can still make Tails jump off with Controller 2. Then go to loc_2983C: (Obj7F_Action and just above: Code (ASM): clr.b obj_control(a1) add this line: Code (ASM): bclr #4,status(a1) ; Clear the character's roll-jump flag Now if you did roll-jump onto the vine, you can now jump off to the left or right. Next: Code (Text): ; ---------------------------------------------------------------------------- ; Object 80 - Vine that you hang off and it moves down from MCZ ; ---------------------------------------------------------------------------- Go to "loc_29AAE:" and change: Code (ASM): move.w (Ctrl_2).w,d0 to Code (ASM): move.w (Ctrl_2_Held_Logical).w,d0 ; Let CPU jump off as well This will make Tails as the CPU jump off the vine (the vine that moves down) when you do. You can still make Tails jump off with Controller 2. Then go to loc_29ACC: (Obj80_Action and just above: Code (ASM): clr.b obj_control(a1) add this line: Code (ASM): bclr #4,status(a1) ; Clear the character's roll-jump flag Now if you did roll-jump onto the vine, you can now jump off to the left or right. See that text in the red? This brings an annoying bug that when the vine moves down, Tails will try to jump off (CPU controlled Tails) when the vine moves down. If you do not hold a directional button as Sonic, Tails will just jump and land back on. If you are holding a directional button as Sonic, Tails will more than likely jump off. When the vine stops, Tails won't jump until you do. If you do not want this bug, then don't change the "Ctrl_2" in the red. But then you get the bug that Tails will never jump off. So it's entirely up to you which bug you want. This choice is only for the vine that moves down, this does not concern the stationary vine, so you can still change the "Ctrl_2" safely for the stationary vine. Hope this fixes your problem. If this doesn't and the bug in question still exists, I have no idea.
That does fix the problem that they were probably referring to, though now I wonder how to fix that other bug with Tails jumping when he shouldn't. Setting it to follow "logical" is what makes Tails follow Sonic, correct? So... perhaps Tails is jumping because Sonic is moving downward, and this is somehow telling Tails to jump for some reason... Unless I'm mistaken, Tails exhibits similar behavior almost any time Sonic is moving due to another object, such as a platform or the like... (Prime examples being Tails walking off of faster moving platforms, such as the small platform in MCZ, the lift in HTZ, etc.) I believe that this "new bug" is caused by the same thing that causes Tails to act wonky in the other situations and is not a new bug at all. The code that makes Tails follow Sonic is to blame and needs to be fixed. I think this also exists in Sonic 3 as well but I'm not exactly sure. I can look in the Tails object to start but I think someone more experienced than myself could probably do a bit more... All this said, I'd say users should stick with your newest fix to these objects RHS, and then later add a fix for Tails' behavior later when one is found. and nice catch with the rolling jump bug. That's the second one with that, following the MTZ wall spring bugfix... I wonder what other objects have that same issue?
Yeah, Tails jumping off with the vine is similar to when you go down the lifts on CNZ. Tails jumps then. Go stand right next to any solid object (monitor, spings, spikes) and Tails will jump on the spot. In my Sonic 2 Recreation when the platform moves down in CAZ3, Tails jumps. It is to do with Sonic's movement. If I recall correctly, I think flamewing fixed this type of issue in his Classic Heroes.
Just wondering if there's a download available of the latest Sonic 2 (Xenowhirl or SVN, doesn't matter) source with all fixes applied thus far? Thanks.
Not to my knowledge. But why not just download the recent Xeno/SVN disassembly then apply these fixes yourself? It won't take you long. All the guides and fixes supplied are very decently clear that you should have no issues.
I might when I get some more time. But I have done the Super Sonic fixes and a few more with the latest Hg disassembly. Anyways what fixes for Sonic 2 would you consider the highest priority to fix? Oh, here's an interesting "bug" I encounter in Sonic 2 but I don't know if it's been mentioned yet. Beat the Metropolis Zone boss without destroying any of the balloon Robotniks (you can try avoiding the balloons and beating the boss as Super Sonic or cheating with debug mode to avoid the balloons) then press the egg prison with them bouncing towards you. They start to glitch out then they all disappear when one hits you and causes you to lose your rings.
