#post 2 out of 6

so normal per-address anti-abuse throttling would treat my test rig like one machine opening too many connections. The bypass applies only to loopback traffic, which keeps it appropriate for local testing.

On the client side, I found and added six executable patches:

Offset Patch Reason 0x00588742 75 to EB Bypass the single-instance mutex so twelve clients can run. 0x003776E3 7F 11 to EB 11 Bypass the first AddPlayerError crash path during race start. 0x00377BDE 7F 11 to EB 11 Bypass the second AddPlayerError crash path. 0x003B5022 limit 08 to 0C Raise the race creator’s player-list capacity to twelve. 0x003B507A limit 09 to 0D Raise the occupied-slot boundary to support twelve entries. 0x003B50BA limit 09 to 0D Raise the slot-assignment boundary to support twelve entries.

These changes got twelve players much farther than a server-only limit increase. At this stage, twelve-player rooms could exist and the clients could enter and start races, but the complete post-race flow was not safe yet.

July 7: Automating Full Test Rooms

Manually clicking eleven clients into every new room was slowing down every test, so I added a reversible local room automation system to the server.

The new local_test_rooms config contains:

• enabled- auto_fill_on_create
• auto_ready_on_join
• A tracked list of CherryMG (really it is test1 through 12) through CherryMG12

When a tracked account creates an eligible twelve-player test room, the server marks that room as managed, summons the other tracked online accounts into it, and automatically readies them as they enter. I restricted this to configured users and eligible local test rooms so it would not affect ordinary players or every room on the server.

I originally triggered the auto-fill too early in the room-entry process. That could make client01, the creator, crash while joining its own newly created room. I moved the auto-fill call until after the creator had received the complete room-entry response and existing users had received the join notification. I also protected the twelve-player count from the vanilla UI sending its normal eight-player room option, and prevented an occupied room from being shrunk below its current population.

This is why all players now join as soon as one room is created: it turns one room-creation action into a repeatable full-load test. The feature can be reversed by setting local_test_rooms.enabled to false.

July 8: Updating the Story of Alicia Repositories

The project had moved ahead upstream, so I updated the local development environment instead of continuing to build on an increasingly old snapshot.

Before changing anything, I created backups/update-20260708-152328. That backup includes:

• A server branch named backup/cherry-test-before-upstream-47fada2-20260708-152328.
• The previous server head.
• The active game directory.
• All twelve instance directories.
• multi-client.
• mod-launcher.
• The existing editor CLI assets.
• The launcher executables.
• The old res.pak and res.pak.001 files from both active locations.

I moved the server work onto upstream Story-Of-Alicia/alicia-server commit 47fada238fd3cc8a0660b20867b08e68c1960652. I preserved the local 12-player protocol, room, loopback, and automation changes on the upgrade/upstream-47fada2 branch instead of replacing them.

I also cloned the new Story-Of-Alicia/alicia-editor repository into D:\alicia modding\alicia-editor. I kept alicia-editor-cli and alicia-web-editor intact because they serve different purposes and were already part of the workflow.

For the launcher, I downloaded the stable alicia-launcher-cli 1.2 release and installed its CLI executable after backing up the previous one. The installed CLI hash matches the downloaded 1.2 binary.

post 1 of 6

Alicia 12-Player Modding Devlog

Development period covered: April 12, 2026 to July 27, 2026
Developer: CherryMakesGames
Main goal: Make Alicia support real 12-player local races, keep the setup practical to test alone, update everything to the current Story of Alicia code and resources, and track down the client crash at the end of a race.

Why I Started This

I am 18, and this project turned into a much bigger reverse-engineering job than I expected. The original target sounded simple: raise an eight-player race to twelve players. In reality, the player limit existed in several different places at once. The server protocol had limits, the room code had limits, the race-start code had limits, the client executable had hard-coded limits, and the finish UI appeared to have its own eight-entry allocation.

I also needed a way to test this by myself. Waiting for eleven other people after every small change would make debugging almost impossible, so I built a 12-client local test setup. It lets me reproduce a complete room whenever I want, test twelve separate accounts or client states at once, and see whether a change works for the host, ordinary players, finishers, DNFs, and late disconnects. It also makes repeated tests consistent instead of depending on different people joining each time.

The most important rule throughout the project has been reversibility. The base game executable stays clean, experimental patches are applied only to per-instance copies, resource-pack switching is controlled by a toggle, server compatibility work is behind config options, and I made full backups before the upstream update.

April 12: Building the Local Test Environment

My first major step was creating a proper local client installation and committing the test setup in the Story of Alicia repository. I added:

• Twelve client folders, from instances/client01 through instances/client12.
• One account entry per instance.
• Individual launchers for each client and a launcher for all twelve.
• A PowerShell launcher that creates and repairs each instance layout automatically.
• Separate writable log and _tmp directories for every client.
• Junctions and hard links for large shared game files so I did not need twelve complete copies of the whole installation.
• A 4x3 window grid so I can see all twelve clients on one monitor.
• An automatic Alt+Enter step to move clients out of fullscreen before tiling them.
• A dry-run mode for checking account paths, arguments, and instance layout without starting the game.
• A check that each configured local account has a matching server user record.

The launcher starts development mode with -GameID 2 and supplies each account’s username and password. I documented the required 127.0.0.1 aliciadev hosts entry because the development client connects to that hostname.

The reason each instance has its own Alicia.exe is that every copy needs binary patches, but I do not want to patch the clean base executable. On launch, the script reads the base executable, verifies the expected original bytes, applies the required modifications in memory, hashes the result, and writes only the instance copy. If the executable does not match the version the patch was designed for, the script stops instead of blindly corrupting it.

April 12 to April 15: Raising the Race Limit

The first server changes raised the protocol and room assumptions from ten or eight players to twelve.I changed AcCmdCREnterRoomOK and AcCmdCRStartRaceNotify so their racer lists accept up to twelve entries. I added validation that throws if the server tries to serialize more than twelve. I also changed room creation so Magic Team rooms resolve to twelve players instead of being clamped to eight.

I added a special loopback exception to connection throttling. All twelve clients connect from 127.0.0.1,