this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
WorldProviders now have the following requirements removed:
- __construct() is no longer required to have a specific signature
- static isValid() no longer needs to be implemented (you will still need it for registering, but it can be declared anywhere now)
- static generate() no longer needs to be implemented
This paves the way for more interesting types of world providers that use something other than local disk to store chunks (e.g. a mysql database).
WorldProviderManager no longer accepts class-string<WorldProvider>. Instead, WorldProviderManagerEntry is required, with 2 or 3 callbacks:
- ReadOnlyWorldProviderManager must provide a callback for isValid, and a callback for fromPath
- WritableWorldProviderManagerEntry must provide the same, and also a generate() callback
In practice, this requires zero changes to the WorldProviders themselves, since a WorldProviderManagerEntry can be created like this:
`new WritableWorldProviderManagerEntry(\Closure::fromCallable([LevelDB::class, 'isValid']), fn(string ) => new LevelDB(), \Closure::fromCallable([LevelDB::class, 'generate']))`
This provides identical functionality to before for the provider itself; only registration is changed.
this makes more sense overall from a reader's perspective.
and also provide a rug-jerk for any idiots using World->close() when they aren't supposed to? ....
3 is absurdly small. 8 is a more realistic estimation of what the average player's render distance will be (it's also the default server.properties limit).
3 doesn't even fill the default spawn-radius setting, meaning that delays during player connection would occur anyway due to generation.
requestChunkPopulation() respects the queue size, orderChunkPopulation() does not.
requestChunkPopulation() should be used for non-essential generation (which mainly includes generation for player use).
orderChunkPopulation() should probably be used by plugins.
instead of being forced to use the Server async pool
right now the intent of this is to reduce (and ultimately eliminate) the dependency of World on Server, but it might come in useful for other stuff too, for example a chunkserver-based generator implementation which blocks on network instead of eating CPU (it would just waste CPU for other tasks).
The motivation for this is to prevent passing a dynamic argument to cancellation, which in almost all cases is a bug in user code. This same mistake also appears in a few places in the PM core (as seen in this commit), but in those cases the mistakes were mostly harmless since they were taking place before the event was actually called.
closes#3836
