Valid "empty" inventory data

Eidolon

Member
This questions is more for server devs and doesn't really have to do with Tethealla, but I don't know where else to ask about this.

I'm writing my own server from scratch at the moment, and I have BB clients logging in and getting through party creation, but something is wrong with either my bank data or my inventory data defaults and the client crashes immediately upon zoning into a floor or when opening the main menu (the F1-10 hotkeys work).

I recognize that for an inventory or bank slot to be considered "empty", the item ID needs to be 0xFFFFFFFF and the first 2 bytes of an inventory slot need to be set to 00 FF (0xFF00 as a u16). For my default character's inventory, the number of item slots used is set to 0. Is there more that I am missing here?

My mapping structures for character data are here http://git.idolagames.com/furyhunter/idolapsoserv/src/master/psomsg_bb/src/chara.rs#L9 and here's the code that initializes some extra data outside of the Default implementations, http://git.idolagames.com/furyhunter/idolapsoserv/src/master/src/block/handler.rs#L115 . The code is in Rust which may be a little hard to understand, but the impl Default for * blocks define a common function for obtaining a default value for a type. That is where my defaults go.

Edit: It turns out I wasn't actually setting the first two bytes to 0xFF00. Whoops, hours wasted debugging that...
 
Last edited:

Soly

Member
In the tool I made to manage character data, I always set the whole inventory item to 0 (including the ID) and the flag, for the bank items I use 0xFFFFFFFF for ID. But the ship server could be changing it before sending to the client.
Maybe you want to look into Tethealla's function to create a character.
 

Eidolon

Member
I am looking at a combination of Sylverant's and Tethealla's implementations to figure out precisely what is going on. Sylverant reads from a Fuzziquer newserv save file for making a new character, so reading it with a hex editor has been helping. Tethealla has the default inventory hardcoded, which is also helpful. Both servers seem to have 0xFFFFFFFF for inventory and bank item IDs that are not in use. This lines up with how tech levels are stored, too, for unlearned techs.

My code causes the client to crash when pressing Quit Game in the menu, and also still when zoning into a floor. It may be related to appearance data, it may also be that my BB action bar defaults are invalid.
 

Soly

Member
Although I was aware, I never bothered with it, I might change my tool to do this, also the tech flag which apparently is 0x50, I know the old Teth doesn't do that.

Teth doesn't have the base char harcoded, it uses e7base.bin for it.
 

Eidolon

Member
That's right. The file extension it uses is "nsc" and represents a subset of the BB Full Character packet. I believe it also stores character data for other versions as well, for the backup/restore function. Sylverant's struct representing this is at https://github.com/Sylverant/libsylverant/blob/master/include/sylverant/characters.h#L211 .

This isn't yielding much. Even if I have proper inventory data in the first slot, and item count set to 1, the client crashes when entering the lobby. The item data is just a plain old saber, 00010000 00000000 00000000 00000000 (unique id 0x00010000).
 

Soly

Member
Are you sure it's the items? ... I mean, as it is right now, the items seem to be ok (every other server would be crashing clients no?).
Also, if it was the items, I'd expect it crashing loading the block/common lobby when that data is sent (iirc).
 

Eidolon

Member
I'm scouring the message data for details and it seems my character packet has 4 bytes more than it should. The header size should indicate 0x399C and the actual size should be 0x39A0 (padded on 8-byte boundaries for encryption). However, my serializer is emitting exactly 0x39A0 bytes and putting that in the header as well (even after double-checking the upper serialization code).

Somehow this is triggering the client tutorials and the "Beginner" team flag.

This doesn't seem to affect the client at all. It seems the Full Character message's actual size is supposed to be 0x39A0 (after adding up everything by hand), not 0x399C.

I'm about to just write a proxy and hook it up to one of the existing servers and compare their packets to mine because I've spent over 40 hours trying to fix this stupid bug. I have no idea what's causing it at this point. I can even parse .psochar files from the Ephinea backup thing, which are just straight BB Full Char messages, without issues, so it's not anything with character data that's causing it.
 
Last edited:
Top