#docs

1 messages ยท Page 4 of 1

lost sealBOT
lost sealBOT
#

In there is:

The internal CraftBukkit code is relocated to org.bukkit.craftbukkit. unless you run a Mojang-mapped version of Paper. This is unlikely to be the case in most production environments.

I think may need to be updated as the current paper always doesn't have it unless someone has a reobfuscated version, which is unlikely in current most production servers

Idk how to properly change that so decided to make an issue and not a pr

lost sealBOT
#

If auto replenished is enabled, stationary containers can be re-looted. When broken, usually by players, the loot is unpacked and the loottable is destroyed.

The commit expands the wording to also cover shulker boxes, which work a bit differently. In case a player breaks them, they are immediately looted and loose their replenishment ability. In case of a piston breaking them, they cannot unpack their loot table as no player exists in the context, so they only loose their loot table if the...

lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#
[PaperMC/docs] New branch created: feat/velocity-forwarding-env
lost sealBOT
#
[PaperMC/docs] New branch created: feature/void-damage-config
#
[PaperMC/docs] branch deleted: feature/void-damage-config
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#

Some properties are not documented:

paper-global.yml:

  • block-updates
    • disable-chorus-plant-updates: false
    • disable-mushroom-block-updates: false

paper-world-defaults.yml

  • entities
    • behavior
      • player-insomnia-start-ticks: 72000
    • spawning
      • ticks-per-spawn:
        ambient: -1
        axolotls: -1
        creature: -1
        monster: -1
        underground_water_creature: -1
        water_ambient: -1
        water_creature: -1
  • tick-rates
    • dry-farmland: 1
    • wet-farmland: 1
lost sealBOT
lost sealBOT
#

Are these the only system properties provided by Minecraft?

Well I didn't look everywhere (they aren't exactly in the same place in the source code...) and in this area there is only an additional one to switch to the staging URLs of the official Mojang API servers via a single system property which don't seem to be useful in the Paper context hence why I decided to not include that. (And if you need those URLs you can set them manually via the documented values anyways)

lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#
[PaperMC/docs] New branch created: deps/docusaurus
lost sealBOT
#
[PaperMC/docs] branch deleted: deps/docusaurus
lost sealBOT
#

As the site wiki.vg is soon ("November 30th") to be sunset, references should be replaced with their own docs or redirects to a another source.

wiki.vg sunsetting post:
https://tkte.ch/articles/2024/11/11/sunsetting.html

References in the docs (at the time of writing, only 3 references, and 2 distinct ones):
https://github.com/search?q=repo%3APaperMC%2Fdocs+wiki.vg&type=code

At the time of writing, it seems possible that wiki.vg will be merged into m...

lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#

This PR aims to improve the documentation for Paper's new way of declaring commands using the Brigadier API.

[!WARNING]
Do not merge this PR yet, as it is incomplete. You can check out the current state of things below:

Roadmap:

  • [ ] Add Bukkit Paper command comparison
  • [ ] Introduction page
  • [ ] Native Arguments (StringArgumentType, IntegerArgumentType, etc)
  • [ ] Player/Entity Selector Arguments
  • [ ] Registry Arguments (The current arguments page)
  • [ ] Common I...
lost sealBOT
#
[PaperMC/docs] New branch created: feat/remove-versioning
lost sealBOT
lost sealBOT
lost sealBOT
#
[PaperMC/docs] New branch created: lifecycle-plugins
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#
[PaperMC/docs] branch deleted: feat/migration-guides
lost sealBOT
#
[PaperMC/docs] New branch created: feat/data-components
lost sealBOT
#
[PaperMC/docs] New branch created: obfuscation-changes
lost sealBOT
#

I'm not sure if the sidebar icons add any value to the navigation experience, it just seems like visual clutter to me; maybe make them a little smaller and darker (to make the page/section names stand out more)?

visual bug when page names are wrapped (icons are shrunk)
<img width="311" alt="image" src="https://github.com/user-attachments/assets/9893d1b0-62c0-4ad5-8069-eb6295af4176" />

light mode makes the sidebar icons blend in with the background completely

lost sealBOT
#

Perhabs remove the "programming interface" part, as that is already contained within API. Also add a line wrap for better readability in-editor

The Data Component API provides a version-specific interface for accessing and manipulating item data that is otherwise not representable by the `ItemMeta` API.
Through this API, you can read and write properties, called "data components", of an item in a stable and object-oriented manner.
lost sealBOT
lost sealBOT
#

This PR removes the filtering out of beta versions from the latest-version fetch in order to display the now pretty much stable beta builds, as they are required for 1.21.4 support and provide fixes for older versions as well.

Furthermore, I have added a reference to the Gradle wrapper page for updating your Gradle distribution and added a reference to the #build-tooling-help channel from our Discord server for people seeking further support.

lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#

Yeah. Those are parts that have not yet been added to the documentation, due to the PR being huge enough already, but I still included these in the introduction. There are two ways I can see this resolved, you may choose whichever you find more fitting:

  1. I temporarily remove these so that it doesn't cause any confusion.
  2. I add a notice at the top mentioning that the documentation is not yet complete and and those topics below, which do not have a link to a site, will be added further do...
