Help me plz 1.12

Hey Community,

can anyone can tell me how to cancel this thing:

http://prntscr.com/fi9yy3

I want the left no items to be displayed
Thx

 

Click on the Book. You can't vanish the book.

 

of course a other german server has it already vanished ;(

 

Isn't this Forge?

Sent from my E2303 using Tapatalk

 

no its not forge, with spigot 1.12

 

@DispenserLP
What do you mean by cancel?

If you click the green book icon you can close the menu.

 

Sorry... I thought that that gui was made with forge... Haven't played 1.12 yet..

Sent from my E2303 using Tapatalk

 

@DispenserLP
Are you sure they are canceling it, and not just using resourcepacks to hide it?

From what I can tell, spigot does not have any events that detects that feature. If you would like to check, look at the docs here:
https://hub.spigotmc.org/javadocs/bukkit/

 

you can go to cloudmc.de <-- german server (1.12) and convince yourself

 

@DispenserLP
Not too convinced..

 

The server uses Via version I think.

Sent from my LG-H860 using Tapatalk

 

@RcExtract
Too bad via version is not support on the forums.

@DispenserLP
It looks like all they are doing is blocking the advancement packet (the one that add the recipes). As shown above, the menu will still exist, which is what I thought you wanted to block.
http://wiki.vg/Protocol#Advancements

 

@Zombie_Striker @DispenserLP
Well, cancelling the advancement packet (and btw, this server is almost certainly using via version, so it's just not sending it in the first place) does nothing with the recipe GUI. In fact, looking at all packets being sent, there doesn't even appear to be a packet sent when the GUI opens.

What is the effect we're trying to achieve here?

Right, scratch my previous posts (I didn't read the last sentence of the original post). But cancelling the advancement packet doesn't do this (advancement packet is for advancements, not recipes). This is the packet you want to cancel:
http://wiki.vg/Protocol#Unlock_Recipes

 

Ok, but can anybody help me, how to cancel this packets?

 

@DispenserLP
Two main approaches:

1. Use ProtocolLib (makes it easier and more reliable, but does require everyone using your plugin to also install ProtocolLib)
2. Use a custom channel injector (more unreliable, have to deal directly with NMS, but does not require an external dependency).

If you tell me which one you'd like to use, I can help you. Personally I'd recommend ProtocolLib.

 

I would like to performe with NMS, i hope you can help me

 

@DispenserLP
Alright, I'm going to give you two util classes that I've written (so you don't have to worry about the internals.. then we'd be here for weeks). You need to add these classes somewhere in your project (preferably in the same package, otherwise you'll have to import some classes):
https://gist.github.com/Alvin-LB/ac5626f861be7523a8c11338db3afb59

Then we need to register the PacketInterceptor in your plugin. Given that my documentation in those two classes is quite appaling, I'll just give you the code you need to do it and try to explain it. You need to stick this somewhere when you want the packet to be cancelled (onEnable would be a good place):

Code:java

new PacketInterceptor(this, "PacketPlayOutRecipes") {
            @Override
            public boolean packetSendingAsync(Player player, Object packet, String packetName) {
                return false;
            }
        };

Now for the quick explanation. The way my PacketInterceptor class is setup is that you override the class (you must, since it's abstract), and choose to override one or more out of four methods. They are packetReading() (reads packets incoming from clients), packetReadingAsync() (same as packetReading(), but not executed on the main thread), packetSending() (reads packets queued up for sending to the clients) and packetSendingAsync() (same as packetSending(), but not executed on the main thread).

We don't care about the parameters since we only need to cancel the packets, which we do by returning false in the method. This also means that we can choose the async method, since we don't need to access any potential non-thread-safe methods (or any methods at all for that matter). The constructor arguments are pretty simple. The first one is the plugin instance, which will be used to register event handlers to, and the second one is the packet we want to intercept. In this case it's PacketPlayOutRecipes (if you're wondering how I found out the name, have a look here).

NOTE: I still strongly recommend that you write a ProtocolLib implementation and use only use this as a fallback, since I cannot guarantee that this will not break in future versions (although I have tried to the best of my ability!). But of course, the choice is yours.

 

Great Thanks to you

 

You could also use maven so that the end user doesn't have to install ProtocolLib.
https://www.spigotmc.org/threads/tutorial-how-to-use-maven.60122/

 

@Horsey
Could you explain how that would work in a little bit more detail?

The only thing I could think of is if you'd use maven to shade ProtocolLib into your plugin, which is a terrible idea, since it's going to make your jar a whole lot heavier, and more importantly, it's not going to work if you don't modify it. And ontop of that, you don't need maven to shade, most IDEs are capable of shading already.