this was making the location table point to an offset that did not yet exist, which caused the region header consistency check to discard the region as corrupted the next time it was loaded.
this works around a bug where corrupted text on preexisting signs can mess up the client. This also prevents corrupted text getting onto signs in the future by having them scrubbed and validated before applying them.
this fixes effect durations being off (mostly), closes#2650
there are still some minor differences, but this is closer matching than the previous version.
this is a partial fix for #2717, but still not ideal because it'll spam whenever a chunk is attempted to be generated. However, fixing this properly requires potentially breaking API changes.
this now has a mouthful of a name. I'd like to invert it, but I can't do that without silently breaking backwards compatibility, which is unacceptable.
not ready to call this "fixed" yet because any chests that were already affected by the bug will still be affected. This change will prevent the creation of more broken chests like this.
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.
generating 1 large bounded random costs the same as generating 4 small ones, so it makes more sense to do it like this instead.
Note that prior to 7.1 this code would not work due to it not handling 64-bit appropriately.
In vanilla it doesn't drop the exact number of points you collected. Rather, you lose a little for every level above 1 you had (1 level requires 7 points, later levels require +2 per level), and can recover at most 100 points. Hence, if you had 10 levels, you get back enough points to fill 5 levels and most of a 6th. 14-15 levels gets you the upper bound of about 7.5 levels.
This is not identical to vanilla, but I don't care because it gets rid of edge cases and also makes it easier to integrate with EntityDeathEvent in the future.
I believe this is caused by a bug in the linux kernel, since it only impacts certain machines I tested (one, to be specific). Whatever the case, setting a max backlog size is prudent anyway, and fixes the problem.
Packets with a too-short payload would either cause the RCON thread to hang until the client disconnected, or crash the RCON thread entirely.
commit 90bb1894d7f87645b806f5fc67d1b877bb963180
Author: Dylan K. Taylor <odigiman@gmail.com>
Date: Tue Jan 22 18:15:46 2019 +0000
fix some bugs in RCON
This will now throw an exception at the source instead of crashing when the entity is saved, which should put the blame on the correct plugin responsible for this.
This also includes magic method hacks to preserve backwards compatibility, since the fireTicks field is now protected.
Encoded tags larger than 32KB overflow the length field, so we can't send these over network. However, it's unreasonable to randomly throw this burden off onto users by crashing their servers, so the next best solution is to just not send the NBT. This is also not an ideal solution (books and the like with too-large tags won't work on the client side) but it's better than crashing the server or client due to a protocol bug. Mojang have confirmed this will be resolved by a future MCPE release, so we'll just work around this problem until then.
If a plugin was involved in a crash, we can't safely blame it for the crash, since it might have innocently triggered a core bug. Furthermore, it's difficult to accurately detect plugin causing things like invalid argument crashes.
it's much less expensive to just calculate the modulo of the current tick and 20, and overwrite past entries. The effect is the same. The only difference is that the arrays won't be ordered by time, but that doesn't matter anyway.
This is better for performance because these then don't need to be reevaluated every time they are called.
When encountering an unqualified function or constant reference, PHP will first try to locate a symbol in the current namespace by that name, and then fall back to the global namespace.
This short-circuits the check, which has substantial performance effects in some cases - in particular, ord(), chr() and strlen() show ~1500x faster calls when they are fully qualified.
However, this doesn't mean that PM is getting a massive amount faster. In real world terms, this translates to about 10-15% performance improvement.
But before anyone gets excited, you should know that the CodeOptimizer in the PreProcessor repo has been applying fully-qualified symbol optimizations to Jenkins builds for years, which is one of the reasons why Jenkins builds have better performance than home-built or source installations.
We're choosing to do this for the sake of future SafePHP integration and also to be able to get rid of the buggy CodeOptimizer, so that phar and source are more consistent.
Since 3.2 there have been some runtime performance issues related to garbage collection and dynamic AsyncWorker booting. This is partly because of GC being dumb about shutting down what it thinks are "unused" workers. A worker which has been idle for a single tick is considered the same as a worker which has been idle for hours. The result of this is that on active servers, workers would get shut down and then immediately restarted because of something like chunk sending. Since booting an async worker is frightfully expensive, this causes lag spikes, which is obviously bad.
This commit changes the GC mechanism to only shutdown workers which have not been used for the last 5 minutes.
This was removed way back in 2016 because of an unidentified bug which caused permissible commands not to show up on the client. Back then, command parsing and validity checks were client-sided, and the client would simply not send the command at all if it didn't recognize it. Now, that problem is gone, so it doesn't matter as much if there are permission bugs which cause commands to be erroneously missing.
closes#2625
this bug has existed for so long I forgot it was still here. People stopped pestering me to do something about it, and as a result I forgot to do anything about it.
This hack isn't perfect, but it filters out the worst of the noise. It has side effects for legitimate fast double-clicks, but I don't think anyone will be too bothered - just click more slowly.
This hack may also have negative side effects on poor connections where latency spikes are a problem, but there isn't really much that can be done about that.
Always order chunks ASAP on chunk change, not just during the spawn sequence. This fixes the sluggishness observed in BlockSniper when doing async chunk modifications.
I don't know why this would be missing, but in some cases it is, as seen in the crash archive. Whatever the case, we shouldn't be shitting the bed because of this.
this was observable by planting a sapling underneath an existing tree and punching it with bone meal.
This change will also prevent trees generating too close together.
this should have been done a long time ago, but we didn't want to cause compatibility problems with CA. Now it enforces version checks, this isn't a problem anymore.
this doesn't fix shit but it at least doesn't crash. Fixing this properly can't be effectively done any other way without backwards compatibility breaks. Fortunately it's not common practice to grow trees at the top of the world.
this attribute is not visible on the client and is only used for controlling saturation depletion. It's extremely spammy and as such really shouldn't be sent over network. This has also been causing some minor client-side performance issues in survival.
this must have been missing for how many years now? thanks @shoghicp
this is why we don't do releases on friday night... in my defence my device had the beta installed...
This allows to save the language without rewriting pocketmine.yml. Since this is a "standard" config option (something that the user might want to directly modify) it's reasonable to put it in server.properties. pocketmine.yml is generally reserved for more advanced configuration options.
this technically involves non-breaking API changes which should happen on a patch release, but I can't be bothered with the dust cleanup, so we'll just blow it away now. It doesn't hurt anyone anyway.
This was the cause of a bug with regeneration which caused players taking fatal damage under regeneration not to die correctly. On the server side they would die and immediately regenerate some health, which would cause the next attribute sync to not report the health drop to zero, which made the client unaware that it was dead.
Perhaps attributes should be forcibly synced in some circumstances, but nonetheless regeneration shouldn't apply post-death.
This is an incremental improvement over 4a6841a5a4. This change works better because it also reduces disk spam of crashdumps.
This will now sleep if the server uptime was less than 120 seconds before crashing. If unattended, this will clamp down on automated crashdump spam. If attended, the user can simply press CTRL+C to abort the process and skip the delay.
This takes advantage of two key behaviours of PHP:
1. Assigning a string does not copy the string
2. Changing an offset in a string causes the string to be copied.
These two factors combined, along with the fact that blocklight and skylight arrays are usually all-zeros, allow us to produce a significant memory usage reduction of loaded chunks.
A freshly generated PM world with 3,332 chunks loaded drops from 310MB to 200MB memory usage with these changes applied.
This was suggested recently by @TheDeibo. We don't want users running source-code installations unless they are developers, and developers should know how to boot a source-code installation anyway.
this process of fast-serialization, fast-deserialize, network-serialize is an order of magnitude slower than just doing the network encode directly on the main thread, and also copies more useless data.
For the main thread, the figures were something like 3x more expensive, and then an extra 7x for deserialization on the worker thread. This is a ridiculously large overhead.
this is perfectly fine to use, and preferable to getting a cyclic ref to the scheduler. TaskScheduler->cancelTask() does pretty much the exact same thing, and the scheduler internals are designed to deal with this anyway.
this should produce some reduction in spam at the source.
This could also be used to control the rate at which constantly-crashing servers restart to stop them spamming the disk as well, but the main concern here is eliminating crash archive involuntary DDoS by crashy servers.
This supersedes addChunkPacket() in most cases, and has a more clear name. It broadcasts the given packet to every player who has the target position within their chunk load radius.
This can happen when a light source is removed and later encountering another light source to fill the gap. A higher light level may get set and then not propagated. This bug is difficult to explain, but fairly easy to reproduce.
Grass can cause issues here by requesting blocks randomly offset away from itself, which can cause silent chunk loading on chunk ticking. It also causes crashes if chunk autoloading is taken away, which is obviously undesired.
It was also noticed that player chunkloaders cause chunks to start getting ticked as soon as they load their first chunk, which is before the entity is visible to everyone else on the server. This is probably undesired behaviour.
this can happen when eval() is used, and then we get a big blank mess with nothing on it. eval() is a special case that should be handled separately, but for now this is just fixing a bug.
This was observed in a recent crashdump where a plugin triggered a recursion error, but the stack trace did not contain any sign of a recursive event call. I conclude that this must have been caused by previous event handlers triggering errors 50 times in order to make the recursion detection break, because the recursion detection did not decrement the counter in cases where an exception was thrown.
while we can't deal with this information, it's needed for the sake of unit testing so we don't shit on every bit of incoming data of these packet types.
Use of this by plugins will produce a lot of undefined behaviour, such as event handlers not being unregistered, scheduled tasks not being removed, and registered permissions causing memory leaks.
This check is completely unnecessary since handlers get unregistered when a plugin is disabled. Additionally, this is an extremely hot path and this change produces a modest 5% performance improvement to event calls.
this is cleaner than leaving the player hanging for 5 seconds (which they'll often timeout from anyway). Banning the IP without kicking the player can often look like "lag" and end up getting brushed off as a performance issue.
this dates back to the days where PM used to kill threads to stop them. Today we're more civilized and ask it to stop nicely, so this isn't necessary anymore.
This has the triple bonus effect of a) making a lot of code easier to read, b) reducing Server::getInstance() usages, and c) removing a whole bunch of Server dependencies.
The network and block namespaces are untouched by this commit due to potential for merge conflicts. These should be dealt with separately on master.
This is dependent on the changes made in b1e0f82cbf. This now makes it possible to call events without fetching a Server reference, allowing to eliminate a vast array of Server dependencies.
The basic principle here is "if you're not expecting it, don't catch it".
Event handlers are **never** supposed to throw exceptions. If they do throw exceptions, it's usually going to one of two things;
1. Broken code producing an error
2. Code triggering (and not catching) a runtime error
Both 1) and 2) boil down to defective code on the part of the event handler, and thus should not be caught by the caller, but instead allowed to crash the server and produce a crashdump.
It's also undesirable to catch unexpected errors here for a few other reasons
- It leaves the owner of the event handler in an unknown, potentially unstable state
- It allows broken code to cause event handlers to spam the logger in events that happen frequently (for example movement handlers)
- It allows the process to continue down a train of further undefined behaviour, which may lead to more errors or ultimately a crash, so it makes no sense to hold off the inevitable.
This has a few advantages that are not merely inverted disadvantages:
- Crash dumps will now be created and automatically submitted for defective event handlers, allowing quicker issue location, debugging and fixing in plugins without manual user interaction
- Event calling now isn't dependent on Server to work.
This assumes that the region is properly garbage-collected and packed, but if the file contains uncollected garbage this may not be the case, resulting in a region larger than a gigabyte.
readline on Windows causes issues with console output corruption. Additionally, PM readline impl is extremely buggy and probably ought to be removed. However, have a hotfix for now.
This came to light after observing cfb6856634 in a fresh light. I noticed that this fix should not have been necessary because clearPermissions() should have dealt with it. Unfortunately, permissions can be set without being set in PermissibleBase->permissions, so this misses things.
This is needed for batched lighting updates to work. It also reduces the overhead involved with simply preparing a lighting update and moves the pain to the execute() instead.
this usually causes the console to get spammed with errors. Additionally, in the case where doTick() throws any exception, it's usually because we're in a state we didn't want to be in, so we really should not carry on trying to keep ticking when something breaks here. Instead, this should generate a crashdump.
Previously every thread using the logger had to inherit runtime-defined INI entries in order for the timezone to be set correctly. This removes that requirement.
- Don't allow the same window ID to be used when another window is already using it
- Detect window ID collisions when selecting IDs for regular containers (should never happen, but anything is possible)
this is an absurd bug that nobody would ever otherwise notice, but the problem is that the doOnFireTick() call isn't evaluated if hasUpdate is already true.
leaving out turtle helmet for now because of complications relating to the effect application - I REALLY don't want to tick armour if I can avoid it, due to the performance concerns.
A common pitfall developers fall into with this function is that it has to be called from the scope of the tile class you're creating NBT for, but people commonly do Tile::createNBT() directly, which then results in cryptic "Tile is not registered" errors. This now throws a BadMethodCallException instead to be fully clear about this.
In the future this will be removed completely once NBT is no longer required to create a tile, but for now this is a confusing issue that should be dealt with.
PhpStorm can't see constructor usages when the class name is dynamic. This causes maintenance problems because cross-referencing constructors called like this doesn't show up dynamic calls.
I am eating my own words this once, because having the tester plugin as a separate repository makes no sense - it is just added barriers to writing proper tests with no actual benefit. Since the tester plugin is specifically intended for CI, it doesn't make sense for it to be in its own module.
The original regex almost completely failed at its objective, because it a) only worked if there was no value for the key, and b) did not prevent all such occurrences getting transformed, while quoting patterns that would not get transformed anyway.
There's no implementation here yet, but that can come later. This lays the ground for allowing plugins to have an integrated method to send forms, as well as a solution to the ID conflict problem.
A built in implementation should not be a concretion and it should be able to be swapped for third party implementations. This enables the possiblity to do so.
Previously any random error could occur during an AsyncTask preparing a chunk, and the Level would never know about it and thus never send the chunk.
I don't know how many invisible-chunk bug cases this fixes, but I expect it's quite a lot.
RuntimeException is very generic and might be thrown for other reasons apart from web request failures.
This is backwards compatible because InternetException is a descendent of RuntimeException. Additionally, getURL() and postURL() have intentionally been left untouched for backwards compatibility's sake.
* Added a new PermissionManager, remove ridiculous cyclic dependencies of Permissions on Server
Aside from all the other ridiculous design problems with the permission system, the biggest problems are its API. This is, once again, a result of poor API design copied from Bukkit.
This pull request removes all permission-related functionality from `PluginManager` and moves it to the `pocketmine\permission\PermissionManager` class.
As can be observed from the removed code in the diff, the permissions system was previously entirely dependent on the Server, because it needed to get the PluginManager for registering permissions. This is utterly ridiculous. This refactor isolates _most_ permission-related functionality within the `permission` namespace.
As mentioned above, this stupid API is a direct result of copying from Bukkit. If you look at the API documentation for Bukkit for `PluginManager` you will see that the methods I'm deprecating here are also in there.
## Changes
- Added a new `PermissionManager` class. This can be accessed via its singleton `getInstance()` static method.
- Deprecated the following `PluginManager` methods - these will be removed no later than 4.0.0:
- `getPermission()`
- `addPermission()`
- `removePermission()`
- `getDefaultPermissions()`
- `recalculatePermissionDefaults()`
- `subscribeToPermission()`
- `unsubscribeFromPermission()`
- `getPermissionSubscriptions()`
- `subscribeToDefaultPerms()`
- `unsubscribeFromDefaultPerms()`
- `getDefaultPermSubscriptions()`
- `getPermissions()`
- Added `Internet::getIP()`, `Internet::getURL()`, `Internet::postURL()`, and `Internet::simpleCurl()`.
- Deprecated the corresponding functions in `Utils`. Updating to the new functions is as simple as replacing `Utils` with `Internet`, since this doesn't break backwards compatibility.
The deprecations should be catered for by plugin developers. These deprecated redirects will be removed no later than 4.0.0.
This reverts commit 0081e30a89.
The logic introduced by this commit is correct in MC JAVA 1.9+. Unfortunately, nobody likes 1.9+ for combat.
Some testing in MCPE vanilla made it apparent that this logic isn't correct for MCPE. The old logic is correct for pre-1.9 knockback.
it's possible to walk off a tower while flying without moving vertically, and this code previously wouldn't detect that, leaving a gaping hole in the anti-cheat.
Under normal circumstances, none of the boxed code will throw exceptions. Under exceptional circumstances, the caller should know about it. Usually the caller is the server. We don't want to catch unexpected exceptions because those should crash the server and generate a crashdump.
this was an interesting bug.
This was discovered by making a projectile's drag 0, making its gravity a factor of its throw force (such that force / gravity = integer value), and then throwing it directly up. At the apex, an error would occur due to trying to do a ray trace with a zero vector.
This also led me to realize that there's an edge case in the current movement system - if an entity's motion reaches 0, it will stop getting movement updates. This can be undesirable when things such as gravity cause motion to become zero when throwing a projectile directly upwards. This will need to be fixed separately.
As discussed in #2297:
Honestly I don't see a fit purpose for async saving at all. It should either always be synchronous or always asynchronous, and at the user's own option. However, this isn't currently possible because Config doesn't enable you to get the serialized content without writing it to disk.
Consider the following code:
```php
for($i = 0, $size = $this->getServer()->getAsyncPool()->getSize(); $i < $size; ++$i){
$this->getServer()->getAsyncPool()->submitTask(new class extends AsyncTask{
public function onRun(){
sleep(5);
}
});
}
$config = $this->getConfig();
$config->set("steve", "hi");
$config->save(true);
$config->set("steve", "bye");
$config->save(false);
```
Output:
```yml
---
steve: hi
...
```
Expected output:
```yml
---
steve: bye
...
```
Additionally, if your configs are causing you performance issues when you're saving, it's a clear sign that
a) you're saving too much
b) you're abusing configs and should consider using a database.
Configs should be used for _simple_ data which does not change much. Configuration is such that the _user_ is expected to be able to modify it. As such, it should never be an issue to save synchronously.
In the future, something like ReactPHP may be introduced to allow proper async saving. When this happens, async saving would always be sequential but non blocking. Using threads for this makes no sense.
I wasn't sure whether this would be considered a bug fix or a feature. Nonetheless, it's a behavioural change, so it belongs in 3.1 if anywhere.
Prior to this, plugins would be required to call saveDefaultConfig() before calling getConfig() or anything else. Calling getConfig() without saveDefaultConfig() first would generate an empty configuration file. Instead, it now saves the default config before loading it.
I don't care if this matches PC behaviour or not. bugs.mojang.com is full of bug reports about this. Just search for "minecraft spawn protection not working" and you'll see what I mean.
If you want to disable spawn protection, actually disable it. This behaviour is something that most users are not aware of and find astonishing when they discover it.
This behaviour was copied from Minecraft PC, and it's nearly as unexpected there as it is here.
This commit reverses the stupidity done in eb0525e892.
fixes#2295
There is still an issue in that the spawn point will not be offset if the chunk is not generated, but this is better than the spawn point being down at y=0. The other issue is a job for another time.
This is quite an interesting bug. If you have
```php
class A{
public function onMove(PlayerMoveEvent $event){} //shouldn't be a handler because this class isn't a Listener
}
class B extends A implements Listener{}
```
then
```php
registerEvents(new B, $plugin);
```
then `A::onMove()` will be registered as an event handler even though `A` is not an instanceof `Listener`.
This was observed by noting that plugins which do something like `extends PluginBase implements Listener` causes `registerEvents()` to try and register `PluginBase` methods as event handlers, which could lead to astonishing behaviour.
then A::onMove() will be registered as an event handler even though A is not an instanceof Listener.
This was observed by noting that plugins which do something like "extends PluginBase implements Listener" causes registerEvents() to try and register PluginBase methods as event handlers, which could lead to astonishing behaviour.
this fixes a potential exploit where clients could append JWTs signed with their own keys to the end of the chain containing fake XUID/UUID/username which would then overwrite the legitimate ones in earlier links.
This stems from the fact that the final link of the vanilla chain contains the client's own pubkey, so the client is able to append its own data to the end of the chain.
I considered making this instead save the default config instead of creating an empty config file, but that would be (albeit minor) a behavioural change which therefore belongs in 3.1.
this goes on 3.1 because it changes the behaviour of chunk cloning, which might possibly break some plugins, and this isn't a bug fix.
This should see no change in behaviour other than a minor performance improvement and slight reduction in memory usage.
If there is an empty list of blocks in the changedBlocks array for a chunk, that means that blocks changed the normal way and then were later set the direct way in the same tick. This means that no action needs to be taken on these chunks.
onGround doesn't necessarily reflect 0 motion, because something else could change the motion prior to the onGround flag getting updated - for example 2 knockbacks in a row.
This can happen when an attacker attacks a victim wearing thorns armour while having low health, which prior to this commit would cause the tool to be duplicated.
this has already been seen to cause duplication bugs when thorns is used. Anything else that modifies inventory during applyPostDamageEffects() when the mob is possibly dead will also cause duplication issues.
This allows controlling how arrows are picked up:
- by anything
- by only creative players
- by nothing
This adds new API methods to Arrow:
- getPickupMode()
- setPickupMode()
This adds new public constants to Arrow:
- PICKUP_NONE
- PICKUP_ANY
- PICKUP_CREATIVE
they got removed from the tasks array, but not from the queue (for performance reasons). The queue gets cleaned up by the heartbeat, but it was checking if there were things in the main array, not in the queue.
There are a couple of other bugs with cancelling tasks that this doesn't fix that are rather more complicated to deal with.
krakjoe's profiler hasn't been updated since 2013. I doubt it's going to get updated in the near future. These days we use xdebug, which is either always on or always off.
PhpStorm can't see these or understand how they are being called, which is very annoying for bug hunting. Additionally, we already have the CodeOptimizer for this.
This has long been a waste of time and creativity, and that's only going to continue to be the case now that we're going to be properly versioning. New codenames every couple of months is not worth the bother.
This may raise a few eyebrows.
Does this mean that all the things that were planned for API 3.0.0 are done?
Not at all. The plans laid out in December 2016 for API 3.0.0 were far too ambitious, and as a result the ALPHA series dragged out forever (18 months now). This is a break away from those plans, to bring development and release flow back to some sort of sanity.
Does this mean that my plugins will stop breaking all the time now?
No, it does not! Development isn't going to stop, although breaking changes will be confined only to major API releases. It's anticipated that the major API version will be bumped as nearly as often as the ALPHA version was during the last 18 months. The reason for this return to 3.0.0 is to allow us to fine-tune our release flow so that plugin developers can get advantage of newer, non-breaking API features without having to bump the API in a breaking way.
What are the criteria for the API versions now?
- Major: This will be bumped for breaking changes, changes which will break plugins. it's expected that we'll roll out new major versions regularly.
- Minor: This will be bumped when non-breaking feature additions are made, such that API 3.0.0 plugins would still load on 3.1.0. However, plugins requiring 3.1.0 will not run on 3.0.0.
- Patch: This will be bumped for bugfix updates. Plugins requiring 3.0.0 will work on 3.0.1, but not vice versa.
TL;DR: This insanity has gone on far too long.
This features a near-total rewrite of PluginLoaders and some code associated with them.
Highlights:
- PluginManager->registerInterface() does not return anything, and now accepts a PluginLoader instance instead of a string.
- PluginLoader itself is drastically simplified. getPluginFilters(), enablePlugin() and disablePlugin() are now removed. loadPlugin() responsibilities are now solely confined to doing whatever is necessary to make the plugin's classes visible by the server, and does not emit log messages or check for data directories.
- PluginBase->init() and PluginBase->isInitialized() have been removed.
- Plugin interface now declares a signature for the constructor which implementations must comply with.
- Plugin interface now declares setEnabled().
This changes how the AsyncPool works so that it does not immediately always start all of the workers in the pool.
Instead, workers will be started only when an idle worker was not found.
This allows for significant memory footprint reductions while idle.
In effect the async-workers setting in pocketmine.yml now dictates a _maximum_ pool size, not a fixed pool size.
* Implemented InventoryEventProcessor, fixes#1986
Event processors can now be registered and unregistered at will. Entity inventory/armor change events are now handled by event processors instead of the inventories themselves, which allows enabling/disabling the calling of these events at will.
This now avoids stupid things happening when initializing inventory contents, since the callers for those events are now registered _after_ the contents are initialized.
the Entity base also accounts for this, and assuming that this is automatically valid is causing lots of crashes. I am not sure of the circumstances under which this is suddenly becoming null, but this shouldn't assume that the level is valid nonetheless.
If the same chunk is set into multiple different places in the world, the chunk's position is no longer able to be relied on, because it will have the position of the last place it was set. This results in chunks not getting sent correctly when the same chunk is set in multiple places.
This avoids the bug by using known valid coordinates (using chunk hashes) to establish the real coordinates, and also adds an assert to notify developers should they unintentionally set a duplicate chunk by mistake.
- Doesn't need to be pre-populated with biomes prior to calculating the heatmap - now population of biomes is entirely dependent on the lookup function, improving consistency
- Uses an abstract class method for lookup instead of callback (use anonymous class instead)
- Faster because the heatmap is directly populated with biomes instead of biome IDs, removing an unnecessary lookup.
- Removed `Server->getScheduler()`. All plugins now have their own scheduler which is accessible using `Plugin->getScheduler()`. Aside from being syntactically more concise and pleasant, this also allows much more effective management of tasks when plugins are disabled.
- Removed `PluginTask` class. Before this PR it was necessary for plugin tasks to descend from `PluginTask` to ensure that the server could clean them up correctly on plugin disable. This is no longer necessary, so the `PluginTask` class has been removed. Plugins may now utilize the `Task` class as a base if they like.
- Added `Server->getAsyncPool()`. Since the global scheduler does not exist any more, it does not manage the server's `AsyncPool` any more. Additionally, `ServerScheduler` was previously bloated by a lot of `AsyncTask` related methods, which are now not necessary because direct access to `AsyncPool` is granted instead.
- `ServerScheduler`:
- `ServerScheduler` has been renamed to `TaskScheduler` since it is now a general-purpose task scheduler which is non-dependent on the user. This allows much greater flexibility and also makes it possible to unit-test.
- All `AsyncTask`/`AsyncPool` related methods have been removed - the task scheduler does not manage the async pool anymore.
- Calls to `Server->getScheduler()->scheduleAsyncTask()` should be replaced with `Server->getAsyncPool()->submitTask()`.
- Calls to `Server->getScheduler()->scheduleAsyncTaskToWorker()` should be replaced with and `Server->getAsyncPool()->submitTaskToWorker()`.
## Backwards compatibility
This poses significant backwards compatibility breaks for any plugins utilizing Tasks or AsyncTasks. These breaks are described above, along with basic upgrade steps. The upgrade process is quite straightforward.
## Follow-up
A large part of the goal with this pull request is to modularize these parts of the code so that they can be reused and also unit-tested. I would like to remove the existing test set from TesterPlugin at some stage when the AsyncPool can operate without a Server.
Because of the above, I am considering making further backwards incompatible changes directly to `AsyncTask` to remove the `Server` parameters from `onCompletion()` and `onProgressUpdate()`. These shouldn't be too difficult to upgrade from and can be prepared for in advance.
This is a significant breaking change for anything utilizing Tiles as they now do not store their NBT at runtime anymore.
This is another step in the process of ridding PocketMine-MP of runtime NBT.
It can be noticed that all tiles are now using class fields to store properties instead of NBT, which is much faster, uses less memory and is also more concise when written in code.
Highlights:
- Tile->namedtag has been removed.
- Tile->saveNBT() now accepts a CompoundTag() parameter. Typically it's expected that this will be fed a newly-created CompoundTag (this part may be improved in the future).
- New internal methods Tile->readSaveData() and Tile->writeSaveData() have been added. Instead of overriding __construct() and saveNBT() to load and save properties from NBT, you should now implement these methods instead.
This is not final and will see further changes before it's done.
This is caused by the Spawnable constructor calling spawnToAll() before the tile is fully initialized. I really really really hate constructors that _DO_ things by themselves.
this never really worked properly and is a bad idea anyway. This was the cause of many sign-going-blank bugs before it was broken (by me), and since it's broken it's now useless. I don't think there's any practical way to make this work properly, so I leave it up to plugins to decide whether or not they want to cancel sign editing in protected areas. PocketMine-MP built-in spawn protection will already block this by default anyway.
By default it starts 30 workers on Travis because there are 32 logical cores available. This is ridiculously excessive and pollutes the log with debug spam.
This change breaks pretty much all API pertaining to synchronous task scheduling.
Significant changes:
- Server->getScheduler() has been removed
- Plugin->getScheduler() has been added - every plugin now has its own scheduler
- Because schedulers are now per-plugin, it is now unnecessary for PluginTask to exist because stopping plugin tasks on plugin disable is as simple as destroying the plugin's scheduler. Therefore PluginTask has now been removed and it is expected for things to now use the base Task class instead.
For the most part, plugins will simply need to change Plugin->getServer()->getScheduler()->... to Plugin->getScheduler()->...
Another highlight is that plugin tasks now no longer have global IDs - they are unique to each scheduler.
This commit contains quite a few breaking changes with respect to how AsyncTasks are handled. This is necessary to allow separation of the ServerScheduler and the AsyncPool, because in the future the ServerScheduler may be removed and instead there will be isolated per-plugin sync-task schedulers - but we cannot have every plugin with its own worker pool for memory usage reasons if nothing else.
The following things have changed:
- ServerScheduler: scheduleAsyncTask(), scheduleAsyncTaskToWorker(), getAsyncTaskPoolSize(), increaseAsyncTaskPoolSize() and similar methods have all been removed. Additionally the static \$WORKERS field has been removed.
- Server: added API method getAsyncPool(). This grants you direct access to the server's AsyncPool. Calls to getScheduler()->scheduleAsyncTask() and scheduleAsyncTaskToWorker() should be replaced with getAsyncPool()->submitTask() and submitTaskToWorker() respectively.
this implementation was god-awful bad and it was entirely avoidable to make it this complicated.
This utilizes the fact that pthreads treats static properties as thread-local. AsyncTask local storage now utilizes a \SplObjectStorage stored in an AsyncTask private static field.
Code dependencies can be seen in the code and in the composer.json file. Besides, there are additional third-party libraries used by PocketMine-MP now which are not listed in this section, and I don't plan to maintain it...
Once upon a time, these userland functions were faster than calling builtins, but not anymore. According to my test the Math functions are twice slower in PHP 7.2 with typehints and 50% slower without typehints.
Inlining is slightly faster than using builtins, but the difference is very small - not worth making the code look any more ugly than it does already.
This is the same bug that Entity->getBlocksAround() had, except this actually checks for BB intersections. What this means is that as a result of the bug, one extra layer of blocks is unnecessarily checked on the max sides of the BB.
For example:
Assume you have a BB with maxY -5.5
You're definitely colliding with block -6 (because you're inside it) and you want to check an extra block in case you hit something weird like a fence.
So you want to check _at most_ up to block -5 (inclusive).
Following this maths:
-5.5 + 1 = -4.5
ceil(-4.5) = -4
This causes us to check block -4 unnecessarily. This may be a performance waste - depending on the BB size it could be proportionally a lot of blocks getting unnecessarily checked. This has not been benchmarked.
these are items that do nothing and/or are only used for crafting. As such they are simple to add.
Others will be added later on, but others require extra work and/or reverse engineering which I don't have time for now.
Totem usage can be detected using the MODIFIER_TOTEM constant of EntityDamageEvent.
This does not currently support using the totem in the offhand because offhand is not implemented yet.
The general purpose of this is to split up base damage from modifiers.
- Added methods getBaseDamage(), setBaseDamage(), getOriginalBaseDamage(), getModifiers(), getOriginalModifiers()
- setDamage() renamed to setModifier() and type is now mandatory
- getDamage() renamed to getModifier() and type is now mandatory
- getOriginalDamage() renamed to getOriginalModifier() and type is now mandatory
- Removed MODIFIER_BASE constant
- Constructors now accept: float baseDamage, float[] modifiers instead of just float[] modifiers
Terminal::hasFormattingCodes() should be used instead (this is also portable across threads even if constants aren't inherited by child threads, provided that the child thread has an autoloader available.
Since this is managed by Composer now, it's expected that users should install dependencies appropriately when running from source code. We have a few more dependencies than just RakLib and SPL which are version-critical which are not checked here, and I don't have the taste for adding more version checks here.
A better way would be to automatically detect outdated Composer autoloader and warn that dependencies might need updating, but I'm not sure how to do that off the hop. Users should prefer using prebuilt phars anyway - only developers and/or people who know what they are doing should be running the server from source code.
this is only used in one place, where it's being given floats, and it's 10% faster to use int for this because it won't convert it.
It is also 25% faster to remove typehints and 60% faster to inline it. We really need a proper PHP preprocessor for inlining.
this fixes crashes when PurePerms causes this to be recalculated on player login - the client doesn't like receiving this before StartGame and crashes.
Confining this to post-spawn should not cause any issues since any permission recalculation in login events will be reflected immediately afterwards when the initial command data is sent anyway.
This same bug popped up at 1.1... I don't know why it wasn't fixed properly back then.
this is nearly the same as 1.5.0.0, except the skin packet premium boolean has been dropped.
This isn't production ready yet because the blockID table needs updating (waiting on MrARM to fix his script for that).
Players have a few associated inventories which might need sending nowadays, such as main, armour, offhand (not implemented yet), cursor, crafting (if it ever worked). Under these conditions we should be sending all open windows.
long overdue... this isn't quite as extensible as the original api3/blocks system was, but this is primarily intended to replace Item->useOn(). If plugins want to use it it can be extended later on.
This now utilizes Snooze in order to have the server wake up to process RCON commands ondemand, similar to how the CommandReader thread operates. This is better for performance and response times.
This also makes a few other changes:
- RCON thread will now waste less CPU since it uses a blocking select() with timeout to read
- Following from that, IPC sockets are used to allow interrupting select() from the RCON thread.
- Multiple threads for RCON has been removed (this is entirely unnecessary, reading data from sockets is not CPU-intensive, and a single thread is easier to work with)
in some cases the main thread was trying to signal the server killer to stop before it was even started due to limited resources available for scheduling.
ArrayOutOfBoundsException is not thrown by SPL anymore since the exception handler throwing it was removed by @shoghicp. Regardless, it seems cleaner to to check it properly.
This allows other threads to notify the main thread to wake it up while it's sleeping between ticks, allowing reduction of processing latency.
Currently only RakLib and the CommandReader threads utilize this, but it's planned to extend it to more things in the near future.
CommandReader is now event-driven instead of poll-based - the server will not poll the CommandReader thread for messages each tick anymore.
RakLib utilizes this mechanism to get packets processed without delays to lower latency.
This now adds an extra dependency - `pocketmine/snooze` library contains the meat of the code used for this. See the Snooze repository for details.
pthreads doesn't play well with resources, and this code upsets it. Also, this code is utterly pointless.
The whole of RCON needs burning to the ground...
It is somewhat reasonable to have a function in an event handler which accepts an Event parameter, but is not a handler. For example, multiple event handlers can redirect to the same function to process an event, but this function may not want to receive called events.
There are other ways to get around this, such as making the event handler protected/private, or adding a dummy parameter, but this way is cleaner and more explicit.
Relevant old-repo PR: PocketMine/PocketMine-MP#2143
This allows plugins to soft-depend on other plugins without separating their listeners into a dedicated class for listening to that plugin.
This can be utilized by adding a `@softDepend PluginName` to the event handler's annotations.
If the plugin providing the event does not exist or is not loaded, then the handler will silently not be registered.
If it does exist and the event is not found, the original behaviour applies and an exception will be thrown.
This change should be fully backwards compatible.
Yes, I am not happy about this either. new-versioning has issues, and there hasn't been enough development and testing on it.
I didn't want to delay release to cram in a half-baked new versioning system, and it's ended up delayed anyway and new-versioning is still half-baked.
we're overdue a new release, so here it is.
this was causing unexpected behaviour particularly on burning trees, whereby fire would be unconditionally extinguished if the block below it was removed.
This makes the behaviour match vanilla. This will now allow Fire block itself to handle deletion of itself when the area is not suitable (now that the logic is implemented in Fire for this).
This allows attempting to place in invalid conditions, which is as expected. This will produce the sound and flash as per vanilla, as the fire extinguishes itself.
this happens when a player respawns before their death animation ends. I don't know why, but their bounding box height suddenly becomes zero. This solves the bug by simply resending the height and width properties to viewers on respawn.
Closes#2135.
As of 1.2.13 release, the client now skips the crafting grid step when it crafts with right-click on the recipe book. This means that we can't validate crafting based on the crafting grid contents anymore. The only way to do it now is to use the inputs and outputs calculated by the transaction balance.
Returning false all the time could mean any one of a range of things. Throwing exceptions is better in that it allows us to catch them and see what actually broke.
This is basically how blockstate discovery would actually work in the full-blown system. This maps blocks with unrecognized blockstates to static runtimeIDs not known to the client.
This means that all blocks which don't have corresponding runtimeIDs in the new system will translate to update! blocks instead.
Mojang do this differently: they try to a) match id+meta, if that fails b) match id+0, and if that fails, then replace with update! block runtime ID. I can't do that here because I need to be able to convert both ways. They only need to be able to convert from legacy -> new.
this needs further changes (particularly to Furnace) to stop things abusing NBT for runtime data handling, otherwise performance is going to drop off a cliff.
This allows deleting lots of code, and additionally provides a huge reduction in the compressed size of CraftingDataPacket. Since we don't care about these UUIDs (they are only used in CraftingEventPacket, which is broken and unused in PM) we fill them with zeros instead.
This commit brings in a much-needed rewrite of crafting transaction handling.
The following classes have been removed:
- CraftingTransferMaterialAction
- CraftingTakeResultAction
The following classes have significant changes:
- CraftingTransaction
- All API methods have been removed and are now handled in CraftItemEvent
- CraftItemEvent
- added the following:
- getInputs()
- getOutputs()
- getRepetitions() (tells how many times a recipe was crafted in this event)
- Recipe interface:
- Removed getResult() (individual recipes may handle this differently)
- CraftingRecipe interface
- removed the following:
- matchItems()
- getExtraResults()
- getAllResults()
- added the following
- getResults()
- getIngredientList() : Item[], which must return a 1D array of items that should be consumed (wildcards accepted).
- matchesCraftingGrid(CraftingGrid)
- ShapedRecipe
- constructor now accepts string[], Item[], Item[]
- ShapelessRecipe
- constructor now accepts Item[], Item[]
the requirement for a crafting table is determined by the number of ingredients can fit on the grid (shapeless) or the max height and width (shaped). It's impossible to craft a big recipe with a small crafting table simply because you're not able to put the required resources into the grid.
This now handles the case where there are multiple options which could be taken, and opts for the first result which successfully ties all the actions together. Previously it would be entirely down to chance (ordering) whether the actions would get ordered successfully.
this old code is extremely inefficient. This showed up distinctly in my crafting bruteforce benchmarks, where I discovered that getContents() accounted for the vast majority of the time taken to match shaped recipes.
Since the addition of resetLastMovements(), this code is useless.
Additionally, it doesn't make sense to ignore the first movement, because the first movement still _moves the player_ from point A to point B.
This just causes it to attempt to spam chunk orders prior to the player spawning. It won't succeed, because the render distance is zero.
The other time this could occur is when teleporting into an unloaded chunk, but it's not necessary to continually spam chunk orders in that case, especially since chunk orders are done on teleport anyway.
This prevents unexplained segfaults on accidental event call recursion by limiting the max depth of event call stack to 50. If another event attempts to be called, an exception will be thrown.
* Event handlers always handle subclass events. public static $handlerList no longer required.
* Removed $handlerList declarations
* HandlerList cleanup: Removed HandlerList->handlers and related bake methods
* Removed obsolete Event->getHandlers()
* EventPriority: Added fromString()
* PluginManager: throw exceptions on registering handlers with invalid priorities
This allows specifying a handler of `EntityDamageEvent` which will handle any instanceof it (as per current behaviour), AND also now allows specifying a handler specifically for `EntityDamageByEntityEvent`, which only handles `EntityDamageEvent`.
This was not previously possible due to limitations in the way handlers were registered.
Abstract events may not be handled unless they declare the `@allowHandle` PhpDoc tag.
This is a bad fix for an issue found in one specific use-case. This is redundant because the only places this is used are places where it's guaranteed to be valid, or places where it is checked to be valid anyway.
The Level leak originally noted that led to the creation of this class is something I consider to be a non-issue, because all the heavy things will be cleaned up anyway.
This happened when a block was set into the world with a direct update, when an entry for that block was already present in the changedBlocks map. This fixes the bug by removing the entry from the changedBlocks map to avoid sending outdated block updates in batches.
closes#2106
For some strange reason, using aliases overwrites the original command name instead of coexisting with it. This is rather astonishing behaviour, and probably a bug in the client. However, this workaround is the same thing vanilla does (see /tp in vanilla).
Chunks were used by tiles for a couple of things:
- 1. for coordinates - which can be gotten using bitshifts
- 2. setChanged() - which is unnecessary as seen in the previous commit
Removing this circular dependency was actually remarkably easy to do.
This allows the removal of lots of ugly code, and also exposes lots of similarities with how this update type was handled. This can be further improved in the future to more generically handle cases.
I realized in the process of changing this, that it might actually be simpler to treat to treat scheduled updates and neighbour updates as one and the same. They use the same mechanism for being saved on chunks (TileTicks),
and doing that would make updating only require one queue instead of two.
RedstoneOre: use onActivate() to trigger glowing
this is not technically correct behaviour, but this preserves the current behaviour.
Previously to this, a level would be considered "not generated" if no level providers registered as valid for that directory. This caused astonishing behaviour when the user's world has, for example, a mixture of .mca and .mcr region files - the world would instead get _re-generated_ according to the default level format, which might or might not load the existing regions depending on the format used for generation. This behaviour is utterly absurd.
This changes the behaviour of the generated check to check for a non-empty directory in the given path. Non-empty directories without recognized world files in them are now considered to have an unknown format.
This is necessary because the stupid client constantly spams right-click actions if you carry on trying to eat/throw/whatever the item when cooldown is in effect. Therefore ender pearls would be fired like machine guns without these checks server side.
this was caused by abe5d94d5b because player's lastBlah wasn't getting updated anymore.
Player movement handling really needs cleaning up, but for now this fixes the issue.
save() calls saveChunks() which saves any chunks found to be modified. But chunk unloading does this anyway, so it's better to unload first and then trigger the save mechanism, to avoid saving chunks twice.
This supports vanilla placement of paintings, with overlap and collision checking.
Paintings are removed when a block is placed inside them or if any of their supporting blocks are removed.
As per vanilla, a random painting is chosen from the largest subset that will fit into the given space.
it appears that errors are occurring in the exception handler when handling corrupted regions, leaving regions in the provider index with incomplete location tables. This causes strange-looking errors later down the line.
This moves the region assignment to the end of the condition to avoid leaving incomplete/corrupted regions in the location table when errors occur.
This now removes logging from the level providers (for the most part) and replaces it with exception throws and catches. The implementation using the providers should catch these exceptions if they are thrown.
closes#2047
Since the player list already indexes players by UUID, it's simple to just use that for fetching the player.
A possible future improvement could be to allow fetching an _offline_ player by UUID, but no capability to do that is yet available.
This function is not declared in any useful places (like the CommandSender interface) and it is not present in Player (!!!). Additionally, an is-player check is better done with an instanceof so that type safety is enforced and IDEs can give auto-complete.
This is a BC break, but this is such a pointless function that it's probably not even worth mentioning.
This is completely unnecessary and adds extra complexity for no good reason. Maybe it was used historically, but nowadays it is only used to identify players to send async-prepared batch packets to.
There are two alternative ways to do that:
1. use spl_object_hash() as the targets array in CompressBatchedTask
2. use ServerScheduler's object storage to retain references to the Player[] array.
I've opted for the second method.
Removing these identifiers allows great code simplification in removePlayer() and removes the need for those old stupid hacks.
This also includes a backwards-compatibility break by removing the $identifier parameter of Server->addPlayer().
The child powershell is a workaround for an unidentified bug which causes colours to get messed up after using git in the same console window. However, loading profiles on the child is a major slowdown when starting the server, and for no good reason.
https://bugs.php.net/bug.php?id=75992
When plugins do time-limited bans and users enter stupid time values, a shitty bug in ext/date gets triggered, but only when reading the ban entries from disk. DateTime->format() is able to produce formatted strings which have more than 4 digits in the year, which are then considered invalid. This works around it by trying to parse a formatted version on the fly to ensure that it is valid.
This also cleans up and improves ban list loading and handling.
This cleans a lot of mess out of the bootstrap file, and also has the added bonus that threads which do not inherit functions can now get access to them by autoloading Utils.
Currently an ItemBlock is created for every Block requested, but this will need to change in the future (for Anvils because they have stupid bitshifts on the meta instead of a nice bitmask). This allows registering items in the ItemFactory with IDs lower than 256 and having them recognized.
This allows retrieving the name of an item without the custom name being plastered over the top. This will also allow weird things to have special functions for their names.
This convention is used throughout the code to allow plugin developers to alter the behaviour of the event. In this case, it would instead produce unexpected behaviour when the event is not cancelled by a plugin.
Since we don't use the PEAR-style namespacing convention, there's no reason to use PSR-0 autoloader.
We don't quite follow PSR-4 conventions because there is still a pocketmine subdirectory, but changing this might pollute the git history, so I'm wary of changing it.
These are never called accidentally, or at least it's highly unlikely to do so. It might be reasonable to throw exceptions for this, but for the meantime they are redundant - extra indentation for no good reason.
This also removes the $force parameter from BlockFactory::init().
Wanting initialized item factory does not require initializing the creative inventory. This is often useless and unwanted extra baggage (when this is used on threads for example).
This code is no longer necessary, because entities are constructed with a Level instead of a Chunk since API 3.0.0-ALPHA4. This means that they will not get allocated in the wrong chunk at runtime after having been saved on the wrong chunk by something else (such as an older version of PM). They will instead be allocated in a chunk selected by bitshifting their coordinates.
This is necessary to be able to fix#1789 without causing entities affected by the infamous bitshift-on-floats bugs to inexplicably vanish.
* Revert "Revert bad duct-tape fix that broke lots of other things"
This reverts commit 4a4900e5e7.
Player: Perform respawn actions when joining while dead
This fixes exploits related to #1567 by calling respawn logic on join when the player has zero health.
This is a shitty fix and doesn't solve the actual issues described in #1567, but it's a simple solution for the exploits related to it.
This also removes a cyclic dependency between TextFormat and Terminal, meaning that TextFormat is now standalone without any external dependencies.
This is also an API break. Beware all ye who wander here, master = bleeding-edge!
TAG_String has a UTF-8 payload, which makes it more expensive to work with. Also, skins can contain bytes which are not valid UTF-8 characters and will therefore be treated as corrupted by external tools.
Additionally a TAG_String can only hold 32767 bytes, which might become a problem in the future.
A TAG_ByteArray can hold up to 2GB of data, and there is no character encoding restrictions on it.
This fix doesn't fix existing data, but it will prevent the bug happening in the future by capping the length of strings to 32767 bytes, and throwing an exception if too long.
This extension hasn't been maintained in 4 years and it doesn't make sense to update it to PHP 7, since :shoghi: just dumped a blob of PHP into zephir. It's not worth the hassle of updating.
I prefer to modularise and then C-ify modules, so that they can be reused on their own.
SIGKILL constant is defined by pcntl, not by posix. If pcntl is not compiled then bugs can occur when trying to kill() the server (such as during a crash).
Closing the command window immediately when an error occurs is particularly unhelpful. This keeps the command window open so that the user can see what went wrong.
[ci skip]
Exceptions occurring early in the start sequence (before BaseLang is initialized) will result in the server hanging and not killing process as expected. This works around that issue.
This was causing new players to inexplicably spawn in the wrong place when joining a world for the first time which had a different level name than folder name. With LevelDB worlds, this caused them to spawn wayyyy up at y=32767 for no good reason.
We don't want people to be using latest development builds, but that's the first thing people see when visiting Jenkins. We want them using releases instead.
Synchronize with the logger thread when logging an exception or killing. This forces the main thread to wait for disk write to complete when logging exceptions or killing the process.
everything else should produce a nice big stack trace for debugging purposes, because everything else is probably bugs
This fixes random exception error messages getting relayed to the client when a user does stupid things like editing the source code without knowing what they are doing.
This was a bug in older versions, fixed by 890f72dbf2. However since ALPHA10 this has been moved to the new, strict-ified CompoundTag API, which shits its pants when it encounters a tag of the wrong type.
Closesjojoe77777/Slapper#119
This makes #1567 less exploitable. Now, players who attempt to exploit this bug will get stuck - they won't be able to move or do anything. Not ideal, because they won't be able to respawn either - but it's better than nothing.
This needs to be updated server side and isn't because of the way player movement is currently handled. Fixing this properly will require a lot more work than this.
Inventory holders are now freed from BaseInventory. They are now declared by subclasses by convention, but are not required in most cases.
Ideally, this would be followed by the removal of the need for inventories to know their holders at all. They should just be simple containers of items.
This fixes#1560 by removing FakeBlockMenu.
plugins might be using this method, or the item may have been dropped involuntarily due to server-side logic. Therefore it should be handled when the transaction is received and not when the item is dropped into the world.
Try setting a fire at z = -204, then stand on the edge between -205 and -206.
The coordinates that a BB's corners are encapsulated in are always the floor()ed coordinates
If you stand at -205.0, your BB min is -205.3 and your BB max is -204.7, which then incorrectly tells you that the BB intersects with block -204
because ceil(-204.7) == -204
when you actually are only intersecting with -205 and -206
this is as bad as using (int) to floor integers :kms:
This includes several other changes, including:
- SLOT data properties now accept items directly
- POS data properties now accept floored Vector3s (in future this will be block positions) or null for 0,0,0
- VECTOR3F data properties now accept Vector3s or null for 0,0,0
It's only now used in the Durable class, so it does not make sense to keep it in Item anymore. This is a leftover from the days where Durable did not exist.
So this came from a bugfix (795d6c8ddf) which fixed a memory leak related to entities getting kill()ed on chunk unload.
HOWEVER, me2016 did NOT realize that this code is actually entirely pointless and causes unexpected behaviour.
removeEntity() is used in 2 places in the core code:
1. in Entity->close() (so close() doesn't need to be called again, obviously)
2. in Entity->switchLevel() (which then causes the entirely unexpected behaviour of close()ing the entity on level change.
Conclusion: This code is pointless. This fixes the bugfix.
Invalid characters in plugin names are no longer stripped. They always result in a load error.
The behaviour of replacing spaces with underscores is not changed.
MOP doesn't make any sense anyway.
RayTraceResult is a container which represents the point at which a line hits a bounding box. No dependence on blocks or entities is wanted or needed.
MovingObjectPosition has API changes to allow it to wrap RayTraceResult, but nothing uses MOP anymore anyway.
This would allow modularisation of the pocketmine\\math namespace.
Fixes#1903Closes#1906, which, while a pretty solution, is very inefficient (see PR discussion). This is an optimization of microscopic proportions, but the point still stands.
First working enchantment on master. Hooray for 3 years late.
This works out of the box (the code checking for this enchantment already exists in Human->doAirSupplyTick()).
Remove MCPE-network specific stuff from BinaryStream, added NetworkBinaryStream
This removes dependencies of BinaryStream on core code, while providing some consolidation of network handling code.
at the expense of magma no longer working (which will need to be done better anyway).
This:
- reverts the +0.01 outset which hugely exacerbated the lava bug (fixes#1892)
- adds a 0.001 inset (PC-style) which prevents entities incorrectly intersecting with diagonally adjacent blocks at far-ish coordinates (lava at x=4000, z=4000 is a good way to test this).
PR #1880 does also solve this issue, but again at the expense of magma. Since the bugfix does not require a big bounding-box handling refactor, it has been separated out.
This is a rather larger commit than I'm happy with, but oh well.
This kills off the enormously overcomplicated BlockIterator and replaces it with a VoxelRayTrace class containing ray tracing generator functions. These functions are independent of any Level. They yield Vector3 objects with current ray trace positions to allow implementations to handle the intercepted blocks in their own ways.
Living->getLineOfSight() now uses VoxelRayTrace instead of BlockIterator.
This used to cause problems in earlier versions of pthreads if PTHREADS_INHERIT_CLASSES was not used. This is no longer a problem in pthreads v3, because pthreads v3 copies passed threaded object classes under the hood, so there is no need to manually include them anymore.
Additionally, the files in these paths don't exist anymore.
This might cause problems later on, but it's unlikely. Right now however, I am tired of my various PHP version directories showing up in git untracked files.
This is annoying and it requires that the server must match this precisely to not cause bugs. Additionally, this code shits its pants when the client hits a spot of network lag.
This can be implemented easily as a plugin. There is no reason whatsoever for this to be in the core.
Survival reach distance is 6, but that's only a measure of how far the player must reach to hit any part of the target block. Measured from the centre, this again provides a possible corner reach which is too far away from the centre of the block by sqrt(3) / 2 blocks.
Simple fix - allow an extra block's distance.
Since chunks are unloaded before changed blocks are processed, there is a small chance that a block might get changed in a chunk, and then get unloaded due to not being in use, before the updates are broadcasted.
This is unlikely to ever happen since chunks usually don't get unloaded unless they don't have loaders anyway, but it could happen (?) if a chunk is forcefully unloaded.
This is needed because players can break blocks that are outside of their field of view. A player can be inside a block and be able to break that block, while looking up, which places its centre (which is where the interact check is done from) actually behind the player's field of view. This causes anti-cheat to be triggered and makes it impossible to break blocks one is inside.
This commit changes the max negative diff to be half of the distance between a block's centre and its corners (M_SQRT_3 / 2).
This now removes the need for recursing around for structures comprised of multiple blocks. Instead, override getAffectedBlocks() to return all blocks that need to be deleted when the current block is deleted, and make sure that only one half of the block drops something. When a player breaks one of the blocks, all the blocks affected by that block will also be destroyed, creating particles and sounds where appropriate.
This fixes creative drops for double plants and beds.
This may be invalid in some cases, such as:
- chunk is not loaded
- entity is not fully constructed
- entity is a Player who has not yet completed the login sequence.
Level providers are now cut back to just an interface to a world's data. They don't keep their own chunk registries or any stupid shit like that because the Level already does that.
This furthers the goal of being able to move level I/O off the main thread, and also drastically decreases the complication of implementing level providers.
The remaining methods, constants and fields in the NBT class now pertain to generic NBT functionality (except for the matchList()/matchTree() methods, but that's a job for another time). All NBT I/O specific logic has now been moved to NBTStream and its descendents.
the modulo (%) operator only operates on integers. If it's used on floats, they are silently casted to ints, which results in loss of accuracy. Fractions of a degree might not seem important, but for ray-tracing purposes a fraction of a degree can make the difference between hit and miss.
* Removed broken EntityEatEvents - these don't fit the pattern since they only apply to Human entities anyway. PlayerItemConsumeEvent and PlayerInteractEvent can be used for cancellation purposes, and plugins can do custom stuff without mess.
* Restrict item consuming to Living entities only
* Added FoodSource->requiresHunger()
* Only items implementing the Consumable interface can now be consumed.
* The effects from consuming items are now generic-ized by way of the Living->consume() function. This is overridden in Human to allow applying food and hunger.
* Fixed the hardcoded mess for buckets
This fixes#983, but I haven't yet tested if this will prevent cheating in an actual hacker scenario. Needs more tests.
Additionally, this should remove the need for the negative threshold - if the diff is less than 0, the player is almost definitely cheating.
This issue can be seen on W10 Edition. Stand on the corner of a block and turn so that the majority of the target block is behind you. Then look down and try to mine it.
Rarity is used for "weighting" enchantments on enchantment tables and such. Therefore higher numbers mean the enchantment is more common. This changes the rarity values to match vanilla.
* Enchantment: Split enchantment type data from instance data
This commit splits enchantments into (effectively) enchantment TYPES vs enchantment INSTANCES.
When applying an enchantment to an item, it only needs to know 2 things:
1. the enchantment ID (identifier) which is used to identify the TYPE
2. the enchantment LEVEL which is used to modify the enchantment's power IN THIS INSTANCE.
Therefore, the LEVEL is not an immutable property. However, all other properties of the currently-named "Enchantment" class are immutable type properties.
Currently, when applying an enchantment to an item, a copy of the enchantment object is created from the registry, and returned. This copies all of the properties contained by the type, which is obviously sub optimal.
MCPE always uses LF for line endings. PHP_EOL might be LF, CRLF, or CR depending on the platform, so it should not be used for (for example) sending messages to players containing newlines.
This changes the block cache to be a 2-dimensional hashmap of [chunkHash][blockHash]. This is needed to more effectively dispose of chunk-specific block caches when chunks are modified.
This now destroys the cache for specific chunk indexes in the following circumstances:
- When a chunk is unloaded (the cache isn't needed anymore)
- When a chunk is set into the world (for example, from the generator)
- When a chunk is loaded (probably unnecessary)
This resolves the ghost blocks bug many have been complaining about.
Seems that leaves are another special case - they technically speaking accept any tool to break, but only drop when shears are used. They don't REQUIRE shears because if they did the break time would be longer for non-shears tools.
getDrops() should now be overridden only for special cases. There are some non-trivial overrides left that are going to need some extra work to clean up.
The function name is a little long-winded, but that can always be refactored later if needed. This provides a way for blocks requiring specific tools to override drops with non-standard stuff without needing to worry about what tool type was used.
It's also possible that passing the Item used here is actually entirely redundant, but again that can be fixed later.
This name better describes it. "can be broken with" implies that items which this returns false for cannot destroy the block at all, which is incorrect. What this actually returns is whether the item is the best tool to use to break the block.
@ -28,7 +28,7 @@ NO support whatsoever will be provided for third-party modified variants of Pock
Note that 32-bit platforms are no longer supported by PocketMine-MP and issues concerning 32-bit platforms will be closed.
-->
* PocketMine-MP:
* PocketMine-MP:<!-- LATEST IS NOT A VALID VERSION -->
* PHP:
* Server OS:
* Game version: PE/Win10 (delete as appropriate)
@ -43,6 +43,6 @@ If the issue is **not** reproducible without plugins:
### Crashdump, backtrace or other files
- Do not paste crashdumps into an issue - please use our Crash Archive at https://crash.pmmp.io for submitting crash reports to not spam the issue tracker. Add links to your reports in the Crash Archive here.
- Please use gist or anything else to add other files and add links here
- Please use gist or anything else to add other files and add links here
- **make sure that you are using the latest supported version** before opening an issue.
- **test it on a clean test server, WITHOUT PLUGINS**, to see if the issue still occurs. If not then it may be a plugin issue. Please also indicate the result of such tests.
-[Search the issue tracker](https://github.com/pmmp/PocketMine-MP/issues?utf8=%E2%9C%93&q=is%3Aissue) to check if anyone has already reported it, to avoid needlessly creating duplicate issues. Make sure you also check closed issues, as an issue you think is valid may already have been resolved.
- If your issue is related to a plugin, **do not report here, contact the plugin's original author** instead.
- **make sure that you are using the latest supported version** before opening an issue.
- **test it on a clean test server, WITHOUT PLUGINS**, to see if the issue still occurs. If not then it may be a plugin issue. Please also indicate the result of such tests.
- **[Search the issue tracker](https://github.com/pmmp/PocketMine-MP/issues?utf8=%E2%9C%93&q=is%3Aissue)** to check if anyone has already reported it, to avoid needlessly creating duplicate issues. Make sure you also check closed issues, as an issue you think is valid may already have been resolved.
-**Do not report plugin issues here.** If your issue is related to a plugin, contact the plugin's original author instead.
- **Support requests are not bugs.** Issues such as "How do I do this" are not bugs and will be closed. If you need help, please see [here](README.md#discussion) and do not misuse our issue tracker.
- **No generic titles** such as "Question", "Help", "Crash Report" etc. A good issue report provides a quick summary in the title. If you just got a crash report but you don't understand it, please look for a line starting with `Message`. It summarizes the bug.
-Information must be provided in the issue body, not in the title. No tags like `[BUG]` are allowed in the title, including `[SOLVED]` for solved issues.
- Similarly, no generic issue reports. For bugs, it is the issue author's responsibility to provide us an issue that is **trackable, debuggable, reproducible, reported professionally and is an actual bug**.
<br><br>Valid issue reports must include instructions how to reproduce the issue or a crashdump/backtrace (unless the cause of the issue is obvious).
<br><br>**If you do not provide us with a summary or instructions on how to reproduce the issue, it will be treated as spam and will therefore be closed.**
<br><br>In simple words, if the issue cannot be properly confirmed to be valid or lacks required information, the issue will be closed until further information is provided.
- **Provide information in the issue body, not in the title.** No tags like `[BUG]` are allowed in the title, including `[SOLVED]` for solved issues.
-**No generic issue reports.** For bugs, it is the issue author's responsibility to provide us an issue that is **trackable, debuggable, reproducible, reported professionally and is an actual bug**.
<br>Valid issue reports must include instructions how to reproduce the issue or a crashdump/backtrace (unless the cause of the issue is obvious).
<br>**If you do not provide us with a summary or instructions on how to reproduce the issue, it will be treated as spam and will therefore be closed.**
<br>In simple words, if the issue cannot be properly confirmed to be valid or lacks required information, the issue will be closed until further information is provided.
- To express appreciation, objection, confusion or other supported reactions on pull requests, issues or comments on them, use GitHub [reactions](https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments) rather than posting an individual comment with an emoji only. This helps keeping the issue/pull request conversation clean and readable.
- If your issue is related to the PocketMine-MP website, forums, etc., please [talk to a human directly](README.md#discussion).
## Contributing Code
-To contribute code to the repository, [fork it on GitHub](https://github.com/pmmp/PocketMine-MP/fork), create a branch on your fork, and make your changes on your fork. You can then make a [pull request](https://github.com/pmmp/PocketMine-MP/pull/new) to the project to compare your branch to ours and propose your changes to our repository. We use the Pull Request system to allow members of the team to review changes before they are merged.
## Contributing
To contribute to the repository, [fork it on GitHub](https://github.com/pmmp/PocketMine-MP/fork), create a branch on your fork, and make your changes on your fork. You can then make a [pull request](https://github.com/pmmp/PocketMine-MP/pull/new) to the project to compare your branch to ours and propose your changes to our repository. We use the Pull Request system to allow members of the team to review changes before they are merged.
- By proposing a pull request to the project, you agree to your code being distributed within PocketMine-MP under the [LGPL license](LICENSE).
### Licensing
By proposing a pull request to the project, you agree to your code being distributed within PocketMine-MP under the [LGPL license](LICENSE).
- At PocketMine, **we enforce a very high standard for contributions**. This is because PocketMine-MP and its related projects are used very widely in production. While this might seem like we are being mean at times, **our priority is what is best for PocketMine-MP itself**. We try to ensure that our project's codebase is as clean as possible and ensure that only top-quality material makes it through to PocketMine-MP itself. **If a contribution does not live up to our standards, changes may be requested or the pull request may be closed.**
- **Your pull request will be checked and discussed in due time.** Since the team is scattered all around the world, your PR may not receive any attention for some time.
- **Avoid using GitHub Web Editor**. The web editor lacks most useful GIT features and **should only be used for very minor changes**. It is immediately clear if the web editor has been used, and if so the PR is more likely to be rejected. If you want to make serious contributions, **please learn how to use [GIT version control](https://git-scm.com/)**.
- **Do not copy-paste code**. There are potential license issues implicit with copy-pasting, and copy-paste usually indicates a lack of understanding of the actual code. Copy-pasted code is obvious a mile off and **any PR like this is likely to be closed**. If you want to use somebody else's code from a Git repository, **use [GIT's cherry-pick feature](https://git-scm.com/docs/git-cherry-pick)** to cherry-pick the commit. **Cherry-picking is the politer way to copy somebody's changes** and retains all the original accreditation, so there is no need for copy-pasted commits with descriptions like `Some code, thanks @exampleperson`.
- In addition to the above, **make sure you can explain your changes**. If you can't provide a good explanation of changes, your PR may be rejected.
### Contribution standards
- **We enforce a very high standard for contributions**. This is because PocketMine-MP and its related projects are used very widely in production. While this might seem like we are being mean at times, **our priority is what is best for PocketMine-MP itself**.
We try to ensure that our project's codebase is as clean as possible and ensure that only top-quality material makes it through to PocketMine-MP itself.
- **If a contribution does not meet our standards, changes may be requested or the pull request may be closed.**
### Pull requests
- **Create a new branch for each pull request.** Do not create a pull request with commits that exist in another pull request.
- **Code should use the same style as in PocketMine-MP.** See [below](#code-syntax) for an example.
- **The code must be clear** and written in English, comments included.
- **Use descriptive commit titles.** You can see an example [here](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
- **Try to stick to one change per commit.** This ensures that if you create a PR with several changes, we can decide which ones we wish to include and which ones not to include.
- **It is inadvisable to create pull requests with large commits** unless this has been discussed with the team beforehand. Large pull requests are difficult to review, and such pull requests may end up being closed. The only exception is when all features in the pull request are related to each other, and share the same core changes.
- **Do not include multiple unrelated changes in one commit.** An atomic style for commits is preferred - this means that changes included in a commit should be part of a single distinct change set. See [this link](https://www.freshconsulting.com/atomic-commits/) for more information on atomic commits. See the [documentation on `git add`](https://git-scm.com/docs/git-add) for information on how to isolate local changes for committing.
- **Your pull request will be checked and discussed in due time.** Since the team is scattered all around the world, your PR may not receive any attention for some time.
- **It is inadvisable to create large pull requests with lots of changes** unless this has been discussed with the team beforehand. Large pull requests are difficult to review, and such pull requests may end up being closed. The only exception is when all features in the pull request are related to each other, and share the same core changes.
- **You may be asked to rebase your pull request** if the branch becomes outdated and/or if possibly conflicting changes are made to the target branch. To see how to do this, read [this page](https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request).
- **Details should be provided of tests done.** Simply saying "Tested" or equivalent is not acceptable.
### Code contributions
- **Avoid committing changes directly on GitHub. This includes use of the web editor, and also uploading files.** The web editor lacks most useful GIT features and **should only be used for very minor changes**. It is immediately clear if the web editor has been used, and if so the PR is more likely to be rejected. If you want to make serious contributions, **please learn how to use [GIT version control](https://git-scm.com/)**.
- **Do not copy-paste code**. There are potential license issues implicit with copy-pasting, and copy-paste usually indicates a lack of understanding of the actual code. Copy-pasted code is obvious a mile off and **any PR like this is likely to be closed**. If you want to use somebody else's code from a Git repository, **use [GIT's cherry-pick feature](https://git-scm.com/docs/git-cherry-pick)** to cherry-pick the commit. **Cherry-picking is the politer way to copy somebody's changes** and retains all the original accreditation, so there is no need for copy-pasted commits with descriptions like `Some code, thanks @exampleperson`.
- **Make sure you can explain your changes**. If you can't provide a good explanation of changes, your PR may be rejected.
- **Code should use the same style as in PocketMine-MP.** See [below](#code-syntax) for an example.
- **The code must be clear** and written in English, comments included.
**Thanks for contributing to PocketMine-MP!**
@ -78,17 +68,18 @@ It is mainly [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accept
- Strings SHOULD use the double quote `"` except when the single quote is required.
- All code SHOULD have parameter and type declarations where possible.
- Strict types SHOULD be enabled on new files where it is sensible to do so.
- All constant declarations SHOULD be preceded by a visibility modifier.
There are a very wide range of already-written plugins available which you can use to customise your server. Check out [Poggit](https://poggit.pmmp.io), or just search GitHub.
@ -23,19 +22,10 @@ There are a very wide range of already-written plugins available which you can u
Yes you can! Contributions are welcomed provided that they comply with our [Contributing Guidelines](CONTRIBUTING.md). Please ensure you read the relevant sections of the guidelines carefully before making a Pull Request or opening an Issue.
### Where can I get the latest .phar?
Head over to our [official Jenkins server](https://jenkins.pmmp.io/)
- Latest release builds can be found in our [GitHub releases](https://github.com/pmmp/PocketMine-MP/releases).
- Latest bleeding-edge development builds (and other builds in the build job channels) can be found on our [Jenkins server](https://jenkins.pmmp.io/).
**Note: Please avoid development builds unless there is no other alternative for what you need.** Development builds are subject to changes at any time without notice, and it is likely that your server or plugins might break without warning.
//If PHP version isn't high enough, anything below might break, so don't bother checking it.
return[
\pocketmine\NAME." requires PHP >= ".MIN_PHP_VERSION.", but you have PHP ".PHP_VERSION."."
];
}
$messages=[];
if(PHP_INT_SIZE<8){
$messages[]="Running ".\pocketmine\NAME." with 32-bit systems/PHP is no longer supported. Please upgrade to a 64-bit system, or use a 64-bit PHP binary if this is a 64-bit system.";
}
if(php_sapi_name()!=="cli"){
$messages[]="You must run ".\pocketmine\NAME." using the CLI.";
}
$extensions=[
"bcmath"=>"BC Math",
"curl"=>"cURL",
"ctype"=>"ctype",
"date"=>"Date",
"hash"=>"Hash",
"json"=>"JSON",
"mbstring"=>"Multibyte String",
"openssl"=>"OpenSSL",
"pcre"=>"PCRE",
"phar"=>"Phar",
"pthreads"=>"pthreads",
"reflection"=>"Reflection",
"sockets"=>"Sockets",
"spl"=>"SPL",
"yaml"=>"YAML",
"zip"=>"Zip",
"zlib"=>"Zlib"
];
foreach($extensionsas$ext=>$name){
if(!extension_loaded($ext)){
$messages[]="Unable to find the $name ($ext) extension.";
critical_error("Selected PHP binary ($binary) does not satisfy some requirements.");
foreach($messagesas$m){
echo" - $m".PHP_EOL;
}
critical_error("Please recompile PHP with the needed configuration, or refer to the installation instructions at http://pmmp.rtfd.io/en/rtfd/installation.html.");
echoPHP_EOL;
exit(1);
}
unset($messages);
error_reporting(-1);
function error_handler($severity, $message, $file, $line){
if(error_reporting() & $severity){
throw new \ErrorException($message, 0, $severity, $file, $line);
$logger->warning(PHP_EOL.PHP_EOL.PHP_EOL."\tYou are running ".\pocketmine\NAME." with xdebug enabled. This has a major impact on performance.".PHP_EOL.PHP_EOL);
}
if(\Phar::running(true)===""){
$logger->warning("Non-packaged ".\pocketmine\NAME." installation detected. Consider using a phar in production for better performance.");
$logger->warning("Timezonecouldnotbeautomaticallydeterminedorwassettoaninvalidvalue.Anincorrecttimezonewillresultinincorrecttimestampsonconsolelogs.Ithasbeensetto\"UTC\" by default. You can change it on the php.ini file.");
}while(false);
functiondetect_system_timezone(){
switch(Utils::getOS()){
case'win':
$regex='/(UTC)(\+*\-*\d*\d*\:*\d*\d*)/';
/*
* wmic timezone get Caption
* Get the timezone offset
*
* Sample Output var_dump
* array(3) {
* [0] =>
* string(7) "Caption"
* [1] =>
* string(20) "(UTC+09:30) Adelaide"
* [2] =>
* string(0) ""
* }
*/
exec("wmic timezone get Caption",$output);
$string=trim(implode("\n",$output));
//Detect the Time Zone string
preg_match($regex,$string,$matches);
if(!isset($matches[2])){
returnfalse;
}
$offset=$matches[2];
if($offset==""){
return"UTC";
}
returnparse_offset($offset);
case'linux':
// Ubuntu / Debian.
if(file_exists('/etc/timezone')){
$data=file_get_contents('/etc/timezone');
if($data){
returntrim($data);
}
}
// RHEL / CentOS
if(file_exists('/etc/sysconfig/clock')){
$data=parse_ini_file('/etc/sysconfig/clock');
if(!empty($data['ZONE'])){
returntrim($data['ZONE']);
}
}
//Portable method for incompatible linux distributions.
$offset=trim(exec('date +%:z'));
if($offset=="+00:00"){
return"UTC";
}
returnparse_offset($offset);
case'mac':
if(is_link('/etc/localtime')){
$filename=readlink('/etc/localtime');
if(strpos($filename,'/usr/share/zoneinfo/')===0){
$timezone=substr($filename,20);
returntrim($timezone);
}
}
returnfalse;
default:
returnfalse;
}else{
$phar=new\Phar(\Phar::running(false));
$meta=$phar->getMetadata();
if(isset($meta["git"])){
$gitHash=$meta["git"];
}
}
/**
* @param string $offset In the format of +09:00, +02:00, -04:00 etc.
$logger->critical("Running ".\pocketmine\NAME." with 32-bit systems/PHP is no longer supported. Please upgrade to a 64-bit system or use a 64-bit PHP binary.");
$exitCode=1;
break;
}
if(php_sapi_name()!=="cli"){
$logger->critical("You must run ".\pocketmine\NAME." using the CLI.");
$logger->critical("You have the native PocketMine extension, but your version is higher than 0.0.4.");
++$errors;
}
}
if(extension_loaded("xdebug")){
$logger->warning(PHP_EOL.PHP_EOL.PHP_EOL."\tYou are running ".\pocketmine\NAME." with xdebug enabled. This has a major impact on performance.".PHP_EOL.PHP_EOL);
}
$extensions=[
"bcmath"=>"BC Math",
"curl"=>"cURL",
"json"=>"JSON",
"mbstring"=>"Multibyte String",
"yaml"=>"YAML",
"sockets"=>"Sockets",
"zip"=>"Zip",
"zlib"=>"Zlib"
];
foreach($extensionsas$ext=>$name){
if(!extension_loaded($ext)){
$logger->critical("Unable to find the $name ($ext) extension.");
++$errors;
}
}
if($errors>0){
$logger->critical("Please use the installer provided on the homepage, or recompile PHP again.");
@ -38,10 +38,14 @@ class HardenedClay extends Solid{
}
publicfunctiongetToolType():int{
returnTool::TYPE_PICKAXE;
returnBlockToolType::TYPE_PICKAXE;
}
publicfunctiongetToolHarvestLevel():int{
returnTieredTool::TIER_WOODEN;
}
publicfunctiongetHardness():float{
return1.25;
}
}
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
