I wanted to add armory chest support but the current state of the
inventory was a little frustrating. Adding new containers was too
difficult, so I made the system *even more* generic and easier to use. I
have also split it up into it's own module with a nicer file layout.
Oh yeah, and armory chest works too now.
Everyone's favorite copying mechanism/purchasable item is now functional
in Kawari. The item doesn't disappear once you use it, because there's
no API for that yet.
I wanted to make the lobby screen reflect your currently equipped items,
but that doesn't yet for some reason. These are still good refactorings
though!
There's no point in doing this yet:
1. This *crashes* the client, nice. Most likely because we're not
actually obsfucating anything, only tricking the client into thinking we
were. Why this can crash the client is beyond me?
2. Obsfucation is still optional.
This is to workaround a bigger bug where I don't properly enclose actors
in their zone, so you can hit an assert while traveling between zones.
But this is something that has been needed anyway, and also fixes that.
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.
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.