Question: What are the changes in RD's binaries?

[Bluebotlabz]

From what I know, ReactiveDrop runs on a somewhat modifier version of ASW's engine branch as Valve provided the DLLs for it

I'm mainly just wondering, what were the changes made to the binaries?

[BenLubar]

It's been a while since I thought about this, but from what I can remember (@geotavros might remember better than I do):

• increased something related to max bandwidth limit
• built against a newer (but by today's standards still very old) version of the Steamworks API (I think 1.38a?)
• splitscreen support is enabled in the engine but needs lots of work before it can be enabled in the client/server
• sv_cheats isn't ignored in singleplayer (this is probably the most important change)
• there are multiple changes to the engine code that AS:RD makes at startup - look for VirtualProtect in the source code to find the ones that touch executable code

[Bluebotlabz]

Interesting! I honestly don't think I was expecting so many changes, I honestly thought it was just rebranding and maybe one or two RD specifics

Are there any plans to potentially upgrade these binaries to like... some kind of weird source2 mess? Or at least something newer since as you mentioned, they are definitely still quite old

(source 2 mess: no I'm serious: https://github.com/Enhanced-Source-Project/Enhanced-Source/commit/4e08bb06374c335857c0cbbff726776e6073c9a0)

[Bluebotlabz]

Also, in regards to AS:RD making changes to engine code... do you mean that RD is patching source's engine binaries at runtime?

[BenLubar]

Also, in regards to AS:RD making changes to engine code... do you mean that RD is patching source's engine binaries at runtime?

Yes, for example we change the +showbudget command to allow it to work with cheats disabled, and the audio mixer settings are made by reading audio mixer data directly from engine memory.

[Bluebotlabz]

Wow, that's... incredible! Reading up a bit on VirtualProtect I assume you're... somehow finding the location of said DLL in memory, then... patching it at the right location... presumably using Ghidra to find the address before hand or... something?

Do you by anychance know of any good resources where one could read up on using this to patch stuff? I would definitely be interested in experimenting with patching some engineside stuff... specifically some VPK and BSP loading code...

[BenLubar]

Yes, the process (something I learned to do while developing DFHack) includes static disassembly Ghidra as a main component, as well as leaked engine code for reference. We're not allowed to publish anything based on leaked code, but I can use it to help me figure out what the decompiled code is supposed to be doing. Then I work backwards to find a way to get the part of the code I need to change from somewhere that the game can access, usually a concommand.

There isn't any leak I'm aware of on the L4D or Swarm engine branches, but a lot of code is the same as it was in the 90s because math still works basically the same way it has forever.

BSP-related code sounds like it would be hard to change because basically the entire engine is built around the data structures being laid out in a specific way. But if you just want to understand it better, you can look at the map compiler code in Source SDK 2013.

[Bluebotlabz]

So Valve is... technically (unofficially) kinda ok with using leaked code so long as it's only for reverse engineering purposes 🤨 LOL

but specifically I really just want to redefine the map command to be within the client/server rather than entirely engineside for cursed BSP preprocessing reasons (ok that's not as engineside-BSPey as I made it out to be)

as for VPKs I'm just looking into increasing the ASW max VPK limit to something larger which seems to require actually replacing functions... I know of some implementations that use leaked code though I might just try my best turning Ghidra code into compilable code lol

Thanks so much for your response!

[BenLubar]

Max VPK limit as in total file size? If the VPK is bigger than 4 gigabytes, it needs to be split into volumes like pak01_dir.vpk is, and each individual file can't be more than 4 gigabytes because that's just how big the file size number is in the directory.

[Bluebotlabz]

no as in how many VPKs can be loaded at a time, apparently there is a limit (according to the person who found this, at least on the base ASW branch, leaked code seems to indicate this as well)

(definitely nothing to do with a fixed-length array of filehandles)