* Address warning "warning: very complex type used. Consider factoring parts into `type` definitions"
-But instead of making a new type we just create PlayerData directly
* Address "warning: this expression creates a reference which is immediately dereferenced by the compiler"
* Address "warning: calling .bytes() is very inefficient when data is not in memory"
-The match has been moved into src/ipc/zone/event_scene.rs and slimmed down
-EventScene now provides a function to decide the opcode based on how many params it has
-The tests for EventScene were updated to acommodate the new changes
Attempt to improve the accuracy of:
-ItemOperation: Now sends back ItemAcknowledgeAck as well as InventorySlotDiscard and *Fin when discarding items
-ClientTrigger::EventRelatedUnk -> send back commonly observed ActorControlSelf responses
This doesn't make cutscenes play *yet*, but stops the client from
getting stuck waiting for a cutscene to begin. Now the event script
continues, and ends the event.
I re-implemented Unscrambler, but in reverse! This currently only
affects names in the PlayerSpawn packet, it needs to be extended
into others to be considered complete.
See #9
We aren't going to be adding quests ever or anytime soon, so all you
can do right now is force every quest to unlock with the aptly named
!completeallquests.
Document some opcodes related to shops and implement a generic gil shopkeeper script
* You can now interact with shopkeepers, and if you have enough gil, you can attempt to purchase items
* Upon trying to buy items the event will auto-cancel for now, because we're missing implementations of several opcodes related to inventory management
This isn't sent in the PlayerStatus packet *yet*, only on
UpdateClassInfo. For some reason, passing it makes the client freak
out and I'm not sure why yet.
This removes a ton of implementation overlap between the two
command systems. For example, we had two different implementations
of unlocking aetherytes which is just unnecessary.
On the flipside, this makes implementing new GM commands just as
easy as writing debug ones. I moved the existing debug Lua
implementations into their GM counterparts and updated the USAGE
accordingly.
This reads the unknown packet data, just throwing it in a byte
buffer. This allows us to read the rest of the segmenets in
the packet, and fixes parsing.
Note that this still log spams with "wrong size" as we can't
determine the size of the unknown packet ahead of time. This is
easy to fix, but it's not a high priority yet.
Fixes#73
The PlayerStatus struct shifted around recently, so I fixed the offsets
yet again. Unlocks should be persistent now, but this as usual requires
a database wipe, sorry!
I also included some refactors of the !unlock debug command that still
had references to the old unlock_action API.
According to the decompiled Lua code, they sometimes can return
negative numbers (like -1, to indicate an error.) I also improved
the debug display of these in the server log a bit.
I figured out a few of these while figuring out the crystal bell
event, although their purpose is still generally unknown. It doesn't
really affect anything functionally as the event still works as
well as it did before.
I also fixed the crystal bell scenes so they don't finish the event
prematurely, although it looks weird without the hairstyle menu. But
that still isn't figured out yet.
When learning how to unlock emotes, apparently FFXIV just has one
kind of ID for all kinds of stuff. So I picked a number, stuck it
as the max (this is unconfirmed) and you can now unlock everything.
