dev-osrose / osirose-new Goto Github PK

The entityX frameworks throws an assertion when trying to access a component after the character is loaded in memory. The error is Entity::component() assertion 'valid()' failed.
Is it an entityX bug? Or is it from us.

In CPacket we currently have rose packet structures and enums defined. We should move that out into the rosecommon project and make a child class named CRosePacket.

We need a way to remove sessions from the session table. It should happen automatically when a client disconnects but it should also be cleaned on a fresh boot.

For completion of this, we do not need any interactions with the NPC/MOBs. They only need to be able to be seen on the client.

• Spawn NPCs
• Spawn MOBs

We should add into the account table a 'salt' col. This would allow one to salt every password to make it harder to brute force the password hashes.

If one server (char, login or map) crashes, the other ones crashes shortly after as well.

We need to update the MySQL interface class to support stored routines. Using these routines will allow us to change MySQL tables without having to recompile the server application. It should also increase the database security.

Pages to look at:
https://dev.mysql.com/doc/connector-cpp/en/connector-cpp-tutorials-stored-routines-statements.html

We should be able to connect to a MySQL server as well as a PosteGres one in the same pool and everything should be streamlined.

Research on how we can implement the new entity system with the current implementation.

We need to rewrite some of the unit tests, mainly the ones that test server functionality. We should create mocked classes that way we can truly verify that things are working as intended. We should actually move each test area into their own executable that way we can actually make use of the mock classes.

For those who would like to know more info about google mock, see https://github.com/google/googletest/blob/master/googlemock/docs/ForDummies.md

Use std::future* and lock mechanisms to make sure it's thread-safe.

From what I saw, the skills table doesn't get deleted when a character is erased.
It should so we can keep the database clean.

Currently when you login to the server, the server doesn't update the database saying that the account is already logged in. This allows you to login to the same account and character at the same time.

We need to escape all the data sent by the client, especially when sending it to the database.
I was thinking of adding the escape function inside the driver directly to make it more secure.

running too many ioservice threads may kill server performance. We might want to look into creating a ioserver pool that distributes clients out to a fixed number of threads.

The isc clients should attempt to reconnect to the server if the connection was lost. As it is now, once the connection has been lost, the server will just disable and delete the connection. We should not do that as we want to keep the server up and it may have just timed out.

Now that we are starting to have good components, it would be interesting to rewrite the char server packets to use them and simplify maintenance.

• Load skill db
• Load character skills
• Save character skills

It would be good to be able to specify a max length when retrieving null terminated strings (For now it just continue until finding \0 or hitting the end of the packet).
Two possible solutions :

• Add a parameter in CRosePacket constructor specifying the max length of null terminated strings in this packet
• Add some kind of option system: *this >> password >> CRosePacket::Option(CRosePacket::Option::MaxLength, 16) >> username_;

Due to the massive usage of templates, the travis build keeps failing because we are using so much memory in the later build projects.

I have determined that the cause is that the map server includes and builds EVERY packet that the game can use when it only needs a subsection of them. Each cpp file should only include the packet headers it needs instead of including all of them. Doing this will increase build speed.

While we are at it, we should also change the headers to use as much forward declarations as possible to further increase build speed and lower memory usage.

• Create a party
• Invite a player
• Remove a player
• Party Chat

The isc connections need to periodically send the ALIVE packet to the other servers so they won't timeout.

The player should be able to actually move around in the map

It would be nice to be able to start up the servers with command line settings. This would allow us to override server settings without changing the config file and such.

In network_thread_pool.h we create a fixed number of threads to handle I/O operations. It would be better to spawn threads until the CPU usage hits a threshold. This would ensure that we are running at the maximum performance for the server.

Ref on how to get cpu usage: http://stackoverflow.com/questions/63166/how-to-determine-cpu-and-memory-consumption-from-inside-a-process

