Both sides of this message uses QUERY_CHARACTER_EXISTS because I'm just
trying to push forward, without worrying about mistakes I might be making.
I just want to merge this back into the main branch so I can say that I've
actually done something over the last few months.
I've also removed a large amount of commented and uncommented code from
in_world.cpp, simply because so much code was dummied out. I can readd
this code as I reimeplement various features.
Project also builds, since I went through and adjusted it. It's hacky
right now, but I just want to make sure it worked. I'll give it another
pass before merging into develop.
The server's changes were easy. The clients means that the constructors
for each scene have one less argument, and each scene has one less member.
The exception to this is LobbyMenu, where the config is used in multiple
places, so it was easier to have the config's reference as a member.
To replace the config's usage, I added this line in most cases:
ConfigUtility& config = ConfigUtility::GetSingleton();
The only requirement is that ConfigUtility::Create() and
ConfigUtility::Delete() are called from the main() function.
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.
Here are more tweaks:
* InWorld's quit event now exits to the main menu, bypassing a relayed disconnect message
* InWorld's disconnect hander no longer throws exceptions (dropped creation packet bugfix)
* CombatData's internals now point to std::pair objects
* Enemies are stored in a global list
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.
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.
This algorithm is designed to find the distance of a certain region,
however it may have been better to do a quick check, rather than worrying
how many regions were loaded at once.
I've also added in some debug code to the map classes, because I was
hunting down a std::bad_alloc beingthrown. Turns out I forgot to set the
map sizes in the client's InWorld constructor. I'm committing the fix, and
the debug code.
Kayne Ruse