The Caterkiller extra frame fix.

Probably stupid, but what bug do you mean? I never heard about any bug releated to the caterkiller before.

 

Selbi: if you roll into a caterkiller at a high enough speed (e.g. after a spin dash, but it's possible to do this also in plain Sonic 1), you will kill it like you're supposed to, but it will harm you as well because the spiked portions of its body have one frame available to harm you.
Stealth fixed this in KiS1, not sure if other hacks ever had this fixed.

 

Ah, got it. Well, found a fix, but it's by a great chance not the best way to do it, it works though:

Go to "Obj78_BodySeg1" and put this right after the label:

Code (ASM):

1.         tst.b   ($FFFFFFD9).w       ; is flag set?
2.         beq.s   Obj78_BodySeg1_Cont ; if not, branch
3.         move.b  #0,$20(a0)      ; set collision flag to "nothing"
4.  
5. Obj78_BodySeg1_Cont:

Then go to "Touch_ChkValue" and put this after the first move command:

Code (ASM):

1.         cmpi.b  #$B,d1          ; is touch response $B (a couple of badniks, including caterkiller)
2.         bne.s   Touch_NotB      ; if not, branch
3.         move.b  #1,($FFFFFFD9).w    ; set flag to destroy caterkiller
4.  
5. Touch_NotB:

And now, to make that flag cleared again, simply go to "Obj78_Delete" and put this at the very beginning:

Code (ASM):

1.         clr.b   ($FFFFFFD9).w   ; clear flag again

You will probably have to throw a couple more fixes into it though, but I hope this works for now.

 

I find this Caterkiller bug particularly annoying, too, especially in the low corridors of MZ where rolling is your only good choice.

I don't know much about the vagaries of the FindFreeObj routine in Sonic 1, but I get the sense that there might be some situations in which the body segments have an earlier slot in the OST than the head, making Selbi's fix (if I'm interpreting it correctly) not quite ideal (though I admit it wouldn't fail that often). I have to deal with this type of thing all the time when working with object collisions in GM - the order is important.

So I took a crack at it. In the SVN disasm, find this in "_incObj\sub ReactToItem.asm":

Code (ASM):

1.  
2. React_Caterkiller:
3.         bset    #7,obStatus(a1)
4.  

...or in the Hivebrain disasm, find this:

Code (ASM):

1.  
2. loc_1AFDA:              ; XREF: Touch_CatKiller
3.         bset    #7,$22(a1)
4.  

And put this between the two lines:

Code (ASM):

1.  
2.         move.b  #1,d0
3.         move.w  obInertia(a0),d1
4.         bmi.s   @skip
5.         move.b  #0,d0
6.     @skip:
7.         move.b  obStatus(a1),d1
8.         andi.b  #1,d1
9.         cmp.b   d0,d1           ;is Sonic moving in the direction the Caterkiller is facing?
10.         bne.s   @skip2          ;if not, move on
11.         btst    #1,obStatus(a0)     ;is Sonic in the air?
12.         bne.s   @skip2          ;if so, move on
13.         btst    #2,obStatus(a0)     ;is Sonic spinning?
14.         beq.s   @skip2          ;if not, move on
15.         moveq   #-1,d0          ;don't get hit
16.         rts            
17.        
18.     @skip2:
19.  

The general idea is to exit if Sonic is moving in the opposite direction than the Caterkiller is facing, while on the ground and rolled up. I tested this and it worked, and seemed to affect nothing else.

I'm still really hamfisted when it comes to asm, so I assume there may be ways to squeeze the code a little tighter, too.

(I also wonder what Stealth's fix was...)

 

Surprised that you're using the SVN version Mercury, considering that barely anyone uses it and prefers to use the older ones.

 

I never really considered this a bug. If you roll at a robot that consists of a chain of interconnected spike balls, just because you "kill the head", doesn't mean the rest of the segments are rendered harmless. If anything, this is a badnik design I've always thought was great to fight because it uses Sonic's speed against him If you want to defeat it, you need to control your velocity lest you make the kill but plough on through into the deadly debris.

If you want to fix it, that's great but Sonic players seem to be becoming more and more accustomed to sleepwalking through combat, what with the normalisation of the homing attack even in 2D segments in the modern games. I've said this before, but to me this amounts to nothing more than press B to kill, which is even worse than hold right to win in my book.

I like to fight my enemies, not just plough straight through them.

 

The Werehog was made with you in mind.

 

If that's the case it missed it's target demographic quite spectacularly.

 

Really? I thought you liked to fight my enemies, not just plough straight through them, and the Werehog allows you to do just that.

 

I think this is starting to stray outside the topic of the thread, but I'll humour you anyway. "Fighting enemies" rather than "ploughing through them" in a 2D platformer like Sonic means enemies which take agility, timing or precise jumps to kill. I just think it is more interesting to bounce off a crawl, then manoeuvre behind him and kill him, than to say, ball up and plough through a row of crabmeats, chameleons or chomps which offer no resistance at all unless you are stupid enough to run straight into them defencelessly. Adding a homing attack so you are simply required tap a button whilst near to automatically kill them... yeah, not for me.

As for the werewolf thing, I never played that particular game and probably never will. It's simply not my sort of thing. PC FPSes, sure. Colourful console 3D beat 'em ups? I'm sure it's fun but it's not my kind of game.

 

If this is a discussion of the change (if this isn't desired here, I / someone else make a topic about it) then I agree with iojenkins. It's part of the badnik's characteristics, intentionally or not. It's like trying to jump onto a Roller when it's rolling, it may look vulnerable, but you hit it and you realise it isn't. Seeing as this badnik is clearly of modular design (it moves by articulating it's individual segments, pretty obvious) destroying the head will simply make the rest of it immobile but still harmful.

As for fighting them, because we all know how to take on these badniks on by now, I have often considered each individual badnik needing at least 2 hits before it is destroyed. Of course, if there are still people that haven't played Sonic before, it may be a little hard, but still. This would appease the players that like difficulty, without making "super badniks" so to speak, that are just grossly powerful.

 

I have to disagree. Platformers, especially Sonic, are based on bold, simple decision making prompted by (often obvious) visual cues. Because Sonic doesn't get hit every time he rolls/spindashes into them, there's no sense of it being intended design that teaches the player what to do or not do. It just causes frustration and seems glitchy, like Shellcracker and Rexxon. If it were really meant to reward slowing down to destroy the Caterkiller, then it work every time when Sonic was slow, and not work every time he was fast. Since in reality, it's a lot more random, that doesn't make for good gameplay. [/rant]

Anyway, I forgot to add one extra thing that makes the fix complete. The segments need to change into normal damaging objects when they go flying - we don't want it to be possible to roll through the individual segments without getting hurt should you choose to chase them down and try to do so.

We can fix this like so: Open "_incObj\78 Caterkiller.asm" if you're using the SVN, or open "sonic1.asm" if you're using Hivebrain's. Find the loc_16CAA label and add this line before the loc_16CC0 label starts:

Code (ASM):

1.  
2.         move.b  #$98,obColType(a0)
3.  

This will make them have the same collision type as the thrown Orbinaut spikes when they become separated from the Caterkiller.

Er... I just realised that the fixes I've listed use constants like obColType and so on. For anyone not using the SVN disasm, they'll need to look here for reference.

I'm surprised anybody can stand using the old ones without the helpful labels and split files, but to each his own, I guess. Also, it's the only one that builds on my machine, so... :v:

 

Just out of curiosity, why is this so? Voluntarily choosing to use a 5 year old disassembly when a much newer and improved version is available seems quite counter-productive to me.

 

^I assume it's because the SVN one doesn't retain the old loc_XXXXX labels as comments, making it hard to use for following How-To's and so on. Also, it seems some people have compatibility issues with it, for instance not building on 64bit machines.