Setting type to Torch requires block underneath

XMLWordPrintable

    • Type: Bug
    • Resolution: Won't Fix
    • Priority: Minor
    • None
    • Affects Version/s: None
    • None
    • Environment:

      Debian GNU/Linux 7.8 (wheezy) (KimSufi KS-4)

      I discovered what looks to to be a bug today which is that I can't set a torches data unless it has a block under it. Regardless of whether I setType with doPhysics set to false or not, the Torch will break before I can set it's data unless there is a solid block under it.

      I currently have a dirty workaround for it that isn't 100% guaranteed to work (block under might be a torch or something else), the code is as follows:

      @EventHandler
      public void onBlockBreak(BlockBreakEvent event) {
          final Block broken = event.getBlock();
          final byte originalData = broken.getData();
          final Material originalType = broken.getType();
      
          event.setCancelled(true);
          broken.setType(Material.AIR);
      
          Bukkit.broadcastMessage("Broken type set to AIR");
      
          // This code won't work - the torch will drop
          Bukkit.getScheduler().runTaskLater(this, new Runnable() {
              @Override
              public void run() {
                  // Set back to it's original state and don't apply physics
                  broken.setType(originalType, false);
                  broken.setData(originalData, false);
                  Bukkit.broadcastMessage("Failed code ran, the torch was set.");
              }
          }, 60L);
      
          // This code (dirty workaround) will work - the torches data will be able to be set
          Bukkit.getScheduler().runTaskLater(this, new Runnable() {
              @Override
              public void run() {
                  Block under = broken.getRelative(BlockFace.DOWN);
                  Material underOriginal = under.getType();
                  boolean flag = false; // Whether we modify under
      
                  if (under.isEmpty()) {
                      flag = true;
                      /* Any solid material that a torch or similar can sit on should work */
                      under.setType(Material.BEDROCK, false);
                  }
      
                  broken.setType(originalType, false);
                  broken.setData(originalData, false);
      
                  if (flag) {
                      under.setType(underOriginal, false);
                  }
      
                  Bukkit.broadcastMessage("Working code ran, the torch was set.");
              }
          }, 100L);
      }

      What is essentially happening using this code is the first runnable (with code showing that I can't set the torches data before it disappears) runs 3 seconds after I break the block (breaking torches) and attempts to set the block back to it's original material and set it's data (both with doPhysics set to false). The second runnable executes another 2 seconds after the buggy code to show that I have to put a solid material under the torch before setting the type/data to get the intended behavior and then removing the solid block after (the client won't render it).

      This behavior doesn't occur (from what I've observed) to other objects with SimpleAttachableMaterialData (ie. Lever, Button, etc). I'm not entirely sure if this is intended so I've posted this thread in hopes to bring light to it.

      Here's a video showing the code's execution:
      https://www.youtube.com/watch?v=amOwGylgsQA

            Assignee:
            Thinkofname
            Reporter:
            Matthew Steglinski
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: