detector rail has fundamentally different functionality than activator and powered rails, so it's misleading to present the same APIs for both.
detector rail's 'powered' state is better referred to as 'activated', since it means the detector rail is actually _producing_ power, and not _receiving_ power.
because of the way async tasks are processed, we might collect results from a task before it's able to be collected by collect(). Therefore, the queue might be empty, even though there are still tasks to be collected.
this avoids needing to call Terminal::init() before starting a MainLogger. Since it inits the formatting codes anyway when log messages are first recorded, it shouldn't be necessary to pre-initialize it.
this resulted in a deadlock in https://github.com/pmmp/PocketMine-MP/runs/1831812620?check_suite_focus=true because the notify() arrived while writeLogStream() was executing.
This ensures that either:
- the notification will occur before the sleep, and therefore no sleeping will occur (this->shutdown = true before the wait)
- the notification will arrive during the sleep.
Player->useHeldItem() assumes that if the old item == the new item, we want to set the item back into the inventory if it's modified in-place. Therefore, we don't modify the item in-place to bypass the problem.
closes#4022
variadics are a bad fit for this because what we really need is to accept callable with any number of arguments. LSP requires that the provided number of arguments must be >= than the required number of arguments.
clickPos is relative to the base block position, so if you keep aiming at the same spot on the block and jump, it thinks you're still spamming.
closes#2730
we don't need to scan the parent classes for anything other than private properties, because protected and public properties will appear on the main reflection as if they were declared directly as such.
this provides some performance improvement (although it's difficult to measure because of cache).
this does mean that we read some garbage data during chunk reads, but it's less costly than hitting the disk twice.
I was unaware that fseek actually makes a syscall which is rather costly, which became painfully obvious during large world conversions on PM4.
On average this problem appeared to be adding about 5ms to the load time for a newly loaded region, which is insanely expensive.
originally I introduced this to make it easier to implement the various APIs addPattern removePattern etc, but those were later removed in favour of simple getPatterns() and setPatterns(), allowing plugin developers to use ext-ds APIs to manipulate patterns.
However, ds poses a number of headaches because of mutability combined with by-ref semantics, which make it a pain to use these on the APIs because we can't guarantee that they won't be modified.
As much as arrays suck, they have two significant advantages over ext-ds: 1) they have copy-on-write semantics, and 2) they support PHP 8.0 without any extra work from me.
