BlockState no saving all the block information? [Bug¿?]

Discussion in 'Spigot Plugin Development' started by pollitoyeye, May 6, 2015.

  1. Well to reset some areas I've been saving the block states in an arraylist.
    Lets say I have a Block called bl and the ArrayList with all the states it's called toSave.
    Once I get a block I use:
    toSave.add(bl.getState());
    Well, a block state can be casted to Sign or CommandBlock so it should be saving all the information of the block.
    The problem comes in the update in wich I use:
    for(BlockState state : toSave){
    state.update(true);
    }
    That updates the block with the material and it's position to how it was but the problem it's that if the block it's something like a command_block the interal information (Command) isn't updated. This thing happens also with banners etc so my question is: Shouldn't BlockState be saving this all? Am I doing something wrong?
    Thanks in advance. :)
     
  2. gigosaurus

    Supporter

    I checked through the source code and can confirm that Block#getState() returns an object which contains all the expected information, and that BlockState#update(true) will correctly update the block with this information.

    The problem must lie on your end. Could you show more of your code?
     
  3. Can you check it youserlf?, I know too what's supossed to do, I'm using the last version of spigot.
    You don't need more code because that's all, I mean I just save the block state and then update, the block it's changing the material so of course it's saving correctly.
     
  4. I have run into this as well before I think:
    For me tile entities (signs, chests, etc.) didn't restore their tile-entity-specific content IF the block type changed in the time between when you got your block state and when you run the update method of it. Even when for ex. a sign block was changed to some other block type and then back to sign.

    My current theory is the following:

    The issue might be that the tile entity, which is stored in the sign block state (for example), which receives the line update, is no longer be the same / no longer valid / no longer has an existing representation in the world, if the block type was changed in the meantime.

    So when a sign block gets changed to some other block type and then back to sign, the world might create a new tile entity which holds the data of that new sign at the same location. And the block state still points to the old tile entity, which was holding the sign data for the old sign at that location. If you update the data of the old tile entity, those changes might not be applied to the current (new) tile entity.

    Maybe
    it would be fixed by letting the update method of block state restore the block type, and then getting the tile entity freshly from the world at the location, and then applying the stored sign lines (chest content, etc.) to that tile entity instead.

    I have created a ticket about this issue in the past (in the bukkit issue tracker), but it was never resolved.
     
    #6 blablubbabc, May 7, 2015
    Last edited: May 7, 2015
  5. Sorry for bumping an old thread, but has this issue ever been resolved?
     
  6. It seems it has never been resolved.