Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
The category is any%, so it is the least arbitrary category chosen for this game, and TAS timing is the default timing method.
You didn't describe other strategies that would lead to a better time. You are talking about overkill, but what set of weapons would lead to more damage potential that wouldn't require the fight to be significantly longer?
Also, I'm sorry but given the nature of the game (heavily rng dependent), you can't expect it to be optimized to the frame. There are probably a few frames that can be saved with this strategy, but it would need exploring a much larger space of randomness. It may feel like a lame excuse, but I spent a few hours on this last fight alone, getting a better rng may requires 10 times more.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
ais523 wrote:
I'm not sure it makes sense to end input early in cases where that causes the use of a suboptimal strategy for the fight. It's delaying the end of the run by a substantial amount, and is saving very little in terms of ending the input (I'm not sure, but most likely it's a few frames of luck manipulation).
Isn't this the case of most "end input early" cases, to have a suboptimal end? Going for an optimal would need to send the second volley manually, to activate hacking/manipulate luck/drones/etc... which would cost at least 20 seconds (time for the flak 2 to recharge).
ais523 wrote:
(I also wonder if sufficient amounts of overkill might make it so that you don't have to resync the Flak, and thus save time when it comes to ending input, too.)
Sorry, I don't understand what "amounts of overkill" means.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
There are subtitles if you didn't see them. Otherwise, I guess I could dump all the events I encounter.
Regarding pre-igniter glitch, I couldn't use it unfortunately. When entering phase 1, the clocking makes all non-powered weapons to discharge, so that I can't keep charged weapons for the next phases.
Phase 3 fight could be speed up, yes, but it won't change the final time which is based on the last input (beginning of the fight).
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
Score is computed from collected scraps, number of visited beacons and number of destroyed ships.
A TAS with highest score would visit as many beacons as possible before the rebel fleet arrives (manipulating nebulas). Then, it would visit every single beacon of the sector again (controlled by rebels), because rebels overwrite each beacon event with a rebel fight, counting toward the number of destroyed ships (and gives 1 fuel). Rebel fights are very hard, but a TAS should be able to fight them unharmed.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
Blazephlozard wrote:
Tasvideos as a site is completely neutral towards everything.
I don't agree with that. Tasvideos has made some political choices, and it's ok to do so. For example, using Creative Commons for movies, or allowing people to display their gender in the forum.
Also, like it was said in another topic, not taking any side is itself a choice, so it is political.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
So, jemalloc opens some file during init (looks like it is "/proc/sys/vm/overcommit_memory"), but libtas allocates some memory in its "open" hook, resulting in a deadlock. I will look at it.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
I didn't talk about that in the submission, indeed. This is a bug with the turn coat that was fixed in version 4.1, it allows for various clips. I chose to use the last released version.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
FractalFusion wrote:
I noticed you didn't enter a couple of stages right away; I suppose this is for RNG reasons.
You cannot manipulate RNG like that, unfortunately. When you unlock a character at the end of the stage, you must wait a bit before being able to skip the message.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
Oh, sorry, you need to check "Runtime > Asynchronous events > evdev". I thought it was inside the movie metadata, but it's not. It is required because controller events are handled in a separate thread (see libtas issue if interested)
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
Hey,
Lately, I'm running more and more into the general issue of multithreading and determinism. A lot of games do render on a separate thread, which makes input handling code running concurrently on different threads. So you need extra synchronization code to make all input code run always in the same order.
For now, I've always tried to fix those issues in the more general and game-agnostic way, which lead to some obscure settings. Users can't possibly know which ones to toggle unless it is explicitly written on the game compatibility page or movie submission page.
Also, these general fixes are sometimes not very efficient, or don't work properly on slow machines, or just don't work. So I'm thinking that it may be the time to accept that I'm indeed writing game/engine-specific code, and use the knowledge about the game behavior to write the most efficient synchronization code for each game/engine. This would appear on the libTAS UI as a specific menu, or it could be enabled automatically by detecting the game (from the game executable name or hash?).
Note that I'm not talking about hacks, I'm not altering the game behavior, but just adding extra synchronization code to ensure determinism.
This should also allow existing TASes that have synchronization problems (Celeste, SteamWorld Dig 2) to run without the extra procedure.
What do you all think about this?
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
The game was released on Switch recently, so I think it is likely that it will never be released on linux.
Usually, a game that is not released on Linux on the first day won't get a Linux release unless the developers are motivated (and usually are verbose about it, because some linux users can be insistent). I would be very surprised to see a linux port 2 years after the initial release.
EDIT: also, the game runs fine on wine, so even less motivation for the devs to get a native linux port.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
There is very experimental support for wine games with the current interim version of libTAS. Some games seems to run fine, some games run but with dropped/unstable inputs support so recording is unusable. And some games don't launch of course.
Proton itself is not supported because I couldn't manage to launch without a connection to Steam. But it is possible on Steam Linux to select any game on your library (even Windows-only) and in the options check that you want to download the Windows/Proton version. Then you can launch it through Wine in libTAS.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
This was fixed by dynamically linking to swresample. I modified the deb package dependencies accordingly (requires either libswresample2 or libswresample3).
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
The whole goal of libTAS is to be game/program agnostic, i.e. rely as little as possible on how each game/program behave. What you are suggesting is the opposite, basically implementing a program-specific hack.
At that point, you would better implement TAS tools inside PPSSPP (or connect its core to BizHawk), it would be better in every way.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
Small update about Half-Life: I could launch it successfully on libTAS from commit 30d20e4.
Required settings are:
- Runtime > Force locale > Native, and also uncommenting "en_US.UTF-8 UTF-8" in /etc/locale.gen and running locale-gen as su to avoid a popup message at startup
- Uncheck Runtime > Prevent writing to disk as it crashes on level loading
- Runtime > Wait timeout > Infinite waits
- Runtime > Virtual Steam client
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
Yeah, this is probably because Ubuntu 19.04 is shipped with newer version libavutil56 and libswresample3, whereas Ubuntu 18.04 or Debian Stretch (used to build the package) is shipped with libavutil55 and libswresample2, so you have a dependancy problem.
It is really annoying that they renamed the libraries like that, as the API otherwise didn't change much, so you probably could use the newer versions for libTAS. Try installing the newer ones and install libTAS using `sudo dpkg -i --force-depends libtas_1.3.4_amd64.deb` command.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2828)
Joined: 3/17/2013
Posts: 391
Nicos wrote:
i guess we can't skip the vision area and directly oob to the second lab coat ?(is the vision considered a separate area / map ?) or grapple glitch into a wall to zip upward to the last area ?
Before doing Vision, the room that is supposed to contain the Trenchcoat does not have the item.
Getting into a wall doesn't zip you upward but places you in the last valid location. Zipping only occurs with the purple enemy.
We are really close to save a good amount of time, because both the drone teleport and the Trenchcoat only need one use (to enter the Temple), and the Red Coat also only need one use, to access the last area.
