Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
KusogeMan wrote:
it seems like the participants consider it trivial to go through the hassle of adhering to site rules and producing verification movies when in fact it is not.
It's incredibly ironic that you're accusing others of making submissions harder to get published when it's your proposal (which I understand as disallowing cleared SRAM submissions to be accepted as separate branches for fighting games) that would create these exact barriers that you claim to be against.
Allowing people to submit what they want to work on breaks down barriers to entry. Disallowing people from submitting certain types of movies does the opposite, it creates barriers to entry. In this case, disallowing SRAM-cleared submissions quite literally creates exactly what you're arguing against: it forces anyone who wants to work on a fighting game to make an SRAM-anchored movie or else it would be rejected.
KusogeMan wrote:
I feel like the suggested change to the rules in my perceptions subtracts the value of the research and routing of using or not a SRAM unlocked characters in the discussed TASes
Maybe there was a miscommunication along the way, but the "change to the rules" that started the most recent discussion was what to call SRAM-anchored branches. And the thread in general was originally about allowing SRAM-anchored branches in the first place, which was officially added to the rules a while ago. You're the one here who's proposing a change to the rules to reduce what kinds of movies can be accepted for fighting games. Most others have argued in favor of keeping the rules as-is, with both SRAM-cleared and SRAM-anchored movies being acceptable.
Whether the branches are defined by SRAM or by something else seems like something better suited for case-by-case decisions on an individual game's branches, rather than a sitewide (or genre-wide) rules change. If a game has people working on SRAM-cleared TASes then they should be able to get those TASes published as such. And if a game doesn't have people working on SRAM-cleared TASes then it's a moot point as there won't be a branch for it in the first place.
KusogeMan wrote:
I could just have sticked to the "second best easier to publish" really.
You've previously brought up the argument that TASers will only work on the easiest branch of their game, but I think this argument is out of touch with reality and is easily disproven by spending 5 minutes looking around the site. Many TASers work on whatever interests them, even if it's more challenging than something else. And in this particular case where the extra challenge comes exclusively from creating the verification movie, I would suggest spending less effort towards trying to get other submissions rejected and more effort towards proposals that streamline the process of verifying SRAM-anchored movies (which was one of the original questions in the first post of this thread). I can certainly see a solution where a save file is provided along with documentation on that game's save structure instead of having to provide a full verification movie. But it's hard to have that discussion when your argument is exclusively about adding even more restrictions to what can be accepted.
Honestly, a lot of this comes across as a case of taking a personal distaste and trying to push it onto others. It's perfectly fine to not care about a particular branch and only pay attention to another branch that you do care about. This happens all the time, both in RTA speedrunning communities and in TASing communities. But when it turns into trying to enforce that personal distaste onto others as an official policy, that's when things start to get back to the old way that TASVideos did things that so many people have been working hard to change.
Allowing both SRAM-cleared and SRAM-anchored movies as opposed to only one or the other gives TASers the freedom to work on what they actually want to work on without having to worry about their movie being disallowed on the site before they even make their first input. And I'm very much in favor of staying on that path of acceptance, rather than reverting back to more restrictive policies.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
Not every single game needs to have the main category be clean SRAM movie files.
That's not at all what was being proposed. There's no such thing as a "main" category on TASVideos, other than what individuals consider on their own to be important. And clearly for these games, starting from SRAM would be more important to the respective communities, therefore they'd be considered the main branches by those communities. In fact, there won't even be an SRAM clear branch in the first place unless such a TAS is created and submitted.
Nobody is enforcing a ruleset of clearing SRAM here, either. It's allowed, not required. Glitchless is equally allowed and equally not required, but you're seemingly not complaining about having the ability to submit glitchless TASes of fighting games. If a community wants to make a TAS under a particular ruleset then they should be allowed to do so. Banning people from submitting SRAM-clear TASes of fighting games because some fighting game TASers don't like it is unnecessary gatekeeping and does the very thing you claim to be against, which is enforcing a particular ruleset on people who may not want to follow it.
Again, if people are TASing it then that shows enough interest to make a branch. If they're not TASing it then there won't be a branch. Many games don't have all possible branches that the rules allow, because a lot of those branches haven't been TASed.
As for the actual topic at hand, I think New Game+ is a good general name but I'd be open to other game-specific branch names as well, like "All Characters Unlocked" if that applies, or using some in-game terminology if there is any. I think it would make sense to look at it in a more case-by-case way and taking into account what the author or game's community prefers to call it.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
There is currently no other optimized TAS on the original version of the game. The only optimized TAS of this version of the game is tendog's TAS in this submission. The next closest thing was a segmented BTT run on the original version, which was completed a bit over a year ago. This BTT run is slightly faster in a few segments due to the new strats, but is slower overall than tendog's TAS. There's a comparison between that BTT run and tendog's TAS (the same one in this submission) here:
Link to video
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
There are just a few new tricks possible on the original version that weren't known at the time. One is a method of clearing the intro text slightly faster (it's way more complicated than it sounds) that saves 1-2 seconds. Another is using auto-run, which saves one frame per room but loses some setup time. There are also a couple movement optimizations that save a few frames each, and RNG manipulation which can save a couple seconds throughout the run. Not counting the intentional time loss that was discussed earlier, this would roughly add up to about 5-6 seconds of optimization
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
feos wrote:
OceanBagel wrote:
It might usually make sense if a faster TAS is made during judgement to reject the slower one, but I'm not convinced it makes sense to judge a 2019 TAS by comparing it to 2024 speedruns, especially when a large portion of the time save comes from newer versions of the game.
How large is it?
I timed out the more obvious version differences and it added up to 65 seconds. I know there are also more subtle differences throughout the run that I didn't time out, so the actual portion of the time save that comes from version differences is even higher than 65 seconds.
There are several glitches that became possible on later versions but weren't possible on the initial demo, so a lot of the time save comes from skipping minibosses, cutscenes, or entire rooms using these version-exclusive glitches. The new TAS also achieves a different ending (speedrunners call it True Pacifist, it's the "good" ending of the chapter) because the new glitches make it faster than the standard ending.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
You're able to freely select either chapter 1 or chapter 2 from the start. You can select chapter 2 without having ever played chapter 1 and it'll give you a default set of equipment (probably to compensate for difficulty scaling). But you are able to carry over progress from one chapter to the next (including items, completion of secret bosses, and completion of alternate routes) and this likely means that some future content will only be available when playing through all the chapters one after another.
For speedruns on the chapter 1+2 demo, this mainly affects which equipment you have and how much gold you have. RTA speedruns of chapter 2 on its own require that it's started without chapter 1 data so that you have the default equipment, and that's also how I would expect TASes of chapter 2 to be done. But full game speedruns bring stronger equipment from chapter 1 into chapter 2, which leads to some advantages in chapter 2 over the default equipment.
Also, I should mention that NG+ status is tracked per-chapter, so you're able to get the benefits of NG+ in chapter 2 even if you never played chapter 1.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
lexikiq wrote:
The existence of a more optimized TAS might be a big blocker in getting this published now but I certainly agree that this should be/should've been published.
I don't know what kind of precedent there is for rejudging, but I would hope that the submission time is taken into account during the process when it comes to beating known records. It might usually make sense if a faster TAS is made during judgement to reject the slower one, but I'm not convinced it makes sense to judge a 2019 TAS by comparing it to 2024 speedruns, especially when a large portion of the time save comes from newer versions of the game. I'd like to think TASVideos also functions as something of a historic record of TASes, and this one stood for nearly 5 years.
There's also the matter of the new Deltarune chapter 1 TAS possibly not being acceptable on TASVideos. The movie rules currently say that the movie must beat the game, which for the version used in the newer Deltarune chapter 1 TAS would mean completing the game through chapter 2. That's as opposed to tendog's Deltarune chapter 1 TAS, which was done on the old demo that only had chapter 1 in it, thus following this rule. This is a rule that I hope will be changed eventually, but it's still there as of now. It would be a cruel twist of irony for the original chapter 1 TAS to be rejected because of the existence of a newer chapter 1 TAS that was also rejected...
Also, I did make an abbreviated post on the "Revisiting rejected submissions..." thread summarizing my above post and linked back to this thread: Post #527379
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
feos wrote:
duuuuude5 wrote:
This functionality exists in the base game's "debug mode" in the form of the following code, which is executed every time F10 is pressed:
if (global.debug == true)
{
global.interact = 0
if (global.phasing == 0)
global.phasing = 1
else
global.phasing = 0
}
The patch removes the global.debug check, so that pressing F10 toggles global.phasing (noclip) even if debug mode is disabled.
Is it possible to recreate that patch from something that can publicly shared in a text form?
For enabling the noclip functionality, you can open the data.win/game.unx file in a hex editor, navigate to the offset 9F5044 (for the Windows v1.00 version), and change the byte from 01 to 00. This effectively changes the true in the first line of the above code to false, which is the value this variable is always set to, enabling the functionality.
feos wrote:
duuuuude5 wrote:
Line 1: Change from the name you used when creating the save file to
I'm not sure if you're asking for clarification on the instructions or asking about the name itself. If it's the latter, Undertale's text system has various control characters it uses to change things like font and text color in the middle of a line of text. This is commonly used in vanilla text throughout the game. So by putting these control characters into the name, duuuuude5 is able to show off this functionality in ways that you normally wouldn't see, in any line of text where the name is used. This can be seen in a few spots, including at 23:01 in the submission encoding.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
#6300: tendog's Linux Deltarune (Chapter 1) "Any% NG+" in 25:37.67 was rejected under a few different rules that have since been changed. This includes the acceptability of demos, starting a movie from a save file/saveRAM, and using an unofficial Linux port of a Gamemaker game. I made a more detailed post (Post #527366) in the submission thread outlining each part of the judgement that has changed, and I also made a verification movie for the submission (User movie #638402543939765159).
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
Hello, I would like to request this submission to be rejudged, as I believe it meets the criteria to be accepted and published. There were several points made in the rejection reasons and each of them I believe has been resolved since then. I'll go over each section of the judgement message and why I think it no longer applies.
This game is a demo version of an in-development game...
As Memory pointed out above, Deltarune is scheduled to release in installments: Chapter 1 released as the initial demo, and then chapter 2 released with a largely unchanged chapter 1. The next announced release is chapters 3 and 4 together as a paid release, with a tentatively hinted total of 7 chapters in the full game.
However, the rule against demos has since been removed, so this portion of the judgement should no longer apply.
First, it uses an unofficial Linux port...
This technique of porting Gamemaker games to Linux has become more acceptable since this judgement has been written. For example, [4708] Windows Undertale "Genocide ending, minimum confirms" by duuuuude5 in 1:22:29.95 is a published Undertale TAS that uses this technique to be able to TAS the Windows-only initial release of Undertale. The main principle of this self-porting technique is that Gamemaker games isolate the game data into one cross-platform file that is then interpreted by the runner, a generic executable with no game data. By setting up a Linux executable and the (unmodified) game data, the game can be run in a largely equivalent manner on a different platform. So far, this has been the only reliable way to TAS Gamemaker games that don't have Linux releases.
Due to this technique being already used in published movies, I would argue that this portion of the judgement has since been addressed and should no longer apply.
Second, it starts from a non-clean state...
This rule has been changed since the initial judgement, as submissions are now allowed to begin from SaveRAM per the movie rules. NG+ is the established standard for the Deltarune speedrunning community which is why it was used in this TAS and continues to be used in other Deltarune TASes.
In any case, we would need a verification movie...
This submission didn't initially have a verification movie to generate the save files for NG+, but I have created one and uploaded it as a userfile: User movie #638402543939765159. I've confirmed that this submission syncs to the end when run after the verification movie.
Due to the movie rules now allowing SaveRAM-anchored movies and the verification movie I created, I believe this portion of the judgement has been addressed as well.
Third, it intentionally loses time to do unnecessary things...
This was a total of 3.6 seconds spread out across three portions of the run, as detailed by tendog in a previous post in this thread on the matter. Each of these was entertaining to fans of the game and members of the speedrunning community and none of them detracted from the reputation of this TAS as the standard of comparison for Deltarune chapter 1 speedruns. Moreover, these three points in the run were isolated and didn't impact any of the routing beyond the immediate small amount of time loss. They could have been removed, but that would only bring down the final time and wouldn't add to the flair of the run. In fact, it would have taken away a fun part of the TAS that people still find entertaining to this day.
To say this wasn't well-received is quite the understatement. Multiple communities lost faith in the TASVideos site because of this portion of the judgement, and feelings of distrust continue to this day. It felt like arbitrary gatekeeping to have small but meaningful nods to the game's community being cited as rejection reasons, as if they invalidate the months of work spent optimizing the other 99.8% of the TAS.
I believe this portion of the judgement was wrong at the time and is still wrong now.
Lastly, it's worth mentioning that this TAS is no longer the fastest Deltarune chapter 1 TAS, as a new TAS was recently completed:
Link to video
However, the newer TAS uses a version that didn't exist at the time of this submission and I believe this submission should be accepted based on it being the fastest completion at the time of submission and for several years afterwards.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
Glad to see this movie was accepted! There are a couple things I want to mention since the idea of a full completion movie was brought up.
I'd consider the completion of all 93 endings to be one of the requirements for full completion, but this can't be done if you're required to wait out the Genocide Ending until the game closes. Once the game closes on your first Genocide Ending, you're locked out of the second Genocide Ending as all future Genocide routes will end in Soulless Genocide. The end point done in this movie and in RTA speedruns (upon making the choice), as well as the end of timing in the Genocide Ending movie (upon closing the last textbox), still happen before the autosave. If there were to be a full completion movie with all 93 endings, closing the game before the Genocide autosave would just be an inevitability that doesn't really have a better workaround.
There can be a similar discussion for the Neutral Endings as well. Although it wasn't shown off in this movie, there's a strat in the True 100% category where several Neutral endings are completed one after the other without letting the game autosave. Although the ending is counted upon touching the door, the autosave doesn't happen until the title card shows up. So by touching the door and immediately closing the game, you can respawn in the final room after Flowey, use various items to change the ending, and then touch the door again to get a new ending. Unlike the Genocide Ending end timing, this one is not strictly required for completing the endings. However, it would likely be a major routing change to move the end timing because of this strat, as it saves an estimated 1 hour for RTA runs. If I were to work on such a TAS, I would most likely maintain the same end timing as RTA runs rather than wait for the autosave.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
If this is the worst decision in TASVideos history then TASVideos must have some impeccable history... This TAS is a legend at this point and I'm happy to see it accepted! Truly a historic moment in site history.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
feos wrote:
I've always understood softlock as being able to move but being unable to advance in the game (you're technically stuck).
There's a common type of softlock where you end up stuck in place, unable to move or influence the game, while the game around you continues to advance. It happens in several games and is generally understood by most people to be a softlock. In cases like that, I don't think I've seen anyone describe it as a hardlock, due to the game clearly and often visibly continuing to run. So the game is "playable" in the sense that gameplay continues to happen, but the player loses the ability to influence the game.
The state achieved in this TAS is simply an extreme example of that kind of state, where the game continues to run but the player loses the ability to influence the game. In fact, the player can even delay the softlock indefinitely by frame-perfectly mashing arrow keys. In this state, the game continues to run in the strictest sense of the word, but because the game is running within a single frame, no more input polling will happen.
It's certainly right there on the line between a softlock and a hardlock, but the main thing that convinces me it's closer to a softlock is that as far as the game engine is concerned, the game is running completely fine. The window continues to be displayed and the music continues to play. This is as opposed to when a Windows game stops responding, for example, where the window is shaded and eventually Windows prompts you to shut it down. That doesn't happen in this case, as it's just the game running its code forever. Such a state can even be triggered intentionally by the game developer. It's usually not a great idea to do this in Gamemaker games, but some people still do it anyway.
You could argue that this isn't enough code to call it gameplay, but then I'd ask, where would you put the line between game code that isn't gameplay and game code that is gameplay? Does it just need to advance through multiple parts of the code? Does it need to repeat the whole game loop? but what if the game is coded to pause in a tight loop to begin with? Do screen elements need to be moving? but what if it's an area where nothing on the screen moves anyway? You could end up diving down a rabbit hole of subjective definitions on how much of the game needs to be running for it to count as gameplay, which is why I think it's valuable to have a more concrete test: is it executing game code? If yes, then it's a softlock. If no, then it's a hardlock/crash. There are still edge cases that would need to be looked at more subjectively like error handlers that are part of game code, but fortunately that doesn't apply here.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
I managed to improve this 4-second TAS by 3 seconds using a framerate of 1 billion on the splash screen. The reason this saves time is because the splash screen is displayed for 180 frames regardless of the fps.
I'll update the submission text in a bit, but for now here's the new ltm file and an encoding.
User movie #638166136878274658Link to video
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
ais523 wrote:
Isn't this a hardlock, rather than a softlock? Softlocks require the game to be running enough of the main game loop that they're reacting to user input to at least some extent (the classic example used to be something along the lines of being stuck in a wall, allowing you to pause the game but not to move), whereas this seems to be an infinite loop that bypasses any player control of the game at all (if the name screen were reacting to the player's keypresses, that would presumably escape the loop.
Of course, that doesn't really negate any of the interest in the run – you just have to change the category name.
I've taken "softlock" to mean that the game is still executing game code in some way, and although nothing is actually happening here, game code is still being executed. For example, the music continues to play out and the code within the loop is still being run normally. As far as I understand it, this can be any amount of code as long as it's the game's code that's running.
My understanding of "hardlock" is that it refers to an actual game crash, taking execution outside of the game loop. Gamemaker games have a distinctive crash screen for this situation and there are certainly ways to get that to happen in Undertale. (In fact there's even a speedrun category called "10 Unique Crashes")
When messing around with this on the Windows version of Undertale, I'm still able to interact with the game window itself so maybe that counts as being able to handle user input? It's certainly in a grey area at the very least but I think there's at least an argument to be made that it could be considered a softlock.
I think within the context of Undertale, it makes sense to consider this a softlock. Hardlocks in Undertale almost always come with a crash screen detailing a code error of some sort, and the rest of the time they close the game unexpectedly. Softlocks in Undertale almost always take the form of being stuck in place in-game, unable to move or open the menu or do anything other than close the game. It's a relatively easy line to draw here between locks that halt game execution and locks that continue game execution, and although I can certainly see that definition break down in other games, I think it works fine here.
Either way, it's a lighthearted submission anyway, so I'm not too bothered if it's actually considered a hardlock after all.
There are a few places where I get better RNG than Ocean, and there are also strats I use in this TAS which aren't used in his TAS (e.g. "Misogynist Ice Puzzle Skip"...
The ice puzzle strat was the same, although you did save one additional frame in movement optimization in that room.
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
Optimization looked good, at least in terms of the major strats and routing.
There are a few spots where you could save some frames. I know the first seed puzzle at the start of Waterfall was recently optimized a bit more (picking up the leftmost seed is faster), although that was probably discovered well after you finished that part.
In terms of the save file you started from, I did notice one minor improvement you missed out on. If you finish the first phase of the Mettaton fight while creating the save file, Mettaton's text during the run is shorter, allowing you to wrong warp out of the room. I believe this saves about 7 frames.
Overall it's a pretty neat run!
Experienced Forum User, Published Author, Player
(173)
Joined: 8/18/2020
Posts: 18
In terms of the routes themselves, TPE requires some extra content to be completed such as the dates and the True Lab. Getting access to the True Lab requires a Neutral ending to have been completed, so Asgore and Photoshop Flowey are also included in the route. However, due to the dates and other requirements, the Neutral ending completed in TPE speedruns is significantly slower than the Neutral ending by itself. For reference, the Neutral ending in the TPE TAS is 5 minutes 44 seconds slower than the Neutral ending in the Neutral ending TAS. In that sense, the routing change is pretty major.
As far as the current TPE TAS compared to this Neutral TAS, the TPE TAS misses out on several major timesaves that the Neutral TAS includes. Some of these were discoveries made after the TPE TAS (such as SGS, the ~30 second skip at the start of Waterfall) and others were known at the time of the TPE TAS and just not implemented. Notably, the persistence glitch is a new discovery that happened after the TPE TAS, which allows for skipping the Mad Dummy fight and getting the Burnt Pan early, both of which are also optimal in TPE. Since this wasn't discovered at the time of the TPE TAS, that TAS does the whole Mad Dummy fight (and loses two turns to the fastest fight known to be possible/one turn to the basic RTA fight).
There are other sources of optimization in the Neutral TAS that weren't done in the TPE TAS, such as doing RNG manipulation. A good example would be the Photoshop Flowey, where the Neutral TAS does RNG manipulation for the Book, Gun, and final phases to make the fight go as fast as possible. The TPE TAS doesn't appear to do this and as a result loses time on all three phases, including one turn on the final phase. This results in over 6 seconds of timesave due to optimization in the Neutral TAS Photoshop Flowey fight.
There's a pretty long list of possible optimizations to the TPE TAS in the Youtube comments of the TASVideosChannel encoding, posted by RichConnerGMN. This might not be fully exhaustive but it's good for getting an idea of how many optimizations were implemented since the TPE TAS.