Orignally the reason why the submodules were put into the tools folder was because I would have the CI services check to see if the folder "3rdparty" was created, if it was not we would download a zip that had the 3rd party dependencies that we couldn't build. Since we have long since gotten rid of that step, we should move all of the submodules out of the tools directory and into the 3rdparty directory (since they are 3rdparty dependencies and not tools).

The servers should send the authenticate packet to make sure they are allowed to be connected. If they fail to authenticate within the allotted time, disconnect them and possibly block connections from that IP for a short time.

The database queries need to ensure that when they are being destructed all of the results have been consumed. If they are not, mysql will throw an error saying that commands are ran out of sync. The best way to recreate this is to run a Stored Procedure call and only consume the first result.

The cross-platform compile is broken because functions deprecated in Visual Studio do not exist in GCC.

Write an automated way to load components from database

Remove old, dead code to make it easier to read the actual working code.

List of dead code so far:
CServerSocket::DoSQL

client states account doesn't exist when using wrong password. should differentiate between these two.

Use sqlpp11 to make it easier to use the database.

• Add sqlpp11
• Implement the current osirose database as a c++ file
• Rewrite the idatabase class (remove?)
• Rewrite the irow class (remove?)
• Rewrite the CMySQL_row class (remove?)
• Rewrite the CMySQL_database class (remove?)
• Rewrite the idatabase_pool
• Rewrite the cmysql_databasepool class (remove?)
• Rewrite the idatabasepoolfactory & idatabasepoolabstractfactory (remove?)

• Load quest lua scripts
• Attach quests to the mobs/npc triggers

• Normal
• Shout
• Whispers
• Broadcast
• Party

The database class will only ever be created once. In this case we do not need to store a pointer to the class in the Server class.

We need to add documentation doxygen-like for at least Core and RoseCommon so people can get involved more easily and don't have to crawl through pages of code to find the right function/class/member or so they don't re-create functions that are already in the code base.

The character server (and map server) needs the structures/classes created for holding character data. This would include inventory, stats, skills, and quest structs. We will also need a way to serialize the data to a database or file.

• Basic character data (stats, looks)
• Inventory
• Skills
• Quests (Do not need to make them work, just the data)
• Load from database
• Save into database

For the map server, we will need to be able to load all relevant data from the client files. This would include map data, mob spawns, NPCs, item data. These classes must be thread-safe and should clean up all memory when destructed. Make sure to write unit tests for the code as well. See ./src/tests/ folder for help on writing tests.

• STBs loaded and stored

I need to rewrite the thread pool class so we can use it for more then just the networking. Also we need it rewritten so it will be API independent.

The pool should be a singleton. It should be used with an interface to be able to experiment with different pool sizes and be able to change the database model (MySQL/PostSQL/etc) used in the pool.

The pool should spawn databases as needed with the correct configuration.

The char server needs to send the login server the list of the channels currently connected. This way we do not need to waste resources on maintaining a db table with currently active servers.

However, we will still log the connections into the database for logging purposes.

• Map server registers with the char server
• Char server tells the login server all relevant info about the map server
• Login server keeps a local copy of the connected channels
• Map server notifies the char server that it is shutting down
• Char server notifies the login server that a channel has shutdown

Currently the top level CMakeLists.txt is a mess and needs to be cleaned up. For example we are setting MySQL++'s include directory even if we don't have mysql enabled.

Write an automated way to save a component to the database

The send function has the chance of trying to acces deleted memory due to the use of async functions. CNetwork_Asio needs to queue the packet buffers and handle deleting the memory after it has sent the packet.

I have decided to require a coding style. We will be enforcing Google's coding style to ensure all code created is easy for someone new to the project to understand by being consistent.

Currently the login server does not make sure that the client has logged in before allowing the client request other data. This can be easily solve by adding an enum on the client state and making HandlePacket only accept packets related to that state.

Example:
They just connected, we will only let them request the ability to login.
They successfully logged in, we now can accept the server select packet, keep alive packet, etc.

The inventory system is already written, but it doesn't take into account the type of the object nor checks if the object can be worn. The stats update also isn't done yet (there's a system for that, but the functions are empty right now).
Everything should be finished.