Multiworld

Following is my research regarding multiple world support, i.e. the ability to use multiple different game servers from a single login server.

Please note this is early work in progress. Darkstar is far away from proper support and some parts will have to be rewritten. Furthermore, even the largest Darkstar servers have not reached the point that they need multiple worlds (actually right now even retail doesn't have enough population to justify it) so it may or may not happen. Most packet research has been done though.

Adding multiple worlds to the character creation screen

This is the list of worlds that appear when creating a new character (after setting the character name). Currently Darkstar only provides a single entry, set to the server name as specified in the login server configuration file.

The packet involved is LOBBY_024_RESERVEPACKET (located in mmo.h). Surprisingly it is sent immediately on client connection and not only when characters are created. The structure of the packet is as follows:

• 0x00 - Packet size, uint32 - Currently set to 64 bytes (0x40) however if there's more than one server on the list then 64 bytes will not suffice, in which case increase this as necessary.
• 0x04 - "IXFF" - Standard packet magic
• 0x08 - Packet type, set to 0x23

Bytes between 0x12 and 0x32 are unknown. They may be used by POL (not all are zeros on retail), for now keep them as they are.

• 0x20 - Running counter, uint32. For some reason it starts with 0x64 (in both Darkstar and retail, not sure whether this is mandatory).
• 0x24 - Server name, capped at 15 characters. If less than 15 characters then pad with zeros
• 0x33 - Zero byte (presumably so the server name is always null-terminated).
• 0x34 - If more than one server then this is the next running counter (uint32) followed by server name etc.
  • Seems that the counter does not have to be always incremented by one. Retail has 0x64, 0x65 but then skips to 0x68. This is probably due to decommissioned and/or special use servers (e.g. Atomos). The counter cannot decrease though.
• The packet will always end with the trailing zero after the last server name.

Associating characters with worlds

See the following code in lobby.cpp - [code] LOBBY_A1_RESERVEPACKET(ReservePacket);

//server's name that shows in lobby menu memcpy(ReservePacket + 60, login_config.servername.c_str(), std::clamp<size_t>(login_config.servername.length(), 0, 15));

// Prepare the character list data.. for (int j = 0; j < 16; ++j) { [/code] To associate different characters with different worlds move the memcpy instruction into the for loop and change the name accordingly. ReservePacket itself does not seem to be used after that point so it is OK to overwrite (at least for now).

Refactor Darkstar code

This is by far the biggest challenge since the login server assumes there is only one map server (technically different map servers can be used for different zones but still within the same world). Several database structures are shared between the servers.

Two possible ways to refactor -

• Use different databases for each world and another one for the login server.
  • Accounts tables are on login DB, Main char table has to be duplicated on both, all others on game DB only.
  • Pros: Strict separation minimizes risks. Even if one DB crashes the other worlds still work (as long as the crashed DB is not the login).
  • Cons: Will need to create an IPC between the game server and the map servers to cover the cases where map servers need access to data stored in login DB (mainly accounts_sessions).
• Use the same DB for all worlds, add "world" column to several tables.
  • Some indications that retail may be using this approach though not certain.
  • Pros: No complicated IPC, world transfer is easier.
  • Cons: Possibility of worlds clashing due to bugs. May need to patch code in multiple locations to handle the new world columns.