Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
AntyMew wrote:
However, it would be very possible to build the game for x86 Linux and then drop in all the necessary non-GPL assets from an official release.
This seems to basically be an extended case of TASing PC games by porting them to Linux (when possible, e.g. GameMaker or Unity games that run the actual game code in a virtual machine instead of compiling to native code), only in this case you are simply porting the game to x86. We already have a publication which does that: [4579] Windows Unworthy by keylie in 24:05.40. We also have [4496] Windows Backyard Baseball "Pick-Up Game" by TiKevin83 in 04:45.05, which is a publication that unofficially ports the game to Linux using (as far as I understand it) an engine replacement known as ScummVM. So, I'd say the scenario with OneShot here is acceptable, and in fact even more acceptable than those previous two examples, since we're only porting it to a different architecture while keeping the operating system the same.
In general, any unofficial port is allowed as long as it doesn't introduce anything different gameplay-wise from the original game, and is reproducible and syncable. You're even allowed to patch the emulator or TAS tool if needed - we've accepted #7242: duuuuude5's Windows Undertale "Genocide ending, minimum confirms" in 1:22:29.95 on the basis that it's syncable using a release build of libTAS with a backported patch from a later release.
AntyMew wrote:
more broadly speaking it's an interesting question. What if the engine also requires some source code edits to make it TASable?
That's a bit iffy, but in theory at least, we would be able to audit exactly what the patch does and make a determination as to whether it introduces something different gameplay-wise. (Too bad VVVVVV couldn't test this for us, it's already such a good, well-behaved game that it was TASable in libTAS and we didn't need the source code release at all.)
As long as the run is syncable and the patches to the game reproducible and reasonable, I don't see why we couldn't accept them.
AntyMew wrote:
What if the engine is not open source, and a mod of some sort makes it TASable?
That's more tricky. I vaguely recall there being a bit of an effort to write the rules for game- or engine- specific TAS tools (e.g. Source Pause Tool, Minecraft TASmod, and so on) and make them acceptable, but I'm not sure where that's at right now. Regardless, I think in the future they would be acceptable as long as the tools are good enough (e.g. replay is input-based and not state-based so you can't modify the replay to do impossible things).
AntyMew wrote:
What of downporting it to an earlier OS, ex. Windows XP? Etc. etc.
Again, this seems to just be an extended case of porting Windows games to Linux, and like I said above we have two movies published based on that. So I'd say it's generally acceptable (as long as it syncs and is reproducible and doesn't introduce massive gameplay differences).
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
I can report that this syncs and dumps with no issues (make sure to have -force-gfx-direct), though if you don't have a 4k monitor you'll need to check the virtual screen resolution to be 3840x2160. It's much faster than the current RTA world record and since it's a point-and-click game there's not much to mess up in terms of optimization.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
Nickolas wrote:
Is there an option to display the forums and/or site with something approximating their old appearance, similar to what Reddit does with old.reddit.com? I vastly prefer the previous appearance and layout.
No, there is not. Both of the sites are so different, it would be vastly too much work to maintain for a volunteer-run site like ours.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
KirbyComment wrote:
I thought it's best for a forum post to not get into the specific potential issues until I make a submission, but the short of it is that when I play back the recording, there's some stuttering going on which may just be on my end. And then there's one specific frame where the menu bar of the emulator activates and freezes the game until you click the window of the emulator. This was accidentally left in and from my attempts to tinker with the wtf-file I couldn't remove this freeze without either desyncing the TAS or Hourglass failing to read the file at all.
Yeah, this sounds like something that can be removed in post. Doesn't require editing the movie.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
KirbyComment wrote:
I did realize that libTAS is a thing during the making of this TAS, but I honestly don't have the faintest idea about how this tool works.
It works just like Hourglass, except it runs on Linux and it's much, much more reliable.
KirbyComment wrote:
I don't have a Linux device either, so I dismissed trying to do anything with it.
It sounds like you think Linux devices are some sort of special sub-category of desktop computers, but they aren't. You can just install Linux on your computer. It's an operating system just like Windows (except better).
But you don't even need to install and boot into it natively. You can install it in a virtual machine, or better yet, install Windows Subsystem for Linux (WSL), which basically lets you run Linux applications on your Windows machine without even needing a VM. There's even a guide to use libTAS with WSL, it's a pretty popular option.
KirbyComment wrote:
When I use Hourglass with Neko Project, not once did I run into desyncing issues, so on that end it should be fine.
If I remember correctly, the problems with Hourglass are that it's prone to crashing and has audio dumping issues. Oh, and that you need to run it on Windows XP (i.e. an outdated, unsupported, insecure operating system). But I digress. Really the biggest problem is that it's running on an operating system actively hostile to debugging of the caliber Hourglass needs and intentionally lies to userspace, whereas Linux doesn't have this handicap from the get-go.
KirbyComment wrote:
There are a couple of little things that may require some editing to whoever would encode the TAS recording.
Depending on what you're talking about, this might not even require editing the movie in any way. But you would need to be more specific here.
KirbyComment wrote:
If there is a problem there, I may wanna try to figure out what I can do with libTAS (provided it's compatible with Hourglass' file format because I'm not redoing the TAS itself).
Well, .wtf (Windows TAS file) and .ltm (Linux TAS movie) are two completely different file formats. But in theory it should be possible to write a converter between the two (though it will be a bit annoying because Hourglass made the sub-par decision to be a binary file format, whereas libTAS uses plaintext which is better).
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
KirbyComment wrote:
My TAS uses Hourglass r81 to record and play back inputs from another emulator (Neko Project 21). This is because the game runs on the NEC PC-98 for which (to my knowledge) there's no emulators that support TAS recording tools.
Have you considered using libTAS + WINE instead? (That is, run Neko Project in libTAS, and libTAS will automatically run it through WINE so it can run on Linux). Hourglass is one of those tools that are 'Accepted but not preferred' due to various reasons. (And yes, libTAS + WINE is not listed as being officially supported, but just like libTAS + Ruffle before the first published Flash movie, if it syncs and can be reproduced reliably then there's no reason to not accept it.)
KirbyComment wrote:
Now I don't know how this site treats TAS submissions like this, where you use a TAS program to record another emulator. And for that matter, is this allowed?
Yes, this is allowed. We have [4634] Flash Super Smash Flash "Adventure Mode" by ikuyo in 02:28.87, which runs a Flash game inside Ruffle (a Flash emulator) being TASed by libTAS (a Linux TAS tool). Not to mention other cases like PCem being TASed in libTAS.
KirbyComment wrote:
Since the game in question runs on a PC-98, the framerate is also somewhat unusual. The game runs at 56.4 frames per second. I'm not sure if this would in any way be problematic for the judging/encoding process.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
First off, we don't use the "any%" branch label, due to its ambiguity (this RTA run calls itself "any%" too, but it goes for the neutral ending). The more appropriate branch label for this run is probably going to be "hard mode".
Anyways, this syncs fine and dumps fine. Here's the movie file with the length corrected. Note that the best way to run this game is to use the Steam runtime, i.e. launch libTAS with ~/.steam/bin/steam-runtime/run.sh libTAS. Make sure to select the old_version_101 Steam beta.
I would also like to note that the submitted movie file ends on Frisk slashing Toriel, and stops at her saying "You..." whereas the temporary encode advances past that dialogue and gets to the "UNDERTALE [HARD MODE] Coming... Maybe, Eh. don't count on it." screen. The movie file should probably be updated to get to that screen.
The movie seems optimal, but I can't check because for whatever reason (some weird GameMaker jank, probably), Undertale wants the XFree86-VidModeExtension and will refuse to launch without it, so I can't launch it inside my Xephyr X server, so I can't use savestates. Speaking of awful GameMaker jankiness, this game is horrible in a tiling window manager. By default it launches maximized, but I can't blacklist it in my i3 config because its class and instance are completely blank, and i3 doesn't seem to be able to support blacklisting blank names (it results in a syntax error), and libTAS modifies its title so I can't use title either!
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
Syncs and dumps fine. You do need to specify -g gl like any other Ruffle game, because libTAS doesn't support Vulkan.
Also make sure Ruffle doesn't open maximized because this game uses a mouse on the main menu and mismatched screen sizes causes a desync. (I'm probably the only one with this problem because I use a tiling window manager...)
Regarding optimization, I did find this TAS from last year made by the same people, which is faster. I'm assuming this comes down to using version 2.5 of the game while this submission uses version 3.0, and the submission says that version 2.5 can't be used in Ruffle? I did find this Ruffle issue (first castle level results in softlock on 2.5), which is quite unfortunate. I think it's fine to accept while knowing it will be obsoleted later if/when Ruffle supports 2.5 and a new TAS is made on that version.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
Syncs fine and dumps fine. You do indeed need to set the virtual screen resolution, or else it either doesn't get past the title screen (I'm guessing this is due to having to click on the "Play" button with the mouse) or it doesn't get past the Unity splash screen? Weird Unity jank, I guess. And also you should never under any circumstances ever fast-forward the game, or else it desyncs.
I didn't have the option to set the screen resolution to 1366 x 768, so I went with 1280 x 720, which seems to sync fine anyway.
This game is pretty hard to optimize because not only does it run slow in realtime and you can't use fast-forward, but there's soft-body physics so any change is really hard to resync. Even being one frame off changes your angle and trajectory drastically. Not to mention that there are tons of moving platforms so no change is guaranteed to save any time unless you can save a platform cycle. So this movie seems optimized enough for me.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
Who's to say that any replacement term won't end up walking the euphemism treadmill again and take on the exact same negative, permanent connotations as "rejected" does now?
Also, should we make a poll for this?
It works in terminal, but not in libTAS. You still need to enter something valid in "Game executable".
At minimum, you need to specify the java binary itself as the game executable, and place -jar game.jar -path blahblah -silent etc. in command-line options. This is trivial if you take one second to actually think about what it actually means when you run a command: The first word you put in is the binary you're executing, everything else after that is just command-line arguments you provide to it.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
zaphod77 wrote:
Now we need to make a new VVVVVV version that patches this, and see if someone else can STILL credits warp.
Lol I'm not patching this.
The previous GEG was patched because it was easy to accidentally trigger text storage when playing casually (just exiting and entering back in with the text prompt up). Here in this case you have to deliberately do it, so there's no reason to patch it.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
slamo wrote:
There's still the matter of what to name this. There is already a "game end glitch" branch on 2.3, and this very obviously should not fall under 2.0 anymore. Maybe just calling it "Glitchrunner" would be the cleanest way to do this?
I was thinking it be called "2.0 glitchrunner", as it's only possible when selecting "2.0" in glitchrunner mode. I added a 2.2 mode as well but it only emulates glitches present in 2.2, and 2.2 fixed unbounded gamestate incrementing.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
Evan0512 wrote:
I heard that Ruffle updates the app once a day, I tried to update it using sudo apt update && sudo apt upgrade, but it doesn't update Ruffle.
Yes, that doesn't update it. sudo apt update only fetches the latest stable versions of packages from your package manager (apt)'s repositories; Ruffle hasn't had a stable release yet so it's not even in your package manager. To download the latest version of Ruffle, you'll have to go to the releases page on GitHub.
Evan0512 wrote:
Maybe I should try using Ruffle in Hourglass (does Hourglass have mouse support)?
No, it doesn't. And you really shouldn't think of Hourglass as a viable option; last I heard it only worked in Windows XP! (and barely, at that!) Which is a 21-year-old operating system at this point. There's no chance in hell it would work and it's a better use of your time to use libTAS + Ruffle instead.
Thanks. After taking a look at the inputs, I do think it's because this run skips over (most of) the delays in the gamestate sequences, which I'm pretty sure is possible on 2.0 as well.
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
slamo wrote:
From the gameplay portion to the ending dialogue is about 4 seconds faster - could you explain why? Is this something that was possible in 2.0?
It's hard to tell without seeing the Hourglass inputs, but this probably comes from strategically pressing ACTION to skip over the delays in the gamestate sequences (which I did in my run too).
Experienced Forum User, Judge, Moderator, Player
(196)
Joined: 7/15/2021
Posts: 110
Location: United States
feos wrote:
When using the runner from discord I get
./runner: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
even tho it's there in usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
EDIT:
Turns out you can just launch libtas with steam libs and the game will run fine
~/.steam/bin/steam-runtime/run.sh libTAS
For future reference (and who knows, maybe using the Steam runtime is better), you can debug these kinds of errors by running strace, e.g. strace ./runner. It will show all syscalls that the binary makes, including every filename it looks for to find the library. To show only syscalls related to files, pass --trace=file, e.g. strace --trace=file ./runner. And for better usability, you can pass -o to redirect the strace output to a file, e.g. strace --trace=file -o output.txt ./runner.
