Home

NexusTomorrow is a server for the WildStar client, build 16042 (the game's final patch), written in C# on .NET 10. It started from NexusForever's game_rework branch and builds its own server core. Today a real client logs in through it and creates characters; entering the world comes next.

Note

This wiki covers how the server is designed, how it's built, and how we work on it. The repository's README is the front door.

Start here

If you want to	Read
Run a server of your own and log in with your client	Running a server
Understand what we're building and why	Server core design
See what's built and what comes next	Roadmap
Build the code and run the tests	Running the tests
Find your way around the code	Repository layout
Contribute	CONTRIBUTING.md, then Code standard for the why

Every page

Grouped by area, each with its kind: guides give steps, references give facts to look up, explanations say why things are the way they are, and design pages say what we intend to build.

Running it

• Running a server (guide) - set up the database, extract your tables, start the server and log in with your client.
• Running the tests (guide) - the suite on your own machine, and in CI on GitHub's runners.

How the server works

• Server core design (design) - one process and one world, owners reached through the gateway's opcode table, declared messages, public hosting, and the client as ground truth.
• Roadmap (design) - the six build steps, milestone one exactly, and where each step stands.
• Host (explanation), with Host lifecycle (reference), and Host design (design) - the one process: its composition, the settings it checks at start, migrate, and the order it starts and stops in.
• Gateway (explanation), with Gateway connections, Gateway sign-on, Gateway gate, Gateway limits and Gateway opcode table (reference), and Gateway design (design) - the client ports and every connection: sign-on, the gate every message passes, the opcode table and each of its rows, keys and limits.
• Owners (explanation), with Owners base, Owners account and Owners realm (reference), and Owners design (design) - one thread per owner over its message queue: the account, realm and map owners, the watchdog, and the protocols between owners.
• Map scheduler design (design) - every map ticked to its own deadline on a shared pool or a thread of its own, missed ticks skipped, the tick and the update interval.
• Timer wheel design (design) - every rule in milliseconds: each owner's timers, waits and cooldowns, fired in order without allocating.
• Persistence (explanation), with Persistence schemas and Persistence write-behind (reference), and Persistence design (design) - one PostgreSQL 18 database with a schema per owner, character id blocks, and the write-behind queue that keeps every key's work in order.
• Command layer (explanation), with Command layer dispatcher and Command layer commands (reference), and Command layer design (design) - typed admin commands, checked on the server and audited, and every command with its permission.
• Harness (explanation), with Harness server and Harness scenarios (reference), and Harness design (design) - the real server in-process with headless clients, and the pregame scenarios.

The protocol

• Client protocol (reference) - how the client talks to a server: its connections, the envelopes and keys, and the conversation from login to the end of the loading screen, as far as it's verified.
• Messages (reference) - every client message by opcode, with its direction, how far it's verified, and a page per area giving each one's fields. Generated from the declarations.
• Codec (explanation), with Codec declarations, Codec layout tree and Codec facts check (reference) - one declaration per message with explicit widths, a generated reader and writer, and the client-facts table that checks them. Codec design (design, superseded) keeps how it was built.
• Message audit design (design) - every message checked against the client before the core uses it: verification rungs, neutral names, the full-layout check and the generated reference.

Working on it

• Repository layout (reference) - the root files, every project and what it depends on, the tests and the workflow.
• Code standard (explanation) - Microsoft's conventions held by the build, and the handful of choices that are ours.
• Branches and workflow (explanation), with Branches and workflow design (design) - main, bootstrap and throwaway test branches, why the tests run only when dispatched, and the agreed move to dev with a weekly step to main.
• Documentation standards (index) - page kinds, the status ladder and the header badges. Read it before you write a page.
• Documentation standards house style (index) - chapters, callouts, tables, diagrams, spelling and voice.

About

What you bring

A WildStar 16042 client. The repository holds server code only: no client, no client files and no game data. Tables and maps are extracted from your own copy, and stay on your machine.

Licence

NexusTomorrow is licensed under the AGPL-3.0, inherited from NexusForever, whose full history it keeps. If you run a modified server that other people connect to, you owe them its source.

WildStar and everything in its client belong to NCSOFT. This project isn't affiliated with or endorsed by NCSOFT or Carbine Studios.