Implements pattern matching for easier identification of database types.
Adds support for Postgres alongside existing Sqlite and MySQL types, enhancing flexibility for database connections.
Updates enum to include Postgres type.
Implements a query creator for PostgreSQL, allowing for proper database type mapping and table creation functionalities.
Enhances the library's database support by incorporating PostgreSQL-specific features such as SERIAL/BIGSERIAL for auto-increment columns and improved escape handling for table names.
Improves the extensibility and compatibility of the database framework with different SQL databases.
Removes obsolete query builder interface and implementations.
Introduces a new namespace for query-related classes to enhance organization.
Updates various database managers to use the new query utilities, promoting code reuse and maintainability.
Enhances query functionality, ensuring better consistency across the codebase.
Implements a DbBuilder class to streamline the creation of database connections for both SQLite and MySQL storage types.
Enhances error handling for database setup and ensures that necessary directories are created dynamically based on configuration settings.
This refactor improves code maintainability and readability, consolidating connection logic into a dedicated builder class.
This fixes a bug with a bad actor getting banned with a blank client UUID and then preventing anyone from joining the server due to a lack of UUID on the Connect Request ban check.
This also kicks those who never finish handshaking upon chat now. (To free up the resources a bit I guess?)
Before a player finishes the connection handshake, the server will check if it's necessary to send them a packet - it checks against a list of necessary packets like:
- ContinueConnecting (Send User Slot),
- PlayerSpawnSelf (CompleteConnectionAndSpawn),
- WorldInfo (Which the server does a further check if the player is at the appropriate state to be sent the world info)
- Status
- Disconnection
- TileFrameSection & TileSendSection
If the player has requested world data before sending the spawn player packet, they should be at state 3, otherwise they should be at state 1 for skipping it. Just check based on that instead.
- The player will only finish the handshake once they spawn their player, a normal client would always do this eventually.
- They cannot chat, even if they request world data but just not spawn their player.
- Other clients will not be notified of their join/leave in both cases (dont request WD or do but dont spawn)
- And most importantly, they do not show on the in game player list but still show on the server console /playing cmd.
