CrashKoeck STRM.TOOL

Inspiration

I created STRM.TOOL because there were no programs that did everything I needed. I would have to run 6-12 programs just to manage the basics of my show, and even then there were huge gaps in functionality. With STRM.TOOL, I have a tool that can work with any existing bot, replace many different pieces of software, is extremely lightweight, and just simplifies my entire show.

What it does

STRM.TOOL is a "listener" background application that uses Triggers - HTTP requests - to perform actions. By using HTTP requests, it is compatible with every major chat bot (even cloud-based bots), devices such as Stream Decks, OBS browser sources, Touch Portal, phones/tablets...basically anything at all that can make an HTTP request. It also utilizes a user's personal free or paid ngrok account to allow Twitch EventSub webhook calls. The user can also stack Triggers to have them fire sequentially and pass data from one to another, then these Stacks can also be used in other applications or even in Twitch Events within STRM.TOOL to allow multiple Triggers to fire on cheers, subs, raids, follows, channel point redemptions, etc.

How I built it

STRM.TOOL started out as a collection of about 100+ personal AutoHotkey scripts all working together for my own show, but it was a pain and there were obviously weak links. At the time, I had to use Streamlabs Chatbot and the AHKParameters plugin to activate these scripts. One major drawback for Streamlabs Chatbot was that it was no longer being actively developed, and simple additions like Channel Points were not an option. Another drawback was that I needed my game PC to be controlled by my stream PC, so I had scripts that would activate MIDI notes, which then would send the signal to my game PC over rtpMIDI, then have Bome fire more scripts based on the MIDI notes passed.

So, because everything was so complicated, I combined all of my personal scripts into one Autohotkey Script and included an HTTP server so that I could easily control multiple PCs over the network in near realtime. During alpha and beta testing, I used the built-in Autohotkey GUI to make a user interface, but it was very clunky and left a lot to be desired. I wanted to make it better, but couldn't think of an efficient way to do it. Then one day I was making some adjustments in my router one day and it just clicked - I already have an HTTP server, why not make a web interface like my router? So, I rebuilt the entire frontend for Version 1 and now STRM.TOOL has a much more efficient and user-friendly interface that can also be accessed by other devices on the network. If the user wanted to build Triggers for your bot that runs on your streaming PC, but those Triggers are for STRM.TOOL on your gaming PC, you didn't have to somehow copy the URL over to your streaming PC from your gaming PC - you could copy the Trigger right from the remote user interface into your bot. Also, the web interface will also allow me to make major changes to the backend in the future and leave the frontend alone so it's easier for the end-user.

Challenges I ran into

One big challenge is that the language I have been most comfortable with for controlling a PC is AutoHotkey, and it is very limited. It can't natively work with WebSockets, so I have to use workarounds to connect it to OBS. It is single-threaded and I/O blocking, so it can get overloaded and fall behind at times. I have been able to get around the single-threaded and blocking limitations of AHK by building a separate handler script that actually performs the actions, while the main script simply listens for HTTP requests and then passes the information to the handler. If there are multiple, simultaneous requests made, multiple instances of the handler are created to handle each one.

Accomplishments that we're proud of

Just the fact that I've been able to make this extremely lightweight program that is incredibly powerful, while still very easy to use, even though I am not a developer/programmer - I'm a carpenter. I've learned all of this as I went. I know what I wanted it to accomplish, so I did whatever research I needed to in order to achieve my end goal. I've tried to design the UI in a way that is familiar, like Streamlabs or StreamElements, so that it is easy for new users to dive into STRM.TOOL.

What I learned

People will always find ways to use your software in ways that were not intended Kappa. I have also learned that, even though I can try to make my software as compatible and user friendly as possible, there will always be a few instances where the user or their system just will not be able to utilize the software without a heavy time and effort investment that will take away from what the vast majority of people need/want. The needs of the many kind of thing. This was very hard for me to get around as I really dislike leaving anything "good-enough", but now I realize that a developer can only do so much.

What's next for CrashKoeck STRM.TOOL

I have now hit a wall with what I can accomplish with AutoHotkey and am taking a Node.js course so I can rewrite the entire backend in Node, which will give much more headroom for future plans, including full WebSocket support (more dynamic overlay elements) and full IRC capabilities for native Twitch chat support. If STRM.TOOL did win, I would reinvest the winnings into hiring another developer to help me port STRM.TOOL over to Node.js and also help me maintain it for the rest of the year.

Note to Judges

I will gladly unlock Premium Access for the judges, but I will need to know the Twitch accounts that will be used to access STRM.TOOL as Premium Access is tied to a user's Twitch Account.