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
this produces a major performance improvement for large render distances, and reduces the impact of lighting calculation to zero on servers which have random blockupdates turned off.
this fixes TNT spawning multiple entities when lit by flaming arrows.
The problem here is a bit more complex (entities aren't immediately notified when local block updates happen, so they cache stuff that becomes unusable). The simplest option would be to just lose the cache, but that would have some impacts on performance.
Barring a rethink of the block updating mechanism, this solution seems usable for now.
again, this should never happen, because chunk unloading cleans this stuff out. But if it did happen, loading chunks is not the way to take care of it.
this should never happen, but it could have happened if there was a bug in the code for some reason.
Readers note: I know this looks lik I'm undoing the changes I just did, but what really happened is a name change.
Various bugs existed for a while with stuff using chunk managers instead of worlds when interacting with terrain due to a behavioural inconsistency between World::getChunk() (return from cache or load from disk), and SimpleChunkManager::getChunk() (return from cache only). This change brings the two in line.
World::getOrLoadChunk() has been added as a replacement, which has the same behaviour as the old getChunk() and also makes it more obvious that there is an issue with code using it during refactoring.
the expectation is that eventually this will receive arbitrary internal runtime IDs instead of static id/meta, and RuntimeBlockMapping doesn't really care about this crap anyway.
PHPStan has no idea what is going on in this code because unpack() returns mixed[].
Possibly it might be a good idea to implement a dynamic return type extension for this.
this solves multiple architectural issues:
- improves reusability by avoiding having old state info stick around to fuck stuff up
- prevents access to propagation state from outside of propagation
this also reduces the latent memory usage of light-updates after they have been used.
TODO: we could probably change LightPropagationContext to LightPropagator and move all the propagation-specific code into it if we can solve the subchunk-iterator and effective light problems.
this new form allows skipping some useless checks during sky light calculation and also allows getting rid of the last hard dependency on core Block classes.
We're getting real close to native light now.
I accidentally added this during a separation of my local changes, but it's useful anyway, so we should use it.
This removes BlockLightUpdate's implicit dependency on Block, which is a
step towards native light.
