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 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.
This allows specifying a PocketMine-MP PHP file to execute (phar or source) to use to run the server, like start.sh. If not specified, auto-detection is used.
This parameter is hardcoded to \pocketmine\PATH in PocketMine.php. Additionally, it does not make sense for the server source path to not be the server source path. \pocketmine\PATH is accessible from the Server context, therefore it should be used and does not need to be stored.
This is already checked in Living->attack(). It's preferable to allow it to be cancelled there since plugins can then un-cancel EntityDamageEvent to bypass the effect.
* Added Liquid->getLiquidLevelDecreasePerBlock()
* Fixed lava turning into cobblestone when flowing over water
* Cache liquid flow vectors for faster entity movement
* Removed a condition that made lava impossible to get rid of
In the PC code, the equivalent code makes the delay between scheduled ticks 4 times longer. Here, it just breaks the code. I don't know what the 4x stuff is about, but this code does not produce the expected behaviour and lava works fine regardless.
* Fixed strange behaviour with liquids trying to flow into other liquids
Liquids should consider other liquids as a path of least resistance. However, they should not actually flow into them. This fixes a variety of CPU leak issues with falling water in large water bodies such as oceans.
This also fixes the plus-shape effect that liquid is supposed to produce when a source is placed above ground.
* Removed a bad optimization making liquids flowing down slopes behave undesirably
* Optimize performance of slope searching by limiting recursion depth based on previous path lengths
If we already found a step down on a previous run after 2 blocks, it doesn't make sense to continue allowing checking 4 blocks because the results will just be ignored. This allows limiting the number of recursion steps, which significantly improves the performance when flowing down slopes.
However, this will still be just as bad for performance on flat terrain as it was to start with.
* Make some Liquid methods only accept Blocks as parameters
these are only ever passed blocks anyway, doesn't make sense to allow vectors.
* Moved some things to local variables
these are each only used in one function, so it doesn't make sense for them to be class members.
* Fixed water flow down slopes going everywhere, but degraded performance again
* Lava should only search 2 blocks for a slope
* Stop wasting CPU calculating optimal flow directions for liquids with too-high decay
It calculates the flow directions and THEN doesn't use them when it
realizes the flow decay is too high. This is completely pointless.
* Use a less hacky method to handle lava flowing into water
* Doubled flow performance on flat terrain
Since calculateFlowCost() usually ends up visiting the same blocks about 6 times when on flat terrain, it makes sense to cache some stuff for when blocks get revisited so expensive dumb checks don't need to keep on being done. On my machine this produces a 50-60% performance improvement when flowing on flat terrain.
* Fixed missing return values in Liquid->onUpdate()
these return values aren't used anywhere, but we should be consistent
* Don't allow flowing back in the same direction we just came from
This reduces the recursions by about 30%, providing about the same percentage performance improvement.
* Remove Liquid's temporalVector (it's not used anymore)
primitive types for the win!
* Move liquid collide to its own method
* add sound for lava/water mix
Plugins may cause this issue unexpectedly by unloading levels directly during events such as EntityDamageEvent. This adds a better error message to allow developers to understand what is going on and create appropriate workarounds.
this resolves problems with crashes when getName() is called on an unloaded level. This obviously doesn't solve the root cause of the issue (level being accessed after unload) but since many things use the level name without checking if it's unloaded first, it's a bad idea for it to be volatile.
This resolves the server crash issue noted in #1527, where an exception is raised due to level unload during a tick, which subsequently causes a crash when trying to log the exception.
This could occur when light sources were placed near each other and one of them is removed, the other's light would not be propagated far enough because the node wasn't queued for updating although it was marked as if it was.
Most of these methods are called from onUpdate(). It's unreasonable to
assume that the level might be null during a tick (unless a plugin
messes with a block update event or something, but that's undefined
behaviour anyway). Using getLevel() simply wastes processing time by
constantly checking if the level is closed.
Always register the level provider (to allow detecting the world format) but throw exceptions if anything tries to use it without the extension being loaded.
This reverses a bad solution for #1482 for level unloading on PlayerQuitEvent which caused more widespread issues with plugins doing other, more common things on player quit which directly affected the save data.
since we don't have a stats server at the moment, this simply causes long delays on server stop while the server instance attempts to communicate with stats.pocketmine.net.
sadly this isn't particularly useful without something like the intl
extension to translate the language codes to ISO-632-1 codes like the
ones PocketMine-MP uses. However, this will do for now.
otherwise we could end up with undesirable bugs like players having the wrong skin when travelling from another part of the world... the skin has to be sent to everyone to update the player list
this will still always save using the legacy format to remain compatible with PC < 1.11.
TODO: entirely separate entity NBT format from entity implementation for proper multi-format compatibility
If this was an inline assert, it would be harmless. Since it's in a function, it contributes to a 20% performance loss when using these functions on a large scale regardless of whether assertions are enabled or not.
Additionally, there's no need to assert that we have enough bytes since unpack() will raise warnings if there isn't, which will trigger exceptions, and for readByte(), an undefined offset notice will be raised, which will also trigger an exception.
TL;DR: This is simply wasting CPU time for no good reason.
this is not an optimal solution because you'll still only get 1 crafting
event when the user actually crafted a lot of items, so this isn't very
nice for plugins to work with. However, for gameplay purposes it works,
so it'll do for now.
take fences as an example: say you have fence1 and fence2 next to each other, like this:
|==|
and they are joined together
then delete the fence on the right
the left fence will then look like this
|
but the server would still think its collision boxes were like this:
|=
so you wouldn't be able to shoot arrows through that space.
This commit clears pre-computed bounding boxes when a block is set using Level->setBlock() (in case the block was previously already set and has pre-calculated outdated AABB). However, because of weird blocks like fences, glass and walls, they must also be cleared on neighbour block update (since connection state isn't shown in the block data).
This change resulted from many complaints and ugly boilerplate code because getNamedTag() is only ever used when you want to read from the tag or modify it. If you have code that depends on this returning null, you should use hasCompoundTag() instead.
- fixed ridiculous network stats when title ticker or console colours are disabled (shoghicp, what fit of madness led you to think this was a good idea)
- fixed network stats reporting kb/16ticks instead of kb/s
- fixed TPS reporting getting reset after 16 ticks instead of 20
- title ticker and MOTD is now updated every 20 ticks instead of 16
- we don't use the UUIDs, and they change every time, this just pollutes the diffs and makes my contribs ridiculous
- we don't need the height/width of shaped recipes because the generated shape tells us what it is
the footprint of compressed chunk batches is so small now that it doesn't make sense to disable it out of the box. The performance gains from caching chunks are more than worth it.
As of 1.2, the average footprint of these caches is usually ~2% or less of the size of the actual chunk itself. Moving around a lot will frequently cause the same chunks to get sent several times as it passes in and out of your render distance, and the chunk isn't even changing in that time, so the chunk is getting needlessly re-serialized over and over again. So even if your world is not static (for example a creative server) chunk caching will still offer benefits, and the memory expense is so small it's a no-brainer.
zero is not allowed because it's pointless, just raise your compression threshold if you want zero compression.
Chunks will always be compressed regardless of threshold because they are huge. It doesn't make sense to allow uncompressed chunks when even compression level 1 will reduce their size 50x. The point of the last two (reverted) commits was to prevent compression level zero being used on chunks. Probably obvious that I was up late and not thinking very clearly.
Revert "Reduced chunk compression level to 7"
This reverts commit 49ac2555ce.
Revert "Always use best compression for chunks"
This reverts commit 42dd9d6abd.
According to benchmarks 8 and 9 are simply orders of magnitude slower while not saving enough bytes to make it worth the performance loss. 7 is a good balance.
this is a little buggy with water updating due to a hack for liquids to fix a CPU leak (210bdc2436), but everything works fine when a block nearby gets updated.
"Minecraft: PE Server" is no longer accurate, "Minecraft: Bedrock
Edition Server" is too wordy, and "Minecraft: BE Server" just sounds
weird.
and I'm not calling it simply a "Minecraft Server"
This can be enabled or disabled using the "online-mode" directive in
server.properties.
NOTE: For safety reasons it is enabled by default, since many naive server owners currently believe that authentication is not needed because "the client is forced to sign-in".
Newsflash for readers: the forced authentication is easily bypassed using a LAN proxy.
Un-authenticated LAN connections will still work fine if the online mode is disabled.
Added the following API methods:
- Server->getOnlineMode() : bool
- Server->requiresAuthentication() : bool
- Player->isAuthenticated() : bool
JWT verification is rather expensive, so it is done in an AsyncTask. Make sure you don't hog your worker threads.
- nametag visibility flags don't work properly, only players show them all the time
- invisibility overrides nametag visibility
- scale 0 triggers asserts on debug builds
..... how hard is it to NOT break these simple things each update Mojang?
closes#1205
moving whole stacks in & out of the crafting grid works now, splitting stacks is fucked up because the transaction system can't handle the same slot changing multiple times in one transaction
Far too often I see people using IDEs which generate the constructors for them and then accidentally unintentionally store things in the object store. This parent constructor behaviour is unexpected. If a developer wants to store something, they should now do so explicitly by calling storeLocal().
fixed cake flat-out doesn't work
fixed last slice of cake vanishing (NOOOOO)
fixed EntityEatBlockEvent not getting called
made AABB calculation less confusing
This occurred if the player happened to be closed during the packet being handled, and then an uncaught exception bubbled up to the RakLibInterface. This resulted in a crash due to trying to get the address of a player who no longer had a network session, in order to block their IP address.
This could only be seen in a build with a non-suffixed API version, for example 3.0.0. When attempting to load plugins which specify API like 3.0 the server would raise errors.
This should only execute if the current liquid block is actually still existent. When decay is negative, it means the water block doesn't exist anymore.
the count parameter is useless since Item ctor should now only be used for constructing item _types_, not actual items. All item creations for inventories etc, should go through the ItemFactory.
More expensive to do it this way, but this should be foolproof. The old method ran short by 4 or 5 bits, causing the Y coordinate of the third loop to be always < 8 and the Z coordinate to always be 0.
- fixed zombies and villagers movement not updating
- fixed dropped items "movement" lagging the living **** out of the server when not actually moving
- fixed arrows not falling when the supporting block is removed
- fixed knockback
- fixed zombies + villagers being un-attackable after hitting them
... the list goes on
These changes produce about 3x performance improvements. Some numbers
from my machine (i7-7700k @ 4.5GHz) with TNT:
- before changes: 35ms
- after changes: 11ms
in powersave mode (0.9GHz):
- before changes: 170ms
- after changes: 60ms
This will never be null if the block factory was initialized correctly. This will also cause a crash if bugs like e88053faf4 occur again in the future instead of silently causing unexpected behaviour.
Did you guys think ALPHA7 changes were done?!
Sone stuff still needs some work, most notably data-properties can't be typed yet because they are just mushed into a couple of methods.
* Do not create new NBT objects on Tile::getSpawnCompound()
* PocketMine's string formatting
* Remove more useless array indices and create lesser new NBT objects.
* Remove unused imports and type-hint Sign::setText() params
* Do not mess with Sign::setText() params due to #1204
* Fix formatting
* Make getSpawnCompound() final and add abstract addAdditionalSpawnData()
* Make the same changes for Bed tile
* Fix a missing "->" and remove some unneeded int casting.
- Fixed log writes being blocking (these were executed on a thread, but IN A SYNCHRONIZED BLOCK - what the fuck shoghi?!)
- Fixed log file being open for reading as well as writing
- The logger will now be buffered for 25ms before writing to disk, as it should have been to begin with.
- Moved the log resource to a local variable (it's unsafe to try to access resources from different threads, this takes away the ability to do so)
- Fixed line endings to use PHP_EOL instead of hardcoded LF, fix viewing logs in Notepadi
If the precision is positive (i.e. there are numbers after the decimal point), the results should be floating-point numbers rather than integers, hence the additional check.
Even if the precision is negative or zero, the $mode parameter may still be useful.
* Improve usability of Sign API
* PHP
* Throw exceptions if out of range
* Fix phpdocs
* Formatting, additional checks in the SignChangeEvent.
* Blame php storm
* require line count to always be 4
* Adjust exception message
Remove null hint from MainLogger::getLogger() so static analysis doesn't complain everywhere
just make sure you register the logger before trying to use MainLogger::getLogger() on a different thread!
Something as simple as forgetting the reset() when encoding would cause lots of problems which could go unnoticed. This should be fully backwards-compatible but needs more tests.
* Fixed chunks not loading when respawning and some minor spawn sequence cleanup
* This causes too much unexpected behaviour to be useful
Revert "Make use of Mojang's pitch hack, close#821"
This reverts commit c2dfef700f.
* Removed delayed-teleport system and cleaned up movement reset for dead players
* Fixed health resetting to max when quitting and rejoining
FixesLegendOfMCPE/EssentialsPE#354
When the config file didn't exist, no type detection was performed. This resulted in the case statement for Config->save() falling through and not writing anything to the file.
- I don't know why it wasn't done like this to start with
- This provides a significant lightening of workload for large servers with lots of players in the same area because packets are only compressed once instead of for each player.
- Improves client-sided performance receiving these in batches instead of being spammed with many individual packets.
* Some Binary cleanup, type-hints and strict types
yes, I know this is very crashy... that's good, because it highlights unexpected behaviour
* added some default values
* Added PlayerDataSaveEvent, resolved#487
* Added getPlayer() to PlayerDataSaveEvent
may return an IPlayer
* Fixed quit messages
This TranslationContainer vs. string mess... >_<
Seems :shoghi: used stdClass to silence IDEs, which before ALPHA5 would complain about myriad undefined fields due to lack of type checking (switch based on packet id 🤦)
* Added "extensions" attribute in plugin.yml with version checking
* Renamed getExtensions() to getRequiredExtensions()
As per recommendation from @dktapps
Seems these metadata fields are actually the _base_ height/width. Setting the scale will cause the client to calculate bounding boxes with the scale already taken into account. This caused the scale to be applied twice on the client.
TODO: improve this to take stuff like swimming, ladders, enchanted tools into account, fix wrong tool break time calculations for bad tools (pmmp/PocketMine-MP#211)
Seems we can now climb ANY block if the climbing flag is true, and nothing if false. This commit adds local block checks to see if a climbable block exists at the entity's feet and if so, sets the flag.
<!--- use our forum https://forums.pmmp.io for questions -->
<!--- Any issues requesting updates to new versions of MCPE will be treated as spam. We do not need issues to tell us that there is a new version available. -->
<!---
Write a short description about the issue
<!---
THIS ISSUE TRACKER IS FOR BUG REPORTING, NOT FOR HELP & SUPPORT. If you need help, use the links below.
If you are reporting a regression or unexpected behaviour, please include the below information:
Expected result: What were you expecting to happen?
Actual result: What actually happened?
Any issues requesting updates to new versions of MCPE will be treated as spam.
Please do not create issues for missing/un-implemented gameplay features - they will be closed.
-->
<!--- Write a short description about the issue -->
<!--- If you are reporting a regression or unexpected behaviour, please include the below information: -->
- Expected result: What were you expecting to happen?
- Actual result: What actually happened?
### Steps to reproduce the issue
<!--- help us find the problem by adding steps to reproduce the issue -->
1. ...
@ -16,15 +21,28 @@ Actual result: What actually happened?
### OS and versions
<!--- use the 'version' command in PocketMine-MP
NOTE: LATEST is not a valid version.
PocketMine version should include Jenkins build number and/or git commit hash.
ALSO NOTE: NO support whatsoever will be provided for forks or spoons of PocketMine. Issues relating to non-official distributions will be closed as spam. Please send such issues to whoever is responsible for the fork or spoon you are using.
NOTE: LATEST is not a valid version. PocketMine-MP version should include Jenkins build number and/or git commit hash.
NO support whatsoever will be provided for third-party modified variants of PocketMine-MP. Issues relating to third-party modifications will be closed as spam.
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)
### Plugins
- Test on a clean server without plugins: is the issue reproducible without any plugins loaded?
If the issue is **not** reproducible without plugins:
- Have you asked for help on our forums before creating an issue?
- Can you provide sample, *minimal* reproducing code for the issue? If so, paste it in the bottom section
- Paste your list of plugins here (use the 'plugins' command in PocketMine-MP)
### Crashdump, backtrace or other files
<!--- please use gist or anything else and add links here -->
- 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
- **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**. 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 your issue does not appear to be a bug or a feature request, or if the issue cannot be properly confirmed to be valid, 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 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`.
- **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!**
@ -76,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 [the old plugin repository](http://plugins.pocketmine.net/) and [Poggit](https://poggit.pmmp.io), or just search GitHub.
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.
### For developers
* [Latest API documentation](https://jenkins.pmmp.io/job/PocketMine-MP-doc/doxygen/) - Doxygen documentation generated from development
@ -23,7 +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.
$logger->warning("Timezonecouldnotbeautomaticallydetermined.Anincorrecttimezonewillresultinincorrecttimestampsonconsolelogs.Ithasbeensetto\"UTC\" by default. You can change it on the php.ini file.");
}
}
}else{
/*
* This is here so that people don't come to us complaining and fill up the issue tracker when they put
* an incorrect timezone abbreviation in php.ini apparently.
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.
