Samsara
She/They
Site Admin, Expert player (2376)
Location: Northern California
Joined: 11/13/2006
Posts: 2899
Location: Northern California
I'm going to go ahead and say that everything we would need to do to account for HK TASing in its current state is far beyond what we should be accounting for. Just reading through the list of things we need to change or keep in mind makes me think that the process is likely to fail at any given point, and strictly speaking as an Admin and the head of judging, I can't imagine putting staff through this with every new submission. It may have to wait until libTAS is better able to support Unity games or HK itself so we don't have to worry about the nondeterminism. As for the philosophical side of the arguments, I totally understand the concerns there. The movie rules and submission instructions were atrociously elitist for a very long time, and even after the massive amounts of overhauling I and others have done over the past few years to fix all of that, there's still a lot more work that needs to be done for everything on the site to accurately reflect our current policies. My ideal for TASVideos is for it to be an expansive archive and repository for TAS information, with the community focusing more on collaboration and support rather than trying to be the absolute best at everything. This thread in particular isn't meant to be us trying to force other communities to adhere to our standards, it's meant to be us trying to support everything we possibly can within reason in order for us to be a more complete source of information, but given our past I don't blame anyone for thinking otherwise and still getting bad vibes from us. If there's anything I can do to correct that, I'm absolutely willing to do it. I'll put it this way: Even if it's too much for us to support HK TASes on a technical level right now, I still want to and would love to put in the effort to supporting the community in any other possible way we can.
TASvideos' Third Strongest Site Admin 🩵 Currently working in limited capacity.
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Memory
She/Her
Site Admin, Skilled player (1663)
Location: Dumpster
Joined: 3/20/2014
Posts: 1838
Location: Dumpster
Personally willing to consider some alternate methods of displaying runs that might not be able to run in one coherent segment. Honestly found that being extremely virtuous about certain things like has to sync in one go is just going to annoy people from outside communities. The big issues we have atm are largely technical and/or related to manpower. So such features might be a ways off.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Joined: 10/15/2023
Posts: 3
One option that would open things up a lot would be a way to list unverified/unverifiable videos (with a clear label as such), Because, I agree, I wouldn't want to subject verifiers to having to try to sync my movie files even if I cared about the stamp of approval; it's just too time-consuming and painful of an ordeal to ask volunteers to undertake. That said, I think there are some folks in the HK TAS community who'd be more interested in getting verified in some way, but I definitely don't think the traditional method of TAS verification would work for HK without fundamentally new PC TASing technology (even if it were more reliably deterministic, the slow encode speed is still quite onerous.) Another option would be something akin to 'rta verified', i.e. verified in accordance with the standards normally applied at speedrun.com for rta runs of equivalent categories. Most of the 'serious' HK TASers are following rta rulesets (with the obvious exception of using tool assistance) and so the only form of verification that's really applicable is whether it's following those rules. Which, of course, is game-specific, thus why every game on SRC has its own set of moderators/verifiers. Fundamentally I think the issue is that there's no way to create a single unified ruleset that makes sense for TASes in all types of games, especially when complicated PC games are in the mix.
Emulator Coder, Site Admin, Skilled player (1278)
Joined: 4/17/2010
Posts: 11869
Jarlyk wrote:
That said, I think there are some folks in the HK TAS community who'd be more interested in getting verified in some way, but I definitely don't think the traditional method of TAS verification would work for HK without fundamentally new PC TASing technology (even if it were more reliably deterministic, the slow encode speed is still quite onerous.)
If the game can run on a machine like this (or anything else PCem/86Box supports) running Windows XP or Debian 12, that might eliminate all of the verification/encoding problems.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 10/15/2023
Posts: 3
feos wrote:
If the game can run on a machine like this (or anything else PCem/86Box supports) running Windows XP or Debian 12, that might eliminate all of the verification/encoding problems.
Given that HK encodes at about 1/20th real speed using libTAS, which is executing natively with hooks to control reported time rather than via emulation, I imagine the encoding time on an emulator would be abysmal. It could be interesting for someone to try, since the biggest likely culprit for our nondeterminism issues is multithreading, but I'm not particularly hopeful that it would work well. HK is just not a very well-optimized game. (:
Emulator Coder, Judge, Skilled player (1309)
Location: California
Joined: 2/26/2020
Posts: 915
Location: California
The WinXP+PCem combo just wouldn't be viable at all here (and really this applies for most modern-ish PC games):
  1. This is an emulator. An emulator for a really old PC. It's not like libTAS being an "emulator" simulating an extremely powerful machine (with its ability to just lie about time). Rather, you will be dealing with running the game at however fast that really old PC can run it (which for Hollow Knight sounds like it would not be able to maintain full speed at all, so you can imagine that, assuming you were running PCem itself at full speed, you'd still be running the actual game at 5-10 fps or whatever, and that's going to be reflected in an encode.
  2. Hollow Knight, looking at its Steam page, already has a Windows 7 requirement, which cuts off support with the WinXP+PCem combo.
  3. Hollow Knight also, on it's steam page, seems to have a D3D10 requirement. This also cuts off WinXP, which only supported at most D3D9. Even then, the best GPU that PCem supports (3DFX Voodoo 3 3000) only supports up to D3D6.
  4. There is also a likely chance that even the 32 bit version (which apparently exists for HK?) wouldn't work, as it's highly probable it is built assuming SSE/2 support. With more modern compilers (e.g. more modern MSVC / gcc) the developer needs to add additional special flags to actually make a compiler spit out something not making these assumptions.
  5. 2 could in theory be worked around by using some modern Linux distro. But then you are swapping out 3's D3D10 requirement with some OpenGL requirement. The best GPU that PCem supports only supports up to OpenGL 1.1. For context, this predates support for shaders (also similar case with D3D6; D3D8 was the first D3D to support shaders). This itself is going to eliminate practically any modern game that uses the GPU as they are going to be using shaders, not the ancient fixed function pipeline ancient GPUs used (which is even possibly outright unavailable for newer GPUs, so even more reason for modern games to use the more modern APIs which that Voodoo card fundementally cannot support).
  6. 5 could in theory be worked around by forcing software rendering. Which just makes 1's issue get turned up to an insane level. Keep in mind that software rendering is going to be happening on that emulated CPU. An emulated CPU that only has 1 core (and no hyperthreading magic), and is only running at 450MHz, and predates even the basic SSE extensions that have been present for over 20 years.
