mirror of
https://github.com/PaperMC/Paper.git
synced 2025-01-08 09:17:36 +01:00
dd1bee786b
This metadata implementation has the following features: - All metadata is lazy. Metadata values are not actually computed until another plugin requests them. Memory and CPU are conserved by not computing and storing unnecessary metadata values. - All metadata is cached. Once a metadata value is computed its value is cached in the metadata store to prevent further unnecessary computation. An invalidation mechanism is provided to flush the cache and force recompilation of metadata values. - All metadata is stored in basic data types. Convenience methods in the MetadataValue class allow for the conversion of metadata data types when possible. Restricting metadata to basic data types prevents the accidental linking of large object graphs into metadata. Metadata is persistent across the lifetime of the application and adding large object graphs would damage garbage collector performance. - Metadata access is thread safe. Care has been taken to protect the internal data structures and access them in a thread safe manner. - Metadata is exposed for all objects that descend from Entity, Block, and World. All Entity and World metadata is stored at the Server level and all Block metadata is stored at the World level. - Metadata is NOT keyed on references to original objects - instead metadata is keyed off of unique fields within those objects. Doing this allows metadata to exist for blocks that are in chunks not currently in memory. Additionally, Player objects are keyed off of player name so that Player metadata remains consistent between logins. - Metadata convenience methods have been added to all Entities, Players, Blocks, BlockStates, and World allowing direct access to an individual instance's metadata. - Players and OfflinePlayers share a single metadata store, allowing player metadata to be manipulated regardless of the player's current online status. By: rmichela <deltahat@gmail.com> |
||
|---|---|---|
| .. | ||
| src | ||
| .gitignore | ||
| LICENCE.txt | ||
| pom.xml | ||
| README.md | ||
Bukkit
A Minecraft Server API.
Website: http://bukkit.org
Bugs/Suggestions: http://leaky.bukkit.org
Compilation
We use maven to handle our dependencies.
- Install Maven 3
- Check out this repo and:
mvn clean install
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.
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.