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.
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.
Conflicts:
server/server_application.cpp (resolved)
After completing the serialization code, I'm merging it into the server's
development branch. This means that although the connection and
disconnection functionality work, I still need to test the player systems
from the new server with the new serialization code.
Immediately following this commit, I'll be merging the minor tweaks to the
editor from the master branch into this one.
I've dummied out the player code, so only the client connection code is
working. Otherwise the protocol hasn't changed.
I've also made a few other tweaks as I went along, but nothing really
major.
This code is essentially copied from the old branch, since the two
branches are now functionally identical. How much time have I wasted
rewriting this?
This is a pretty straight forward port of the old version, including the
incredibly hacky server list. But I just need to remember that this is a
prototype.
This is a reimplementation of the old network queue, but using a class.
This still uses a separate thread, so that packets can wait if there's any
lag. Really, thinking about it, I wonder how necessary this was.
On the upside, no singletons this time. Which means that you can have
several instances of UDPNetworkManager. That's unintentional, but good to
know.
Kayne Ruse