This reminds me of Dragon Warrior 3 "no item glitch"'s case.
I don't know why people seem to insist on keeping it from being obsoleted despite the ratings have indicated the old run isn't all that entertaining even back then. :P
For whatever it's worth, I do find that longer DW3 run entertaining as far as its niche goes, and I rewatch it every now and then (generally as part of a marathon of no-major-skips runs of as many DW/DQ games as I can get my hands on).
So: ratings at the time aside, opinions may differ.
Yes - as I said, that was the only way I found to get a Linux version. Though I often prefer to build from source myself anyway, if I can't find the program in the Debian repositories.
That would explain the difference. From the thread I thought you were using the [J] version, but apparently I misread which parts of the discussion were about hypothetical possibilities vs. which were about what has already been done.
Yes, it syncs with the [U] ROM, although it does complain about a mismatch between accuracy core vs. compatibility core.
I noticed the lack of subtitles, but I figured that was reasonable for this stage of progress, even when I thought you had been using the [J] version already.
I'm possibly doing it wrong (I've never used a rerecording emulator before, or at least not gotten a movie to actually play back on one), but the latest WIP on this that I can find desyncs for me immediately - as in, no later than the "select a save file" screen - with the Soul Blader ROM I have. Does this require any particular settings, or particular ROM version?
(I ended up compiling lsnes from source, installing missing libraries and the like at every build failure along the way, since I couldn't find a prebuilt Linux version. So there's a chance I got that wrong too - but it seems to work on a basic level.)
I was planning to translate Soul Blader at one point, and I've got a partially-complete translation sitting around somewhere (though not remotely close to being playable). There's a lot more detail and nuance in the Japanese version, but the overall gist seems to be more or less accurate in all the places I remember checking on.
There's no chance of me completing a translation far enough to be useful in time for anything to do with this run, but if there's anything in particular where you'd like to check if it's different, please feel free to point me to the appropriate Japanese text and I can see if I can find anything out.
about the obsolete items, I'll still use the "as powerful as Link can be" concept.
For comparison, my general rule of thumb (applied to most games, not just Zelda) is: If you could explore the game again, would you be able to tell that the "lesser" item had not been gotten?
Using the White Sword and Magic Sword as examples: if you get the Magic Sword without having gotten the White Sword first, and then go back to the cave where you would have gotten the White Sword, is the White Sword still there? If so, I would say getting the White Sword first would be mandatory; if not, I could probably be convinced that getting the White Sword is not necessary for 100%.
Similar things could apply for the Blue and Red Rings, and the Wooden and Magical Boomerangs, and so forth.
Enemy Bait, potions, shields which are eligible to be eaten by Like Likes, and things like the Giant's Knife are IMO all different types of consumables. I don't have a single, easily-described rule for whether - and, if so, how - consumables should be counted towards 100%; by and large I would say "you have to get at least one of each, but you don't have to keep it", but I would also make quite a few exceptions to one half or the other of that.
Baxter wrote:
The shield is less useless as having the piece of meat a second time. At least you can walk head first into some enemy projectiles without being hit, which could theoretically be useful.
The Enemy Bait can also theoretically be useful; if memory serves, its official primary use is to distract enemies, so that you can either slip past them without fighting or come up behind and stab them in the back. Admittedly I've never seen it really used that way, or had much success using it that way myself, but the idea is there.
The game's title screen shows a list of all treasures. Collect each of them at least once plus all eight Triforce pieces and you'll have 100%.
Interpreted strictly, this would mean you'd only need to get one Heart Container, rather than all of them; IIRC, the Heart Container is only present in that list once.
I certainly wouldn't count it as 100% without all of the Heart Containers; I'd also require discovering all the "warp stairs" locations in the overworld. Other than that, for the little my opinion is worth, I'd be inclined to agree with this definition for speedrun purposes.
(There's also the question of whether it's still 100% if you get one of the Heart Containers and then give it up later to buy your way past a locked door. I'd say it isn't, but there's rationale to disagree with that.)
The encoded video on YouTube is downloadable if you know what you're doing; I use cclive for that purpose most of the time.
The "best quality" version of it is a good 4GB, though.
DarkKobold says he doubts anyone watched all 45 minutes of this run. Will someone step forward to my defense?
Very belatedly, since I just noticed this question:
Yes, I watched the entire run straight through (in the encoded form).
In fact, I've done it at least twice.
Oops, the torrents used incorrect webseed type (httpseeds as opposed to url-list). I edited those files by hand (hex editor!) but didn't remember to rearrange the fields.
Thanks for the prompt response; the updated files work fine for me.
(It turns out that my own attempt at a fix put exactly one byte out of order... I could probably have gotten it right if I'd taken the time to read the spec itself.)
When I try to download the published run from either of the two torrents, using BitTornado, I get a "bad bencoded data" error. I get the same when I try to even display the file information using btshowmetainfo.
I've done a bit of digging, and I think the relevant information is here:
http://echelog.matzon.dk/logs/browse/bittorrent/1182722400
Essentially, some clients (adhering rigidly to the BitTorrent spec) will choke on any torrent file which either includes extra data at the end or puts its fields out of alphabetical order. (uTorrent, for example, has apparently been known to create such noncompliant files at some points in the past; also, some multi-tracker software will mangle files in this way.) In this torrent file, the 'url-list' field is prior to the 'info' field, which contains various other fields.
I've tried to fix this by hand-editing the file (in the absence of a working torrent editor, as opposed to generator, which doesn't require Wine), but I haven't been able to produce anything which seems valid.
The last torrent I used from TASVideos was the one from the MMX6 100% run last month, and that one did (and still does) work fine. It claims to have been created with Azureus 4.7.0.0; one of these failed ones claims to have been created with Azureus 4.6.0.4.
Was something done differently when generating these torrents? Is there any chance of updated torrent files which don't have this problem?
The published encode doesn't play properly for me, at least not in MPlayer.
MPlayer identifies the file as having a frame rate of 0.083 frames per second, and as a result, the video is far too slow and the audio is far out of sync.
ffplay can play the file at what appears to be the correct speed, with good sync, and reports a frame rate of 50.52. However, passing that frame rate to MPlayer with the '-fps' option does not produce good playback; nothing I've done (in terms of custom FPS playback and/or video/audio delay) has been able to get MPlayer to play the file correctly.
Ordinarily I wouldn't bring that up here, it'd be a problem with MPlayer, except that since I haven't had that problem with any other TASVideos publications that I recall - and as MPlayer still plays a random other recently-released encode just fine - I'm wondering if there might be something wrong with the file.
Has anyone else had any problems playing back the published encode?
(For what it's worth, this is with current SVN MPlayer as of the 6th.)