Simply be, PCem is very much not a magic bullet once we talk about any modern-ish PC game. Especially not Unity games (along with most modern-ish PC games), which would all use shaders, and so fundementally would not work here.
Editor, Experienced player (582)
Joined: 2/11/2018
Posts: 279
Posting this to possibly refer to in future: Trying to make Minecraft acceptable for TASVideos
🇺🇸 United States
Joined: 3/10/2014
Posts: 13
Location: 🇺🇸 United States
Writing after a quick chat with Memory about the potential for the Dustforce single-game-tool of "Dustmod" / "Dustforce Script" to be considered and validated/approved for submissions. Past discussion for reference: https://tasvideos.org/Forum/Topics/14003?CurrentPage=2&PageSize=25&Sort=CreateTimestamp Based on what Memory wrote: The 3 main hurdles from what I understand from the "loose but vaguely also ideally tight to most/all of these requirements" from this thread https://tasvideos.org/Forum/Topics/22894?CurrentPage=1&PageSize=25&Sort=CreateTimestamp 1. Dustmod afaik is not open source because it was essentially built ontop of the game's source code itself. The developer of dustmod was given permission and access from the Dustforce dev's directly to the source code to make dustmod possible. Open sourcing it would run into copyright problems. 2. Dustforce/Dustmod lacks an AV dumping tool. I dont know about KKapture i'd have to look into it. 3. a movie parser does not exist for Dustforce. Hopefully the documentation in 6. is sufficient for that to be created? Non-issues: 4. Playback across PC specs is achieved. 5. Run time can be determined by the # of total input frames of the TAS, dustmod standardizes load times. The game runs at 60fps. 6. Documentation for how to run TAS input files can be found here https://dustkidblog.wordpress.com/2016/08/07/nexus-tasing-with-dustmod/ The bottom of that documentation page has an example script file, to "play the tas" or access "the tas" as a file it is literally just a notepad .txt document with the proper Dustforce script formatting. You simply input into dustmod a "fullgamessalllevelstas.txt" into the field and it will play the inputs within that script inside the game itself. This is how the youtube and streams were created as linked by Keylie in the game thread at the time. We have had intermittent contact with Kilaye and I'm not 100% certain of the most recent status but I believe the input calling dustforce uses causes issues with libtas and so while running Dustforce's scripts through dustmod DOES work on libtas (as it isnt "polling" to send inputs but "reading" the input file for what inputs to send), porting the scripts and running inputs natively through Libtas as an emulator more directly/standardly does not fully function. It would at least be a larger undertaking that is less likely to be pursued. Running vanilla dustforce inside libtas also does work, but playback is inconsistent due to the issues which dustmod has patched.
Emulator Coder, Site Admin, Skilled player (1278)
Joined: 4/17/2010
Posts: 11869
TheBirdOfPrey wrote:
1. Dustmod afaik is not open source because it was essentially built ontop of the game's source code itself. The developer of dustmod was given permission and access from the Dustforce dev's directly to the source code to make dustmod possible. Open sourcing it would run into copyright problems.
While open source would have been ideal, it sounds like a case that requires a little bit more leniency than with acceptable emulators.
TheBirdOfPrey wrote:
2. Dustforce/Dustmod lacks an AV dumping tool. I dont know about KKapture i'd have to look into it. We have had intermittent contact with Kilaye and I'm not 100% certain of the most recent status but I believe the input calling dustforce uses causes issues with libtas and so while running Dustforce's scripts through dustmod DOES work on libtas (as it isnt "polling" to send inputs but "reading" the input file for what inputs to send), porting the scripts and running inputs natively through Libtas as an emulator more directly/standardly does not fully function. It would at least be a larger undertaking that is less likely to be pursued. Running vanilla dustforce inside libtas also does work, but playback is inconsistent due to the issues which dustmod has patched.
If you run the movie inside libTAS and capture video using libTAS, will that work?
TheBirdOfPrey wrote:
3. a movie parser does not exist for Dustforce. Hopefully the documentation in 6. is sufficient for that to be created? Non-issues: 4. Playback across PC specs is achieved. 5. Run time can be determined by the # of total input frames of the TAS, dustmod standardizes load times. The game runs at 60fps. 6. Documentation for how to run TAS input files can be found here https://dustkidblog.wordpress.com/2016/08/07/nexus-tasing-with-dustmod/ The bottom of that documentation page has an example script file, to "play the tas" or access "the tas" as a file it is literally just a notepad .txt document with the proper Dustforce script formatting. You simply input into dustmod a "fullgamessalllevelstas.txt" into the field and it will play the inputs within that script inside the game itself. This is how the youtube and streams were created as linked by Keylie in the game thread at the time.
Making a new movie parser is quite easy, if we get a pull request that implements support for your movie format, we'll gladly merge it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Memory
She/Her
Site Admin, Skilled player (1663)
Location: Dumpster
Joined: 3/20/2014
Posts: 1838
Location: Dumpster
While open source is ideal, I believe as long as there's enough transparency as to how dustmod works and what can be done with it, there shouldn't be too much a problem in my eyes. It will be assumed that TASes done through dustmod would match or be at least close to what can be done on the base game if one were able to do the same inputs. If there are additional modifications to say physics or something, that should be disclosed to maintain trust with the community and the audience. EDIT: To clarify, I don't think you all would intentionally hide such physics changes, it's just that should be the underlying principle.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
🇺🇸 United States
Joined: 3/10/2014
Posts: 13
Location: 🇺🇸 United States
Memory wrote:
While open source is ideal, I believe as long as there's enough transparency as to how dustmod works and what can be done with it, there shouldn't be too much a problem in my eyes. It will be assumed that TASes done through dustmod would match or be at least close to what can be done on the base game if one were able to do the same inputs. If there are additional modifications to say physics or something, that should be disclosed to maintain trust with the community and the audience. EDIT: To clarify, I don't think you all would intentionally hide such physics changes, it's just that should be the underlying principle.
Yes that is 100% the underlying principle, we have verified that our TAS replays do playback identically and match to baseline game behavior from a player-inputs perspective (meaning outside of the camera shake and stuff) on a vanilla version of the game. There hasn't been any dustmod physics-related changes for many many years at this point (the camera shake and load race conditions are the only ones that were ever made afaik) it has been stable and stagnant of changes as far as anything related to TASing goes.
Editor, Experienced player (582)
Joined: 2/11/2018
Posts: 279
I haven't been involved in the site much recently, but based on the available evidence, I believe there's been extensive discussion amongst staff regarding support of single game/TASing tools, and similar topics. I don't know what these discussions have focused on (whether it's more about the rules or the implementation), but my concern is that this is not being discussed with the wider community. Maybe this is fuss over nothing, but I can't really know what's being discussed in private, and decided to bring this up after considering it for the past couple of months.
ikuyo
She/Her
Senior Judge, Experienced player (610)
🇨🇱 Chile
Joined: 7/8/2021
Posts: 183
Location: 🇨🇱 Chile
Hi! Well, I've been at the forefront of several discussions about single game/engine support. A lot of it tends to come in spurts of specific interaction as interest dies down, and at least for Ocarina of Time that has rung quite true. The way I personally see it (and as a disclaimer, this is not the official TASVideos stance, just my personal opinion) is that game engine and single game tools that can be reliably proven to sync, are open source (so the changes to game behavior can be documented and tested) and can provide accurate timing measurements should be supported provided we have parsers for them. I put those ideas at the forefront to ensure they do what I think are the most important elements of TAS work: open collaboration (allowing anyone to get into the work and share it with others reliably), curiosity, and open access to information. Could you be more specific about what are the issues you currently see in regards to our intent to support those tools?
GuanlongX wrote:
auuuugh my face when games are creative and cool and don't fit arbitrary rulesets
Editor, Experienced player (582)
Joined: 2/11/2018
Posts: 279
The site's requirements for adding a new emulator/TASing tool are laid out in Wiki: EmulatorResources/Requirements. These requirements are rarely tested though, I believe in the past 7 or 8 years, the only new tools to be supported by the site have been Citra (2022) and libTAS (2018).* Adding many new single-game TASing tools for submissions, if that's the intention, will be quite a significant shift for the site, even if it was technically always allowed by the requirements. And I've been concerned such a thing could suddenly drop without public discussion beforehand. I'm not necessarily against any such changes; I did comment on this thread in 2023 questioning how progress could be made regarding this. *I'm not counting GBAHawk because it's just BizHawk. There have been emulators run inside libTAS being permitted, but these don't have to go through the whole process
Emulator Coder, Site Admin, Skilled player (1278)
Joined: 4/17/2010
Posts: 11869
The thread about this is pinned on forum since 2021, and on Discord since 2022. If getting any progress at all on this front still somehow feels sudden, I don't think anything can be done to make it even more gradual.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Editor, Experienced player (582)
Joined: 2/11/2018
Posts: 279
Indeed it's possible no one cares. But this thread has been largely dormant since 2024, and has not been used to discuss the implementation of the Celeste or GZ parsers that has happened over the past few months. So unless users are following GitHub PRs, would they even know about such changes? Edit: To clarify, adding a movie parser to the site in itself is pretty inconsequential. But I have a feeling there is more than that happening
Emulator Coder, Site Admin, Skilled player (1278)
Joined: 4/17/2010
Posts: 11869
All new per-game parsers are added based on what is discussed in this thread, conceptually. GZ discussion happened in GZ submission thread.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
ikuyo
She/Her
Senior Judge, Experienced player (610)
🇨🇱 Chile
Joined: 7/8/2021
Posts: 183
Location: 🇨🇱 Chile
I would like some further clarification. Is the issue that we are not properly disclosing current progress on site improvements and changes? Is the issue that our community feels Staff does not inquire with them enough before proceeding with site changes? Is it a combination of both? Is it something else? The former and latter issues have different solutions, and while I can think of a couple ways to address the former, I am not entirely sure how you all think we should handle the latter.
GuanlongX wrote:
auuuugh my face when games are creative and cool and don't fit arbitrary rulesets
Bigbass
He/Him
Moderator
Location: Midwest
Joined: 2/2/2021
Posts: 286
Location: Midwest
Randomno wrote:
But this thread has been largely dormant since 2024, and has not been used to discuss the implementation of the Celeste or GZ parsers that has happened over the past few months.
The discussion for potential acceptance and support of GZM movies has been largely discussed in the thread most relevant to having that discussion. Celeste's support was discussed more so with the Celeste community directly. Understandably, the Celeste community does not interact on this site since there's no reason for them to; they've got their own chat space, TAS tooling, and leaderboards. Plus, their community is much larger than TASVideos. As such, in order to properly determine what interests/goals they have and what, if anything, we could do to support curating their work on this site, we needed to discuss it elsewhere. Speaking from my own perspective, I think both the staff and the community have been pretty vocal about supporting and accepting more and more TAS content in recent years. To me, accepting the OoT practice ROM and Celeste feels like the natural progression of that goal.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Memory
She/Her
Site Admin, Skilled player (1663)
Location: Dumpster
Joined: 3/20/2014
Posts: 1838
Location: Dumpster
Relevant note: after asking, Masterjun wrote up a guide on making parsers for the site: https://github.com/TASVideos/tasvideos/wiki/How-to-add-a-Parser-for-a-new-Movie-File-Format
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero