Solved Slowly losing sanity.

Many aspects of Bukkit are annoying me right now, including how I have to wait a tick before checking sign lines after a SignChangeEvent, but this one takes the cake.


What the hell? Why isn't the sign changing?

Edit: Nvm, figured it out. Had to use the update() method.
Why does Bukkit even have one of these? Why do I need to tell the BlockState to update itself, after updating it?

 

What is the c in s.setLine(0, c("&d[&6G&aE&d]")); ?

Also, can you please not screenshot your code like that, these forums have an insert code function

 

@ImaTimelord7 c is a color code function. I use that as a shortening for the incredibly long ChatColor.translateAlternateColorCodes().

 

Ah okay
Obviously (due to all your debug messages - which its good to see you have used) the code is running to the end, you should try adding another one that broadcasts the String/Message you are trying to put on the sign.

 

@ImaTimelord7 Already solved, edited original post (before your first post). For whatever reason, it wasn't updating, and I needed BlockState#update().

 

It has the update methd because of efficiency. Updating the sign every time is like saving the config every tim you edit something in it. What if you want to change multiple lines, like saving multiple things in the config? Then updating the state of the sign would be unneccessary

 

@mcdorli Except that update() is a BlockState method and not a Sign method, and Sign doesn't override it. It seems to fulfill the same purpose as Player#updateInventory (which I also had to use in this plugin) - a quick fix for a bug that someone was eventually supposed to remove.

 

@pie_flavor, Bukkit has many more of those than we'd like to admit.

 

Same. It's like you want 1 liter hot water, but you only have a 500ml bukkit P), you don't do it like
1.: Get 500 ml water
2.: Poor it in the water heater
3.: Heat it up
4.: Repeat
but like
1: Get 500ml water
2.oor it in the water heater
3.: repeat the first 2 steps
4.: Heat up the water

Heating up the water is updating the inventory. It takes time.

 

@mcdorli I have no idea what you are talking about, but block updates should happen instantly. If I tell it to change a sign line, I don't expect to have to call another method for anything to actually happen.

 

He's saying it's there because if you wanted to change the sign 100 times then the sign would have to run through it's update code 100 times when it's more efficient to just change it then update it once when it's complete.

Like lets say you wanted to edit all four lines of the sign, you edit the first line of the sign, it updates, fires packets out to everyone within a certain radius that the sign has been updated with the new text, then you edit the second line, it updates, sends the packets again, etc. Why spam a connection with packets when you could just as easily call the update() method manually and send the packets once.

 

@Xerox262 Because it's not going to send multiple update packets. Only at the end of each tick does it send out packets, based on a list of queued updates. And again, this is a method not of Sign, but of BlockState, meaning that everything is like that. If I say Block#setType(Material.DIAMOND_BLOCK), I expect it to set the type to a diamond block, not leave it alone until I tell it to AGAIN. And what really takes the cake, is that the client requests an update packet whenever they right-click something. However, right clicking the sign did nothing, including shift-right-clicking.

 

That queue can contain things multiple times. Again, you update the sign and send out packets unnecessarily.

 

@mcdorli No, one change does not immediately mean one packet. Bukkit sends out packets at the end of the tick based on what changes it needs to make. It doesn't care that you changed the sign twelve times that tick, it just sends out an update packet with the final version.