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.
Remember: anything with "manager" in its name organizes a number of other
objects, as far as I'm concerned.
I'll eventually have a database connection in the PlayerManager class;
this'll make it easier to manage the database.
Cause:
server/server_application.cpp: line 93
The last argument to std::pair was simply a call to WorldRoom's
contructor. This created a temporary object that fufilled this line, but
after the new std::pair object was added to worldRoomMap, this WorldRoom
object went out of scope.
server/server_application.cpp: line 96
When OpenRoom() was called using an object that was out of scope, the
entire server simply failed.
Solution:
Changed worldRoomMap to hold a pointer to a WorldRoom object, rather than the
object itself. The new and delete operators should be used to create and
delete WorldRoom objects respectfully.
For some reason, when trying to initiate the room thread, the entire
server simply fails. There is no crash, no error message, or anything. I
have no idea what's wrong.
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?
Networking and multithreading working at the same time is really fucking
hard. It's better to just have the one thread, and not worry about speed
at this stage.
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.
lsqlite3.c looked like a good idea for connnecting SQL and lua, but I
couldn't get it to work and rather than struggle on this, I'll write my
own library later on.
I've created a project for client & editor programs, by simply copying one
to the other. Right now, the client still has the editor scene, but I'll
switch that out soon.
I've also added a license header to the server's source. I don't remember
what else I did, but at this point it should theoretically build out of
the box.
Kayne Ruse