OpenSource/PaperMC
OpenSource/PaperMC
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-12-02 13:07:06 +01:00
Code Issues Projects Releases Packages Wiki Activity
High performance Spigot fork that aims to fix gameplay and mechanics inconsistencies https://papermc.io/
2065 commits 47 branches 14 tags 252 MiB
Java 99.6%
Shell 0.4%
Find a file
Travis Watkins 24143ef6a1 Load chunks asynchronously for players. 
When a player triggers a chunk load via walking around or teleporting there
is no need to stop everything and get this chunk on the main thread. The
client is used to having to wait some time for this chunk and the server
doesn't immediately do anything with it except send it to the player. At
the same time chunk loading is the last major source of file IO that still
runs on the main thread.

These two facts make it possible to offload chunks loaded for this reason
to another thread. However, not all parts of chunk loading can happen off
the main thread. For this we use the new AsynchronousExecutor system to
split chunk loading in to three pieces. The first is loading data from
disk, decompressing it, and parsing it in to an NBT structure.  The second
piece is creating entities and tile entities in the chunk and adding them
to the world, this is still done on the main thread. The third piece is
informing everyone who requested a chunk load that the load is finished.
For this we register callbacks and then run them on the main thread once
the previous two stages are finished.

There are still cases where a chunk is needed immediately and these will
still trigger chunk loading entirely on the main thread. The most obvious
case is plugins using the API to request a chunk load. We also must load
the chunk immediately when something in the world tries to access it. In
these cases we ignore any possibly pending or in progress chunk loading
that is happening asynchronously as we will have the chunk loaded by the
time they are finished.

The hope is that overall this system will result in less CPU time and
pauses due to blocking file IO on the main thread thus giving more
consistent performance. Testing so far has shown that this also speeds up
chunk loading client side although some of this is likely to be because
we are sending less chunks at once for the client to process.

Thanks for @ammaraskar for help with the implementation of this feature.
2012-12-12 19:35:53 -06:00
src Load chunks asynchronously for players. 2012-12-12 19:35:53 -06:00
.gitignore Ignore minecraft resources in src directory 2011-11-29 21:20:14 +11:00
LGPL.txt We're LGPL. 2011-01-02 10:58:11 +01:00
LICENCE.txt We're LGPL. 2011-01-02 10:58:11 +01:00
pom.xml Add isSolid() tests for each material 2012-12-09 18:15:34 -06:00
README.md Updated README.md with more coding and pull request conventions and tips to get your pull request accepted. 2012-02-24 00:09:53 -05:00

README.md

CraftBukkit

A Bukkit (Minecraft Server API) implementation

Website: http://bukkit.org
Bugs/Suggestions: http://leaky.bukkit.org

Compilation

We use maven to handle our dependencies.

  • Install Maven 3
  • Check out and install Bukkit
    • Note: this is not needed as the repository we use has Bukkit too, but you might have a newer one (with your own changes :D)
  • Check out this repo and: mvn clean package

Coding and Pull Request Conventions

  • We generally follow the Sun/Oracle coding standards.
  • No tabs; use 4 spaces instead.
  • No trailing whitespaces.
  • No CRLF line endings, LF only, put your gits 'core.autocrlf' on 'true'.
  • No 80 column limit or 'weird' midstatement newlines.
  • The number of commits in a pull request should be kept to a minimum (squish them into one most of the time - use common sense!).
  • No merges should be included in pull requests unless the pull request's purpose is a merge.
  • Pull requests should be tested (does it compile? AND does it work?) before submission.
  • Any major additions should have documentation ready and provided if applicable (this is usually the case).
  • Most pull requests should be accompanied by a corresponding Leaky ticket so we can associate commits with Leaky issues (this is primarily for changelog generation on dl.bukkit.org).
  • Try to follow test driven development where applicable.

If you make changes or add net.minecraft.server classes it is mandatory to:

  • Get the files from the mc-dev repo - make sure you have the last version!
  • Make a separate commit adding the new net.minecraft.server classes (commit message: "Added x for diff visibility" or so).
  • Then make further commits with your changes.
  • Mark your changes with:
    • 1 line; add a trailing: // CraftBukkit [- Optional reason]
    • 2+ lines; add
      • Before: // CraftBukkit start [- Optional comment]
      • After: // CraftBukkit end
  • Keep the diffs to a minimum (really important)

Tips to get your pull request accepted

Making sure you follow the above conventions is important, but just the beginning. Follow these tips to better the chances of your pull request being accepted and pulled.

  • Make sure you follow all of our conventions to the letter.
  • Make sure your code compiles under Java 5.
  • Provide proper JavaDocs where appropriate.
  • Provide proper accompanying documentation where appropriate.
  • Test your code.
  • Make sure to follow coding best practises.
  • Provide a test plugin binary and source for us to test your code with.
  • Your pull request should link to accompanying pull requests.
  • The description of your pull request should provide detailed information on the pull along with justification of the changes where applicable.