This has been a long-running problem for days, but I've finally
implemented a correctly working hierarchy between the ClientData,
AccountData and CharacterData objects:
CharacterData -> AccountData -> ClientData
There doesn't seem to be any issues with it right now, touch wood.
* There seems to be something iffy with this branch
* The size of SerialPacket may have changed
I've implemented the accountIndex variable as best I can, but I really
shouldn't code at night. I'll need to go over the changes again before
merging this.
* Implemented user accounts.
* Other minor tweaks
I think the general "clientIndex" variable needs to be changed to
"accountIndex", since this will allow for much easier authentication.
To modify an existing user account, change the in memory copy and then
call the function SaveUserAccount(uid), where uid is the index of the
modified account. If the save function is not called immediately, then the
behaviour of the server is undefined.
I'm mostly just testing the waters at this stage, and i've left some debug
code in. There's no way to unload, delete, etc. the accounts, but that
comes later.
I've refactored the network layout. Here is a brief list of changes:
* The new player object is created server-side rather than client-side
* serial.cpp now uses macros to prevent hard-to-find logic errors
* A few method definitions have been re-ordered
* SerialPacket's internals have been slightly changed
* SerialPacket now carries a datestamp defining the network protocol
* server_application.cpp has been split into two separate files
* HandleJoinRequest() has been modified to create the new player object
The bug was being caused by a lack of a new player object being sent to
some clients. Fixed this by adding in the sending code, and preventing the
new entries being "registered" until the end of the HandleJoinRequest()
method.
Hopefully I can simply abstract away some of this code soon.
The bug was being caused by not assigning default values to the player
objects' internals. I've added a quick fix to these structs, but I think
it's best to expand them into proper classes now.
I've divided the server's source into several different files. This should hopefully make it a bit easier to manage.
Please note that I do know there's an exception being thrown by the client
in this build.
I've created a separate branch for this because it's gonna be a bitch to
get compiled, and then I'll still have to ensure that the client & server
are work together correctly.
This build does not compile.
I've added the handle and avatar fields back into the PlayerInfo section
in the network code, because I need to be able to load a specific file
when a new player is created. This wasn't forseen, but it's fine. i'm
leaving the fields in ClientInfo as well, because LobbyMenu is using them
to login to the server.
PlayerIndex is now a shared parameter.
I've shifted some code around in InWorld, however the overall logic is the
same.
This build (as well as the last) does not compile.
The serialization code is now using macros to simplify each line, and to
prevent errors. It should be noted that, apart from the region content,
the serialization and deserialization code is essentially identical.
The list in todo.txt are a list of tasks that will be needed to complete
the login/user accounts overhaul, and will hopefully make the server a
persistent system.
Once the server is persistent (via the database) I can start on the combat
system.
This branch was originally intended to rewrite the login system, but I've discovered some serious problems that could not wait. See the previous commit for more information. Hopefully I can get back to this soon.
I believe this version deserves a new release tag.
Coordinates are supposed to be stored by their x & y, but the sizes of the
tile sheets were getting mixed in as well. When trying to store a region
at (0, 20), it was being stored at (0, 260).
Another visual bug inside the tile sheet's rendering function masked this
issue until now.
Another thing to note is that I've removed an incredibly complex system
for updating the client's map. The new system may seem complex at first,
but it is straight forward compared to what it replaced.
I've also fixed a few logarithmic lagging points in the code.
Kayne Ruse