There is some missing character creation/unloading code, and there are a
few other issues highlighted by TODO tags, see below.
In general, 'mapIndex' has been renamed to 'roomIndex'. Multiple rooms
have not been fully implemented yet, but I'm working on it.
Other issues:
* FileFormat needs to be changed to MapLoader
* Server's character movement is still slaved to the clients
The client does not build.
I've replaced the BBox class with a pair of inline functions in
check_bounds.hpp. I've also renamed the 'position' variable to 'origin' in
several locations.
These changes are mostly to alleviate ambiguity.
I've also stopped using a separate branch for sharing the CharacterData
structre. This commit won't build, mostly because I need to refactor
InWorld to handle the loss of the PlayerCharacter class.
I should probably rename SQL's tables too.
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
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.
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.
It seems that the serialization code has a bug in it. I was expecting
something like this. When the server tries to send the region content, it
exits. I'll try and find the cause of the error, but I'm committing my
changes anyway.
The region's width, height and depth are all defined by preprocessor
macros. The rest of the map system has been updated to match. The
programs proper need to be updated as well. It would be a good idea to
include the macros' values as part of the initial communication protocols,
so that the clients don't connect to a server that is using the wrong
sized regions.
Kayne Ruse