Roadmap - rebaserHEAD/NexusForever GitHub Wiki
What the fork builds next on game_rework, what it leaves alone, and why. The order of what's next is where we're leaning, not a commitment, and it changes as we learn. How each piece gets built and checked is on the guide pages.
The idea
In short
Build server behaviour on the parts of game_rework nobody upstream is rebuilding, cheapest to verify first, and check every feature against the game's own tables and in game before it reaches stable. Leave everything upstream is rebuilding to the branch that's rebuilding it.
Why
On game_rework, the wire is nearly mapped: 927 of the 943 named opcodes have a packet model. Behaviour is the thin part. About half of what a client can send gets handled, and a dozen whole features have complete packet models and no server code at all. So the open work is behaviour on a known wire format, not new layouts.
Gameplay is thin on game_rework on purpose. Upstream is rebuilding it on another branch, and that shapes everything below.
Decisions
Locked
Stay out of what upstream is rebuilding.
| Area | Why |
|---|---|
| Spells and effects, damage, crowd control, AI, movement, prerequisites, public events, death and resurrection, creature templates | Upstream is rebuilding these on expedition-evil-from-the-ether, which replaces those folders nearly wholesale. Work on them here would be thrown away at the merge |
| Loot | Being rebuilt on loot-rework |
| Upstream's infrastructure rework: static managers to dependency injection, the packet path, sockets, the event queue, database repositories, the command system | On the maintainer's own list. Outside fixes there tend to be redone their way |
Build on open ground. Open ground is a feature with a known wire format, no server behaviour yet, no dependency on combat, and nobody upstream working on it. Every idea gets routed the same way:
flowchart TD
IDEA(["A gap or an idea"]) --> L{"Layout known?"}
L -- no --> MAP["Map the layout first"]
L -- yes --> B{"Upstream branch on it?"}
B -- yes --> LEAVE["Leave it to that branch"]
B -- no --> C{"Needs combat?"}
C -- yes --> WAIT["Wait for combat"]
C -- no --> R{"On the rework list?"}
R -- yes --> RAISE["Raise it upstream first"]
R -- no --> OPEN["Open ground: ours"]
What's open today:
- Player-to-player trading
- Crafting and tradeskills
- The marketplace: auctions and commodities
- The CREDD exchange
- Housing neighbours and plugs
- Instance settings and resets
- Reward tracks and rotations
- Add-on channels
- Leaderboards
- Support tickets
- The fortune card game
Duels, PvP flags, challenges, hazards and most path missions have the same shape, but they need combat to mean anything, so they wait until the expedition branch merges back.
Check a feature's packet models before building on them. The archive's models were complete and carefully commented, and still wrong by a field width.
Verify against the tables, then in game. Every feature goes through Verifying a feature before it reaches stable.
Open
The order of what's next. Within open ground, two things decide it:
- How cheap it is to verify. A single-player, table-driven feature can be checked against a prediction from the tables. Anything that needs two characters online needs two clients, and anything with no source in play yet needs a GM command to feed it.
- What it unlocks. Tradeskills feed the two largest kinds of quest objective that nothing on the server drives yet.
Where we're leaning:
- Player-to-player trading. Complete packet models, no server code, no table work and no combat. With the base entitlements in place, the client already opens the trade window and sends the first request. Two clients run side by side on one machine, so it can be checked locally. Built and waiting on its in-game test: Trading design.
- Reward tracks. About the archive's size, and checkable the same way, though nothing in play earns track points yet.
- Tradeskills and crafting. The big one, and the one with the largest effect on content.
Rejected
| Idea | Why not |
|---|---|
Building combat, AI or spells on game_rework |
The expedition branch replaces those folders; the work would be discarded at the merge |
| Fixing what's on upstream's rework list | Outside fixes there tend to be closed and redone the maintainer's way |
| Trusting a packet model because it's complete | The archive's complete models were wrong by a field width |
Where it stands
Done
| Feature | Upstream |
|---|---|
| Galactic Archive |   |
| Web console commands as a character |  |
| Account entitlements |  |
In progress
| Feature | State |
|---|---|
| Trading design | Built on its own branches, not yet run in game or on stable |
Verification status
| Claim | Basis |
|---|---|
| Opcode and handler counts | Counted from the built assemblies of game_rework @ f9bb26ef |
| The stay-out list | Read from the expedition and loot branches' diffs against game_rework, 2026-10-13 |
| Open ground | Packet models with no references in the server code, checked against upstream's open pull requests |
| Trading reaches the client's first request | Seen in game, 2026-10-14 |
| Trading itself | Built and compiled, not yet run |
| Reward tracks' size | Scoped from the code and tables, not built |
Open questions
- When the expedition branch merges back into
game_rework, the stay-out list dissolves, and this page needs rewriting.
Upstream surface
Every feature here lands on game_rework, so the next upstream merge is the risk: a feature that touches a file upstream reworks will conflict. The open-ground features were picked partly because nothing upstream is touching their files today. The expedition branch merging back is the large one, and it lands on everything on the stay-out list at once.
One shipped change already sits on the rework list: #589 extends the command system. It's small and stands on its own, but it may come back redone when upstream reworks commands.