lol, but I also feel there's no point in collecting intermediate upgrades as long as you collect the final. just pointing out the other way to do it. i actually forget the specifics, or if it'd be possible for that way to be faster in a run.
Hey, I said I had no logical explanation. But it has to do with them being specific to their dungeons, and no longer mattering in the overworld, as well as no indications in the overworld that you've collected them. I know that this is not a reason in and of itself for something to be part of or not part of 100%.
I feel very strongly against requiring maps, compasses, and boss keys in zelda 100%s. I have no compelling logical explanation.
You always have the option of skipping half the sword trading sequence, if you prefer to buy and break the giant's knife, which makes a good case for not requiring all possible trade slot items.
Anyone who can get this to sync as the author intended, please let me know and/or upload an encode; one of my favorite games ever.
I had no idea a massive skip glitch was even possible :|
I would love to read a continuing discussion of this, the core question.
Please note that feos said 'enjoyment' and not 'entertainment'.
Your edit does not seem off-topic to me; this all ties into a greater theme of difficulty choice, what it means, what replaces, what coexists.
As a not-FF-player, I will assume this softlock is
- common knowledge
- has been common knowledge for a long time
- most/all of the FF speedrunning community considers it valid completion
Otherwise, why on earth would the author's comments not even mention it?
count me in the crowd for removing the 1h18m and the 28m and having this obsolete them both (shortly followed by a yet-to-be-made run obsoleting this one)
having a unique 'warp glitch' category at this point is like showcasing a bowl of lucky charms with one of the dozen marshmallow types removed
I see a lot of arguments against publication in this thread, most of which could be applied twofold to the Air run that we DO showcase. I did not judge this run based on how much I like hacks, but by the overall quality of the demonstration, and in particular the quality of it as compared to our Air tas.
Can't comment on how well this hack is known vs Air. Just don't get why we have Air at all if we're generally closed-minded about replacing it with a different hack demo. For example, the description for Air says: a trial-and-error platform puzzle game. And I see an argument or two against the puzzles. We only have the one SMB engine hack run published, right? And its a moon
Longer and better than Air/Air 2 while being the same type of game. Equally, or harder, complicated requirements of glitches. Looks notably more like an optimized TAS than the Air runs (see submission comments, there is truth to that). I vote to replace the Air demo with this
I appreciate the sheer awesomeness here.
Following up last year's Pi day with another total control hack run, has a time of 31:41:59 etc.
I'm with the other guys here but holy wow do i give you props for doing it a 2nd time.
looks like easy mode is required for a playaround to work. on that basis i would say you must not reject based on mode choice for playaround alone.
ive never played this game so im not really sure how entertaining i should find this.
I would probably never sit thru a golf tas, of this type of golf game, longer than 5 minutes, if speed was the #1 goal. just so boring. i think for this game type speed never makes sense. maybe there are other golf games that have modes or subgames that look very impressive when speed is #1 maximization. this one is not.
re: branch names. why can't our branch names be perfectly uniform and consistent, while remaining totally unused in games like this? This game doesn't need a branch, because we will only ever have one run of this game. Only a subjectively improved, or otherwise more interesting run, will ever obsolete this one. The only big decision here should be whether to use tags like suboptimal character or playaround
just my 2c
Yes. the game supports its own movie playback format etc etc... same guy who made the TAS tools built all that in. If you wanted a second opinion, well I was always part of that scene.
Of the console versions, the PSX one is the best port. The N64 one is particularly weaksauce
Buddyben: Why do you believe that a File Date can never be lost, modified, changed, reset? In reality, that event is as trivial as adjusting the computer clock. File dates get screwed up all the time. They are not fully reliable indicators. In this way, your statement is not "true regardless of how you interpret it".
Spikestuff: How are you qualifying first? morimoto's was the first seen by many. it is fantasy to assume that no emulator superplays were ever made prior to that one.
TASing was so young in November 2003, that without further information, I would sooner believe the dates on those two files are wrong, than believe they are accurate. Three years is quite a lot of timespan for us to not have any records of anything except a few files. But so too, I would never consider morimoto's as the first, when the only claim ever made about it is that it was the first to be seen by a mass audience. I would think the actual lower bound is the date when a console emulator existed that could record and replay input. Let's find that and go from there.
N.B. I'm assuming we're talking full-scale. Absolute time, and including superplays that are lost in history, or never submitted here. If we are talking strictly related to the NESvideos/TASvideos database, then these are questions the staff here can definitively answer.
I believe this video made the total control hack TAS as accessible as possible to people not in the TAS-loop. The payload being playable was instrumental. Only by performance of the games afterward in a live setting was the finishing touch applied.
This run, properly, was a live performance. That is how it should be appreciated. That is how others should see it. Fuck the movie file. We should add the AGDQ video of the live performance to the site. Without the performance, as many have noted, it does not stand out so notably.
Think you guys are judging the merits of a script without looking at the film that was made from it.
tompa makes everything better.
Don't believe so... I didn't see proof either way that this is or is not the fastest character choice. The author's comments about the speed-increasing glitches only suggest it's one of the fastest characters for adventure mode.
Sorry, I'm aware you can't change characters. I should have said 'the run' instead of 'the whole thing'. I meant, this has huge entertainment value based on the character choice and the implementation of that choice. (I did say this primarily because most of the SSBM footage I've ever seen used Fox or Falco. I've watched a lot of competition footage and the like.) Usually here's where someone brings up entertainment being the primary goal in a fighting game.
I admire the run because it appears to be speed-optimal at what it does. The description shows a firm goal that a variety of moves and types of KOs be used. Right away you know there are speed/entertainment tradeoffs. You should expect that the character choice took this into account. Your considerations are valid... I think it's vault-y logic being applied to a moons tier tas.
As a guy who has seen way too many ssbm videos using fox, this is a refreshing change. This movie has huge value even if you can do the whole thing faster with other characters.
My (probably flawed) viewpoint says: accept a lag compromise, in the interests of completing the run. Everyone can move on to a better emulator with better tools for the next iteration.
Putting effort into shaving 8 frames from this lag situation, only makes sense to me, if we are confident that we won't save 8+ frames in the TAS prior to that point, when it is redone with a different emu and more tools. If we really have already achieved that kind of optimization, what's happening now makes more sense. I'm not in the circle enough here to know how much our top OOT TASers have tinkered with other portions of this game in bizhawk so far.
I thought we had many games where we cuold not emulate elements of randomness intentionally chosen by use of data of a unknown initial state. I thought the status quo was to just go with the emulator defaults, accepting it as not the best possible hardware luck. Example being the pokemon games that use screen blank timing or hardware LCD values to initialize random seeds. Is this really all that new? What's been the running policy? [does this change if the use of unknown data by the game is unintentional, and we can prove it so?]
DRybes wrote:
-Do we have other games that instantly load at the non-beginning level from launch?
My posts are often long winded but I would like if someone could address ^ these two simple questions. Thank you.
I found these posts, nearly consecutively, in the X-man gruefood thread. It made me think of this game, and I think they are relevant here, but were not explored to satisfaction.
So keep in mind I am not quoting or responding to posts from this thread, but from another, and applying them here
mklip2001 wrote:
Also, there's another question worth considering: is this an official game? I don't remember if TASVideos also changed its policies concerning unlicensed games / hacks when it adopted the Tier system.
This game has more in common with a shitty hack or homebrew than a game. We might not be considering it for the site if not for notoriety. You could argue against having a run of this game for this reason.
Heisanevilgenius wrote:
Voting no. Actually the reason I'm voting no is because this run does not complete the game.
- The final boss is not killed and it could be argued this does not agree with the spirit of progressing to the point at which you can no longer continue. This was not adequately resolved for me.
-Do we have other games that instantly load at the non-beginning level from launch? This is an issue for me too. And I do actually enjoy the novelty of this run and appreciate what it does. But again on this point, I cannot reconcile what is happening here with my understanding of what we accept.
I am confused as to where the 6 bits of register reside, that is read from before initialization. I am led to believe from what I have read here that it is on the cart itself. Is it part of the game cartridge itself or are these registers in the NES hardware? If it's part of the cartridge, how many other games depend on such aspects of the cart vs the console? I'm not here to contribute to the debate for/against accepting this, just thinking about the difficult of broad policies here that would be best to have.
I believe in a consistent state of the console hardware to be applied as widely as possible. And I see issues like the RAM as being part of the console that should be level for all. (I know this game/submission is nothing to do about the RAM) Regardless of this current situation, it should be rules that we are assuming console ram initialized as what current emulators initialize it as. It should be mentioned any other values we are also assuming. Messing with things that would be on the cartridge and not in the console is different to me and not necesarily something to instantly reject on principle. As Nach believes, and I am with him fully on this, it's all a means to the end of reasonably emulate the software in a deterministic way. What we have here is an emulation nightmare caused by software flawed in a major way. Maybe these will always be unique corner cases.
But I thought we had many games where it was accepted that we cuold not emulate elements of randomness intentionally chosen by use of registers or ram or other data of a unknown initial state. I thought the status quo was to just go with the emulator defaults, accepting it as not the best possible hardware luck. Example being the pokemon games that, IIRC, use screen blank timing or values, or something else related to the physical LCD on the hardware, to initialize random seeds. Is this really all that new? What's been the running policy?
Should we consider the game software to be just the software code on the cart, or everything that the console would be black-boxed away from on the opposite side of the cartridge contact pins (as far as the console is concerned with it)? If we allow ourselves to choose initial states of cartridge hardware, is that not a can of worms? Do we have to assume and follow some established defaults, until we can definitively prove a quirk of the cartridge hardware, and how it works, and its full ramifications? Then they're fair game to use? I don't like the direction that would take. At the same time I can't disagree with adelikat's argument for allowing this particular case. Extraordinary circumstances for an extraordinary cart.