Wann immer sich eine beliebige Eigenschaft eines Blocks verändert, ob sichtbar oder nicht, spricht man von einem Blockupdate. Der Block kann dabei seine ID ändern. Der Zeitpunkt, wann ein Blockupdate stattfindet, wird durch die Ticks gesteuert. Dabei gibt es zufällige und angeforderte Blockupdates. Beispiele für zufällige Blockupdates sind gefrierendes Wasser oder wachsende Pflanzen. Angeforderte Blockupdates betreffen immer alle Nachbarblöcke, wenn ein Block verändert wird. Wird z.B. ein Block abgebaut, erhalten alle Nachbarblöcke ein Blockupdate. Sind sie z.B. eine stehende Flüssigkeit, beginnen sie zu fließen. Bei großen, schwebenden Sandflächen kann dieses System das Spiel stark verlangsamen, weil jeder fallende Sand seine Nachbarn auch zum Fallen bringt.
Eine Unterart des Blockupdate ist das Blockobjektupdate (engl. Tile Entity Update), d.h. das Ändern/ Aktualisieren der Blockobjektdaten.
Beispiele für Blockupdates:
Ein Block wird abgebaut (ID wechselt zu air) oder gesetzt
Wasser (ID=water) gefriert zu Eis (ID=ice), Eis schmilzt zu Wasser
Erde (ID=dirt) wird zu einem Grasblock (ID=grass_block), ein Grasblock wird zu Erde
Eine Alternative dazu ist der Blockupdate-Sensor. Ein Blockobjektupdate-Sensor reagiert entsprechend bei einem Blockobjektupdate. In den meisten Fällen kann man ein Blockupdate erzwingen, indem man einen nicht brennbaren Block anzündet. Das Feuer geht sofort wieder aus, aber das Blockupdate findet statt. Durch ein Blockupdate kann man Anomalien, wie beispielsweise schwebenden Sand, beheben. Solche Landschaftsanomalien entstehen, weil während der Weltgenerierung keine Blockupdates durchgeführt werden.
Besonderheiten bei Redstone-Leitungen[]
Bei bestimmten Ereignissen mit der Redstone-Leitung wird ein besonderes Blockupdate ausgelöst. Tritt eines dieser Ereignisse auf, wird ein Blockupdate nicht nur für die direkt angrenzenden Blöcke, sondern für alle Blöcke in einem Radius von zwei ausgeführt.
Folgende Aktionen lösen diesen besonderen Blockupdate aus: