separate Player entity from save file data

[collinsmith]

separate Player entity from save file data

[collinsmith]

I guess I should explain why this is a problem and why the separation is needed. Technically single player has access to the character save file D2S, and so far I've been using that as an argument in the constructor for constructing the Player entity. The issue is that multiplayer never has access to this data, at least in its entirety, so I can't just download the D2S onto every client -- which would create a stateful nightmare. So the goal should be that client's should be able to run with or without their character's D2S, and that should exist on the server only for multiplayer.

I'm not 100% sure how I want to handle listen server games, I'm thinking other players would need to upload their D2S to the host, or host updates would cause clients to write the changes to their D2S, but I'm not sure how to handle the authoritative nature of this architecture. I.e., I don't know how much checking should be done if say a host sends updates which breaks a client's save file. It could also be that all client's in a listen server game are their own hosts and are sending updates to each other as if in a regular dedicated server multiplayer game.

[collinsmith]

D2S should also support loading header only (170 or 765 bytes -- 171-765 contains map, merc, quest, waypoint, npc, stats which may not all be needed for character select screen and menus). Not loading after 765 alone would improve the loading time of these screens since the items aren't needed.

[collinsmith]

I implemented deferred loading of non-header data in D2S. Header data includes up to 0x14F. Most of this data will be used in Riiablo.player, whether loaded from a D2S or received over the network. Connecting to your network account will transmit the headers for your characters so the client can render and either connecting or joining a game will transmit the remaining info.

[collinsmith]

I created CharData (Riiablo.charData) which will be a container for save data, either from a local D2S or over the network. This class will also support generating a D2S in the case of single player (multiplayer will generate the D2S on the server and transmit to player). I had to disable some of the networking code temporarily, which is fine because that package is due to be replaced. Next step is to replace the coupling with gameScreen.player with Riiablo.charData for all of the save data accessors. I may also remove/refactor some of the Player class stuff like Player.Stats and Player.Skills to support the other changes and prepare for things like items adding skills to players.

It also may be necessary to keep a reference to the local client's Player entity easily available to do things like use warps or some skills.

[collinsmith]

I refactored in CharData. Tests so far indicate success. I've decided to keep item details always based on the local player.

I wanted to note also, D2S.StatData has been modified so that the float fields are just their unencoded int values. This is to keep these fields in line with the other stats.