lost sealBOT
lost sealBOT
#
[PaperMC/docs] branch deleted: obfuscation-changes
lost sealBOT
#

Within Linux's chmod system, +x grants all users access to execute the file, whereas u+x only grants the user who owns the file access to execute it. Provided the user is the one who created the start.sh file, there's no reason why this permission change wouldn't cause issues, but it's good to get into the habit of using "least privilege" when assigning permissions, and I know from personal experience that hosting Minecraft servers can be the start of a career in sysadmining.

lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#

I think it could be nice to include more information on how to work with Paper's source code. This would include not only information for contributors, kinda how we already have the Events page, but also information regarding how to correctly fork Paper (use paperweight to do so) and maintain your own fork.

The following pages are what came to mind first. I wish to ask for anybody to suggest more pages or changes to these:
| Page name | P...

lost sealBOT
lost sealBOT
#
[PaperMC/docs] New branch created: fix/roadmap-upstream-duplicate-methods
lost sealBOT
#

That's a very good point. It should avoid that people do 2k line PRs and end up being rejected because it doesn't fit the scope of an API.

Furthermore, the forking page could just be a very quick reference to where you can find information about it, doesn't have to be a full-on guide. Just so that we have something to throw at people who ask in #paper-dev on how to create a fork. With all the tooling in the right place. I think people who really need to fork, will somehow figure it out

lost sealBOT
#
[PaperMC/docs] New branch created: feat/remove-target-selector-tag-fix
lost sealBOT
#

I like the idea of this PR, maybe a paragraph like this works better though?


Once you've saved the files, open a terminal (or log into the machine) if you haven't already. Navigate to the directory where you have placed the Velocity JAR file and the start.sh file. Then, you will need to prepare the start.sh script to be executable and run it.

  1. Run chmod u+x start.sh. This command modifies the file's permissions, granting the file's owner (you) the ability to execute (x) the script. Without this step, the system may not recognize the script as something that can be run.

  2. Now that the file is executable, run ./start.sh to run the script.

#

I like the idea of this PR, maybe a paragraph like this works better though?


Once you've saved the files, open a terminal (or log into the machine) if you haven't already. Navigate to the directory where you have placed the Velocity JAR file and the start.sh file. Then, you will need to prepare the start.sh script to be executable and run it.

  1. Run chmod u+x start.sh. This command modifies the file's permissions, granting the file's owner (you) the ability to execute (x) the script. Without this step, the system may not recognize the script as something that can be run.

  2. Now that the file is executable, run ./start.sh to run the script.

lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#

I am avoiding throwing command exceptions for the same reason I am avoiding returning an integer directly - just to keep it consistent and not confuse a user. I am definitely going to be making a separate page for command exceptions as they have quite a few features associated with them as well, but I think I'd keep it as a simple message to the sender for now.

If you explicitly think that is the wrong decision, I have no problem to add exceptions anyways. But I would at least wait with that until the exception page is ready so that I have something I can link against inside a "note" block.

#

I agree with the author here. The purpose is not to explain command errors. Everything around arguments should be kept as simple as possible in my opinion.

Otherwise users might get confused since they are just checking how an Argument works and are suddenly confronted with something they might have not seen. If they want to learn about Command Errors they can do so by reading separate pages in the future.

lost sealBOT
lost sealBOT
lost sealBOT
#

You have both Art and Painting variant overview in the registry arguments page. Ideally names should be consistent either use bukkit name or the name in game.

For the command, I always use the registry name and for the name (the header) I use the backing object type. This is consistent with the other registries (E.g Music instrument). I can rename the headers to be consistent with the name of RegistryKey.XYZ and the in-game command though

lost sealBOT
lost sealBOT
#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

It would be great to document the RequiredArgumentBuilder#suggests(SuggestionProvider) method in order to provide a way for developers to suggest possible input without the need of creating an entire custom argument.

For this, it would be good to examine the SuggestionProvider<S> interface and explain its usage.

An example should also be added. A possible example could be an String argument that suggests values out of a List<String>. It would also be noteworthy to mention good practices, such as filtering by current user input.

A code example should also be given. E.g:

