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.
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
Deleted in the merge:
* combat_management.cpp
* todo.txt
Amended in the merge:
* server/enemy_factory_interface.hpp
* server/server_application.hpp
* server/server_internals.cpp
That version of combat_management.cpp was not what I was looking for. I'll
try again, this time by working my way down from SerialPacket. It's worked
in the past as far as establishing a standard goes.
todo.txt was deleted in this commit, but will be carried over into the
next develop branch.
I'll release a new demo build without changing the version number, since
there are no functional changes.
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.
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.
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 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.
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.
Kayne Ruse