Instead of standalone functions in the common module to perform game data tasks,
there is now a shared GameData struct that these functions moved to. This speeds
up a few things, and can take advantage of Physis' built-in index caching.
I know the current solution isn't ideal (each connection has to mutex lock to
access gamedata) but it's at least better than before.
This is based off existing work in FFXIVClientStructs, but I did make
sure to double-check what these actually did as well. These also can be
a combination of flags, but FFXIVClientStructs doesn't consider it one
yet.
This is to make it easier to interpolate with other tools and projects,
and to reduce the mental barrier (of me and other contributors) of
changing these. This only ports the Lobby connection to use JSON so far,
the World connection is next.
Now the world isn't hardcoded to Gilgamesh, and is configurable. It's also now
the "Dev" server listed in the excel sheet which makes a more sensible default.
This is unfortunately lumped into one big commit, and is very hacky and WIP but
does indeed work! Since the Lobby and World server are two separate servers, it
uses it's own custom IPC packets (reusing the same packet structures as regular
game ones.)
The characters you create in the Lobby server are now saved in the World server,
but this is not yet reflected in the Lobby screen.
My old setup of throwing *all* of the IPC types and opcodes into *one* enum was
becoming unbearable. Now that we have multiple things using the same opcodes
(because they can overlap) I think it's time to repay this technical debt.
This overhauls the structure of the project to move IPC structs into their own
modules, and separate the opcode data/lists into separate ones depending on if
it's clientbound and serverbound.
Nothing has changed functionall, but this is going to make it way easier to add
more IPC in the future.
This doesn't really fix anything functionally, but makes the Character window
look nicer. The same (currently unchangable) data is now reflected in the lobby.
The current situation of throw-every-piece-of-logic-into-one-file for each
server isn't working out. So now there is a new ZoneConnection/LobbyConnection
struct that will be delegating tasks to their own Handlers (for example, there
could be a ChatHandler.)
I'm not sure how well this architecture will scale, but it's better than what
we have right now.
