[ShadowsofYesterday]

redhotsonic, on 20 September 2012 - 03:46 PM, said:

Hey, guys!


There seems to be a bug with following this guide with the SVN disassembly. If you're a XenoWhirl's user, you're safe and can ignore this post and go on with your day. SVN user? Read on.


Seems that if you follow this guide as an SVN user, there may be a glitch with the Special Stages. Sonic and Tails act like they're being hit by the bombs object over and over, making it impossible to get any emeralds in the special stages. The reason? inertia is being used for something else in the special stages. This doesn't seem to be the case in Xenowhirl's dis.


So, in your SST table, you're better off switching inertia with something else. invulnerable_time seems to be the best to swap it with. So change them so you end up with this:

invulnerable_time =	$20 ; and $21 ; time remaining until you stop blinking

inertia =		$30 ; and $31 ; directionless representation of speed... not updated in the air

Any more problems, with either disassembly, give me a shout.



My SST guide has been updated as well to provide this bit of information

Sorry to bump this topic after two years, but hey, hacking information is always worth a bump, right?

I was puzzling for a bit over why this would create a problem on the newer disassembly, but not the old Xenowhirl one. After all, everything's equated, so changing the SSTs shouldn't do anything, right? Well, it's actually a problem with the disassembly, rather than the SST. $20 is a perfectly acceptable spot for inertia. Here's what's wrong: In the old Xenowhirl disassembly, at several points in the special stage's code, objoff_14 is used, whereas in the newer disassembly, this was changed to inertia for some reason. As far as I can tell, this change was completely needless. objoff_14 is still a valid equate.

So basically, if you want an alternative (and in my opinion, preferable) fix to changing the SST, fix what the SVN disassembly changed for no apparent reason instead. To do this, go to the following labels, and everywhere you see "inertia", change it back to "objoff_14".

SSPlayer_DoLevelCollision: (toward the end of the label)
SSPlayer_Collision:
SSPlayer_Move:
SSPlayer_MoveLeft: (a few lines above this label)
SSPlayer_MoveRight: (after the plus)
SSPlayer_Traction: (one before the plus, and another after it)
SSObjectMove:

Technically in the vanilla game, they both use $14, which is why inertia didn't create any problems before you changed its value to $20. But the code is looking specifically for $14, not necessarily for inertia. So changing the SST to $20 made it go haywire, because it was messing with something else that was probably using $20. Really, either fix works just as well. Yours works because it sets inertia to a value that's never called in the special stage's code, so it doesn't interfere with anything else. Mine works because it fixes a misused equate so that it's using the offset it should have been using all along. It's a matter of preference. Yours is simpler, but I personally wouldn't feel comfortable with it.

EDIT: Also, I'd like to point out that you never updated the first post of this thread when you came up with that fix, just your SST thread.

This post has been edited by ShadowsofYesterday: 06 September 2014 - 11:33 AM

[flamewing]

Lets see your argument:
Premise 1: 2007 disasm used objoff_14 for Special Stage.
Premise 2: SVN diasm uses inertia for Special Stage.
Premise 3: The guide fails on SVN because of this difference.
Conclusion: The SVN disassembly is "wrong" somehow.

Huh? I am sorry to burst your bubble, but fact of the matter is that all this does is make the guide incomplete or incorrect, since both disassemblies build bit-perfect ROMs. Moreover, one can make the argument that is is actually the 2007 disassembly that is wrong here: objoff_14 is used by the players in special stage as a measure of speed; hence inertia. See?

[ShadowsofYesterday]

flamewing, on 06 September 2014 - 08:26 AM, said:

Lets see your argument:
Premise 1: 2007 disasm used objoff_14 for Special Stage.
Premise 2: SVN diasm uses inertia for Special Stage.
Premise 3: The guide fails on SVN because of this difference.
Conclusion: The SVN disassembly is "wrong" somehow.

