Hey! This README is for those looking to work on the code. For actual plugin documentation, you’ll want to look at the website at https://mikes.software/sst/ or ask for help in a relevant speedrunning community. NOTE: Please read and understand LICENCE before redistributing this software! ════ Compiling ════ Windows: • Install the Windows 10 SDK and MSVC toolset via the Visual Studio Installer (if you don’t care what else gets installed, installing the C++ Desktop workload should be fine). • Install native Clang from the LLVM GitHub releases page. (NOT MinGW/MSYS2 Clang!). C23 support is required; at the time of writing Clang 16 worked, but Clang 20 is being used now. If you get syntax errors or unexpected keywords or something, your compiler is probably too old. • Run compile.bat (in lieu of a better build tool, to be added later). Linux: • Install Clang (and LLD) via your system package manager. Technically, GCC should be able to compile most of this too, but we are currently relying on a Clang-specific extension or two, and GCC in general doesn’t get tested nor used for binary releases, so it’s probably not worth wasting time on. • Install 32-bit glibc and libstdc++ libraries and associated C headers if they’re not already installed. • Run ./compile (in lieu of a better build tool, to be added later). NOTE: Linux code should maybe compile now but still crashes on cvar registration and almost none of the features usefully work. In other words, it needs quite a lot more development before it’s of use to anyone. It’s also not actively tested really so don’t be surprised if it doesn’t compile at all again at some point. ════ Debugging ════ On Windows, SST’s preferred debugger is WinDBG (specifically the new frontend), because it does everything we need, is free, and isn’t horribly slow usually. The script tools/windbg/windbg.bat will automatically download the latest version into tools/windbg/bin and run it. Alternatively, if you already have a copy, set the environment variable WINDBG_BIN and that copy will be used instead. NatVis definitions are contained in tools/windbg/natvis.xml. Currently there is not much in there but it can be expanded as and when useful things come up. Note that after debugging some specific games (mainly some old versions of Left 4 Dead 2) it may be necessary to run tools/steamfix.bat to make other Steam games launch correctly again. ════ How and where to install ════ IMPORTANT: If your game supports multiplayer, always launch with -insecure as a launch option before loading this plugin! Newer Source builds shouldn’t let you connect to a server with plugins loaded or even let you load plugins without insecure mode at all, but older ones do, at which point you might still get VAC banned. ALWAYS launch with -insecure or load the plugin AT YOUR OWN RISK OF BEING BANNED! Very old Source builds load plugins from the top-level bin/ folder, while relatively modern builds load them from the mod-specific directory, e.g. left4dead2/, hl2/. Left 4 Dead and later branches *ALSO* try to load from the top-level game directory where the EXE is, if other paths don’t work. Since this plugin is designed to be universal, a reasonable recommendation is to make a directory for SST in the top-level engine directory and do for instance `plugin_load ../SST/sst`. The way the paths work out, that always works no matter what, and also avoids cluttering up your game files. When actively developing the plugin, it’s possible to back out of the game installation with `../../` etcetera and load from anywhere you want, as long as it’s not on a different Windows drive letter. This is essentially the best way to work with SST built from source as it avoids the need to copy it to different games. The way the build scripts are written, you can rebuild the plugin in-place before reloading it from the game console. It can be helpful to write some console aliases or set up a bind to reload the plugin quickly on-the-fly. Note: some very old (and very new) Source builds don’t have a plugin_load command. For the time being, these versions are unsupported. ════ How to contribute changes ════ SST has a somewhat unusual development process. We don’t really take drive-by changes via the likes of GitHub pull requests or similar, because the project has very very specific goals and requirements, and also because I find those workflows annoyingly unwieldy. Instead, development takes place in a Discord community known as the Sorse Tecknoledgy Committy™, which you’re welcome to join: https://discord.gg/pC6e7RGQmD Do be aware that much of the day-to-day activity there is just rants and memes, but nonetheless, the best way to get involved in this project is to come and hang out and talk to people. The #sst-dev channel has plenty of discussion of what needs done, how to do it, etc. Don’t be shy! Everyone is friendly! We have a bot in the Discord called PatchBot which allows Git changes to be submitted as patch sets, and creates Discord threads for discussion and review. For convenience, the Git subcommands for working with PatchBot are implemented inside the SST repository itself. You can use one of the following commands to set it up for your current terminal session: • `tools\patchbot\setup-path.bat` (Windows cmd.exe) • `. tools/patchbot/setup-path.sh` (Unix-like/POSIX shell) This will enable the use of `git grab ` to apply a numbered patch series from a corresponding Discord thread under the #sst-dev channel, as well as `git submit "description"` to create a new thread from your current WIP. Note however that the latter requires an authorisation token, both to prevent random spam and to associate submissions with individuals. Once you’re somewhat involved in the project I can happily set this up for you. It’s a bit of a manual process at the moment because there’s nowhere enough people to justify implementing a proper login system. That’s time that could be spent on SST itself, or something. Lastly, please note that any nontrivial contributions require either your real name or a reasonably distinct pseudonym along with a reachable public-facing email address, and your code must be licensed under the ISC licence used by the rest of the project. Alternatively, you may publicly dedicate your work to the public domain if you prefer, provided your jurisdiction allows it. All contributed work must be your own. Any code or other material suspected of being copied from elsewhere or generated by an LLM will be rejected. Thanks, and have fun! - Michael Smith