Is it not possible to put that outdoor section into Act 1? I understand what you mean about that outdoor section, I see it in SonLVL... but is it not possible to put this in the first act layout? Or is it not that easy?
I think he knew that, but was just jabbing me over the filter. :P It's okay, I like 'em. You can also see an odd effect if you climb the final section of Flying Battery 2 quickly enough, which is fairly easy to do with Super/Hyper Knuckles. It's a little less obvious with FBZ at night, but you see the sky color rising through the background.
Not sure if this was posted elsewhere already, but this just made me burst into tears. This game is truly at my core and is a significant part of who I am today.
I didn't see any such bugfix in the changelog... so I'm wondering, does anyone know of a game crashing bug involving the MGZ2 boss? I got a game crash where the boss starts to go up after drilling into the ground for the boss fight. I'm playing as Sonic alone, w/ Lightning Shield, and got about 6 to 7 hits on him before he was about to go up, and the game just up and reset. I can't seem to replicate this bug, nor have I EVER seen it before (in all the time I've ever played this since around 97). Tiddles, I'm curious if you've seen it before? I also didn't see it in Orkal or Razor Zenon's S3K bug videos. ALSO "Is it not possible to put that outdoor section into Act 1? I understand what you mean about that outdoor section, I see it in SonLVL... but is it not possible to put this in the first act layout? Or is it not that easy?" Re-asking this question just outta curiousity... ICZ Act 1 transition, I'm on about here.
Have you had this happen in S3C? It sounds like "Fixed possible Marble Garden 2 boss corruption after killing a Spiker with hyper dash," which was fixed back in 091230 - that's caused by Tails' dormant SST in Sonic Alone mode getting some bum data in it in those conditions, causing Tails to break things when he spawns. The fix just makes sure to clean out his object slot when he appears in that case, so it should cover any other causes of that scenario. The thing you have to remember is that Sonic 3 Complete tries its damnedest to be as stable as or more stable than the original, and that every significant change carries risk. In this case, redoing the chunk layout, object layout, transition, screen events and background events (don't forget both bosses visibly appear against Act 2's backgrounds) to possibly avoid a rare, non-game-breaking glitch isn't really compatible with that goal. On the plus side, it's much harder to reproduce with flamewing's improved Kosinski decompressor implemented anyway.
I only had it happen in a clean S3K... that said it wasn't caused by a hyper dash. I was regular Sonic alone with just an electric shield... that said, it may very well be fixed anyway...
I've definitely seen that bug, but I also have to say that I can't remember the last time I saw it while playing this version of the game. It is indeed quite difficult to trigger.
Not difficult when you're hyper. Though, I don't know what it's like with the decompressor being rewritten.
Which one are we talking about now? The decompressor is only relevant to Icecap (out of the discussions here). In case you're interested, here's a demo of the worst way I know of breaking it between the release build (first) and the current build (second).
Oh wow... I just now realized that Sodahlic was talking about something COMPLETELY different. (I think) MuteKi and I were referring to the MGZ boss thing...
Doesn't the snow on the ground slow you down? Maybe strategically putting something that you have to jump over, like those pillar things that go up and down?
Personally, I'm curious about how feasible it'd be to make the foreground part of Act 2 part of the same layout as Act 1 and just swap the background. Not asking that this be done as the current solution is good enough, but I was wondering if it's theoretically doable or if it'd take too much memory. Yeah, I was talking about the Ice Cap thing. I think it'd be best not to change the design in that way. With the video Tiddles posted, it's already a lot more stable, and the visual effect is much more subtle. And that was the worst way to break it, normally you don't even encounter it at all.
I need to bump the topic for bringing up something that I believe to be a bug. This bug exists in the last S3C release AND the original game. As Sonic or Tails, if you have a fire shield and are going at a horizontal speed of 4.5 or greater... you can bust through the wall simply by jumping into it. Mind you, I'm not talking about performing Sonic's fire blast technique, I mean simply jumping into the wall fast enough when having the fire shield, as either Sonic or Tails. This doesn't happen with Sonic or Tails with any other shield, or invincibility, or when they are shieldless... in fact, the only other time they could bust through walls by jumping into them is when in Super form. I believe this is not the intended thing to happen, and is due to an oversight in the Breakable Wall's coding: (Relabeled code but otherwise identical to vanilla S3K) Code (Text): tst.b (Super_Sonic_Knux_flag).w ; is character in his Super/Hyper form? bne.s BreakWall_Break ; if yes, branch cmpi.b #id_Knux,character_id(a1) ; is Player 1 playing as Knuckles? beq.s BreakWall_Break ; if yes, branch btst #4,status_secondary(a1) ; does the character have a Flame Shield? bne.s BreakWall_ChkRoll ; if yes, branch btst #5,status(a0) ; is character pushing against the wall? beq.s BreakWall_ChkP2 ; if not, branch BreakWall_ChkRoll: ;loc_215E0: cmpi.b #2,anim(a1) ; is character rolling? bne.s BreakWall_ChkP2 ; if not, branch move.w d1,d0 bpl.s BreakWall_ChkSpeed neg.w d0 ; get absolute value of Player 1's horizontal speed BreakWall_ChkSpeed: ;loc_215EE: cmpi.w #$480,d0 ; is character's speed $480 or higher? bcs.s BreakWall_ChkP2 ; if not, branch BreakWall_Break: ;loc_215F4: It checks for the flame shield... for what I believe the reason is that you can perform that flame dash move, and use it to break walls easily while in the air... as Sonic. From then it branches to where it simply checks if the player's animation is the rolling animation... which is usually reached to check if the player is on the ground spinning into the wall. However... this now allows Sonic or Tails to do a basic jump into the wall, busting it in midair as if they were Knuckles. That isn't right!!! I believe to fix this, the flame shield check needs to branch to a new block of code that checks the shield object's animation byte to see if it is in the dash animation. What do you guys think? Bug? Oversight? Leave this anomaly as it is???
Good spot, and it's nice to have the answer laid out for you too. I swapped the order of the push/fire shield checks and added a check for character_id and double_jump_flag, and that seems to make it behave as you'd expect - although note that a similar breakable wall object also has to be changed at loc_1FD72.
I had encountered the fire shield thing when TASing and when porting it to my hack; I disagree about it being a bug, though: the code seems to indicate that this is an additonal power granted by the fire shield, like being Super Sonic.
Yeah, there's nothing in the code that clearly indicates it's a bug. Still, you could say that of various behaviour that arguably becomes more logical in the presence of additional checks; the closest thing I can liken it to is projectile deflection based on double jump state, which I'm convinced was meant for the instashield, but actually doesn't work for it and causes different effects for Tails and Knuckles (which I compromised on since they're relatively well known and used, though I tried to at least have Tails' flight deflection make more sense). This, I think, isn't as well known, and feels contrary to expectations, but I'll keep in mind any feedback given here.
