And at the end of the day, everything is very well drawn.
That's one of the things that they nailed. The art of previous-generations MLP is just hideously ugly. It's the kind of style that's supposed to be cute, but comes out as really ugly, approaching the bottom of the uncanny valley.
With Friendship is Magic, however, they got it just right. The style is genuinely cute. I don't think the series would have got any kind of following if they had simply used a G3 style.
Hideously ugly seems kinda inadequate regarding the overworld sprite.
Speaking of Pokemon, when will [564] GBC Pokémon: Gold Version by FractalFusion in 2:54:27.15 get obsoleted by the current run? It's been a while since I've pointed out why it should, but the movie still seems to be as a seperate, unvaultable branch. :o
It's a little more subtle than that, because the cheats emulate things that you can physically do with difficulty:
-Bring your memory card to an F-Zero AX machine and unlock everything
Any reason you can't do that in a verification movie? Or why not use the JP version?
I think a case can be made for a TAS doing only part of an 'individual levels' mode, then later being expanded to do more of the game (SM64, F-Zero, F-Zero X...)
I still think we need the input of someone who actually gets to decide these sort of things. I'm fully against using AR normally, but I believe an exception should be made for this game. Especially because it's such common practice for real time players.
One of the special parts is needed to make the best flying machine (Buffalo cockpit, IIRC), which is used for almost all the records in the open ladder. This means there's a chance we won't even beat all existing records.
So it's pretty much just up to the mods which rule we violate, really...
I don't believe in making exceptions like this for a game just because it's popular. I mean, I understand making exceptions like when to start from a savefile and all, but using cheats? Wasn't there already a thread debating on the "legit-ness" of using uninitialized RAM? Kinda odd if using AR codes ends up being considered "legit" but not starting at an arbitrary RAM state.
Why not using cheats to unlock stuff if it is the only way? It's already allowed for unlocking difficulties/game modes, so why not here? Does it really matter if the cheats are ingame or from an external device?
It's possible to modify the save file like this. By having a verification file it can be at least proven that what was unlocked is also possible ingame.
Also, unless you know of an ingame cheat, then no.
Finally, MUGG mentioned the save file being corrupted for him in Dolphin 3.0. Does that happen to you, hegyak? :o
I'm putting my foot down at star dupes.
Why? Well...
Legend of Zelda - Ocarina of Time: Golden Skulltula duplication is banned for 100%.
Croc - Legend of the Gobbos: Gobbo duping is not allowed/banned.
There is probably more dupes in other games that is banned.
Then you bring up Ape Escape... where duping is allowed for speedruns. Then it becomes a complicated mess.
Uh...case by case I suppose. For example, duping was done on the "Catch em All" pokemon Blue run. :P
Edit: Besides, this trick doesn't even seem to allow you to get multiple stars at once, since the level ends after you get a star. :P
Uh...I'm confused. People are voting yes, but saying that it should be vaulted. Isn't that a tad conflicting?
Also still no save verification file. It seemed to have created controversy with the Wheel of Fortune run despite having a verification run, but this doesn't? :o
Because that's the way it is.
A particular RAM initialization (say, 00000000FFFFFFFF repeating) must be designated as the "official emulator power-on state" or else we would have endless pedantic arguments about what is valid and how to compare TASes (not that it stops us anyway). The result is that whatever the emulator declares the RAM should be at power-on is declared unquestionably "pure", and all deviations are "cheating". It is the emulator's edict, so just accept it.
So.....basically the person/group/whatever coding the emulator decided what state it should start on, which indirectly causes this argument about "purity" to occur.
I wonder if other groups/people can make their own emulators with the "official emulator power-on state" having TASing in mind....
The default state is considered ok because it's an obvious nothing up my sleeve number. It is obvious that it wasn't selected for the purpose of cheating in a TAS.
It would be kinda funny if the default state just so happens to make a game's RNG optimal as opposed to other states. :P
Also, you make it sound like if a TASer were to deliberately select something else that manipulates RNG (like system Time), it would be cheating. >.>
I'm still opposed to the use of arbitrary initial RAM states, because they move so much of the manipulation time required before the run starts, thus allowing the runner to achieve a bunch of input to the game which they didn't have to spend input for. This is not an ideal example, but it helps to make the point.
I'm just wondering why using the default NES emulator's RAM state is considered ok, despite also being arbitrary. :P
Well, like feos already said, you can find mine here.
Also, according to the ratings, I seem to be a minority, but I still stand by that [1679] DS Kirby Squeak Squad by MUGG in 36:40.54 is one of the best Kirby TASes I've seen so far.
For the other TASes that I've rated 10/10, I think they're self-explanatory for why I did. :P
Since none of them really have as big a "wtf?" factor as, say, Sheer Cold, I would vote for either:
- As before, a simple "C used Metronome!" screenshot, so the viewer doesn't know what it's going to call, or
- The "Should a move be deleted and replaced with Metronome?" screen.
I agree. I personally prefer the first option, since it does lead to people curious about what move would come up (assuming they didn't just skip to the last part of the encode or read the comments), but the second version is still a good idea, since it's a seemingly normal screenshot that indirectly shows the effort required to manipulate the RNG for this game.
For some odd reason, when pasting the 3rd stage to FCEUX 2.2.2, everything is the same, until up to frame 4026 of the converted run, where for some reason the bulldog I'm on is somehow pushed 4 units ahead on the X address. Even stranger is that the lag seems to have occurred at the exact same locations as running on the previous emulators, along with having the same amount of lag.
Since I'm not sure which behavior is correct, I'll just continue this on FCEUX 2.2.2, sync it with BizHawk, 2.2.2, and 1.5/1.4 and see which version console verifies :P
Edit: Btw, the WIP was done with this patch, but the odd thing is that when run on a 1.5 WITHOUT the patch, it desyncs at an earlier point, when I get hit by the snail for the first time.
Which means 3 different behaviors of the game on this stage depending on the version of FCEUX >.>
The video Spikestuff suggested is not very helpful, because it only says copy-paste the code, without saying what's happening. Only skiddies do that.
Well, most of my knowledge on what a section of code does comes from copy pasting an example online, then messing around with it. Not the best way, but it works fine assuming its a hobby and not your job to make the game. :P
Hideously ugly seems kinda inadequate regarding the overworld sprite.
It only seems to occur for some movies too, oddly enough.
:o
No.