RE: https://bsky.app/profile/did:plc:ecvmda6a65qml7f4rh2dedbo/post/3mfrm45nk222w
I've been working on a game controller display in #godot. It's inspired by the design of the excellent OpenJoystickDisplay, which was retired long ago.
https://codeberg.org/kimimaru/collabplayinputdisplay
Most controller displays I could find are based on web technologies, which is dependent on web APIs. As a result, they don't work in cases like #TRBot which can have multiple virtual controllers with a similar name and ID. I wanted to make a controller display using native technologies, and Godot was a perfect fit. (1/2)
Finally, a long-awaited feature players on #type2play have been asking for, which wasn't possible until now: permanent holds! Using the prefix modifier ^ it'll never let go of the input unless explicitly told to. This is useful in games like #supermariobros or #banjokazooie where you hold down a button to move faster. Players would get around this by holding the button for a very long time (~2 minutes), but with this it'll no longer be required!
Next up is linking with macros! Internally, what this does is simply put all the macro inputs into a grouping. As a small optimization, macros with a single instruction (standalone or linked OR a grouping itself), are not put into a grouping to speed up the processing done by the input handler.
Long time no post. The #rust TRBot lexer is feature complete now, and I ran a few tests with the #type2play community to test how well it works. There was a desire from players to use the old syntax, so I ported the legacy parser from #csharp to Rust and implemented a way to convert new inputs to old on the flly. This will help gradually ease players into using the new syntax.
Yesterday, I added the first new feature - linking repeated inputs with other inputs.
After the parser is done, my plan is to write a validator that uses data from #trbot to map the inputs to buttons and axes on virtual devices.
Before starting this, I already took a dive to refine my #rust skills by writing native virtual devices using #evdev-rs that can be plugged into TRBot at a later time: https://codeberg.org/kimimaru/UinputVirtualDevices
I have yet to implement the wrapper for vJoy, but I'll be prioritizing uinput and #gnu / #linux as that's what I use and run my Twitch Plays streams on.
The #csharp version of TRBot uses a big regex for the syntax, which has worked for a long time but also issues. If there's an error in the syntax and the regex doesn't pick it up, there's no way I could indicate what went wrong.
For this new approach, I took lots of learnings and inspiration from the excellent Crafting Interpreters: https://craftinginterpreters.com/
The requirements for #trbot are different, but the concept is similar. There's more work involved, but I also have much more control.
I've been inactive here over the past months, but I've been keeping busy.
I exported most of the #twitch highlights on the #type2play channel to YouTube. Twitch should've given more than 2 months after the 100hr limit announcement.
I've been hard at work on a proper lexer for #trbot written in #rust. The scanner is done and the parser is just missing macro support. Already 300+ unit tests. I made syntax changes for the better. However, there's nothing usable yet. Link: https://codeberg.org/kimimaru/TRBotSyntaxLexer