- 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)
Check size, check header size, check location table offsets point to valid locations, check for shared offsets, prevent issues with corrupted or junk data
This is stable enough for everyone to be using it in production, and we're about 200 commits up from the previous tag. This branch contains hundreds of bug fixes, regardless of other changes which are not yet finished.
If a player quit the server in the 1-second between a chunk changing and a fresh chunk-order requesting a resend of that chunk, the player wouldn't know they were using that chunk and did not unregister themselves, causing the subject chunks to always remain loaded.
- Fixed starvation doesn't deal any damage at all (Human->getFood() returns a float, not an int, === 0 won't work so great)
- Added exhaustion for sprinting, walking, jumping and sprint-jumping as per MCPE (these use MCPE values, and yes MCPE does walking exhaustion!)
- Fixed attributes don't get reset after player death
- Added food and hunger regeneration in peaceful difficulty
- Added API methods Living->jump() (motion isn't updated yet, so this won't actually do much if plugins try to use it) and Living->getJumpVelocity()
TODO: implement exhaustion for swimming
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.
* Schedule all neighbour block updates to execute at the end of the tick, fixed recursion crash, close#251
* doTickPending timings now include neighbour block update times, refactored some var names
This is unnecessary since the player won't see any messages sent before they spawn anyway. This was also causing an occasional client-sided crash due to TextPackets being sent to players at bad times during the login sequence.
Cater for the very very very slim chance that a player could quit while teleporting, be leaked and then have their level unloaded and leak their level.
This condition has been useless since before NBT was introduced to PocketMine.
If there was a use for it, it should have been placed BEFORE anything attempted to read from the NBT.
However, Server now handles bad data automatically now, so Server->getOfflinePlayerData() will never _not_ return a CompoundTag. Hence I've added a CompoundTag type-hint.
This also causes some annoying issues with instabreak (false positives). Shoghi dude, this did _not_ fix those issues, only hid them and replaced them with different ones.
* Fixed an age-old light calculation bug causing solid blocks to filter their own light, fixed#375, probably fixed#288
Light spread reduction should be done based on the _target's_ light filter level, not the source.
* Revert "Fix Glowing Obsidian lighting"
This hack is no longer necessary.
This reverts commit 35c33ba980.
* Fixed wrong light levels for torch and redstone torch
* Take adjacent light levels and opacity changes into account, block light will now spread when an obstruction is removed, close#455
* Added timings for Level->setBlock() and lighting updates
how did I do manage to do somthing this stupid -_- smh what an idiot
Lucky permission is a root node, or the whole commands system would've been compromised. Epic fail.
According to http://minecraft.gamepedia.com/Status_effect#Slowness, anything higher than slowness 7 will cause the player to be unable to move. Therefore this value should be clamped to a minimum of 0, not crash.
- Fixed most issues with item equipment in creative
- Added save and restore of currently-held item
- Reset hotbar on death, added API method PlayerInventory->resetHotbar()
- Creative players now have more leeway to get items, alleviates issues with item equipment in desktop GUI
- Fixed creative players wearing armour
- Found unknown field in ContainerSetSlotPacket
- Removed outdated/redundant constants
- Use a case statement in ContainerSetSlotPacket handler, added handling for 0x7a hotbar slot link update
Re-implement chunk sending, send chunks inside a radius instead of below a count
This sends chunks in concentric squares around players. When the radius is hit, it will pad out the radius until a full circle of chunks is loaded around the player.
TODO: implement radius-per-tick, send chunks in concentric circles, use radius for player spawning.
To set your server chunk radius, change `view-distance` in server.properties. Values are intended to be the same as MCPE render distance values. With matching client and server render distances the chunks should reach the horizon.
NOTE: You may notice significantly increased memory usage per player when increasing these values to something respectable. This is normal and expected.
A player with render distance 14 for example will cause loading of 600+ chunks. A player cannot however exceed the render distance limit set in server.properties - the server will simply not send any more chunks.
Render distance of 8 chunks is approximately 200 chunks. This is roughly equivalent to the original default max-chunks of 192 in pocketmine.yml, but sent in a circle instead of a square.
Wait for client to request a chunk radius before ordering chunks
Use 8 for default maximum radius (roughly matches old setting of 192)
Calculate spawn chunk count from chunk-sending.spawn-radius
- All entity and tile constructors now require a \pocketmine\level\Level instead of a \pocketmine\level\format\Chunk.
- Chunk->getProvider() and Chunk->setProvider() have been removed.
- Chunk::__construct() has had the $provider parameter removed.
- Chunk->unload() has had the unused $save parameter removed.
- ChunkEvents now take a Level parameter instead of going through the Chunk
API bump to 3.0.0-ALPHA4
Revert "fixed player data not saving"
This reverts commit b3beb9f71d.
Revert "Call PlayerQuitEvent after unloading chunks, removed some weird code, fixed crash when unloading player level on quit, close#284"
This reverts commit 14a0ff5caa.
Shows the correct message ingame but not in the console.
PocketMine doesn't handle the translation for gamemode changes, MCPE
does. No idea why but it requires the second and third parameter....
commands.gamemode.success.other=Set %2$s's game mode to %3$s
commands.gamemode.success.self=Set own game mode to %3$s
To solve the problem we have to change the language files and let
PocketMine-MP translate it.
BEFORE anyone yells at me about plugins, having the core demand every extension that a plugin could possibly need is very much sub-optimal. An API for plugin-required extensions will be added in the future.
* Added options to disable movement checks and anti-instabreak and API methods to control this
* Fixed anti-flight false positives
* Fix flight toggle kick cannot be disabled
* Added PlayerIllegalMoveEvent
Removed ySize hack, fixes ladders, fixed original autojump and dropdown issues. These were due to a tiny, tiny tiny margin for error when decoding network floats (usually less than 0.000001, but enough to cause issues. Added Binary floating-point decode accuracy option to combat this. Network Vector3s are now rounded to 4 decimal places.
If a NamedTag was already present, it was modifying the object directly
WITHOUT serializing the tag back to raw NBT for sending. This commit
fixes that by always serializing the tag on change.
According to the wiki, McRegion heightmap should be ByteArray, not
IntArray. This caused issues with converted worlds with pretty much
every conversion tool. Blame @shoghicp.
IntArray McRegion heightmaps will now be converted to
ByteArray on save.
Use stream_select to poll stdin status before reading
Add detection for FIFO pipes, rewrite half of the CommandReader (again)
Add timeout for CommandReader to prevent hang in Windows custom consoles (unknown reason)
Refactored level\format\generic\GenericChunk -> level\format\Chunk.
Re-added support for async chunk sending
Refactored most Level IO into new namespaces for more organisation
Removed LevelDB loader completely (will be re-added at a later date)
Do you guys still have access to the Twitter account? I just noticed that it never got updated. If you still want to use it though, by all means keep this link in here :)
<!--- 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
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. ...
@ -9,15 +16,26 @@ Write a short description about the issue
### 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 version should include Jenkins build number and/or git commit hash.
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 that 32-bit platforms are no longer supported by PocketMine-MP and issues concerning 32-bit platforms will be closed.
-->
* PocketMine-MP:
* 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 -->
You must follow these guidelines if you wish to contribute to the PocketMine-MP code base, or participate in issue tracking.
## I have a question
* For questions, please refer to the _#pmmp_ or _#pocketmine_ IRC channel on Freenode. There is a [WebIRC](http://webchat.freenode.net?channels=pmmp,pocketmine&uio=d4) if you do not want to install an IRC client.
* You can ask directly to _[@PocketMine](https://twitter.com/PocketMine)_ in Twitter, but don't expect an immediate reply.
* You may use our [Forum](https://forums.pmmp.io) to ask questions.
* We do not accept questions or support requests in our issue tracker.
## Creating an Issue
* First, use the [Issue Search](https://github.com/pmmp/PocketMine-MP/search?ref=cmdform&type=Issues) to check if anyone has reported it. Check also closed issues, as an issue you think is valid may actually be invalid.
*If an issue has been _fixed_ and closed, create another issue.
* If your issue is related to a plugin, do **not** report here. Contact the plugin's original author instead.
* **Support requests are not bugs.** Issues such as "How do I do this" are not bugs and are closed as soon as a collaborator spots it. They are referred to our Forum to seek assistance. Please refer to the section [I have a quesetion](#i-have-a-question) instead.
***No generic titles** such as "Question", "Help", "Crash Report" etc.
* 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 is a support request until the actual bug has been found and therefore the issue is closed.
* 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.
* 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 rqeuest conversation clean and readable.
*If your issue is related to the Pocketmine-MP website, forums, etc., please [talk to a human directly](#i-have-a-question).
- If you are reporting a bug:
-**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.
- **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.
- 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
*Use the [Pull Request](https://github.com/pmmp/PocketMine-MP/pull/new) system, your request will be checked and discussed.
* Create each pull request on a new branch. Do not create a pull request on commits that exist in another pull request.
*Code should use the same syntax as in PocketMine-MP. See below for an example.
* The code must be clear and written in English, comments included.
* Use descriptive commit titles
* **Keep each pull request only contain one feature**. The only exception is when all features in the pull request are related to each other, and share the same core changes.
* **Do not create pull requests that only bump the MCPE version**. If it is ready to be updated, the team will update the values directly. Do not change the MCPE version or protocol version in a pull request, unless you have updated the protocol (all packets) entirely.
-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.
-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.
- **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.
- **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).
**Thanks for contributing to PocketMine-MP!**
### Code Syntax
It is mainly [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md) with a few exceptions.
* Opening braces MUST go on the same line, and MUST NOT have spaces before.
*`else if` MUST be written as `elseif`. _(It is in PSR-2, but using a SHOULD)_
* Control structure keywords or opening braces MUST NOT have one space before or after them.
* Code MUST use tabs for indenting.
* Long arrays MAY be split across multiple lines, where each subsequent line is indented once.
* Files MUST use only the `<?php` tag.
* Files MUST NOT have an ending `?>` tag.
* Code MUST use namespaces.
* Strings SHOULD use the double quote `"` except when the single quote is required.
- Opening braces MUST go on the same line, and MUST NOT have spaces before.
-`else if` MUST be written as `elseif`. _(It is in PSR-2, but using a SHOULD)_
- Control structure keywords or opening braces MUST NOT have one space before or after them.
- Code MUST use tabs for indenting.
- Long arrays MAY be split across multiple lines, where each subsequent line is indented once.
- Files MUST use only the `<?php` tag.
- Files MUST NOT have an ending `?>` tag.
- Code MUST use namespaces.
- 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.
if($firstArgument==="exampleValue"){//Remember to use === instead of == when possible
//do things
}elseif($firstArgument==="otherValue"){
$secondArgument=function(){
@ -76,8 +112,12 @@ class ExampleClass{
4=>"value5",
5=>"value6",
];
};
}
}
publicfunctiondoStuff(string$stuff):string{
return$stuff;
}
}
@ -94,78 +134,3 @@ class ExampleClass{
* An RFC will be rejected if less than 50% + 1 (simple majority) has voted Yes.
* If the RFC is approved, Team Members have the final word on its implementation or rejection.
* RFCs with complex voting options will specify the vote percentage or other details.
## Bug Tracking for Collaborators
### Labels
To provide a concise bug tracking environment, prevent the issue tracker from over flowing and to keep support requests out of the bug tracker, PocketMine-MP uses a label scheme a bit different from the default GitHub Issues labels.
Labels are used to identify the type and status of issues and pull requests.
#### Categories
Multiple category labels may be applied to a single issue (but try to keep this to a minimum and do not overuse category labels).
These labels may be applied to issues with bugs related to these, or pull requests that alter the behaviour of these or fix an issue with the same label applied.
-`Category: Core` - Related to PocketMine-MP's core functionality, but not gameplay or API.
-`Category: Gameplay` - Related to gameplay.
-`Category: API` - Related to plugin API.
-`Category: Client` - Related to client functionality or behaviour. This label may be applied to issues reporting client-related bugs, or PRs related to the client such as a protocol update. There are several sub-labels to account for the differences between supported clients.
-`all`: Related to all versions of the client.
-`W10`: Related only to Windows 10 Edition Beta.
-`PE`: Related only to the Pocket Edition
-`beta`: Related only to a beta version of the game.
-`other`: Related only to an uncommon PE-compatible version of the client, such as VR Edition.
-`Category: PHP` - Applied to issues caused by the PHP interpreter or its extensions.
-`Category: Other` - Applied to issues which cannot be categorized with any of the above labels.
#### Pull Requests
Pull Request labels are prefixed by `PR:`. Only one label may be applied for a Pull Request.
-`PR: Bug Fix` - The Pull Request fixes a bug.
-`PR: Contribution` - The Pull Request contributes new features or improvements, but does not fix a bug, nor controversial enough to be an RFC.
-`PR: RFC` - Request for Comments. Refer to [RFC and Voting](#rfc-and-voting).
#### Status
Status labels show the status of the issue. Multiple status labels may be applied.
*Issues*
-`Status: Unconfirmed` - reported issues that have yet to be reproduced by a developer successfully.
-`Status: Reproduced` - a bug that has been reproduced by a developer, or that multiple people are reporting the same issue and symptoms in which case it is automatically assumed that the bug has been reproduced in different environments.
-`Status: Debugged` - the cause of the bug has been found, but has not yet been fixed.
-`Status: Resolved` - applied to *valid* issues which have been fixed. *This label may only be applied to a closed issue.*
*Pull requests*
-`Status: Insufficiently tested` - applied for pull requests that have not undergone tests strict enough.
#### Resolution
Resolution labels show the resolution of an issue or pull request. These labels may only be applied to closed issues.
-`Resolution: Invalid` - Applied to support request issues or issues not related to PocketMine.
-`Resolution: Duplicate` - Applied to issues reporting the same problems as another issue.
-`Resolution: Fixed` - Applied to an issue reporting a bug which has been fixed.
-`Resolution: Works As Intended` - Applied to issues reporting false bugs which work the way they are intended to.
-`Resolution: Won't Fix` - Applied to issues reporting bugs which will not be fixed, for example if the bug is beneficial.
-`Resolution: Obsolete` - Applied to pull requests which are rendered unnecessary by other changes, such as another, similar pull request being merged.
#### Miscellaneous
-`Enhancement` - Applied to issues with viable feature requests or TODO lists.
-`High priority` - Applied to issues or PRs related to critical bugs.
### Closing Issues
To keep the bug tracker clear of non-related issues and to prevent it from overflowing, **issues must be closed as soon as possible** (This may sound unethical, but it is MUCH better than having the BUG TRACKER filled with SUPPORT REQUESTS and "I NEED HELP").
If an issue does not conform to the "Creating an Issue" guidelines above, the issue should be closed.
<!--
### Milestones
PocketMine-MP uses GitHub Milestones to set a goal for a new release. A milestone is set on the following occasions.
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
* [DevTools](https://github.com/pmmp/PocketMine-DevTools/) - A development tools plugin for creating plugins.
### Can I contribute?
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/)
pmmp/PocketMine are not affiliated with Mojang. All brands and trademarks belong to their respective owners. PocketMine-MP is not a Mojang-approved software, nor is it associated with Mojang.
$logger->critical("Running PocketMine-MP 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-MP using the CLI.");
++$errors;
}
if(!extension_loaded("sockets")){
$logger->critical("Unable to find the Socket extension.");
++$errors;
}
$pthreads_version=phpversion("pthreads");
if(substr_count($pthreads_version,".")<2){
$pthreads_version="0.$pthreads_version";
@ -426,77 +442,97 @@ namespace pocketmine {
}
if(extension_loaded("xdebug")){
$logger->warning("
You are running PocketMine with xdebug enabled. This has a major impact on performance.
");
$logger->warning(PHP_EOL.PHP_EOL.PHP_EOL."\tYou are running PocketMine with xdebug enabled. This has a major impact on performance.".PHP_EOL.PHP_EOL);
}
if(!extension_loaded("curl")){
$logger->critical("Unable to find the cURL extension.");
$extensions=[
"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(!extension_loaded("yaml")){
$logger->critical("Unable to find the YAML extension.");
++$errors;
}
if(!extension_loaded("sqlite3")){
$logger->critical("Unable to find the SQLite3 extension.");
++$errors;
}
if(!extension_loaded("zlib")){
$logger->critical("Unable to find the Zlib extension.");
++$errors;
}
if($errors>0){
$logger->critical("Please use the installer provided on the homepage, or recompile PHP again.");
$this->getLevel()->setBlock($this, new Air(), true, true, true);
$sides=[
2=>3,
3=>2,
4=>5,
5=>4
];
if(!$this->getSide($sides[$this->meta])->isSolid()){//Replace with common break method
$this->level->useBreakOn($this);
returnLevel::BLOCK_UPDATE_NORMAL;
}*/
}
}
returnfalse;
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.
