This introduces static getters for every currently-known effect type. At some point in the near future, the magic number constants (which are really network IDs, by the way) will disappear.
Migrating:
- If you used constants (like any sensible person would): for the most part it's just a case of adding a () anywhere you used an Effect constant.
- If you hardcoded magic numbers: ... well, have fun fixing your code, and I reserve the right to say "I told you so" :)
This achieves multiple goals:
1) creating an EffectInstance for application is much less verbose (see diff for examples, especially the Potion class)
2) plugin devs cannot use magic numbers to apply effects anymore and are forced to use type-safe objects. :)
This is a warning shot for plugin devs who use magic numbers. More changes like this are coming in the not-too-distant future.
populateChunk() _sometimes_ does this, but not if the chunk is locked. This means that the empty chunk needed to prevent the shit hitting the fan isn't created when chunks are locked. This change resolves the problem because registerChunkLoader() calls loadChunk() with the create parameter as true when autoload is used. This is a shitty fix but it's the simplest one we have right now, and it works well.
getOfflinePlayerData() will now return NULL if there is no stored data for a given player. The responsibility of checking the spawn point is now delegated to the Player, after it registers a chunk loader on its spawn chunk.
Plugins would indirectly trigger permissible recalculation too early in the login sequence, which then caused their permissions to be recalculated and subscribing them to the broadcast permission far too early.
This prevents plugins sending wrong packets at the compiler level (or would, if we had a compiler). It's more robust than a getter for client/server and throwing an exception since a static analysis tool can detect faults created by sending wrong packets from the server. This is also used to deny service to dodgy clients which send wrong packets to the server to attack it.
this is in preparation for clientbound/serverbound packet separation. I did this already on another branch, but the changeset was dependent on a massive refactor to split apart packets and binarystream which i'm still not fully happy with.
future enhancements:
- make gamemode an object containing information about abilities that players have in this gamemode (gamemodes are just predefined ability sets)
- get the magic numbers out of the API