Huh? I am sorry to burst your bubble, but fact of the matter is that all this does is make the guide incomplete or incorrect, since both disassemblies build bit-perfect ROMs. Moreover, one can make the argument that is is actually the 2007 disassembly that is wrong here: objoff_14 is used by the players in special stage as a measure of speed; hence inertia. See?

You're right, both disassemblies do build bit-perfect ROMs. I just had this conversation with someone else last night. I suppose "wrong" is the wrong way of wording it, more like needless relabeling. Anyone who follows this guide – which in all honesty is a very helpful guide that should be followed by pretty much everyone – is going to be tripped up because a change was made that didn't need to be made. You could argue that the fault is in the guide for not initially taking this into account, but the fact of the matter is, there was nothing wrong with objoff_14 there.

Also, you don't have to be rude about it.

This post has been edited by ShadowsofYesterday: 06 September 2014 - 11:35 AM

[redhotsonic]

ShadowsofYesterday, on 05 September 2014 - 10:29 PM, said:

EDIT: Also, I'd like to point out that you never updated the first post of this thread when you came up with that fix, just your SST thread.

Whoops. Added to the guide. Also, linked to your post too in case they want your alternative fix. Thanks!


Plus, the guide was actually made with Xeno's dis' in mind. It was out of the kindness of my heart that decided to help SVN users. As I never use SVN and will always prefer to use Xeno's, there was bound to be bits and bobs that I would miss for SVN users. But, it works for both now anyway. As for flamewing's (somewhat sarcastic?) conclusion, this would have been the case if I had made this guide before SVN came out, but it didn't, so it was the guide at fault, but again, it's fixed now, all good. Thanks for the alternative fix though

As for the "which disassembly is better/right/wrong", let's not get into that. flamewing and I still continue to argue to this day which is better, and neither of us ever back down =P

[ShadowsofYesterday]

redhotsonic, on 06 September 2014 - 11:26 AM, said:

As for the "which disassembly is better/right/wrong", let's not get into that. flamewing and I still continue to argue to this day which is better, and neither of us ever back down =P

Yeah, I'm sorry to everyone if I came across as abrasive, that was not my intention. I did feel offended by the condescending tone of Flamewing's post, but I suppose he was just defending something that technically wasn't wrong.

Either way, either method stands as a valid fix, so it's just a matter of which way people prefer to do it.

[KingofHarts]

I didn't see what flamewing said as abrasive. Matter of interpretation, sure... such is the nature of the beast with regards to the internet, and seeing typed responses. I think he just typed it out the way he did to illustrate why it appeared you had misunderstood a certain point. I'm sure he certainly didn't intend for you to take it in that manner.

Now, same goes the other way too. I wouldn't interpret you as "abrasive". I'd certainly degree that an overall higher level of detail to all forms of disassemblies of each game is imperative for this site's guides. That said, do understand, as RHS pointed out... that for some people this can spark some unnecessary banter over preferences.

[Clownacy]

You're offended by someone correcting you? You're offended by someone bursting your bubble of delusion? You're offended by someone trying to make you see something their way?

How is it "needless relabelling" to label inertia as 'inertia'? There is everything wrong with using objoff_14 there: It's vague, it doesn't align itself with the other matching-group SSTs, etc...

The problem here is collision_property ($21), which is overwritten by the relocated inertia ($20 & $21). The thing is, the Special Stage objects use both conventions specific to sonic/tails (inertia) and conventions followed by many objects but NOT sonic/tails (collision_property). What to do about this, I have no idea.

This post has been edited by Clownacy: 07 September 2014 - 12:24 PM

[KingofHarts]

Clownacy, on 07 September 2014 - 11:16 AM, said:

You're offended by someone correcting you? You're offended by someone bursting your bubble of delusion? You're offended by someone trying to make you see something their way?

How is it "needless relabelling" to label inertia as 'inertia'? There is everything wrong with using objoff_14 there. It's vague, it doesn't align itself with the other matching-group SSTs, etc...

The problem here is collision_property ($21), which is overwritten by the relocated inertia ($20 & $21). The thing is, the Special Stage objects use both conventions specific to sonic/tails (inertia) and conventions followed by many objects but NOT sonic/tails (collision_property). What to do about this, I have no idea.

