Solved Preventing Interaction with Packet Blocks

Discussion in 'Plugin Development' started by Shortninja66, Aug 22, 2015.

Thread Status:
Not open for further replies.
  1. Offline

    Shortninja66

    HERE IS MY SOLVED CODE, ONLY NEEDED TO USE A WRAPPER TO CHECK THE BLOCK:

    Code:
        public void setupPacketListener()
        {
            ProtocolLibrary.getProtocolManager().addPacketListener(new PacketAdapter(TheAura.plugin, ListenerPriority.HIGH, PacketType.Play.Server.BLOCK_ACTION)
            {
                @Override
                public void onPacketSending(PacketEvent event)
                {
                    Player player = event.getPlayer();
                    if(!combatObject.isTagged(player))
                    {
                        return;
                    }
               
                    if(event.getPacketType() == PacketType.Play.Server.BLOCK_ACTION)
                    {
                       WrapperPlayServerBlockChange wrapper =new WrapperPlayServerBlockChange(event.getPacket());
                       Location location = wrapper.getLocation(event);
    
                       if(Walls.mercuryWalls.contains(location(
                       {
                           //The block clicked is fake!
                        }
                    }
                }
            });
        }
    Many thanks goes out to SainttX, who helped me solve this problem!
     
    Last edited: Aug 26, 2015
  2. Offline

    au2001

    @Shortninja66 I guess the packet is sent every tick or so, to keep the block there.
    When you right-click it updates the block, so it will show the true block.
    Have you tried a block update event?
     
  3. Offline

    Shortninja66

    @au2001 Can't seem to find it on the API docs or in Eclipse. Is it a packet? The BlockChange packet does not work, sadly. I tested in console to see exactly what packet was called when the blocks are updated and it's BlockAction.
     
  4. Offline

    au2001

    @Shortninja66 I meant the BlockPhysicsEvent, it isn't a packet just a simple bukkit event.
     
  5. Offline

    Shortninja66

    @au2001 Hm, never thought about that event. However, it does not seem to be called when I update the packet blocks :/
     
  6. Offline

    au2001

    @Shortninja66 And can you cancel the BlockAction packet you saw? (I don't know much about packets...)
     
  7. Offline

    Shortninja66

    @au2001 Yeah, same here. I've tried that before though, doesn't change the outcome at all.
     
  8. Offline

    au2001

    @Shortninja66 How about re-sending him a block change in that event?
     
  9. Offline

    Shortninja66

    @au2001 What I am saying is that the listener WORKS but it sends the packet constantly while walls are enabled. So if I resent the block change, it would be resending that packet when I don't want it to.

    The real solution I need is a way to listen for this packet, but only when the player causes it (even though technically the packet is always being sent to the player so this is a real doozy).
     
  10. Offline

    au2001

    @Shortninja66 Oh, yes sorry I thought you said that the event was calling on block disappear :x
    Well, I don't see any other way than sending a block change each time the packet is sent :/

    Any way you can use the same block action packet to change the block's type for the player (e.g. setBlockState)?
    Or use something like a pipe that would transfer both packets at once? (Again, I almost never used packets...)
     
  11. Offline

    Shortninja66

    @au2001 Well that's what I'm doing with the ".setMercuryWalls()" method. That would recreate the walls when a block is changed. However, this creates an infinite loop because the packet event is always being called.

    I don't entirely understand the pipe thing you said :p

    @Comphenix Do you still browse around here mate?
     
  12. Offline

    Shortninja66

    Bump, still not solved.

    Did not know a reply to a post counted as a bump???
     
  13. Offline

    au2001

    @Shortninja66 Yes, any reply is counted as a bump since it pushes the thread back to the top of the forum list.
     
    Shortninja66 likes this.
  14. Offline

    Shortninja66

    Bump, not solved. Tried more packets but all seem to be useless :/
     
  15. Offline

    Shortninja66

    Bump. Anybody have any ideas? I might have to resort to PlayerMove possibly but I'd hate to do that personally.
     
Thread Status:
Not open for further replies.

Share This Page