Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
WarHippy wrote:
Memory wrote:
Dacicus wrote:
In the event that two or more runs tie for first place based on time, the combined final score (P1 score + P2 score on the trophy screen) will be used as a secondary determinant of rank; the higher score will have a higher ranking.
I really don't like this rule tbh. It means in the event of two equally as fast strategies, I have to go with whatever gets the most score rather than whatever is the most entertaining. Same with downtime.
This is a contest, and winning by score is a purely objective criteria.
It’s not like the winning movie has never been modified before submission to the site.
Having the most Start inputs in the input log of your movie is also a purely objective criteria. That doesn't mean it's a meaningful way to compare movies, or that it should be used as a tiebreaker.
The winning movie being modified is something of a non sequitur. Generally, the winning movie is modified to utilize the best strategies from the collective pool of contest movies.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Memory wrote:
Dacicus wrote:
In the event that two or more runs tie for first place based on time, the combined final score (P1 score + P2 score on the trophy screen) will be used as a secondary determinant of rank; the higher score will have a higher ranking.
I really don't like this rule tbh. It means in the event of two equally as fast strategies, I have to go with whatever gets the most score rather than whatever is the most entertaining. Same with downtime.
I agree. Strike this rule. It goes against our general site philosophy: we want to publish the most entertaining run, not one that optimizes some arbitrary variable. Declaring one team the winner because of score is an incredibly narrow evaluation of quality.
If by some magic, two (or more) teams have the same frame count, declare both teams the winner. They both deserve it.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
What's the point of the anti-cheating policy if you can use level-select to navigate to a specific level? Even if said navigation doesn't directly bring you to the trophy screen (for instance, if memory corruption was possible in one specific level), how does that make cheating allowed? It would seem to me that allowing this as an exception to the cheating rules would make the cheating rules arbitrary. On the other hand, deciding something's "cheating" when we allow things U+D and L+R and major game-breaking glitches is in-itself an arbitrary decision we made for entertainment reasons. But I think there's something of a line here between intended functionality (the level select) and unintended functionality (the other things I mentioned).
----
As for the question of whether it is really cheating:
I think the developer's intent in not marking level select as cheating for multiplayer mode is to allow the players to repeat levels or skip levels if they're familiar with the game. Which is fine, but it's still a level select.
Developer's intent only goes so far: if a developer said a TAS of their game was entertaining enough for Moons, that doesn't mean we'd automatically put a TAS of their game into Moons tier. Our rules should be able to make nuanced evaluations and not simply rely on what someone says.
And furthermore: there's already a distinction being made in the DTC contest rules that suggests it's cheating: the rules ban use of the level select for non-ACE purposes. So if it's not cheating, why ban it?
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Memory wrote:
I'd rather not change the game at this point. Graphics aren't everything.
I'd tend to agree.
I think the Lode Runner comparison is a bit surface level, since the movement here is quite different, and the 2-player mode makes for some interesting routing possibilities and challenges.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Dacicus wrote:
The button combination allowing you to skip around levels is allowed only for a run aiming for Arbitrary Code Execution/Memory Corruption/SRAM Glitch/Game End Glitch/Wrong Warp Glitch.
How does this button combination becomes not cheating when ACE or other trickery is used? The wiki says:
Bugz Uzebox wiki page wrote:
In single player mode, the following button combinations are considered cheating and will zero your cumulative score, but in two player modes may be used to skip around the levels with no penalty:
SELECT+SL - skip to previous level
SELECT+SR - skip to next level
(In any two player modes, you will both keep your cumulative scores, but lose any points earned in the current level.)
I know that the wiki page quotes single player mode, but I don't get how this becomes any different in multiplayer mode.
I don't quite understand how it becomes not cheating if it's used to assist in ACE. This seems to the definition of a level select code, which seems to go against http://tasvideos.org/MovieRules.html#CheatsDebuggingCodesAndArcadeContinuesAreNotAllowed. Is there some precedent where if a cheat code is used, but ultimately enables memory corruption instead of going directly to the end, it becomes fair game? To me, it would seem there's no such exception in the rules, and such an exception could potentially create problems. For instance: debug codes may be less tested, so getting into an invalid state from them may be inherently easier. One could argue the debug code taints the legitimacy of the run, even if it's used for a purpose different than the intended purpose.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
N64 emulation is tricky business, particularly because BizHawk uses an out-of-date version of Mupen. Newer N64 emulation is more accurate and probably likely to have resolved that problem (though it's still considered one of the more complicated consoles to emulate).
I'm no N64 expert though; I haven't really used it that much. Therefore, there may be some actual direct solution to your problem.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
EZGames69 wrote:
I dont see anyone who is in favor of options 1 or 2, unless they said so in DMs.
From the initial post:
Dacicus wrote:
Contest participants may vote for their game choice after being assigned to a team. Each participant votes individually, but feel free to discuss preferences within your teams. Please PM me your choice before the sign-up deadline. If there is a tie, then I will decide the game in some way (maybe streaming something and using that game's RNG).
Apparently the opinions expressed in the thread don't count if they weren't PMed as votes.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Hey! I just watched this and it looked pretty cool. I've wanted to see an updated run of Clu Clu Land for a while, and it's nice to be able to see one now. I also appreciate the modeling work that went into optimizing the solutions, and look forward to taking the time to read and understand it.
By the way, you don't have to cancel your submission and make a whole new submission when you accidentally submit the wrong movie file. You can just ask for it to replaced, and a site staff member will be happy to replace it. (Also relevant in cases where there are small improvements that don't significantly alter the substance of the run.)
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
I guess my question with regards to all levels vs. any% would be whether the level strategies are different, or whether any% is just a strict subset of all levels for this game?
Having levels in common doesn't necessarily mean the gameplay strategies are similar.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
If you could post the script that was used for generating the camhack, minimap, etc. in the encode, that would be really nice to have. It would help in understanding some of the details, and would just generally be in the spirit of open information TASing.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Warp wrote:
In other words, it's as if the emulator is considered the main authority of how the TAS should work, with an ancillary side variant of it that's fixed to work on the actual console.
Shouldn't it be the exact reverse? I mean in the cases of runs that have been console-verified? Shouldn't it be the console version that's considered the main primary version, with perhaps an ancillary version of the run that has been "fixed" to run on the emulator, if necessary?
I was thinking about this as well. I think it really depends on your perspective.
For the site, I think submission movies that work on emulators are needed as a matter of procedure. Judges (and anyone else curious) can't easily verify that something works on real console; it's infinitely more convenient to have movie files that work on an emulator. Once a movie is published, the site's general operations is that the movie itself doesn't get modified (maybe it does in certain cases; I'm not sure?) In any case, one of the principles of the site seems to be having movies that are accessible to anyone for playing and analyzing.
However, for the purposes of comparing movies and determining which ones are faster, console-verification and the related testing that goes alongside it can show whether improvements should be considered valid (or a previous version considered invalid in some way). Our rules already address cases where new submissions that "seem" to take more time can obsolete older movies by merit of the older movie have inaccurate emulation (often times less lag frames). This can extend beyond lag frames, and console-verification could be considered a final step in understanding how to compare movies.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Just want to weight in here on something related: I think handling of uninitialized RAM should ideally be a sync setting. That way it's documented in the movie file, instead of something floating around in the ether of emulation implementation details.
Though, some uninitialized RAM may be more consistent than others, so maybe my idea isn't fully robust.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Mazzin wrote:
btw i don't wanna hurt your feelings again, but i have to get this off my chest:
you seriously lack game knowledge! i can easily tell from looking at the gameplay.
[...]
me on the other hand, i only spend time with the EU and JP version of the regular game and this evidence strongly suggests that it might be beneficial to play the regular version first to gain a better sense of less significant improvements.
(...or you could just research existing runs to avoid rather obvious mistakes, but i understand that this video here was only a test)
It's not a good look to call someone ignorant and talk about how much better you are then them, especially after they post an improved version of your movie. Ad hominem like this is generally unproductive, regardless of context, since it just denigrates people and doesn't actually help progress discussion. Even if you think you know more about something, it's more productive to just explain in detail how an aspect works, instead of telling them "you have inferior knowledge".
Mazzin wrote:
but now i think i have an idea why! i assume you didn't spend much time with any other version than the color one, right?
because that would make sense then, since it is significantly less laggy and thus it is waaay harder to spot smaller lag differences like candles and such.
This is slightly more useful, but it lacks detail. It would be more useful to explain exactly how the lag works, e.g. "letting candle 11 in level 2 remain on the screen is slower because XYZ".
But really, if you want to show something's faster, you should provide a comparable input file as Memory suggests (i.e. one done in the same game version) proving it's faster. Unsubstantiated claims are much less useful.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
I've done some more investigation.
Essentially, most of the time differences come down to the hammer's animation logic. By delaying frames differently, or rerouting so non-chisel movements will occur at a different time, the hammer animation cycle will be at a different point by the time the end is reached. The hammer animation timer is also probably related to avoiding timer lag.
There are at least four important variables for understanding the hammer animation timer: $D81E-$D821 (a few variables after that have some relevance). $D820 and $D821 are indexes, while $D81E and $D81F probably more directly relate to the hammer's current state (they are also indexes of sorts).
So far, I've analyzed two levels. In Easy 3F, the huge 8-frame time difference basically comes down to a sort of framerule from saving one frame early on through adjacent A inputs. In Easy 2E, the altered timing for the non-chisel movement mid-solve are what result in a single frame being saved in the ending animation.
I'll probably come back once I understand the exact logic for how the hammer animation cycles work.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
I think that's a pretty hacky method of getting it to work. Preferably, this would be built into BizHawk in some manner. BizHawk already has similar functionality for loading games and Lua scripts, so it should definitely be implemented for external tools.
Especially since external tools are intended to be a more powerful and robust alternative to Lua scripts.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Since Jigwally's submission, I've been working on my own movie. This movie has all the puzzles solved: User movie #65083085390942935
It's actually slower than my previous movie, because the puzzle solves were entirely generated from scratch. There's actually a bit of subtlety to how fast a puzzle solve is, so it may be a little while before I'm satisfied with the level of optimization and end up submitting.
EDIT: Here's a level-by-level comparison:
The differences in level times comes down to (at least) three factors: whether the first two A-presses are adjacent, timer lag, and the time it takes to chisel the final square. The third factor is the most significant, making a difference of up to 7 frames in the final product (at least from this comparison.) All the solutions are optimal.
Also, all differences could be accounted for by in-level comparisons, so each level can probably be treated individually without worrying too much about later consequences.
The most I expect to save over my most recent WIP movie upload at this point is 00:38.58, and that's a pretty optimistic projection (assumes saving 9 frames on each level).
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Alyosha wrote:
RetroEdit wrote:
But I also think there's a huge difference between being able to verify a movie by adding a few frames to adjust for certain transition screens and not being able to playback on console at all.
I don't think so. If you have to modify it, then you aren't verifying the movie. Even if it's only one frame, the solution is to fix the emulator so it works correctly. I disagree with the rules here, and think the emulation environment is an important part of a TAS.
In some sense we're talking past each other: I'm not arguing that changing a few blank frames means the original movie file in such a publication plays back accurately on real-console. That is demonstrably false.
Neither am I arguing that the emulation environment is unimportant to a TAS, as you seem to imply. That's literally the reason we're trying to do runs on console: to evaluate the accuracy of the original movie. Improving emulation is certainly a desirable end-goal. But it's not like a few frames in a movie can instantly fix emulation; it takes time, and documenting these differences is exactly how we arrive at more accurate emulation.
Alyosha wrote:
I think a movie that works on a NES should be considered superior to one that only works on Not-A-NES.
That's exactly what changing a few frames does: it creates a movie that works on an NES. I agree, that movie is superior in accuracy to the original movie it derives from. I would simply argue the gameplay between the two movie files is essentially identical.
Alyosha wrote:
[Marking SMBA4: SMB3 as console-verified] would still leave the 10 loading frames inconsistency, which I personally don't agree with excluding and calling it verified.
I completely agree. We shouldn't be sidestepping the 10-frames being changed, and it should be explicitly acknowledged.
But that leaves a question: We have gotten a movie file that represents more accurate emulation, namely the movie file that has been resynced to real-console. How do we proceed? How do we treat the original publication?
There are many possible answers to this question, and I am curious what you think:
1. Allow the movie file to replace the publication movie
2. Allow the movie file to be a new submission that could obsolete the previous publication.
3. Allow the publication to be marked as console-verified and link to an an explanation of any details (frame alterations, direct console-verified movie file [e.g. GBI format], etc.)
4. Completely ignore that we have an accurate resynced movie file for the purposes of the publication, and relegate that to a forum post on the submission discussion thread.
As I see it, 1 and 2 are unworkable unless the altered movie file syncs on emulators, as the ability to reliably playback movie files is important, and console-verification setups are less accessible to players and judges alike.
But waiting around for emulation to be "fixed" doesn't resolve this either. One reason being our movie rules don't allow movies with identical gameplay to obsolete prior movies (unless you disagree with that rule?)
If our goal is to actually improve emulation, it would be better to improve the ability to communicate the console-verification status of a movie, rather than obscure that by making console-verification completely black and white. Having the site index this is much more convenient than requiring independent efforts to keep track of "verified but somehow not verified" movies.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
For SMA4: SMB3, "loading data" is not the problem. The problem is that loading the SRAM medium is nondeterministic between cartridges. It also can degrade in performance over time, so even the same cartridge may not always exhibit the same behavior. There's unlikely to be a perfect solution, and any verification would probably need to be adjusted to the specific cartridge anyway (hence a separate SaveRAM-anchored movie).
In general, I think it would be beneficial if we could more robustly communicate the nature of the console-verification. Adding frames to a movie does demonstrate the emulation for a movie was inaccurate, and we should probably be able to attach extra movie files and explanations for what steps needed to be taken for a movie to be console-verified, and maybe some sort of asterisk on the console-verified checkmark.
But I also think there's a huge difference between being able to verify a movie by adding a few frames to adjust for certain transition screens and not being able to playback on console at all.
I think it's misleading to say a movie was "impossible to console-verify" just because the emulation was slightly inaccurate. Consider how the site judges emulation improvements in regards to movie comparisons:
Movie Rules wrote:
When comparing against a prior movie for faster time, the faster time must come from improved play in the actual game-play segments. For example, gaining time by switching to another version which loads faster, has shorter cut-scenes, or by more optimized usage of the title screen menus is not counted as an actual time improvement. A movie which doesn't have any actual in-game game-play improvements over its published predecessor will not be accepted.
If time is gained from using a more accurate emulator, but game-play hasn't been improved, such a movie will be rejected. However, if improved emulation introduces more lag, extends the cut-scenes, or slows down game-play in some way, yet the actual game-play has improved, such a movie will be considered a valid improvement.
By this metric, we clearly wouldn't consider a movie with the same gameplay made under more accurate emulation valid for another submission. Console-verification can be considered the pinnacle of accurate emulation.
It seems fundamentally inconsistent to say the slightly altered movie can't be accepted as a new submission because it's too similar to the previous movie, but also can't be considered a console-verification for the publication it derives from. In effect, what you're saying is that certain movies cannot be console-verified, not because of anything inherent to the movie itself, but because the emulation at the time the movie was created was slightly inaccurate (probably the case for most movies, except platforms where emulation is extremely refined, but even then there can be complications).
By the way, I am not saying all movies can be console-verified. For instance, movies that manipulate RNG in ways that wouldn't be possible on real-console are un-verifiable. But adding or removing a few blank frames from a movie and getting it to playback on real console has verified the gameplay, which is generally what we consider the essence of the movie in other aspects of the site.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
What's with the pause around 2:02 in the video before ending Level 3? Also, wouldn't it save time to lure multiple enemies on one burger to drop the burgers down farther, or does the time for the enemies to move into place outweigh the potentially faster drops?
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
I don't think this movie should be accepted in its current form. There are a variety of reasons for this, but the main one is that it's been demonstrated to suboptimal in some rather significant ways, regardless of how you look at it.
1. Using SGB mode. I don't personally care too much about the extra time here, but a frame purist would say it's unnecessary time for the purposes of comparison, and I assume this movie is going to be accepted as a Vault movie.
2. Slow hint-cancelling. Every hint-cancel in the submission loses 30-frames by pressing B instead of R then A.
3. Level mistakes. Holding A at the start of many levels saves one frame by chiseling the top left square followed by immediately moving to an adjacent square (normally, a blank frame is required between inputs). Also, my analysis revealed that the Star 6B level accidentally had some extraneous inputs added that wasted time. This can even be seen in the encode if you watch it at 25% speed, where you can see a square is chiseled, erased, then re-chiseled.
4. If completing all the Time Trial levels would obsolete this movie anyway, maybe we might as well do that now if it wouldn't take too much time. Optimal solutions would need to be found for the additional 64 levels, but I'm already working on a program to do so. I think this is less important than the other 3. Another submission can be made later.
Overall, I think the original movie is a good foundation for a site publication, but it just has a few issues. I would urge Jigwally to request a delay if he's interested in waiting for me to finish my version, which would be co-authored with him, since I'm probably going to be using his solutions for the most part.
----
EDIT: Here is the fastest movie file I've gotten so far. It addresses all of the above issues except for #4: User movie #64941625601488011. This movie goes through EASY PICROSS and PICROSS, ending input early before the PICROSS completion screen is guaranteed to appear, which already seems to be confirmed as a reasonable endpoint. If Jigwally is willing, it can replace the submission, and I'd be more comfortable with the submission being accepted.
I'm kind of wondering if completing all 64 time trial puzzles should be in a separate submission anyway, since the validity of that being considered full completion is more contentious. It will take some time to add those new puzzle solutions and create a new movie file, so this movie being accepted in the interrim wouldn't necessarily pose a problem, even if does end up ultimately being obsoleted by a "more complete" movie later.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Hi! FCEUX is a fine emulator to use. BizHawk is a bit more up-to-date with its NESHawk core, but in my personal experience, NESHawk runs a bit slow.
If you're using FCEUX, I would recommend checking out the TAS Editor tool within FCEUX. It allows you to see all your inputs and generally makes it easier to organize and alter your inputs.
Also, a thread about Gyruss already exists, and generally we use one thread for each game. A forum mod will probably merge the thread shortly, so you don't need to worry about that.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
CasualPokePlayer brought up that this screen appears after beating the easy levels (if you don't reset to get to the next level set faster):
I think this is a good point: the game clearly delineates between "EASY PICROSS" and "PICROSS". I think they should be considered separate branches for this game, since they have different content.
And to be clear, this is not a trivial game. Firstly, the optimal solutions had to be calculated for each layout, which Jigwally has nicely done in this movie. Secondly, the difference in level lag between soft-resetting and hard-resetting suggests the possibility of significant lag reduction with more research, leading to more deep meta-optimization.
As for full completion... ThunderAxe's definition sounds reasonable enough. I think it's important to keep in mind that not all games have SaveRAM anyway, so artificially restricting the completion of certain puzzles just because completion flags don't show up in the save file seems a bit of a weak argument. On the other hand, you could take a more relative approach and reject it on the basis of completing puzzles in Time Trial without individual acknowledgement being less meaningful than the explicit tracking in the other part of the game. But it's still unique content either way, and would probably present different challenges to the TASer in addition to those presented by the other modes.
I think this is a good point: the game clearly delineates between "EASY PICROSS" and "PICROSS". I think they should be considered separate branches for this game, since they have different content.
And to be clear, this is not a trivial game. Firstly, the optimal solutions had to be calculated for each layout, which Jigwally has nicely done in this movie. Secondly, the difference in level lag between soft-resetting and hard-resetting suggests the possibility of significant lag reduction with more research, leading to more deep meta-optimization.
As for full completion... ThunderAxe's definition sounds reasonable enough. I think it's important to keep in mind that not all games have SaveRAM anyway, so artificially restricting the completion of certain puzzles just because completion flags don't show up in the save file seems a bit of a weak argument. On the other hand, you could take a more relative approach and reject it on the basis of completing puzzles in Time Trial without individual acknowledgement being less meaningful than the explicit tracking in the other part of the game. But it's still unique content either way, and would probably present different challenges to the TASer in addition to those presented by the other modes.