vexyl / mchawk2 Goto Github PK

Before the Vector class I used Position, now there's both and Position automatically converts player coordinates upon copying from Vector, which is confusing. There should only be Utils::Vector with either an explicit conversion function or handled by network-specific code (for conversion between player coords -> block coords).

The server should negotiate each supported extension for each player, storing them in some lookup table. The server should only use those extensions for players supporting them, and it should try to make a sensible replacement if it's not supported. The server should also be allowed to require all or specific extensions for players. Adding extensions through this system should be straightforward and painless to do.

For some reason there's some weird issues with sol2/Lua plugins on Linux (at least on my Debian system). Certain things randomly don't work, but do on Windows. I have a plugin where there's a PlayerData table (and metatable to make it like a class) with functions associated to it, and calling them randomly doesn't execute some of the code inside, but will if inside the main init.lua class. Bizarre. Probably something I'm doing wrong with sol2.

Some plugins may depend on other plugins, so the server should somehow resolve these dependencies. One solution may be to simply have a OnPluginsLoaded hook plugin's can use so that it knows that all plugins have been loaded and initialized up to that point.

Currently, the server does a bunch of CPE stuff before actually getting all the CPE entries from the client. For example, player's that have CPE enabled will receive ExtAddEntityPlayer packets before CPE negotiation confirms support for that entry.

The server should instead wait to add player to the world until some timer expires after receiving an ExtEntry packet, so that the server can assume the client is done negotiating and can continue adding the player.

Some parts of the server could really benefit from some kind of multitasking task scheduler, especially sending maps to players. It doesn't even have to be threaded--switching between tasks every time slice would be sufficient.

I noticed a permanent increase in memory of about .2MB when reloading plugins.

Currently, protocols have lists of valid block types, and the server has no concept of a block with properties. There should be a block struct or class with all needed properties (type, solidity, texture, etc.), storing block definitions in a file and loading them into some list on server startup.

Entities should be automatically replicated to players, updating their name, position, and heading every tick (for which rate should be modifiable). Maybe have some kind of priority? Entities should only be replicated to players nearby unless set otherwise (distance should be modifiable). Adding to replicated entity list should send all interested players the new entity (i.e., ExtAddEntity2) and removing them should also remove them on the player's client (i.e., DespawnPlayer).

This makes it easy to do stuff with entities. If a developer wants NPCs in a game (bots), then they'd manage their own NPC list, linking them to the replication system. Then, if they wanted them to move, they'd simply update their position and it would automatically be replicated to interested players.

Session would make it clearer what the class is supposed to do since all it does is basically keep the connection information and facilitates send/recv for the underlying socket.