Setting a block type has odd results

Discussion in 'Plugin Development' started by \\slashies, Mar 2, 2011.

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

    \\slashies

    n.block.setType(Material.GLASS);

    In game this works and works well. The blocks are set to glass, things look good. This is trigged when a certain type of block (log + some logic) is chopped down with an axe. Nevermind those details, they work as advertised.

    The glass is just a filler and later "decays" (via a thread spinning out random numbers and a runable task that actually does the block changes in the main thread via scheduleSyncRepeatingTask and a thread safe queue) into air and drops wood. It is just an effect to visualize to the player that "something happened".

    In the end a sapling is planted and all the glass turns to air having dropped the wood using n.block.getWorld().dropItem(n.block.getLocation(), new ItemStack(Material.LOG,1)); (again, this is in the main thread because I know that the world does not take kindly to being modified otherwise).

    Hit that sapling with an axe (it was planted with setType jut like the glass and the glass decaying to air) and the game behaves as if the blocks that used to be the tree were SILL WOOD. The trunk of the tree re-appears in glass form and decays into wood. In short the algorithm sees wood there. Somehow, SOMEWHERE, those blocks are stored as wood, but they show up in game as air. Can even walk through them to plummet to your doom through them.

    It's not my code, it looks around using constructs like test.block.getFace(BlockFace.DOWN).getType().equals(Material.DIRT) all starting with the block passed via the break block event.

    I'm terribly confused. Any insight?
     
  2. Offline

    Afforess

    You mention that you set the block information in a thread-safe queue, which is good, but where do you get the block information in the first place? If it's in a parallel thread, you have 2 problems:

    1.) Might not be thread-safe. Haven't really encountered this, but a possibility nonetheless.
    2.) The block might not have updated when you check it. There's a tick delay before block updates, IIRC, and if you check again on the same tick, you will be getting old info.
     
  3. Offline

    \\slashies

    The decay thread uses the block objects gathered during the event handler.
    Decay does not occur until at least 1.5-2 seconds later. It has a 10% chance every 500ms to increase the decay value (held elsewhere) for the block. At a value for 4 it is sent to the queue and waits for the scheduleSyncRepeatingTask to execute the block change from glass -> air in the main thread. I don't think it would be stale information, though that is VERY good to keep in mind for the future.


    Anything sound incorrect about that? I imagine that perhaps I should be getting the blocks based on coordinates in task that changes them from glass -> air, but they are turned to glass in the event handler initially so the behavior of later events (minutes even) seeing wood in those blocks instead of what is currently there is confounding. (For clarity, in the event handler I always use the block passed to the handler as the starting point).

    Additionally, trees GROW from the auto planted saplings and the client correctly renders naked air.

    I hesitate to file a bug report to bukkit about this because I'm sure that I'm missing some critical but ill documented call to somehow update the blocks... but them rendering properly and trees growing properly makes the whole thing not add up quite right =/
     
Thread Status:
Not open for further replies.

Share This Page