Dunno if that one was necessary...

Anyway as for the last one... and correct me if I'm wrong, as I'm not so familiar with the S2 Special Stage... but it's different objects that use these conventions, right? I.e. Players use inertia, while others use collision property.

If I'm mistaken... then objects that conflict could perhaps use scratch RAM?

[Clownacy]

KingofHarts, on 07 September 2014 - 11:53 AM, said:

Dunno if that one was necessary...

Well, what bubble do you think Flamewing was talking about? He thought the Git disasm is wrong, when he was wrong. To do that is to be deluded. My point was that if "Sorry to burst your bubble" is the condescending phrase that ticked him off, then it isn't something that exists just to be insulting; it explains the purpose of his post.

This post has been edited by Clownacy: 07 September 2014 - 12:09 PM

[KingofHarts]

Yea... Trying to defuse this situation instead of watching it turn into a potential explosive back and forth... Not saying you or flamewing are wrong, mind you.

[MarkeyJester]

Couldn't we just call it "Speed" and be done with it? Inertia is such a vague word by comparison, the term "Speed" seems far more unambiguous, to a point that it's so damn rediculous.

In other news, I believe the only logical solution behind this is the inclusion of a second (SVN specific) version of the guide (Or at least a note of warning stuck somewhere inbetween).

[ShadowsofYesterday]

This is why I tend to stay away from the forums most of the time. You try to avoid drama, but it always just keeps calling you out.

The discussion was over, Clownacy. I was never trying to start an argument here, or have any hostilities thrown around. I was simply trying to point out in more detail what exactly had caused the bug on the newer disassembly, and put forward a potential alternate solution to fixing it. I'm sorry if my preferred method of fixing this bug is not to your liking. It's my preference, and I won't be changing it in my hack. You – and everyone else – are free to do things another way if you like.

And for the record, yes, it was the "Sorry to burst your bubble", but beyond that, it was the rest of the post. It had a general feel that he was talking down to me, and I didn't appreciate it. But I realised he was just being defensive, and was technically not in the wrong in doing so, and I've already said this. The situation should have been over right there. I would like for it to be over now. If anything I've said in this post has seemed aggressive or confrontational to you, then please understand, that's not the way it's supposed to seem. I'm just trying to clear things up so that we can all go back to holding hands and singing Kumbaya.

We good?

EDIT: I'd like to further clarify that, while I personally don't feel the relabel was necessary, it wasn't "wrong" either. Yes, inertia is used for a measure of speed, as Flamewing pointed out, so it fits here (though as MJ said, "speed" or "ground_vel" or some such would likely be a better way of describing what inertia is used for anyway). But this guide changed inertia to something that interferes with something else in the special stage code, so changing it back to objoff_14 was just one possible way of fixing the bug. It's not the "wrong" way of doing so, it's not the "right" way of doing so, it's just my way.

This post has been edited by ShadowsofYesterday: 07 September 2014 - 03:42 PM

[Clownacy]

What? That wasn't about your method of fix. I found it strange for you to find his post offensive, but hey, I can't read tone.

[Caverns 4]

MarkeyJester, on 07 September 2014 - 02:57 PM, said:

Couldn't we just call it "Speed" and be done with it? Inertia is such a vague word by comparison, the term "Speed" seems far more unambiguous, to a point that it's so damn rediculous.

Actually, I never thought about, but you're actually right. The word "inertia", by Wikipediia's definition is:

Quote

Inertia is the resistance of any physical object to any change in its state of motion, including changes to its speed and direction.

"Inertia" is not just vague, it's literally wrong. Perhaps the nomenclature used in the Sonic 3 & Knuckles, "Ground_Vel" is more appropriate.

Not to derail the thread or anything (Though it is somewhat derailed currently anyway), I just wanted to say that I think MarkeyJester has a point, albeit one that might be more significant to some other thread.

This post has been edited by Caverns 4: 07 September 2014 - 03:55 PM