I tried to send in a TAS of RCR. I packed the .fcm in a .zip with 7zip, but when I submitted the .zip, the site says "No acceptable movie file found in the .zip". Also, it says that the FCM does not begin with a reset, even though it does. If it matters, this was recorded with FCEU 0.98.16
Put the FCM on microstorage?
If Microstorage says anything bad about the start point, the site won't accept it either. I might be able to repair it though.
Joined: 4/20/2005
Posts: 2160
Location: Norrköping, Sweden
Chamale, have you tried making a savestate at the very last frame of the movie, then start recording a new movie and load that savestate? If this new movie isn't accepted by NesVideoAgent either, it's something wrong with the savestates for the original movie. The rerecord count would be 0 for that .fcm, but that can be edited to the correct number.
EDIT: Okay, I watched the .fcm now - but why did it end so abruptly? It didn't desync or anything, the movie just stopped here, without you killing the boss. I have the right ROM and all. Is this supposed to happen?
It says "reset, type unknown" which suggests it's corrupted a bit. I checked the actual FCM, and this movie does not begin from reset. It was rejected because it plays from a savestate.
Joined: 4/20/2005
Posts: 2160
Location: Norrköping, Sweden
VANDAL wrote:
The boss 'eventually' kills himself with all the objects around.
Allright, after how much time? I turbo'ed several thousand frames without seeing the boss kill himself.
I personally think that it would be better to have a slightly longer movie input time if the boss will die 30+ (I guess it's somewhere around 30) seconds sooner, instead of how it is right now. Thoughts?
EDIT: About this movie beginning from savestate: Would it be possible to start recording a new movie that does begin from reset, and then just copy all the input from this finished run and paste it into the new movie using TAS movie editor? That is, of course, if the fact that it begins from savestate does not affect the gameplay in any way.
FCEU isn't actually checking for the 'reset hardware' command. Microstorage checks, but didn't find it, so it's confused, resulting in the message shown. The submission script checks and didn't find it, so it's rejecting your submission.
Here ya go. I fixed it for you. But I think I might have done something wrong -- it doesn't finish properly, so the ending might need to be redone. But this FCM will be accepted by the submission script.
Allright, after how much time? I turbo'ed several thousand frames without seeing the boss kill himself.
About 11,000 frames later.
This poses a rather interesting question related to http://tasvideos.org/Rules.html#3_the_exact_termination_point_is_subject_to_debate_
Whether the "correct" termination point is #1 (as in this case) or #2 is subject to great debate and controversy. So far it hasn't mattered too much since in the few cases where this has been an issue the difference in movie lengths can be counted in a few frames.
However, in this case the difference is enormous and the question becomes much more relevant. It becomes even more relevant given that doing #2 would end the game (vs. end the input) much sooner than #1.
One problem I see with this is that the viewer is watching the gameplay, not the input. Even if the movie shows the "playback finished" text (or whatever it was), it can still be confusing why the game is taking so long to end.
Question: How much longer would the movie be if you beated the boss as fast as possible?
Joined: 3/11/2004
Posts: 1058
Location: Reykjavík, Ísland
The way I see it, it's simple. The .fcm should complete the game as fast as possible. The point is not to make the shortest .fcm file, but to make the shortest game-completion. That's my take on it, and I would vote no on that movie until the ending was fixed.
Ending the input early should only be allowed if it does not result in the game completing slower.
Ending the input early should only be allowed if it does not result in the game completing slower.
Actually the section of the rules I posted the link to seems to assume, at least in spirit, that that's the case. In other words, that the game completion itself is the same in both cases (give or take a few frames, possibly), but the record file could be ended a bit earlier than the actual game ending, thus saving a few frames from the record file. I'm not even sure that the person who wrote that section of the rules was thinking about option #1 actually making the game completion slower than option #2.
If that's the case then it seems that there's no rule for this case. The letter of the rules (although possibly not the spirit) would allow such a movie, but it may just be a case of nobody having thought of such possibility.
Of course one could argue that defining the exact point at which the game "ends" might be quite fuzzy with many games. Does the game end at the frame when the last hit to the last boss is delivered? Does the game end when the last boss dying animation ends? Does the game end at the first frame that the screen changes after the boss has been defeated?
It's quite clear that the game has not ended if the last boss is still alive. However, if the rule is "the movie recording must play the entire game to the end" it becomes a problem of definition what is this endpoint in this game. When can the movie recording be ended for it to be acceptable? If the movie recording is stopped 0.5 seconds before the last boss dies, is that acceptable? (There certainly are published examples where there's even a larger margin between movie and and last-boss-death.)
Edit: Perhaps the rule could be: "The movie file can only be ended when it's not possible to complete the game any faster by adding additional input after the movie has ended."
Of course someone could feel that's unfair. A movie is a movie.
Look at adelikat's Gradius for an example of a movie that ends input extremely early - further input can actually kill the player. It's assumed that a watcher would not provide the input, thus, the movie completes the game.
A missing reset at the beginning could be an instance of this behavior I've had happen to me a few times with FCEU. I still have no clue how to reproduce it consistently, though.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Look at adelikat's Gradius for an example of a movie that ends input extremely early - further input can actually kill the player. It's assumed that a watcher would not provide the input, thus, the movie completes the game.
Can the game be completed faster by adding additional input to the movie?
