Very weird Carnival Night boss (S3&K) glitch

I thought debug finds didn't count

 

I've seen that video before, but never thought to post it.

They don't, in general. However, it's relevant to the topic, and it's pretty unusual to have the game load up a boss from the wrong zone. [emoticon]

 

It must mean that boss was there in the prototype before they made the current boss. They must have moved it to somewhere noone can go in the main game instead of removing it

 

Sorry, I did see that debugs weren't generally allowed; but it was only because debug could access a certain area, rather than making it occur directly through debug which I thought was a good motive for posting it.

It's interesting. Rather than the theory that this boss was originally for Hydrocity, I think perhaps it loads a wrong piece of data, due to the occurance in which it appears. It's up to te dismantlers to figure that out! :v: I am but a messenger.

 

This is indeed a very good find. And it's not the first time that a boss appears in the wrong place (I've been able to get MGZ2's boss in MGZ1 and EMZ), there might be a common factor...

 

That tends to happen more in Sonic 3 alone while using Debug Mode, mainly due to the fact that if you use the in-game reset, and you play a different level the game still thinks your in the level you exited. I actually never got this to happen in S3K...

 

Do you mean you encountered a boss in one of the 2P stages? That I'd like to see.

 

http://www.youtube.com/watch?v=NhE1RPiCjoM

Warnings:

• Uses debug mode
• I recorded this in 2006 so the quality isn't that great

 

Interestingly, I notice the debug coordinates shown in your video are identical to the ones in the CNZ1 boss. This means that the game has already entered the CNZ level event script.

Before I went to check the coordinates, I had thought it was loading the boss by pure fluke from random garbage data, and thus the reason for the reset after you beat it would be because the boss's death would increment the LES routine counter to something that doesn't exist. However, since the boss is actually being triggered by the LES itself, I would expect it to just load up CNZ2 (perhaps without some or all of its tiles, mappings and collisions data, but the palette, level layout, objects and music should be loaded) and think it was carrying on as normal from there.

On a bit of a tangent, supposing it did continue happily on rather than reset, the internal zone counter would probably still read HCZ2. So if you then hit a checkpoint and died, it would load HCZ2 back up again and take you to a nonsensical location based on the checkpoint's position a la Sonic 3 alone's level swapping glitch. Completing the act without dying would take you to MGZ1 instead.

 

Heh, it wasn't as impressive as I expected, as it didn't look like EMZ or any other level. :P

 

Remember that the CNZ mid-boss is special. When it is destroyed (according to the GoldS's glitch videos, the players are teleported to a new position before the end of act sign is spawned, so the level swapping probably haven't kicked in at the time of the crash.

 

Only Knuckles gets teleported. As his miniboss is in a different place to Sonic's, he gets teleported to Sonic's miniboss location when it's defeated so he starts Act 2 in the right place.

I think the CNZ miniboss is the only one to have constant vertical scrolling, and with the wild coding in S3K, I wouldn't be surprised if that had something to do with it.

 

If I recall correctly, the debug coords don't actually change at all during the boss - only afterwards, when the floor starts to scroll into view. During the boss, it just does a raster effect to scroll the background upwards.

 

But doesn't both Sonic and Knuckles start from the same coordinate for Act 2? Sure Knuckles is teleported to Sonic's area before the boss, but we are talking about what happens after the boss.

It may crash because the end of act sign hits the first floor tile offscreen. But it crashed so quickly, I dn't think so (the sign needs to stop spinning before the level swap occurs).

 

The game crashes because once the CNZ 1 miniboss is defeated, the object at $51FCE (more specifically the code inside it at $520AC) increments the level's TriggerEvents (as Stealth terms them) routine counter. (This object is what manages the auto-scroll in that boss btw). When this happens inside HCZ 2 the routine that's been incremented to doesn't actually exist so the game tries jumping to the middle of an instruction and crashes.

The bigger mystery is why that miniboss loads up in the first place. Something about the warp causes the object loading manager to go wacko and load it up, but I haven't been able to figure out exactly what's going on.

Edit: Okay, figured out exactly what's going on.

As the camera scrolls through the entire level, the objects which come into range keep getting loaded. However, since Sonic is technically dead (his routine counter doesn't get reset to normal until he comes out of debug mode), none of these objects' code actually gets run, meaning that none of these objects get deleted either. Obviously a point comes when the entire object RAM area gets filled with objects and no more can be loaded.

Now, the object loading manager keeps track of two addresses inside a level's object placement data when the camera is scrolling forward. The first is the address of the first object whose X position is >= the camera X position - $80, and I'll refer to this as pointer 1. The second is the address of the first object whose X position is >= the camera X position + $280, and I'll refer to this as pointer 2. In what I consider to be a bug in the object manager, once the object RAM area gets filled pointer 1 keeps getting updated as the camera scrolls forward even though pointer 2 doesn't. Eventually pointer 1 exceeds pointer 2, which is of course an anomaly.

When you come out of debug at the end, the object loading manager comes into play again - this time, however, it's because of the change in camera Y position instead of the change in camera X. The routine inside the object loading manager which loads objects when the Y position changes uses pointer 2 - pointer 1 as a loop counter. Normally this value is positive and the loop works normally. In this case, however, the value is negative and gets read as a large unsigned value, which causes the loop to go far beyond the end of HCZ 2's object placement. The loop eventually gets as far as CNZ 1's object placement, and it sees the miniboss is within rage so it loads it. So it's entirely coincidental that the CNZ miniboss gets loaded, but pretty cool nonetheless.

 

Shobiz, is there anything you DON'T know about this game? :v:

In all seriousness though, that's a brilliant explanation. It hadn't occurred to me that the object manager could screw up like that.