according to the starmen.net/pkhack people circa 2005, Bytes 14-15 in the 74-byte enemy ROM data are the "Collision box size". one of these days, i'll add that info to my guide. they also have a few other things i'm missing:
http://starmen.net/pkhack/soe/ntsc/soeenemy.txt
You can get the wrong monster groups too:
http://www.romhacking.net/hacks/621/
My favorite is to combine it with another bug, slap on Charm Bangle, and see Leafers and Dark Winds in the desert near WoR Tzen.
keylie: http://home.comcast.net/~assassin17/c1bank.txt
has a handful of functions commented that aren't in the Slick page (or comments them more thoroughly). 98% of the time, mine's going to be inferior (which is why i rarely link it), but it is the better option for some of the terrain in C1 you're covering.
now, it appears you've done most of the work yourself, but maybe you can doublecheck things or whatever. :/
is this bug known?
https://forum.speeddemosarchive.com/post/links_awakening_glitch.html
it's pretty cool, yet got no response at SDA. as the poster suggested, if it's only accepted in cases that also accept the doghouse glitch, it might be obsolete. but i figured it was worth mentioning.
AsFarAsIGet: yeah, i experienced that too. if your goal is just for assembly learning, and not trying to make compliant TAS video (which probably wouldn't involve a debugging Snes9x regardless), then use the Geiger based on Snes9x 1.43:
http://web.archive.org/web/20080509171127/http://geigercount.net/crypt/
here's a cool bug, discovered by Susan Carriere:
http://www.gamefaqs.com/boards/genmessage.php?board=588436&topic=52906513
i doubt you'll be able to make use of it in your TAS runs, given that you're not losing hearts in the first place.. but i am interested in any theories you might have as to the bug's cause.
thanks both for the replies. do you know how many frames are in the damage queue cycle? when testing this stuff a year ago using frame advance in the emulator, i may've gotten a basic idea by observing how long the spike hit followed after the initial damage (and whether it replaced it or not), but i didn't get an exact count, and i wouldn't remember anyway.
ok.. i'm still curious about this:
(or if it's not a spin attack, then when Link first swings his sword.)
i suspect that if Mothula is very close to the block to start, then it hitting the block will not only cancel Mothula's invincibility timer, but also cancel the damage it was going to receive from the strike. did you observe this at all?
regarding quickly defeating Mothula with the spin attack by relying on the spikes...
how does it work?
by my understanding (see my topic here: http://www.gamefaqs.com/boards/genmessage.php?board=588436&topic=43959744), if Mothula knocks into a stationary spiked block quickly enough after being "damaged" by one of Link's attacks, the 0 damage inflicted by the block will replace the queued damage, thus making Mothula take no damage.
i don't follow how this works in the player's favor. are you saying that you somehow get Mothula to hit the spiked block *after* the queued damage is inflicted (and thus it can't be overwritten), but *before* his invincibility timer wears down? that would require some crazy precision, if it's even possible.
also, what's the most times a given spin attack can contact Mothula? is it more than 2?
see, i would have thought that this strategy would fail because:
- Link traps Mothula by stationary spiked blocks
- Link whacks Mothula with spin attack, damage is queued
- Mothula is knocked into stationary spiked block, queued damage is zeroed, and invincibility timer is cleared
- Mothula bounces back toward Link
- follow-through of spin attack hits Mothula again, and damage is queued again
- Mothula is knocked into a stationary spiked block again, so damage is once again zeroed along with invincibility timer
obviously, if it's succeeding, i'm failing to follow something. how close is Mothula to the spiked block (the one he eventually hits) when Link first unleashes the spin attack?
thanks.
Read his post again, nitwit. He said he loved the idea. Where from that you concluded he "doesn't like runs that don't focus only on speed", I do not know. Maybe you've been drinking too much urine from the ugly horse featured in your avatar?
A followup on the timer bugfix: on April 10, I uploaded a more official archive to my site, complete with patches for the Japanese version and the USA Beta (so now every release of the game is covered), anti-patches, and documentation and commented assembly code that most of you who've read this thread won't need. ;) Get it here:
http://www14.brinkster.com/assassin17/ OR
http://assassin17.home.comcast.net/
All questions and comments are welcome.
hmm.. i clicked the "ff_llc" (rather than "ff_ta") link on Ultima Gardens, and the last FF VI link here:
http://fieldofdreams.happy.nu/
which is:
http://fieldofdreams.happy.nu/ff6/ff6timeattack/ff6GTA2_cap0.html
seems to talk about playtime. the columns at the end of the 2nd and 5th chapters in particular go on and on and on about saving and the gameclock, but Google's and Babelfish's English translations are a little too broken for me to make sense of it.
also, they compare the memo save versus the memory card, though i dunno if their point is simply to show how one clobbers the other, or if there's some bug involved with one saving method.
the 3rd chapter talks about having somebody (Terra?) be levelled up to 99 in the "world after the collapsing", then dying. how that works or why they don't just use the Lete River in the WoB is beyond me.
anyway, i do believe i've found a new catchphrase: "Sweet strawberry shake"! ;)
oy vey.. i scoured ROM sites, and see there's two USA version 1.0 ROMs, both having good checksums, but the files are definitely different. then there's filenames with (A) and a (E), different file contents, both version 1.0, yet their regions are the same according to the emulator.
does anybody know the story on the US ones? is Konami too dimwitted to update the version #, or is one of these a widely circulated hack?
EDIT: ok, according to GoodSNES, one (not the one i made my patch for) is "(Beta) [h1]", meaning a hacked beta. it's almost identical to a ROM with "(Beta)"; the majority of the difference is the cartridge info (game title, ROM makeup, etc) is changed to be normal.
grumble..
oops.. i had a BNE instead of BPL, so the hours were skipped in my conversion loop. a fixed patch is up (same link).
rumor has it certain speedrun maniacs have played 20+ hour games of TMNT4. ;)
dang, for not seeing the code, you sure have this spot-on. :) ex:
like you said, that's right, and it fails in preparing those values for display.
what *should* happen is that it takes a decimal time (e.g. 22d) and then turns into BCD (e.g. 22h). that way, each digit is in a nibble, which makes them easy to output. what the game currently does is:
SED (set decimal mode)
LDA #$0000
ADC time_unit
STA time_unit
CLD (clear decimal mode)
i'm honestly not sure how "decimal mode" works on the CPU. but i do know that while that snippet will succeed at converting 0Ch to 12h (as C isn't a valid 0-9 digit), it will fail at things like 28h (it stays 28h rather than becoming 40h, probably because both digits are already 0-9) and the example you gave.
here's a bugfix (for a USA, version 1.0, headered ROM):
http://assassin17.home.comcast.net/tmnt4_patches/Turtle-Time.zip
what it does is get (time_unit DIV 10) and (time_unit MOD 10) -- many thanks to a pre-existing division routine! -- then correctly sticks each digit in a nibble of the byte.
it seems to work right, but would you mind throwing some more $1BDE values at it and see how it holds up?
thanks
hah.. i remember from waay back that the game told me i finished in like 25 or 26 minutes, even though my actual time was closer to half an hour. i chalked this up to either an inaccurate timer, or maybe time being lost if i died/continued. but it stayed in the back of my head.
good to see this mystery solved.
have you considered making a bugfix? where's the routine at?
wow, another reason why Manual kicks Auto's sorry ass.
to my knowledge:
knife-throwing foot soldier HP = 28
Raph shoulder ram = 10
Raph standing sidekick after ram = 12
Raph second normal hit = 4
thus, you should always need another hit to finish him. can you give a specific example (i.e. location, etc) of a knife-thrower who fell within three hits? better yet, a savestate. :)
that's probably the random 5 vs. 3 damage on his 3rd combo strike we were talking about a few posts back.
holy crap. :)
how do you accomplish the double ram? is it from a single press of Y? or if you have to hit Y twice, do you also have to start running again?
i'm still having no luck with up/down. i neglected to mention in the last post that i had the same results while being below and offset to the left from the enemy.
hmm.. there may be something to that second part. i'll try and figure the minimal frames you have to walk left/right to trigger the throw, then apply that to walking up/down.
you don't have to be on the same side as you started, however. i tried this: stunning an enemy (who was to my right) with my weapon, walking towards it and ending up almost on top of it (but slightly to the left), stunning it again, then walking several frames to the right (which took me past the right side of the enemy), turning around and walking several back to the left, and successfully performing the throw (pressing left + Y).