CptSky

From my experience, the hard part (or badly written part) for the handover is: - not having to share the account database with the game database - not having the account server knows all game servers (and needing to be refreshed when one game server changes) - not leaking the database IDs (or having a too deterministic login) - not having a weak token that can be spoofed - having the proper flow for full/busy states per game servers ----- On my current in-progress source, I'm using a pub-sub pattern (with MQTT) to do the Auth <-> Game Server communications. The Auth Server is a MQTT hub, and Game Servers connect to it so it lazily discover them (no need to have configs about Game Servers). Then, the Game Servers create a topic that the Auth Server is subscribed to with a wildcard (using a local MQTT client), and it periodically broadcasts its status (name, IP endpoint, number of players online, max number of players, degraded state). This gives info about whether it is full, and what to return to the players that try to connect. Tokens are randomly generated, and sent to the right Game Server by publishing on a per-Game Server topic. The token is accompanied with the account ID and the expiration, so that info does not leak to the clients. And then, it is only a matter of having a memory cache to track all recently received tokens. It must be noted that there can be race conditions, and the player may connect to the Game Server too early. So I have a MsgConnectDelayed (custom message) that I enqueue if that happens with the original MsgConnect data, plus a timeout. And will try to re-process it until it expires (at which point, I assume that I'll never receive the token from the Auth Server).

I know that the cipher was different in 4217, and normally it changed in 4267. Maybe you got a client with the wrong executable?

Because sadly artificial intelligence has yet to be able to create wizards and unicorns

Issue #1: As mentioned by Spirited, this ia a client-side bug. AFAIK, clients like 4351 were fixed, so it must have been fixed in-between. You may be able to find a client that is fixed and does not have too many packet changes (i.e. 4351 won't be compatible as-is). Issue #2: I'm not sure what you are referring to, so maybe it was added in later clients. Is it the "PvP" toggle button to hide UI elements? If so, it was definitively added later when the UI became so cluttered that TQ had to add yet another button :P Issue #3: Labyrinth, Gano, etc. are all part of the 4330 client. Basically, you can see it as the version with 2nd reborn JUST before CPs (lottery, etc) were introduced. While there might be some bugs (I experimented with this version and never used it live), it should be decent. The original base (COPS v6) was used for my live server back in the days (so yeah, it supported more than 10 players :P). Also, as pointed out by Rezlind, they have been using this Enhanced version without finding major bugs.

No feel free! And if you need to additional info (i.e. mobs / etc), I know I still have some web archives of some pages around.

Modified executable allowing loopback address to be used: English

Around 2013/2014, I started an emulator for Era of Faith, before forking it and releasing it as COPS v7 Emulator (for Conquer Online). This is my original emulator for EoF, if anyone ever wants to work on that game. Overview Faith Emulator is a C++ emulator of the MMORPG Era of Faith. The emulator is coded in C++ and uses Qt4 / Qt5. N.B. The QMySQL driver must be build to use the QSQL module properly. Features Faith Emulator is currently released as a base source. Most functionalities are not implemented or completed. However, there is some code to log into the game, talk to NPCs, walk around, etc. Additional code could be backported from COPS v7 Emulator, and adapted for EoF. Download https://mega.nz/file/j1twRIDA#9uDz89-PBgD3J0HsZMv14_VoDmC3QlC-hpBjqBBMhB0 Screenshots