Source Speedrun Tools: practice tools and handy features for Source Engine games https://qdb.woz.blue/mike/sst/atom?h=v0.18-BETA 2026-02-16T19:11:24+00:00 2026-02-16T19:11:24+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-26T23:12:11+00:00 urn:sha1:af370088fc178996a46ee508aaa1a2c46318bbf2 For some reason the DLL got a tiny little bit bigger again but that's fine. This will make orig_ calls more efficient in the inline case, and also make it harder to screw up and hook the wrong thing by mistake. Self-explanatory-ish, apart from the fact it's a fairly large API change of course. And it relies on some more bonkers assembler directive hackery. But it works! The only complaint one might have is that the featsetup functions no longer take an explicit string which occasionally yields slightly less perfect error messages, but I've decided this isn't really a problem and makes the API nicer to use. It's a tradeoff, innit. 2025-11-24T03:23:22+00:00 Michael Smith mikesmiffy128@gmail.com 2025-11-24T03:19:49+00:00 urn:sha1:508878ff0a9e4cd8528727c41819bc2d70b33dd0 Quick unused header cleanup pass while we're at it. 2025-06-21T13:50:00+00:00 Michael Smith mikesmiffy128@gmail.com 2025-06-17T19:18:48+00:00 urn:sha1:ac7e7d0f21978afc70fe3ef76db69d575742b974 This improves the ergonomics of a few different things, and sets us up somewhat for the fact OE had a different interface for commands too (it was v1 only and had a separate API call for getting the args). 2025-04-17T19:02:18+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-17T00:39:10+00:00 urn:sha1:8a669bc96ffdb9d0f6f54e464da11e3375c80a55 This probably should have been the design from the start. It's still possible to use void pointers, and this is done in a couple of places for simplicity, but wherever possible, we have actual structs for things now. Additionally, in places where vtables are fiddled with, e.g. vtable hooks, we have actual struct definitions with vtable pointers so there's need for pointer-casting horror. 2025-04-16T20:31:20+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-16T01:13:01+00:00 urn:sha1:4fddfa831d2a33ab3eee7ceb5f181c82d5aa78d2 This both simplifies and complicates things, but probably hopefully maybe simplifies things overall. Certainly in cases like the L4D1 demo thing where there's 3 inline hooks at once, it seems simpler to be able to batch the fallible stuff to avoid rollbacks. In cases where you only need one hook, it's a bit more verbose, but what can you do. Thanks bill for discussing this with me pretty exhaustively and giving a lot of good input. I think both of us still kind of hate it actually. 2025-04-07T21:35:53+00:00 Hayden K imaciidz@gmail.com 2025-04-07T20:18:35+00:00 urn:sha1:25838ab4eb1fc94f59186cb24b75f440f9062f9a Turns out this was fixed in version 2112 (October 2012), so it was fairly easy to isolate in Ghidra (I had previously thought this was fixed by TLS). The CDirector::FinaleEscapeState member is used in CDirector::IsFinaleWon (and maybe another function, I don't remember). Prior to Valve's fix, the value was never reset to 0 after finishing a campaign, so when the Swamp (or Crash Course) "minifinale" events ran, the game would behave as though the player was entering the end-of-finale cutscene and block votes, make players invincible etc. 2112 fixed this bug by setting the member back to 0 in CDirector::Reset, so here we just set it to 0 when quickreset is used, since that is essentially the recommended way to start a run at this point. Now co-op hosts won't need to restart their game after finishing a campaign anymore! 2025-04-07T20:31:32+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-07T20:31:32+00:00 urn:sha1:58b495650f7613cdebfe78fff9de2b99556f1998 They're legally unnecessary as far as I know, and kind of annoying to maintain on a long-term basis. This was done with the consent of all 3 other contributors, in case anyone was wondering. 2025-04-06T15:41:13+00:00 Michael Smith mikesmiffy128@gmail.com 2025-03-10T20:37:28+00:00 urn:sha1:daa55cade14146f04814cf8a7ad2028becf4db66 In the future we can also consider moving to {} instead of {0} for initialisers, but my old Clang (16) doesn't support this, so it might be wise to wait longer on that one so people don't need too bleeding-edge of a compiler just to build this thing. 2025-04-06T15:41:13+00:00 Michael Smith mikesmiffy128@gmail.com 2025-03-10T02:37:19+00:00 urn:sha1:244fea664121acf12871ab5858a5fe95a2606b52 Also switch to somewhat proper C23 flags while we're at it. This is a huge change. It took me forever, in between being really busy. Sorry about that. But the good news is I'm now free to start integrating the various patches that have accumulated since last release. Well, at least in between still being really busy. Gotta manage expectations. The main benefit of introducing GAMESPECIFIC() is that features that don't apply to a particular game no longer show up *at all*, and less time is wasted on init. It also enables a cool optimisation wherein unnecessary REQUIRE_GAMEDATA() checks can elided at compile time whenever the gamedata is known up-front to always exist in supported games. The DEF_FEAT_CVAR macro family meanwhile makes it easier to manage the lifecycle of cvars/ccmds, with less manual registering, unhiding and such. Originally I was going to try and just hack these features into the existing codegen abomination, but it just got too terrible. This rewrite should make it easier to continue tweaking codegen behaviour in future. It also has slightly better error messages. 2024-09-28T17:28:13+00:00 Michael Smith mikesmiffy128@gmail.com 2024-09-25T17:25:08+00:00 urn:sha1:bc9198ba9b654117118a06399d4dbf273262501d Avoids the need to manually mess around with mem_offset() and gamedata off_ and sz_ values as often, because that's kind of annoying. Should also make the codebase a little less confusing for new players.