Notices by Ivan Molodetskikh (yalter@mastodon.online)

I'm on a motivation streak for #HalfLife #TAS editor 2, so let's start a thread, why not?

For context, this is an in-game interactive editor for crafting tool-assisted #speedrun s, implemented in an LD_PRELOAD / DLL-injected mod.

TAS editor 2 is me redoing it completely from scratch in #Rust with all lessons learned and very ambitious architectural ideas. It's been going *very slowly*, but I got the initial groundwork done, hopefully it'll be better.

Yesterday I got started on path drawing.

And here's a video from today where I have rudimentary hover tracking (frame bulk closest to the cursor) and coloring (all frames of the hovered frame bulk turn green).

This time I decided to try implementing drawing with a simple "render list" thing: one function returns "draw line from here to here in this color" commands, and another runs over them and calls OpenGL. The first function is completely side-effect-free and can be easily subjected to testing!

The remaining 51 frames are gray -- which means they are predicted (yes, I have a whole player movement prediction engine implemented) and may be inaccurate.

Little handles that go perpendicular to the path delimit "frame bulks", or individual lines in the HLTAS script (every frame bulk represents one or more frames). They will soon be draggable to edit the corresponding frame bulks, just like in the original TAS editor.

In the above screenshot, on the left you can see a HLTAS script, which is the input file format for Half-Life TASes. On the right is an in-game screenshot from Half-Life where a line shows the path that the player takes when running this HLTAS script.

Here I've instructed the editor to play the first 54 frames and stop, which means the first 54 frames are "real" -- the game actually ran through them and recorded the player positions. These frames are drawn in white.

We are left-mouse-dragging! This adjusts the frame count of the frame bulk, and therefore causes all subsequent frames to be re-predicted. Note how the bright area of the path becomes dim when I shorten past it -- since we have to invalidate and re-predict those frames, they are no longer accurate!

Remember: the path shows how the player will move. Note how as I'm dragging, the player will either jump from the platform, or fall down. Seeing this in real-time is what makes the editor so useful!

Got relative mouse mode + pointer coordinates hooked up

The catch is that I'm also trying to implement the first function as an iterator, with no allocations. Not sure how far I can go before giving up and putting stuff into a vector though, I already had to deal with considerable iterator spaghetti just to get the result on the above video. I think generators would really help, but alas they are not yet in stable Rust.

Btw, if anyone has questions on how any of this works and what any of this even means, feel free to ask!

One of the annoying limitations of the current TAS editor is lack of undo and redo. Let's fix that!

Simple enough within a single session and with a single simplest type of edit. What I want to try however is unlimited undo for all edit types, persistent for the entire history of the project. Never implemented undo systems before, not sure what roadblocks I'll hit, we'll see!

However! As you drag around, the path changes underneath you. If you always use the current path direction, you frequently get super unintuitive behavior, and can even get into a situation where you can't drag the path back. So this reference direction also needs to be saved for the duration of the drag.

Drag adjustment actually has plenty of small details that you might not immediately think of, but that you need to get right for it to feel right.

For example, the direction of the adjustment depends on the direction between the last two frames. Intuitively, if the path is facing right, you expect it to extend when you drag right, but if it's facing left, you expect it to extend when you drag left.

As you can see, the player's path sometimes takes quite discrete steps, and sometimes twitches around. This is the result of the interaction between Half-Life player movement implementation details: this example is at 100 FPS, and every frame the player has a binary movement choice: to turn a set value to the left or to the right (the optimal value for speed gain). Details like this are *so much easier* to deal with visually and interactively in the editor, compared to editing the HLTAS by hand.

That design issue fixed, and another upcoming race condition that I though of, I am keeping in mind. For now it's going great, and I've added the second most important TAS editor operation: right-mouse-button dragging to adjust the target angle! This is where the movement optimization (of course, being a TAS editor in a game with complex 3D movement, we have routines to compute inputs giving optimal movement -- like highest speed gain or turn rate per frame) will move the player.

Here we go, persistent undo/redo proof-of-concept working :blobcattea:

Good thing I tried this early, uncovered a design issue with one of the parts involved that can result in nasty race conditions. I think I should be able to solve this while also simplifying the design, that's for later though

Haven't posted in a week, but that's not for a lack of work. I've actually implemented a lot of the architecture I had in mind, decided it was way too complex (remember the race condition I mentioned?) and tore it all down, then rewrote select parts again with a different, much simpler design.

Two more basic operations: split and delete. Both with full persistent undo and redo support of course. These were pretty different implementation-wise compared to adjusting frame count and angle because they involve an entire frame bulk splitting in two, or disappearing altogether, in contrast to a single value changing. But the undo/redo system seems to hold up well so far!