DEV Community: Tim

Making Star Stable 1 Multiplayer

Tim — Sat, 06 Jun 2026 22:54:59 +0000

Introduction

For those who aren't familiar with the Star Stable titles, they are split into sections:

Star Stable [1, 2, 3, 4] - Singleplayer games
Star Stable Online - Modern-day Multiplayer game

Star Stable Online is built on the base of the singleplayer variants, which all take place in a different 4-season climate.

This is not a copy-paste-friendly version, and isn't aimed at that either.
While the games are abandonware and you could spin a custom server yourself, it is in a legal gray-zone.

This also doesn't cover niché features, read the bottom of the page for a small list.
ImGui setup is also not covered, but utilized a custom fork of hudhook.

For this post I'll be solely focusing on Star Stable 1, with these tools:

Language: Rust
Decompiler: Ghidra
Dynamic Analysis: Cheat Engine

Game Specs

Game Engine: PXEngine (an early 2000's version), written in C/C++
Scripting Language: PXScript (interpreted)
Game File Formats: Mostly all custom or packaged in custom ways. All of them are packed inside of data.csa.
Renderer: DirectX 9
Input Handling: ??? - Weird custom hacky method

Issue 1: The Renderer

Unlike many other DirectX 9 titles, Star Stable 1 does not utilize a proper rendering method, it instead relies heavily on hardcoded values and a screen resolution.

To combat this, you can't simply use a WinAPI call to resize the window, the viewport of the game will still remain at the initial fixed size.

The solution

It's a layered solution, working thanks to luck and heavy testing:

Find the to-be-assigned IDirect3DDevice9 instance. This was quite easy as it's stored within a global.
Hook IDirect3DDevice9::EndScene
1. On each call we drain our backlogged main-thread callbacks, more on that later.
Hook IDirect3DDevice9::CreateDevice
1. Patch the D3DPRESENT_PARAMETERS parameter to a custom width, height and then call SetWindowPos.
2. Call the original CreateDevice function and get the result
3. Once we've got the result of CreateDevice, we hook into IDirect3DDevice9::Reset, ensuring it only happens once via Once.
  1. Once Reset is called, we make sure to re-patch the D3DPRESENT_PARAMETERS parameter before calling SetWindowPos
4. Return the cached CreateDevice result from the hooked CreateDevice, allowing control-flow to continue.
Hook user32::SetWindowPos
1. On each call we force override the desired width and height to always match what the renderer has been forced to, which is defined via a settings file.

The result is we get a mostly fixed renderer which works with modern displays, high refresh-rate displays and so on.
The hooks are messier than they should be, and that's because modern Windows has worse DirectX 9 "support" (DX9on12) than Linux through Wine.

Issue 2: Finding game actors

Almost everything in PXEngine-based games inherit CPXActor, so we need a way to find them.

As with many games, it utilizes a tree-like layout of how actors are defined, to put it simply. There's a ton of weird "shortcut" hacks that the engine setup, but we'll ignore those.

Your players short-path is at global/Player for example, global being a shortcut of another actor.

The solution

PXEngine has a function for finding game actors via tree-path, so I just implemented it, added null-checks and return the pointer.

Issue 3: Executing game scripts

Game scripts will help with iterating and testing in-game at runtime.

The solution

Luckily this one was also easy to implement and find, which was done by attaching a debugger for when I execute a script and just reversing the right function.

Now we can do something like:

CPXActor::NULL.execute_script("global/Horse.Stop();").expect("err");

Issue 4: Abuse the scripting foundation

PXScript is implemented through a "command system" which relies heavily on inheritance and OOP, each command calls back to native code.

To differ commands against different actor classes, PXEngine splits it apart, each command is assigned an ID bound to a specific Class ID.
If you got for example, CPXSkinMesh and call Stop on it, since every actor has an OnCommand function, it just recursively goes down the tree of inherited actors of the current actor.

Stop is a command owned by CPXActor, so it roughly goes like this:

CPXSkinMesh::OnCommand
- Lookup ID of Stop
  - Not found: fallback to parent actor class' OnCommand and repeat
  - Found: Execute

It's ugly, but it works.

What we want out of it

I don't wanna go and find every single native function pointer for everything, and I also don't wanna use PXScript for everything as it's gonna hit a hard barrier eventually and it's not capable of returning native data into Rust, obviously.

So I want to be able to have something like:

// &self = CPXActor pointer
unsafe fn run_command<S: AsRef<str>>(&self, class_name: S, command: S, command_param: <Magic Param Type>) -> Result<*const <Magic Return Type>

This is a cut-down version of how it actually looks like, since it's very complex and utilize a lot of code that has shot me in the back from undefined behavior before.

The solution

I looked up the functions for when the engine starts registering a class, a command and when it ends, then hooked all 3 functions and proceeded with:

Start Registering a Class:
1. Read the Class Name and ID that's being registered, insert it into a global HashMap
2. Store the current-registering Class ID globally via an atomic
Start Registering a Command:
1. Read the Command string and Command ID, storing it into the HashMap of the current-registering Actor Class ID.
Create some helper functions to look up a command via Class Name/ID and so on
Implement run_command and test it

Done, we can now call commands like:

let result = self.run_command("Actor", "Start", ()).expect("err");

It doesn't work for everything, PXEngine utilizes a lot of weird hacks, but it works for most things and we utilize PXScript (or just implement the native function) when needed.

Issue 5: Spawning other players (& horses)

This one may seem easy, and it is quite easy to do via shortcuts.
But doing it from-scratch without utilizing pre-baked objects ("Prefabs" / "Scenes") which are dubbed with the PXO extension, is a nightmare.

The solution

Luckily for me, the game has both the player and horse saved as pre-baked objects.

To spawn them though, we have to:

Call CreateObject with the right parameters, and the right Class ID (in this case: FileObject)
Assign the correct "FileObject" resource to the actor, via SetFileObjectName and loading via FileObjectLoad
... Done?

No.
Our player/horse isn't the FileObject, it's within the FileObject, so we have to move it out which can be done via the Move command.

I just chose to move it to a custom-created global actor that was always active and responsible for holding all players (& horses).

One problem showed up though: The player/horse has physics.
The fix? Just kill the physics via StopPhysics, problem solved - we don't need it anyways.

Once all spawned, we rename the spawned player/horse to whatever we want, within bounds of Aa-Zz 0-9 and basic underscores & whitespaces, alongside limiting the name to 32 characters if I can remember correctly.

Finished Example:

let player = CPXPlayer::new("Albert").expect("err");
let horse = CPXHorse::new("McHorse").expect("err");

Issue 6: Displaying player names

This one took quite a while to solve, because the PXEngine version fo the time had no in-world 3D text, so we had no nametags.

You could likely wire it yourself, but I chose not to.
I remember cheats usually using WorldToScreen for ESPs and such, so I started from there.

The solution

Well, finding it wasn't easy, but I found it eventually.
It also enabled me to create the inverse, like ScreenToWorld and utilizing raycasting, but that's a whole different topic.

To render nametags, I did this:

Calculate the screen-space position of a player, with some offset to get above the head
Utilize ImGui draw lists to render text over the game viewport itself
Position the text at the right screen-space position
Bonus: Make the text fade out if far away, and make it only visible when within screen-bounds & within the looking-direction of the player.

Example:

let ssp = CPXScene::get().expect("err").world_to_screen(player_offset_position);

Actual Code:

// Slave = Networked Player, Master = Current Client Player
ardent_ui_renderer(master_player, master_player_camera, slave_player, slave_name).expect("err");

Issue 7: Animations

This is relatively simple, there are functions on both the player and horse for playing an animation.

What wasn't so easy though was finding the current animation.

The solution

I just opted for hooking the functions for playing an animation, globally queued a packet for the server and then it sent that off whenever it was free.

Issue 8: The Server

A game server is always going to be a hassle to get right, that's correct.
But what I didn't expect to run into was beating my head into a wall over the network stacks themselves.

For reference, I started with TCP, it worked fine at the start but effectively shot itself when the server switched to 60Hz frequency (16.67ms tick-rate).

So what, switch to UDP? sure, let's try that.

UDP

UDP actually did work quite well at the start, but as everyone knows: Raw UDP is FedEx, they don't give a shit and will throw your package through your grandma's window and have you pick it up from her face if it so means saving time.

This caused problems with player spawning packets not always being received.
Yes I know about ACKs, but at the stage the server was at, it was a nightmare to even try and implement that while also trying to reverse a whole game.

Our lord and savior

QUIC, via the noq crate.

I've heard of it before, mostly from websites, but it does work for full-fledged servers too (and I'd highly recommend it after this).