final List<String> suggestions = List.of("first_element", "another_element", "weee");
Commands.literal("customsuggestions")
    .then(Commands.argument("input", StringArgumentType.word())
        .suggests((ctx, builder) -> {
            suggestions.forEach(element ...
lost sealBOT
#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

In addition to custom argument suggestions, normal custom arguments should also be documented. This would have two parts. For once, the standard CustomArgumentType<T, N> and its methods should be documented and given an example to. Secondly, CustomArgumentTtype.Converted<T, N> should also be documented.

One point to definitely mention is the inability to provide the red client-side text in case the argument is invalid, since for that the client needs to do validation, which custom argument types do not do, since they actually only send their native type (and on tab complete possible suggestions) to the client, not their parser.

For the standard custom argument type, a MiniMessage-string styled Component argument could be created, since the native one expects its input as JSON, which is not very...

lost sealBOT
#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

Currently, the documentation documents the separate aspects of Brigadier, but doesn't really bring all of them together in a real command. Therefore, it would be great if the documentation had a step-by-step creation of an actual user-friendly and refined command which provides some more logic. The command should display the usage of the following aspects:

  • Permissions (using requirements)
  • Nested arguments/literals
  • Reused command executors (E.g. default value if an argument is not provided)
  • Some visible change in-game

An example could be a skull-giving command, which has the following structure:

/skull
/skull <offline-player>
/skull <offline-player> <amount>

[!WARNING]
The command example really isn't a great one. I would appreciate it if somebody who has a better idea could suggest it here

It should be made sure that thi...

#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

I think it would be really useful to have a FAQ/Common issues page that we can just link to people if they run into standard issues or have frequently asked questions.

Some of the FAQ points could include:

  • "Can I declare commands using annotations?"
  • "What is the earliest version I can use Brigadier at?"
  • "How can I display a client-side error for my custom arguments?"

More can be taken from the Discord server #paper-dev channel. This definitely does not cover all of them

Some of the common issues points could include:

  • Misplaced brackets deforming the command tree

Similar to the FAQ, I just couldn't think of more in this short time. The #paper-dev channel can be used as a reference + you can suggest some here on this issue

Furthermore, I think a section about community-driven command frameworks could be useful. The Brigadier API was m...

#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

I feel like it'd be great for returning users to have a very simple and quick reference they can use to refresh their knowledge on certain aspects.

For example, there could be a section called "permission declaration" which quickly repeats that one can use the requires method to check the sender's permission in order to execute and view a command or argument.

Possible aspects referenced could be:

  • Argument declaration
  • Argument retrieval
  • Permission declaration
  • Difference sender and executor
  • Custom argument suggestions
  • Custom arguments
  • Registering commands
lost sealBOT
#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

The command dispatcher is retrievable using Commands#getDispatcher(). With it, one can query/modify/register commands. It can also just be used to work with the root command node in general.

All of its methods should be explained. An example on how to use most of them does not have to be given, since the usage of the dispatcher assumes a user to have general knowledge about the internal functionality of commands.

Though, an example for extending existing commands can be given. For this, one could extend a vanilla command to include their own sub command. Perhaps, this could be done for the /effect vanilla command:

final CommandDispatcher<CommandSourceStack> dispatcher = commands.getDispatcher();
if (dispatcher.getRoot().getChild("effect") instanceof LiteralCommandNode<CommandSourceStack> literalNode) {
    dispatcher.register(lit...
lost sealBOT
#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

Continuing with the advanced topics, there should also be a page noting the usage of .fork, .forward, and .redirect. Thanks to https://github.com/PaperMC/Paper/pull/11868, this can now be achieved without the usage of internals or userdev.

Basically, the difference between these "flow controlling" methods should be noted and an example should be given. Furthermore, a reference to the CommandSourceStack#withExecutor/Location should be included. The fact that this is only available since the middle of version 1.21.4 could also be helpful.

A possible example could look like this:

final CommandDispatcher<CommandSourceStack> dispatcher = commands.getDispatcher();
final LiteralCommandNode<CommandSourceStack> node = dispatcher.register(Commands.literal("say")
    .then(Commands.literal("hi")
        .executes(ctx -> {
            if (...
lost sealBOT
#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

Bringing together #533 and #532, the concepts explained in both of those pages can be used to provide an example on how to extend the most complicated command vanilla offers: /execute.

This is to serve as a technical example in order for people, who seek to actually use this kind of command modification, to have a reference to go back to, but also serve as a great learning point for people who wish to further deepen their knowledge about Brigadier.

A possible extension to the command could be the addition of /execute permission in order to only execute a command if the executor actually has a permission. If you have a better idea for an extension, be sure to suggest it!

The code for such an extension might look like this:

private void registerExecuteExtension(final @NotNull Commands commands) {
    final CommandDispatcher<CommandSou...
lost sealBOT
lost sealBOT
#

[!NOTE]
This issue is part of a series of issues regarding the extension of the Paper documentation regarding Paper's Brigadier API.

Combining with #528, it would be very useful to have documentation on CommandSyntaxExceptions. This should cover the build-in exceptions as well as the SimpleCommandExceptionType implementation of the CommandExceptionType interface.

lost sealBOT
#

With so many pages in the documentation, it might be hard for users to find the correct page for a question or topic. For this reason, I propose the addition of a search bar.

That could just be a small icon on the top-right which has a simple "look for matches in titles".

Another possible way to look for pages is that we add a new property at the top of each page which contains certain keywords described in the page.

So for example, for the userdev page, we could add the following content keywords:

keywords: 'gradle', 'userdev', 'paperweight', 'internals', 'mappings'
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
lost sealBOT
#
[PaperMC/docs] branch deleted: feat/tripwirehook-dupe
lost sealBOT
lost sealBOT
#
[PaperMC/docs] New branch created: feature/pdc-next
lost sealBOT
lost sealBOT
lost sealBOT