Welcome to the Metruvia Content Creator Series Local Testing Protocols Guide. You have built the models, balanced the economics, generated the UI, and purged all PC dependencies. Your mod looks and functions perfectly on your high-end development PC.

However, assuming PC stability equals console stability is the fastest route to a Mod.io rejection. When your mod hits the Urban Games QA desk, it is not tested on a 64GB RAM workstation; it is pushed to physical PlayStation 5 and Xbox Series X|S dev-kits. These machines have rigid unified memory limits, strict watchdog timers, and heavily compartmentalized operating systems.

This masterclass will deconstruct how to simulate that hostile environment locally. We will build a battery of stress tests designed to deliberately break your mod. By intentionally bottlenecking your own hardware, simulating console VRAM allocation, and executing the “Save-State Cycle,” you will guarantee your payload passes official certification on the first attempt.

1. The Hardware Simulation: Bottlenecking Your PC

A modern gaming PC can brute-force its way through poorly optimized code. A console cannot. To test accurately, you must temporarily cripple your PC’s performance to mirror the absolute lowest common denominator of your target hardware (the Xbox Series S).

1.1 The VRAM Stress Test

The Series S shares 10GB of GDDR6 memory between the CPU and the GPU. If your mod’s texture atlases and LODs are bloated, the console will panic and crash when it runs out of rendering memory.

To simulate this locally without complicated virtualization software, you must force the game engine to render an unreasonable number of unique assets simultaneously.

The “Texture Bomb” Yard: Load your sterile Diagnostic_Bed_01 (as established in Article 11).

Build a massive, 40-track rail yard.

Spawn your custom train on track 1.

Crucially: Do not just spawn 40 of your trains. The engine will instance the texture, masking the VRAM load. Instead, spawn 39 different vanilla trains alongside yours to fill the VRAM pool with unique data.

If the game stutters wildly when panning the camera over this yard, your mod’s texture footprint (specifically the lack of a proper BC1/BC5 Mipmap chain) is pushing the rendering thread over the edge.

1.2 The CPU Watchdog Simulation

Consoles use watchdog timers. If a Lua script takes too long to execute a single frame (e.g., an $O(n^2)$ loop checking every vehicle on the map), the OS assumes the game is deadlocked and forcefully terminates it.

The 1,000 Entity Rule: To test your scripts (especially custom industry logic or runFn economy modifiers), generate a “Huge” map. Use the sandbox tools to spam 1,000 cheap trucks onto a single massive route.

The Execution: Let the game run at 4x speed. If your custom script is inefficient, the massive array of entities will cause the game to physically freeze for half a second every time your script polls the entity list. This micro-freeze on a PC equals an instant watchdog termination on a console.

2. The File System Simulation: Linux Case Sensitivity

As mentioned throughout this series, PlayStation and Xbox utilize Unix-like file systems. Windows is case-insensitive (Texture.dds equals texture.dds). Linux is case-sensitive (Texture.dds does not equal texture.dds).

A single mismatched capital letter will cause a fatal file not found crash on a console, even though it works flawlessly on your Windows PC.

2.1 The Visual Studio Code Audit

You cannot rely on your eyes to catch these errors across hundreds of lines of code. You must automate the check.

Open your entire mod folder in a code editor like VS Code.

Run a global search (Ctrl+Shift+F) for any uppercase characters in file path strings.

Regex Search: Use the regular expression [A-Z] strictly within quotation marks "" to highlight any path calls that aren’t purely lowercase.

The Fix: Force your entire file naming convention to lowercase and underscores. Rename the physical files in Windows, and update the Lua calls to match perfectly.

3. The Save-State Cycle: Testing Serialization

The most insidious bugs do not happen when you are playing the game; they happen when you try to save and load it. If your mod injects data into the save file that the console OS cannot serialize (convert to binary), the save file is permanently corrupted.

3.1 The “Dirty Load” Protocol

You must execute a strict Save-State Cycle before finalizing any Mod.io upload.

Initialize: Start a new game with your mod active.

Interact: Purchase the vehicle, build the station, or trigger the script. Let the simulation run for two in-game months.

Save: Save the game as Save_Test_01.

The Reload: Relaunch the game and load Save_Test_01.

If the game crashes during the loading bar, you have a serialization error. This almost universally means you placed a non-data type (like a function, a UI pointer, or a game engine component reference) into a global table or the state table of a campaign script.

3.2 The Safe Removal Test (The severityRemove Check)

QA testers will intentionally break your mod to see how the game handles it. You must do the same.

Load a save where your mod is heavily utilized (e.g., 50 of your custom trains are currently driving).

Save and exit.

Disable your mod in the load order.

Attempt to load the save.

The Result: The game should load, but replace your trains with generic placeholder boxes (or delete them entirely) and post a warning.

The Failure: If the game hard-crashes to desktop, your mod altered deep pathfinding logic or introduced custom cargo types without setting the severityRemove = "CRITICAL" flag in the mod.lua. If you fail to warn the user that removing the mod will destroy their save, you fail certification.

4. The Controller Navigation Mesh Audit

If you are uploading a modular station or a campaign with vanilla task UI, you must test it exactly as a console player will experience it.

4.1 The “Mouse-Free” Test.

Unplug your mouse.

Connect an Xbox or PlayStation controller to your PC.

Attempt to build your custom modular station.

The Hitbox Check: Can you cleanly snap the cursor to your module slots using the imprecise analog stick? Or do the spacing boundaries overlap, making it impossible to select the correct slot?

The UI Trap: Does your mod secretly rely on a keyboard shortcut or a tiny mouse-click to function? If you cannot access 100% of your mod’s features using only the D-Pad and face buttons, it is not “Console Compatible.”

5. Summary: The Final QA Sign-Off

Before you generate the final .zip payload and push it to the Mod.io cloud dashboard, execute this final, brutal QA checklist. You must be able to answer “Yes” to all five questions.

VRAM Stability: Can the engine render your asset alongside 39 other unique vehicles without severe framerate degradation?

Case Precision: Has an automated Regex search confirmed that absolutely zero capital letters exist in your file path calls?

Serialization Survival: Does the game successfully reload from the desktop after your mod has been active in the save file for multiple in-game months?

Safe Removal: Does disabling the mod result in a clean fallback, or does it trigger the required CRITICAL save-game warning?

Gamepad Exclusivity: Can 100% of the mod’s features be accessed with a standard controller, with the mouse physically unplugged?

By treating your local testing environment as a hostile, resource-starved console dev-kit, you eliminate the guesswork. When your mod finally hits the Urban Games QA queue, it will pass not by luck, but by rigorous, uncompromising engineering.