Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
When I made TAS editor 1 I was trying to get something working as fast as possible so that I don't run out of motivation. As you can imagine, this has lead to subpar code quality and design. So for a while I've been thinking of a way to architecture the TAS editor properly™ while making it much more powerful.
So, several months of work later, here we are. I've made TAS editor 2.
Link to video
Some highlights are:
Undo/redo system which is unlimited and persistent: even after restarting your game, you can undo all the way back to the start of the TAS.
Branches for easy comparison of different routes.
Manual HLTAS editing through bridged file synchronized with the in-game editor in real time.
Integration with the TAS optimizer.
No save command: all changes are automatically saved to disk as soon as you do them in-game.
Overall, it's the same general workflow, but much less annoying.
And here's also a TAS I made with it:
Link to video
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
The TrackMania TAS tools, apart from hundreds of awesome TASes, gave me inspiration with their brute-forcer. So, I implemented a brute-force optimizer for Half-Life. Here's a video on how to use it and how it works:
Link to video
Despite the simplicity and speed, it actually works surprisingly well and finds real skips and real improvements. I hope that other games can benefit from this idea too.
In particular, this TAS had a ton of help from the optimizer, including finding two ridiculously precise skips:
Link to video
I made the above TAS using the new "camera wiggle" strafing style, which mimics human strafing camera movement (also inspired by batman's surf TASes). There's a little bit of timeloss because the path that the player takes is not a straight line, but it's pretty minor from some comparisons I did.
Finally, the CS 1.6 TASing support is back in the latest BXT release. The contributor who worked on it also TASed a number of very hard kz maps:
Link to video
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
Dimon12321 wrote:
I noticed that quadrazid made some CS 1.6 TAS videos that don't feature any team battles (bots). Can their actions be replayed without desyncs, so I could build TAS-looking team deathmatches with headshots?
In theory yes, in practice it would be annoying to work with, especially if the bots' AI calls the RNG.
Playing with bots usually means local multiplayer, which is not a tested/supported environment for TASing, but I imagine it shouldn't cause too many issues to support on a basic level.
CS 1.6 specifically also requires special support due to slightly different physics (and the multiplayer requirement), quadrazid made his TASes on an old (pre TAS editor) special BXT build with CS 1.6 support, which I never updated past that point.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
We're one more year into the future, which means it's time for another update.
When thinking about how a theoretical libTAS + Bunnymod XT TASing setup would look like, I came up with an idea that I could play back the TAS in a libTAS game instance to get the real player movement, then display it in a second game instance running the Bunnymod XT TAS editor and tools. I then quickly realized that this idea works just fine without libTAS, so now we have fully-accurate player path when TASing with the Bunnymod XT TAS editor! Including all entity interactions and everything.
I also stumbled upon batman's wonderful CSS surf TASes, where I got another idea—global camera smoothing. I implemented it as part of a new in-game TAS camera editor, further reducing the need for manually editing .hltas scripts as text files.
You can get a glance at how both of these improvements work in this video:
Link to video
And you can check how a TAS made with global smoothing looks here:
Link to video
Even if I don't manage attract any new HL1 TASers by posting here, I hope that the TAS editor work could inspire or give useful ideas to enable or improve TASing of other games.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
I enjoyed every second of this gorgeous TAS, I can't imagine how good it feels watching this for people running the game RTA. Thanks so much for putting in the effort to make it!
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
FWIW, Half-Life supports Linux (and therefore native libTAS) starting from the 2013 update, where the console was already enabled by default.
would spend a few time on typing out all the commands required to pull this off
Yeah, you only really need a few joystick settings (configuration files for different joysticks are present in game files, perhaps an argument could be made that you could even use a pre-made file and not type the commands) and fps_override 1 + fps_max 99999999999 to lift the FPS cap (or, if sticking to below 100 FPS, not even that is required). You also want to set mouse sensitivity but you can do that even with the GUI slider, it goes just below the minimum required value.
The problem here is not the speedrun helping tools but the non-existing combination of files that doesn't derived from a single officially released version.
The GoldSrc package was made primarily for RTA rules and provides a set of files from mixed versions along with category rules such as "you shouldn't use unlimited FPS for the WON category". For TASing you can simply use a clean Steam install.
I honestly haven't looked too much at the console documentation for older WON versions, and it's kind of orthogonal to this thread because you can't lift the FPS limit there anyway, so no console is required apart from joystick settings.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
Would this line of reasoning also allow using unlimited FPS in HL past the 2013 patch?
- On old WON HL you cannot go above 100 FPS even if you set fps_single, it's a hardcoded limit.
- On old Steam HL you can go above 100 FPS by setting fps_max above 100 and setting developer 1 (both work in multiplayer without cheats). However, trying to go above 1000 results in the game staying at 1000 and running faster in realtime. Also due to an absence of the frametime remainder, there's a "FPS slowdown bug" which slows down the player movement if you're using just above 1000 / N FPS. These FPS values are called "stable" because using them or just below makes the slowdown negligible, and setting fps_max to these values achieves exactly that if your PC can keep up. The FPS slowdown bug is present even below 100 FPS but due to its nature at those FPS values it's largely negligible.
- In the 2013 update Valve added the frametime remainder thereby completely fixing the FPS slowdown bug:
changelog wrote:
Improved movement when running at more than 100fps
In the same update Valve added the fps_override variable that now controls the 100 FPS limit instead of developer 1. Naturally, it also works in multiplayer without cheats.
changelog wrote:
Re-enabled a fps cap of 100. You can override this behavior if you want to run faster by setting fps_override to "1" but some mods may not behave properly
This update also allows properly running the game above 1000 FPS, which gives rise to "0 ms" tricks referring to the player movement (floored to a millisecond) being run at 0 ms by using FPS above 1000. Due to the frametime remainder, the easiest way to do those tricks is by using very high FPS frames to avoid overflowing the remainder. E.g. two 2000 FPS frames will result in one 0 ms frame and one 1 ms frame instead of two 0 ms frames, and ideally you want every 0 ms frame in your TAS to be 0 ms. However, you can also insert lower FPS frames with particular frametimes to shift the remainder back where you need it (for instance, if you need one 0 ms frame and one 1 ms frame you could use two 2000 FPS frames which will reset the remainder back and allow you to use 2000 FPS for 0 ms again).
Tricks allowed by 0 ms frames, similarly to low FPS frames, save just a little bit of time over the course of the run and make it more technically interesting. I mentioned it earlier:
YaLTeR wrote:
For TASing the situation remains similar with 1000 FPS optimal for most of the TAS due to movement, but occasional low FPS frames best for tricks, and also occasional very high FPS frames for other tricks.
RTA runs allow unlimited FPS for the Steam version, which usually entails setting fps_override 1;fps_max 999999 to get as close to ≥ 1000 FPS as one's computer allows. 0 ms tricks require TAS precision, so Steam RTA is essentially equivalent to using 1000 FPS with low FPS frames where needed (as opposed to WON RTA, which is using 100 FPS with low FPS frames where needed).
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
Okay so the summary (finally). See if it accurately describes the situation.
To me it seems like it does accurately describe the situation. I'll ask other members of the speedrunning community to take a look at it too.
One nitpick:
feos wrote:
Variables that work without enabling cheats are quite literally not considered cheats by the game and its developers, and framerate cap is one of those variables.
I'd limit this to "variables that work on multiplayer servers without enabling cheats". There are plenty of cheaty variables that don't require sv_cheats 1 like r_fullbright 1 or the sk_ family that controls health and damage of various entities. None of them can be used on multiplayer servers, there's some other enforcement mechanism for them. fps_max notably can be used on multiplayer servers.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
So if you only use in-game console, is it possible to do all the FPS related tricks?
Well, Bunnymod XT uses console commands to both fix the FPS (using host_framerate) and send all inputs. However, host_framerate is considered to be legitimate only for TASes and not for RTA runs due to how it works (it fixes the timestep while allowing the game to run as fast as possible).
You're probably asking if it's possible to do FPS tricks by having a constant FPS in libTAS and varying fps_max over the course of the run. The answer is probably? I would need to test how exactly the FPS behaves when doing this. You'd have to bind fps_max n for all values you need in a run to different keys either in a .cfg file loaded by the game or manually using the console before the start of the run. Overall if this approach produces fixed FPS values, I'd say it's manageable and only differs from using variable FPS in libTAS by being considerably more annoying to prepare. I don't think the number of different FPS values will be a limitation, you usually don't need more than a handful.
It is indeed not a cheat, it can be used in multiplayer as well.
feos wrote:
So if you set those right from console as needed, is it identical to setting it in libTAS on the fly?
It's not identical in the sense that it doesn't fix the FPS, just makes it oscillate under the value that you set. But yes, changing fps_max is how you lower the FPS in RTA runs.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
Does the game have any official info on how to control FPS the intended way?
I don't know if the current fps_max is mentioned anywhere in official material. The official readme.txt that comes with an old WON version does have a mention of an older variant of that variable (back then fps_max was split into fps_single and fps_lan):
readme.txt wrote:
JUMP KEY NOT ALLOWING YOU TO SWIM UP
If you are having trouble swimming up when you are standing on the ground underwater, try setting fps_lan to a number less than it is currently set to at the console.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
YaLTeR wrote:
By default HL1 is limited to 100 FPS. It's not vsynced, so depending on the computer performance the FPS can go below, down to 0 (effectively 4 as FPS below 4 is treated as 4 by the game and isn't useful).
The movement is generally faster the higher the FPS, so 100 FPS is optimal for the movement.
Does this mean the FPS value you use affects your absolute speed that you run at? If so, how does it work exactly?
Not really, no. It just lets you gain more speed while strafing because it becomes more fine-grained. Imagine approximating a circle with a polygon, it gets closer to the circle shape the more angles there are—it's that kind of change as you increase the FPS, not "computations assume fixed FPS so speed increases" kind of change.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
YaLTeR wrote:
The purest HL1 TAS would be using some kind of PCem environment, where the FPS would oscillate a bit just like on a real PC and without the ability to suddenly easily change it. However, the current optimal player movement calculation assumes the ability to control FPS exactly. Moreover, it's not clear at all how to adapt the optimal player movement calculation to the case of oscillating FPS which cannot be exactly controlled. Making a HL1 TAS without this optimal player movement calculation is unrealistic.
Can't vsync be forced?
Steam HL has a setting to turn on vsync. This removes much of the oscillating, however it doesn't actually fix the frame-time, it's still oscillating a bit. I believe it's still problematic because Steam HL keeps track of the frame-time remainder for the player movement and inserts a lower-FPS frame when it overflows 1 ms. With the kind of oscillating that I was seeing such a frame would occur every ~23 frames, which is too often to be negligible. Furthermore, when looking at a complex scene which causes FPS drops, the frame-time once again behaves haphazardly, hardly usable for movement optimization.
On old WON HL I could not actually find a setting to force vsync.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
After discussion in Discord, I want to write down the case for Half-Life 1 (HL1) variable framerate.
By default HL1 is limited to 100 FPS. It's not vsynced, so depending on the computer performance the FPS can go below, down to 0 (effectively 4 as FPS below 4 is treated as 4 by the game and isn't useful).
The movement is generally faster the higher the FPS, so 100 FPS is optimal for the movement.
The game has tricks which require temporarily lowering the FPS. Examples include fast NPC turning (8 FPS for 1-2 frames), going through thin triggers (20 FPS for 1 frame), edgebug/jumpbug (low FPS for 1 frame depending on player position, sometimes not needed or can be worked around at 100 FPS), fast water entry (4 FPS for 1 frame), small timesaves on doors and scripted sequences (4 or other small FPS for 1 frame). All in all the timesaves here are pretty minor, maybe several seconds over the course of an any% HL1 TAS. However, using all those tricks really does make the run much more technically interesting.
HL1 generally has only 1 category—any%. There's no well-defined 100%, there's no score, etc. RTA people only run any%, any% on a different engine, and any% with some extra console commands allowed. There's also the hazard course, but it's not really a separate category for the purpose of this discussion, more like a separate game with the same set of categories as HL1 itself (any%, any% on a different engine, any% with extra console commands).
An any% TAS of HL1 would take considerable effort to make, and an any% TAS without variable FPS would not look that much different from an any% TAS with variable FPS, so spending 2 times the effort to create both is not really justified. But as I said, any% TAS with variable FPS is more interesting to make and to watch due to technical quality.
For RTA FPS changes to simulate lag are allowed using the fps_max console command. There's been lots of discussion about this within the community, but in the end it is allowed because in theory nothing prevents the computer from lagging at the correct spots, because some people would actively try to simulate lag (launching heavy GPU rendering during cutscenes, why not) and that's just silly to impose on people who want to compete, and because FPS tricks are interesting and fun but not majorly game breaking.
The aforementioned fps_max command can also be used on the Steam version to lift the 100 FPS limit, which is in fact allowed for RTA for this category. For TASing the situation remains similar with 1000 FPS optimal for most of the TAS due to movement, but occasional low FPS frames best for tricks, and also occasional very high FPS frames for other tricks.
The purest HL1 TAS would be using some kind of PCem environment, where the FPS would oscillate a bit just like on a real PC and without the ability to suddenly easily change it. However, the current optimal player movement calculation assumes the ability to control FPS exactly. Moreover, it's not clear at all how to adapt the optimal player movement calculation to the case of oscillating FPS which cannot be exactly controlled. Making a HL1 TAS without this optimal player movement calculation is unrealistic.
Therefore, libTAS is a much more reasonable environment for making a HL1 TAS because the FPS can be fixed at the desired value. However, considering that we're already fixing the FPS to a pre-set value using libTAS, it's easier to justify also allowing to vary this pre-set value over the course of the run to simulate lag and lower the FPS.
To sum up:
- HL1 TASing requires exact control of FPS, whether it's constant throughout the run or variable.
- It has only one meaningful category, which is any%.
- Any% with variable FPS will not look different enough from any% with constant FPS to justify making a separate TAS, or to justify publishing those two TASes in different categories.
- Any% with variable FPS is much more technically interesting.
- RTA rules allow variable FPS.
- libTAS is confirmed to handle HL1's variable FPS tricks fine.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
A year of improvements has made the last video outdated, so I made a new one covering the improved TASing workflow and generally more in-depth.
Link to video
The notable improvement since a year ago is that the camera twitching is now gone completely. For a taste of how HL TASes look now, check the Office Complex TAS:
Link to video
Also, some more TASVideos-related work that's happened: in spring we worked with keylie to improve libTAS support for HL1 to the point of successfully exporting Bunnymod XT TASes using all kinds of complex things like mouse, joystick inputs and variable framerate to libTAS. However, this is still "work in progress".
1. The converter in BXT still has some bugs (I saw it output 1 pixel off mouse movement on one frame which broke everything).
2. I don't know if/how things involving serverside physics will sync. Player movement uses time floored to 1 ms which is easily replicated by libTAS, but serverside physics uses full precision floating point time, which will likely be different between the way BXT sets it (in-game host_framerate console variable) and the way libTAS sets it (feeding the game timestamps). This will probably need special support in BXT to feed timestamps the same way as libTAS during TASing.
3. I similarly don't know how to hook up RNG between BXT and libTAS. Right now I imaging something like TAS up to RNG part, play back in libTAS, check the RNG values, then somehow plug them back into the game via BXT to TAS the RNG part and hope it all works out?
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
Привет!
Я делал инструменты для Half-Life 1 (http://tasvideos.org/forum/viewtopic.php?t=17062). Там принцип немного другой, библиотека сидит в игре, считает оптимальное движение каждый кадр и передаёт его игре в виде консольных команд. Это достаточно удобный способ (можно читать состояние игры и на основе него что-то считать, так же см. редактор, который я запилил на основе этого), но требует большого количества реверс-инжиниринга.
Другой способ сейчас — это libTAS (http://tasvideos.org/forum/viewforum.php?f=71), но там нужен линукс. Под винду был Hourglass (http://tasvideos.org/forum/viewforum.php?f=61), но ввиду серьёзных технических ограничений его разработка была остановлена, и скорее всего он не сможет запустить COD.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
scrimpeh wrote:
Holy crap, this is amazing. Probably the most innovative thing I've seen related to TASing in a long while. Huge props to you for making this.
Thanks!
scrimpeh wrote:
I do wonder how well this works with some of the actions required in the base game, like shooting, boosting from func_pushables or riding trains.
Yeah, I think interacting with entities will still need to be adjusted manually. The editor works via the player movement prediction, implemented as a library, which doesn't do entity prediction. I was thinking about perhaps somehow predicting at least a number of "simple" entities like doors and pushables, however thus far I'm not sure how to go about doing this.
One idea is to run the server physics together with the movement prediction, however you essentially need savestates to be able to roll the server state back to predict another movement angle, and that's something we don't have in GoldSource (and can't be easily implemented).
Another idea is to re-implement the position updating for simpler entities (like doors) and move them back and forth manually during prediction, however I don't know how well that would interact with the rest of the game's state. In any case, this is what I would probably try first if there isn't a better idea.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
While there hasn't been much interest in GoldSource TASing among this forum's members who are not also present in the SourceRuns community, I feel that it is important to post about this update here because of just how much it improves and speeds up the process.
The recently released Bunnymod XT update introduces an in-game interactive editor for GoldSource TASes which greatly simplifies and speeds up the process of TAS creation. Following is a video introducing the editor and showing how to get started making a TAS of a bhop map.
Link to video
Of course the editor can also be used to TAS the game itself. The video is focused on a bhop map because it presents a simpler case which is easy to get into.