The solution

Take the old raw UDP code and throw it out the window
Implement QUIC, it took about a day to transition both the client and server to it
Test, and shockingly enough: It worked, most of the bugs from before were gone and the leftovers is likely me missing some edge-cases with packet handling as I never finished it.

Send and Receive (S/R) data

For sending data, I first used serde_json - unique, I know. To be extra unique, I compressed and decompressed all the data.

This worked, but since I don't like wasting bandwidth, I switched to rkyv which I've used before.
The transition took approx. 30m to 1 hour, the codebase(s) tried to follow the KISS-principle as much as possible, all code is documented for example.

Issue 9: Thread Safety

PXEngine is not thread-safe, and likely never will be (yes, it's alive and renamed to 'Stellar' in Star Stable Online).

Why was this a problem? oh well, the client implementation was perhaps asynchronous, and what do we get if we mix the two? an error would be the best case, but this was either silent UB or clueless crashes.

The solution

Remember the EndScene hook and how that's called every game frame? Yeah:

Create a global Vec/List (the debate never ends) of callbacks to execute at the end of the next frame, type: Box<dyn FnOnce() -> Result<()>>
Add callbacks via ArdentMainThreadCallbacks::schedule_callback
Pop the entire Vec/List when calling ArdentMainThreadCallbacks::execute_callbacks, if a callback returns an Err value, then the call-chain is interrupted and error logged to stderr; another try is made next frame with the remaining callbacks, repeat.

Actually, not really done.
Box<dyn FnOnce() -> Result<()>> is not thread-safe.

My fix?

/// Ardent hacks `Box<dyn FnOnce() -> anyhow::Result<()>>` for thread-safety.
/// This is classified safe as it's the `FnOnce` entries stored are always called
/// from within `EndScene` on the DX9 renderer, and never anywhere else.
pub struct ArdentFnOnceSyncHack(pub Box<dyn FnOnce() -> Result<()>>);

// Safety: See above.
unsafe impl Send for ArdentFnOnceSyncHack {}
unsafe impl Sync for ArdentFnOnceSyncHack {}

No more brat-like compiler errors, and yes; This actually did remove all thread-safety-linked crashes.

The End

This was all a very slimmed-down version of how it all played out, in the process of it all I had to develop a ton of systems to account for multiplayer in a singleplayer title, I also had to patch things like:

Player/Horse Stats - otherwise it would conflict with spawned player/horse stats
Items - clothes and such have a hardcoded string to lookup the client player when equipped, which makes every networked player apply stuff onto us rather than themselves.
- This entire system was never finished, it's so badly written and it plagues Star Stable Online to this very day, just that they have over 10k items all relying on this terrible system.
- This also required me patching the entire actor-finding function for it to even remotely work.
Input handling - by default we'd otherwise be able to steer networked players and horses
"Insert CD-ROM" checks
Horse variants - otherwise we'd be out-of-sync with the players horse model and coat
Proper horse speed - otherwise the horse animations look off if we don't do this
Tricking the game engine into keeping select "stale resources" loaded - if not, some player items won't be synced and will lead to an error as they're freed from memory

and much more. Keep in mind, this was all done in approx. 2 months, spawning from me being bored and just diving head-first into testing my luck.

Then I also developed:

A custom SIMD AABB collision system as I didn't wanna use their own ODE implementation
Custom game engine editor-like UI, with object spawning/removal/save support
Custom race system
Mini PXScript anti-cheat with server-side validation
DirectX 9 Runtime Texture Swaps without memory leaks
- This also offered restoration of swapped textures
ImGui theme that nearly 1:1 cloned the games own UI theme
A modern player and horse client loop, replacing PXEngine's own buggy loops
- This made input separation and such 20x easier too

Release

I don't think I will ever release this project public, named "Ardent" if you hadn't figured it out by now.

Maybe one day I will, but for now it'll keep collecting dust on my PC, with the usual every-now-and-then DM of "Where's Ardent?".

Why Rust?

Because I don't like C, and I absolutely hate C++.
Zig? I don't care about it.

I've been programming in basically only Rust for years now, I think I've written more unsafe Rust than safe.

That may trigger the forbid_unsafe cultists, but so be it.
If your gig is to strap a condom over your fingers because you are insecure about your own skills as a low-level programmer, then that's on you.

A tip for those who wanna learn unsafe Rust: Just start.
Reverse-engineer that childhood game of yours, dive head-first into it and assuming you're determined enough; You'll come back with 7x more experience than you'll ever get from any tutorial or book.

Abusing c_variadic in Rust

Tim — Sat, 30 May 2026 03:47:47 +0000

What is `c_variadic`?

c_variadic is a recently stabilized feature in Rust that lets you send variadics through C/C++ FFI interop.

The best example is with int printf(const char* format, ...): The ... are your variadics and allows you to pass any number of parameters.

You can utilize it like this in Rust:

unsafe extern "C" {
    fn printf(format: *const i8, v_params: ...) -> i32;
}

pub fn main() {
    unsafe {
        printf(c"My magic number is: %d".as_ptr(), 1234);
    }
}

Backstory

When I was developing a cheat for a video game I eventually grew sick of users requesting new features; I'm not a machine - I chose to implement the Rune scripting language into it.

It worked great at the start, did its job and it opened up the potential for custom community-driven sub-cheat menus.

Although as the project itself shifted to being a cheat framework, this didn't meet my own demands, which were:

Injecting into unprotected games via LoadLibraryA - ✅
Hooking ImGui based on the game renderer (using hudhook, great project) - ✅
Adding WinAPI Memory R/W functions, alongside with pattern scanning and such - ✅
Adding runtime ImGui UI building into Rune scripting - ✅
Adding function hooks and function pointer calling into Rune scripting - 💀

Yeah... 2 challenges from it:

How do I add function calling?
How do I hook functions and call back to Rune?

Implementation

I first tried to tackle the first problem, I could dynamically cast a Rune Value into its native type by doing loads of type-checking and conversions.

So I tried to just call a function with 1 parameter using it and casting the desired function pointer into a extern "C" fn(p_0: *const std::ffi::c_void) -> *const std::ffi::c_void

This worked and the return value was obtainable & sent back to the calling Rune function.

Multi-parameter functions

Not every function is a single parameter. In fact, almost none are in a game.

I can collect the parameters from a Rune function by having the user just pass them all into a large Vec<Value> and then doing type-conversion; that part is solved.

But how would I call functions with varying amount of parameters? I can't change the extern-syntax at runtime; Rust is typed.

Abusing c_variadic

With c_variadic available, I first tried to just force a random function as unsafe extern "C" fn(...) -> *const std::ffi::c_void - and prayed.

The result? It worked but with one caveat: It only works on 64-bit and that's mainly because 32-bit often use different calling-conventions, like thiscall, fastcall and whatnot.

Implementing it in Rune

Rune obviously doesn't have variadics like that, and shouldn't.

So... how should it be implemented?
Simple: match params_vec.len() { ... } - account for a n amount of parameters.

I opted for 15 parameters, making a large match-statement and getting the next parameter from the vector and passing it in.

The result? It worked - but with the downside that we have absolutely no idea how many parameters a function pointer can actually take, so a user could pass in 10 into a function that only takes 2.

The solution? Let them blow their foot off.

Function Hooks

The first problem was solved, now this... The library I was using for hooking was retour in case you were wondering btw.

Where do hooks go?

This was probably the biggest problem of it all: Where do they get sent off to? - Rune as mentioned, is a VM-based language and we can't just redirect it to a VM pointer.

The (ugly) solution

I opted for creating a struct which held data, here's a 1:1 representation of it:

/// Holds the information about a Rune detour.
#[derive(Default)]
pub struct RDetour {
    /// The ID of the detour.
    detour_id: u8,

    /// The pointer of which function will be treated as target, and will be redirected to a
    /// determined detour holder from `determine_detour_holder()`.
    /// If `None`, this detour isn't ready to be used and is free to be acquired.
    from_ptr: Option<isize>,

    /// The `RawDetour` instance.
    /// If `None`, this detour isn't ready to be used and is free to be acquired.
    detour: Option<Box<RawDetour>>,

    /// Rune function to be called as a callback, should return a `isize` of the original functions
    /// return value as a pointer, or a modified value if needed.
    /// If `None`, this detour isn't ready to be used and is free to be acquired.
    rune_function: Option<SyncFunction>,

    /// Optional paramater to be passed into `rune_function` upon callback.
    /// Can be a structure for example, so that variables can be updated.
    opt_param: Option<ValueWrapper>,
}

You may notice one special type: ValueWrapper - and that's just a standard Rune Value but with force-implemented Send + Sync, and that's for one ugly reason: Every RDetour struct instance was stored globally.

It was behind an Atomic RefCell which helped a ton, but yeah not the code you'd typically wanna be writing.

To actually have a real, native function that the hook can call back to, I opted for creating a macro that generated 35 "detour holder" functions that all registered themselves linearly, which then created a new RDetour struct instance and saved it globally.

Installing new hooks from Rune

To install new hooks from within Rune, I ran through these steps:

Find the first-available detour out of the 35 total ones
Switch out rune_function to an user-defined Rune-level callback that the hook would call
Switch out from_ptr to what the user specified
Assign opt_param if the user has defined a custom Rune Value to access within rune_function
Create the hook

If a step failed, then it would log the error visually.

Processing the incoming data

Since we have native hook/detour holders, all data goes to native stub-like functions.

Once data was received, the stub had generated code that would instruct it to look up the hook that was set on its ID.

That helper function (call_rune_function_on_id) would then get the Rune callback function and call it with these parameters:

Trampoline pointer the user should call themselves to continue control-flow. Skip it and the function will just be a glorified return;
A 10-param-sized tuple, the closest to a variadic in Rune. The parameters were - you guessed it - obtained by having every stub-function have a c_vardiadic body
The optional Rune Value so the user can utilize it, if desired

Once the user utilized the newly-added fn_ptr_call function on the trampoline pointer and the right parameters, it would continue on as expected.

The users were often instructed to see how many parameters the function actually wanted, and not just blow off the whole hill with 10.

They often didn't listen (neither did I, I'm lazy) - and it worked for 99% of all cases.

Conclusion

While Rust is a safe language by design, it very much is capable of the same things as C/C++ if you know what you are doing.

Unsafe Rust shouldn't be frowned upon, it should be taught and studied, there's tons of neat tricks that you can utilize.

DEV Community: Tim

Making Star Stable 1 Multiplayer

Introduction

Game Specs

Issue 1: The Renderer

The solution

Issue 2: Finding game actors

The solution

Issue 3: Executing game scripts

The solution

Issue 4: Abuse the scripting foundation

What we want out of it

The solution

Issue 5: Spawning other players (& horses)

The solution

Issue 6: Displaying player names

The solution

Issue 7: Animations

The solution

Issue 8: The Server

UDP

Our lord and savior

The solution

Send and Receive (S/R) data

Issue 9: Thread Safety

The solution

The End

Release

Why Rust?

Abusing c_variadic in Rust

What is c_variadic?

Backstory

Implementation

Multi-parameter functions

Abusing c_variadic

Implementing it in Rune

Function Hooks

Where do hooks go?

The (ugly) solution

Installing new hooks from Rune

Processing the incoming data

Conclusion

What is `c_variadic`?