Search results

I think that's the impropper way to define an empty list in YAML. that looks like a list of size 1 with the contents []. You probably just want to put the [] after the key directly. The "unknown" command is probably it trying to run the command /[] which would be unknown.

set/isPersistent do not do what you think they do. It is about saving the entity to disk, not whether they despawn. The other method you found, setRemoveWhenFarAway is the correct way to control that.

You are going to have to be more specific. The item sorting method with hoppers+comparators works just fine.

Check to make sure the config.yml file is in the jar file. You can just unzip the jar and see for yourself. If it isn't, you probably need to configure maven to copy it over.

That’s because the default permissions in Bukkit also have defaults. The correct ones default to true on players that are opped. So changing that setting shouldn’t have any difference. Here is a scenario that shows its use. Op a player (with level 4). Remove the Bukkit permission for the stop...

So vanilla doesn’t have the same permission system that Bukkit does. Vanilla has op levels, 0-4. What this setting does is ignore those op level requirements for any command that has them, basically making the Bukkit permission system the sole arbiter of who has what permission.

If this is some packet-related thing, protocol lib has helper methods for doing that. Not sure if we want to add more API surrounding the numerical entity ID. It really isn't a good way of identifying an entity.

Take a look at the documentation for how to configure anti-xray. It describes how to enable it for multiple worlds.

Paper has all of the Spigot/Bukkit API. There should be no types on spigot that also aren't present in Paper. Can you give an example of what you are talking about?

While that does work, it really violates a core concept about object-oriented programming. Using static to store state like that can lead to issues if someone uses the unsupported reload command. It's highly recommended to stick to using objects as the language intended and pass state around...

Paper provides an example of declaring a dependency on its API for both maven and gradle which can be found here.

You create a constructor in JoinEvent that takes an instance of your main plugin and then assign it to a field in JoinEvent. Then when you register the event in your main class' onEnable method, you can pass this to the constructor for JoinEvent.

Well, that specific issue about spawning a large number of entities can be somewhat mitigated by using paper's chunk entity save limits. Basically it prevents more than a configured number of a specific entity from being saved in a chunk. So like if you set it to 4 for boats, then only 4 boats...

You probably don't have the craftbukkit-added permission to use selectors which is minecraft.command.selector.

Do you have any plugins on your server? see if you can replicate this issue without plugins.

Offline mode isn't supported here on Paper support channels.

This is a general introduction to the Component API and links to the full adventure library documentation. This, and minimessage if you really prefer strings, are the supported ways of coloring and styling text throughout minecraft.

I think the term "drop in" is a little ambiguous. It probably means that you can have plugins on your server with either (or both). If you are using a paper-plugin.yml, you have to manually add your commands to the CommandMap (available via Server#getCommandMap). You have to extend Command to...

I meant replicate it on a paper server without any plugins and using the vanilla client. Not test it in singleplayer.

Can you replicate this issue without any plugins and on the vanilla client?

Is this a Plugin Development question? If so, I'll move it to the right forum. If you want to have "names" for a collection of items that is persisted across a server restart, you will need some sort of extra storage, whether that is a database you want to create and query/update or just plain...

Isn't this something you should take up with whoever manages that docker image? Paper doesn't have any official docker images, so its all 3rd party.

Try without any plugins. I can place and edit signs just fine on a plain paper server.

I'm assuming you are asking from a non-development perspective as this is in the Help forum, not the Plugin Development forum. Something like this could probably be done by a third-party plugin which integrated with a permissions plugin to revoke permission for a command after it was used, but...

You can take a look at this pinned issue for more information.

No, paper doesn't provide an override for that. This check was added by upstream (spigot) to prevent using the -ea versions of java 17. I'm assuming -internal builds fall into that same category of not guaranteeing that all official Java 17 API will be present, which is why the check was added...

Commands cannot be registered in the paper-plugin.yml. You have to handle registering them yourselves. If you don’t want to do that, just stick with “plugin.yml”. Support for that isn’t going away anytime soon.

It's not a huge issue, but a patch that fixed that was accidentally dropped during the 1.20 update. There's an open pull request to add it back here.

I think it expects the jar to be named mojang_1.12.2.jar inside a cache folder inside the root of your server.

It has to download the original vanilla jar in order to apply the binary patch. So it has to connect to mojang's servers to download it. It would be illegal to host it elsewhere. The jar you download from the downloads page/api isn't the server, it creates and runs the server.