All accounts were sharing the same character list, but now they should
be properly separated. This also modifies the login database to prepare
for multiple service accounts, but there's no way to manage them in the
web interface yet still.
Now your character's nameday, city-state, guardian and voice is transferred
over. There seems to be a problem with the nameday month, not sure who is wrong
yet.
Instead of one single slot available in your inventory, all four pages
should be available now. Moving items around should be less buggy, and
it's now possible to discard items.
Items cannot stack still, and when given will always take up the next
free slot.
Curiously the spawned clone shows up as a player, despite not using the
NPCSpawn packet. This might be a suitable workaround for the
PlayerSpawn packet being buggy from our side.
This now works and Kawari has achieved basic multiplayer! This is of course with
a hundred caveats:
* Previously spawned players are not backfilled
* There is no range or zone detection
* They are carbuncle clones of you, not the other character's data
But it actually WORKS!
This is quite the architecture change, and I started working on the
first Tokio actor tutorial I could find. This actually works though,
and you can now chat between two characters on the server.
The next steps are to clean up my mess, and send actors over the wire.
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.
It turns out (amazingly) that this data exists client-side, I guess because the
server and the client share the same planevent LGB file. So instead of
hardcoding the starting location in each city, it's now literally like retail*
* Except for the fact that we don't support rotation yet, and positions in pop
ranges are probably randomized too. But it's close!
There is now a dedicated StatusEffects struct that provides a nicer API
to work with these. The list is also sent when needed and only when a
status effect changes, as the client handles the ticking down of
durations itself.
