Redstone-Analyse: Nether-Clocks kollidieren mit Overworld-Signalen

Der Stream beginnt mit einer allgemeinen Begrüßung und der Ankündigung, dass es um Craft Attack 14, Woche 3 geht. Der Fokus liegt auf dem Star-Gate-Teleport-System und technischen Problemen mit Redstone-Clocks. Der Host erwähnt, dass Clocks im Spiel oft stehen bleiben und versucht, dieses Problem zu lösen. Er beginnt mit der Analyse, warum Redstone-Server-Probleme auftreten, insbesondere im Nether.

Technikdiagnose: Redstone-Clock-Probleme

00:04:14

Der Host erklärt, dass Redstone-Clocks aufgrund von Neighbor-Updates im Nether-Prozess Probleme haben. Er hat festgestellt, dass Clocks, die in der Overworld funktionieren, im Nether oft fehlschlagen. Die Ursache liegt in der Art und Weise, wie Minecraft die Redstone-Berechnung in verschiedenen Dimensionen verarbeitet. Ertestet, ob Observer oder Piston-Techniken die Ursache sind.

Der Host entdeckt, dass Kaktuswachstum als externer Trigger für Redstone-Updates dienen kann. Da Kaktuswachstum durch ein separates System berechnet wird, nicht von der Redstone-Logik abhängt, fungiert es als zuverlässiger Reset-Mechanismus für fehlerhafte Clocks. Er baut Testkonstruktionen auf, um dies zu verifizieren.

Weitere Tests zeigen, dass Redstone im Nether anders reagiert als in der Overworld. Zero-Tick-Maschinen, die in der Overworld funktionieren, verursachen sofortige Lag-Probleme im Nether. Der Host vermutet, dass die Server-Software für die Nether-Berechnung eine andere Logik verwendet, was zu Konflikten mit Overworld-Redstone führt.

Der Host entwickelt ein System, in dem Clocks automatisch repariert werden, wenn sie durch Neighbor-Updates blockiert sind. Durch den Einsatz von Kaktus-Updatemechanismen werden die Clocks zurückgesetzt, sobald ein Kaktus in der Nähe wächst. Er testet dies in verschiedenen Szenarien, um die Stabilität zu gewährleisten.

Der Host sendet ein Redstone-Signal in den Nether und beobachtet, wie es nachgelagert Portal-Blocks auslöst. Die TPS-Werte sinken sofort, und alle Clocks auf dem Server gehen aus. Dies bestätigt die Vermutung, dass Redstone-Aktivitäten im Nether kritisch sind und zu Server-Instabilität führen.

Der Host stellt fest, dass Redstone im Nether anders berechnet wird. Während die Overworld-Rechnung stabil bleibt, verursacht jede Redstone-Aktivität im Nether sofortige Probleme. Er testet, ob der Effekt nur bei Zero-Tick-Maschinen auftritt oder generell bei allen Redstone-Techniken.

Goldfarm und Chunkloader-Probleme

00:09:40

Der Host zeigt seine Goldfarm, die ebenfalls von Chunkloadern abhängt. Er erklärt, dass das Problem nicht nur bei Zero-Tick-Maschinen auftritt, sondern bei allen komplexen Redstone-Systemen im Nether. Er hat bereits eine Reparatur-Methode mit Kaktus-Updates implementiert, um die Stabilität zu verbessern.

Der Host testet verschiedene Kombinationen aus Zero-Tick-Maschinen und Lag-Generatoren, um die genauen Bedingungen für Neighbor-Updates zu identifizieren. Er stellt fest, dass die Kollision zwischen Overworld- und Nether-Redstone-Berechnungen das Problem verursacht. Sobald beide Systeme gleichzeitig aktiv sind, treten die Fehler auf.

Der Host identifiziert Neighbor-Update als zentralen Fehler. Dieses wird ausgelöst, wenn Redstone-Events in der Overworld und Nether gleichzeitig verarbeitet werden. Die Server-Software verwendet unterschiedliche Threads für beide Dimensionen, was zu Synchronisationsproblemen führt. Der Host dokumentiert die Tests und versucht, eine Lösung zu finden.

Der Host erhält von Homie die Information, dass das Neighbor-Limit minimal angepaszt werden könnte, um zu testen, ob sich das Verhalten ändert. Der Host bestätigt, dass das Problem nicht mit der Anzahl der Spieler zusammenhängt, sondern ein Bug in der Server-Software ist. Er plant, das Limit zu erhöhen und weitere Tests durchzuführen.

Der Host fasst zusammen, dass Redstone im Nether grundsätzlich fehlerhaft ist. Jede Form von Redstone-Aktivität, egal ob Clock, Zero-Tick-Maschine oder einfache Schaltungen, verursacht Neighbor-Updates. Der Host testet auf einer separaten Instanz mit identischer Server-Software, um die Problematik zu reproduzieren.

Testumgebung: Identische Server-Kopie

00:14:27

Der Host nutzt eine exakte Kopie des Craft-Attack-Servers, um Tests durchzuführen. Auf dieser Testwelt wird eine Zero-Tick-Maschine gebaut und getestet. Der Host stellt fest, dass die Maschine in der Overworld stabil läuft, aber sobald sie im Nether aktiviert wird, sofortige Probleme auftreten. Dies bestätigt die Dimension-spezifische Fehlerursache.

Der Host erklärt die Funktionsweise der Zero-Tick-Maschine, die Redstone-Signale in einem Tick permanent an- und ausschaltet. Dieses Design wurde ursprünglich entwickelt, um Bedrock zu brechen. Er testet, ob diese Maschine in verschiedenen Dimensionen unterschiedlich reagiert und dokumentiert die Ergebnisse.

Der Host führt stochastische Tests durch, um die Fehlerwahrscheinlichkeit zu bestimmen. Er baut die gleiche Zero-Tick-Maschine in Overworld und Nether und beobachtet die Ergebnisse. Während die Overworld-Maschine stabil läuft, schlägt die Nether-Version in 100% der Fälle fehl. Dies bestätigt die Dimension-spezifische Problematik.

Reihenfolgetest: Overworld vs. Nether

00:19:04

Der Host testet, ob die Reihenfolge der Aktivierung (Overworld zuerst vs. Nether zuerst) einen Unterschied macht. Er stellt fest, dass das Problem nur auftritt, wenn zuerst im Nether eine Maschine gestartet wird und danach in der Overworld eine andere Technik aktiviert wird. Dies deutet auf eine asynchrone Kollision der Berechnungen hin.

Der Host bestätigt, dass Zero-Tick-Maschinen im Nether 100% der Zeit fehlschlagen, während Overworld-Maschinen stabil bleiben. Er schlussfolgert, dass das Problem mit der Art und Weise zusammenhängt, wie Minecraft die Redstone-Berechnung in verschiedenen Dimensionen verarbeitet. Der Host plant, diesen Bug an die Universe-Entwickler zu melden.

Der Host zeigt seine Goldfarm, die von Filtern und Sortiersystemen abhängt. Er erklärt, dass diese Systeme ebenfalls von Neighbor-Updates betroffen sind. Er hat bereits eine Lösung mit Kaktus-Updates implementiert, um die Clocks automatisch zu reparieren. Er testet, ob das Problem durch die Filter oder die Redstone-Technik verursacht wird.

Der Host entwickelt eine Theorie, dass Overworld-Redstone-Events den Neighbor-Update im Nether auslösen. Er testet, ob das Limit für Redstone-Events in der Overworld überschritten wird, während eine Maschine im Nether aktiv ist. Er vermutet, dass die Kombination beider Aktivitäten das Problem verursacht.

Synchronisationsproblem: Threads und Berechnung

00:23:57

Der Host identifiziert, dass das Problem in der Synchronisation zwischen Overworld- und Nether-Berechnungen liegt. Die Welten laufen async in separaten Threads, was zu Konflikten führt, wenn Redstone-Events gleichzeitig verarbeitet werden. Er testet, ob das Hochfahren der Limits das Problem löst oder nur verschlimmert.

Der Host testet, ob Entities (z.B. Tiere, Items) ebenfalls zur Server-Überlastung beitragen. Er erstellt ein Test-Szenario mit 2900 Schafen, um die TPS zu beobachten. Obwohl die Entities Last erzeugen, bleibt der Server stabil. Dies zeigt, dass das Problem spezifisch mit Redstone und Nether-Interaktionen zusammenhängt.

Der Host bestätigt, dass die Testwelt eine exakte Kopie von Craft-Attack ist, einschließlich dersselben Server-Software und Einstellungen. Er testet, ob die Probleme in Overworld und Nether unabhängig voneinander auftreten oder nur in Kombination. Dies hilft, die Ursache weiter einzugrenzen.

Der Host testet, ob die Position der Goldfarm in Bezug auf Region-Grenzen (Chunks) einen Einfluss auf das Problem hat. Er baut die Zero-Tick-Maschine an verschiedenen Positionen und beobachtet die Ergebnisse. Er stellt fest, dass die Region-Grenzen keinen direkten Zusammenhang haben, sondern das Problem generell im Nether auftritt.

Kaktus-Update-Mechanismus: Lösung für alle Clocks

00:29:36

Der Host entwickelt und testet den Kaktus-Update-Mechanismus als universelle Lösung für fehlerhafte Clocks. Er zeigt, wie dieser Mechanismus in verschiedenen Techniken integriert werden kann, um eine stabile Funktionalität zu gewährleisten. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

Der Host führt einen Live-Test durch, um zu demonstrieren, wie der Kaktus-Update-Mechanismus bei einer gestrandeten Clock funktioniert. Er zeigt, dass der Kaktus, der im selben Chunk wächst, das Redstone-Update auslöst und die Clock automatisch repariert. Dies bestätigt die Effektivität der Lösung.

Kaktus-Technik: Funktionsweise und Implementierung

00:33:59

Der Host erklärt, wie der Kaktus-Update-Mechanismus funktioniert. Da Pflanzen von einem separaten System berechnet werden, das nicht von Redstone abhängt, dienen sie als zuverlässige Trigger. Der Host zeigt, wie man diesen Mechanismus überall implementieren kann, um Clocks stabil zu halten.

Tick-Sync-Problematik: Nether vs. Overworld

00:35:40

Der Host identifiziert, dass die Problematik mit der Synchronisation der Tick-Raten zwischen Nether und Overworld zusammenhängt. Wenn die TPS in der Overworld sinken, während Redstone im Nether aktiv ist, treten Neighbor-Updates auf. Dies deutet auf ein Timing-Problem in der Server-Software hin.

Der Host erkennt an einer Schwelle, bei der Neighbor-Updates ausgelöst werden. Sobald die Anzahl der Redstone-Events in der Overworld einen bestimmten Schwellwert überschreitet, während gleichzeitig Redstone im Nether aktiv ist, tritt das Problem auf. Dies bestätigt die Theorie der Kombination aus beiden Faktoren.

Entity-Last vs. Redstone-Last

00:44:37

Der Host testet, ob Entities oder Redstone-Events die Hauptursache für die Server-Probleme sind. Er erstellt eine Farm mit vielen Schafen (2900) und vergleicht die TPS mit Redstone-Belastungen. Obwoohl Entities Last erzeugen, ist der entscheidende Faktor Redstone im Nether, das Neighbor-Updates auslöst.

Overworld-Test: Keine Probleme ohne Nether

00:49:28

Der Host testet, ob Redstone-Probleme auftreten, wenn nur in der Overworld aktiv ist. Er stellt fest, dass die Overworld alleine stabil läuft, selbst bei hoher Belastung. Das Problem tritt nur auf, wenn Redstone im Nether aktiv ist. Dies bestätigt, dass das Problem spezifisch mit der Nether-Redstone-Verarbeitung zusammenhängt.

Der Host bestätigt, dass das Problem nicht mit der Anzahl der Spieler oder Farben zusammenhängt, sondern ein Bug in der Server-Software ist. Die Kollision zwischen Overworld- und Nether-Redstone-Berechnungen löst Neighbor-Updates aus. Der Host schlussfolgert, dass dies ein Problem in der Universe-Version ist, das von den Entwicklern behoben werden muss.

Neighbor-Update-Verhalten: TPS-Einfluss

00:54:20

Der Host beobachtet, dass Neighbor-Updates auftreten, wenn die TPS sinken, während Redstone im Nether aktiv ist. Er stellt fest, dass die TPS nicht der Auslöser, sondern das Ergebnis des Problems sind. Die Redstone-Berechnung im Nether verursacht die TPS-Probleme, nicht umgekehrt.

Der Host entwickelt eine Theorie, dass das Problem mit der Schedulist (Warteliste) von Redstone-Events zusammenhängt. Wenn ein Spielereingabe (z.B. Schalterbetätigung) ein Redstone-Event auslöst, wird dieses auf die Schedulist gesetzt. Diese wird von einem anderen Thread verarbeitet, der mit dem Nether-Redstone kollidieren kann.

Neighbor-Update-Auslösung: Player-Input vs. Tick

00:59:25

Der Host testet, ob Neighbor-Updates durch direkte Spielereingaben (z.B. Schalter) oder durch Tick-basierte Redstone-Events ausgelöst werden. Er stellt fest, dass direkte Eingaben unabhängig von der Tick-Rate funktionieren, während Tick-basierte Events von der TPS abhängen. Dies bestätigt die Schedulist-Theorie.

Finaler Beweis: Zero-Tick im Nether

01:03:11

Der Host führt einen entscheidenden Test durch, bei dem eine Zero-Tick-Maschine im Nether aktiviert wird, während gleichzeitig Redstone in der Overworld aktualisiert wird. Dies führt zu einem sofortigen Neighbor-Update und TPS-Absturz. Dies bestätigt, dass die Kollision zwischen Nether-Redstone und Overworld-Redstone die Ursache ist.

Causality-Test: Nether vs. Overworld Reihenfolge

01:09:56

Der Host testet, ob die Reihenfolge der Aktivierung (Nether zuerst vs. Overworld zuerst) einen Unterschied macht. Er stellt fest, dass das Problem nur auftritt, wenn zuerst im Nether eine Maschine gestartet wird und danach in der Overworld aktiviert wird. Dies bestätigt die Theorie der asynchronen Kollision.

Observer-Beteiligung: Schuldige Komponente

01:12:52

Der Host identifiziert Observer als Schuldige der Neighbor-Updates. Er testet, ob das Problem durch Observer verursacht wird, indem er diese entfernt und ersetzt. Er stellt fest, dass Observer, die von Pflanzen oder anderen nicht-Redstone-Systemen getriggert werden, das Problem verstärken, da sie asynchrone Updates auslösen.

Der Host testet, ob Neighbor-Updates durch direkte Spielereingaben (z.B. Schalter) oder durch Tick-basierte Redstone-Events ausgelöst werden. Er stellt fest, dass direkte Eingaben unabhängig von der TPS funktionieren, während Tick-basierte Events von der TPS abhängen. Dies bestätigt die Schedulist-Theorie.

Neighbor-Update-Bestätigung: Korrelation vs. Kausalität

01:18:07

Der Host bestätigt, dass es eine Korrelation zwischen Redstone-Aktivität in der Overworld und Neighbor-Updates im Nether gibt, aber keine Kausalität. Die Overworld-Redstone-Aktivität ist der Auslöser, aber das Problem liegt in der Interaktion mit dem Nether. Dies zeigt, dass die Lösung nicht in der Reduzierung der Overworld-Aktivität liegt.

Der Host testet, ob die Position der Redstone-Maschine in Bezug auf Region-Grenzen einen Einfluss auf das Auftreten von Neighbor-Updates hat. Er baut die Maschine an verschiedenen Positionen in der Overworld und im Nether auf und beobachtet die Ergebnisse. Er stellt fest, dass die Region-Grenzen keinen direkten Zusammenhang haben.

Redstone-Verhalten: Overworld vs. Nether

01:24:31

Der Host führt System-Tests durch, um das Verhalten von Redstone in verschiedenen Dimensionen zu vergleichen. Er stellt fest, dass Redstone in der Overworld stabil läuft, während Redstone im Nether zu Neighbor-Updates führt. Dies bestätigt, dass das Problem spezifisch mit der Nether-Redstone-Verarbeitung zusammenhängt.

Neighbor-Update-Bestätigung: Spielerverhalten

01:27:55

Der Host testet das Verhalten von Neighbor-Updates, wenn ein Spieler durch ein Portal wechselt. Er stellt fest, dass das Wechseln der Dimensionen nicht das Problem ist, sondern die Redstone-Aktivität im Nether. Der Host dokumentiert die Tests und versucht, eine präzise Reproduktion des Fehlers zu erreichen.

Der Host führt einen Tick-Freeze-Test durch, um zu bestimmen, ob Neighbor-Updates durch Redstone-Events oder durch Spielerverhalten verursacht werden. Er stellt fest, dass Redstone-Events in der Overworld unabhängig von der Tick-Rate funktionieren, während Tick-basierte Events von der TPS abhängen. Dies bestätigt, dass das Problem in der Interaktion mit dem Nether liegt.

Kausalitätsanalyse: Overworld auslöser

01:34:24

Der Host analysiert, ob die Overworld-Redstone-Aktivität der Auslöser für Neighbor-Updates im Nether ist. Er stellt fest, dass die Overworld-Redstone-Events die Neighbor-Updates im Nether verursachen, nicht umgekehrt. Dies bestätigt, dass die Lösung nicht in der Reduzierung der Nether-Aktivität liegt, sondern in der Synchronisation der Overworld- und Nether-Berechnungen.

Der Host entwickelt einen Workaround für das Neighbor-Update-Problem. Er verwendet Kaktus als externen Trigger, der unabhängig von der Redstone-Berechnung arbeitet. Dadurch können Clocks automatisch repariert werden, sobald ein Kaktus in der Nähe wächst. Der Host testet dies in verschiedenen Szenarien und dokumentiert die Ergebnisse.

Universe-Software-Bug: Tick-Synchronisation

01:39:27

Der Host schlussfolgert, dass das Problem in der Universe-Server-Software liegt. Die Synchronisation der Tick-Raten zwischen Overworld und Nether ist fehlerhaft, was zu Neighbor-Updates führt. Der Host bittet die Entwickler, das Problem zu untersuchen, und plant, das Limit für Redstone-Events zu erhöhen, um die Tests fortzusetzen.

Bug-Fix: Kaktus-basieres Reparatursystem

01:42:55

Der Host testet das Kaktus-basierte Reparatursystem und stellt fest, dass es zuverlässig funktioniert. Clocks, die durch Neighbor-Updates blockiert sind, werden automatisch repariert, sobald ein Kaktus in der Nähe wächst. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist und plant, dies als Standard zu implementieren.

Der Host analysiert, ob die Redstone-Probleme durch die Masse der Systeme oder durch spezifische Komponenten verursacht werden. Er stellt fest, dass es eine Korrelation zwischen der Masse der Redstone-Events und den Neighbor-Updates gibt, aber keine Kausalität. Das Problem liegt in der Interaktion mit dem Nether, nicht in der Masse der Systeme.

Region-Test: Nether-Decken-Position

01:49:27

Der Host testet, ob die Position der Redstone-Maschine in Bezug auf die Nether-Decken-Höhe einen Einfluss auf das Auftreten von Neighbor-Updates hat. Er baut die Maschine an verschiedenen Höhen in der Nether-Decke auf und beobachtet die Ergebnisse. Er stellt fest, dass die Höhe keinen direkten Zusammenhang hat.

Der Host führt einen finalen Test durch, bei dem das Redstone-Limit erhöht wird. Er stellt fest, dass das Problem durch das Hochsetzen des Limits nicht behoben wird. Der Host schließt, dass das Problem in der Server-Software liegt und von den Universe-Entwicklern behoben werden muss.

Bug-Report: Kaktus-basierte Lösung

01:54:56

Der Host erstellt einen Bug-Report für die Universe-Entwickler. Er dokumentiert das Problem und präsentiert die Kaktus-basierte Lösung als vorläufigen Workaround. Der Host betont, dass die Kaktus-basierte Clock-Reparatur zuverlässig funktioniert und als Standard implementiert werden sollte.

Workaround: Kaktus-Clock-Update-Mechanismus

01:58:23

Der Host erklärt, wie der Kaktus-Clock-Update-Mechanismus funktioniert. Dadurch, dass Kaktuswachstum durch ein separates System berechnet wird, wird ein Redstone-Update ausgelöst, das alle Clocks im Chunk repariert. Der Host zeigt, wie dieser Mechanismus in verschiedene Techniken integriert werden kann, um Stabilität zu gewährleisten.

Der Host identifiziert, dass die Redstone-Berechnung in der Overworld und im Nether in separaten Threads läuft. Wenn beide Threads gleichzeitig aktiv sind, treten Neighbor-Updates auf. Der Host testet, ob das Problem durch die Synchronisation der Threads verursacht wird, und stellt fest, dass die Overworld-Redstone-Berechnung den Neighbor-Update im Nether auslöst.

Neighbor-Update-Trigger: Spielerverhalten

02:03:50

Der Host testet, ob Neighbor-Updates durch direkte Spielereingaben (z.B. Schalter) oder durch Tick-basierte Redstone-Events ausgelöst werden. Er stellt fest, dass direkte Eingaben unabhängig von der TPS funktionieren, während Tick-basierte Events von der TPS abhängen. Dies bestätigt, dass das Problem in der Interaktion mit dem Nether liegt.

Der Host führt eine Live-Demonstration des Kaktus-Update-Mechanismus durch. Er zeigt, wie ein Kaktus, der in der Nähe einer fehlerhaften Clock wächst, das Redstone-Update auslöst und die Clock automatisch repariert. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

Overworld-Redstone-Limit: Neighbor-Auslösung

02:08:30

Der Host testet, ob das Neighbor-Update durch das Überschreiten des Redstone-Limits in der Overworld verursacht wird. Er stellt fest, dass das Problem auch bei unterhalb des Limits auftritt, wenn Redstone im Nether aktiv ist. Dies bestätigt, dass das Problem in der Interaktion zwischen Overworld und Nether liegt.

Der Host führt einen Stabilitätstest des Kaktus-basierten Reparatur-Systems durch. Er zeigt, dass Clocks, die durch Neighbor-Updates blockiert sind, automatisch repariert werden, sobald ein Kaktus in der Nähe wächst. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

Neighbor-Update-Auslösung: Overworld-Trigger

02:12:56

Der Host testet, ob Neighbor-Updates durch Overworld-Redstone-Events oder durch Nether-Redstone-Events ausgelöst werden. Er stellt fest, dass Overworld-Redstone-Events den Neighbor-Update im Nether verursachen, nicht umgekehrt. Dies bestätigt, dass die Lösung in der Synchronisation der Overworld- und Nether-Berechnungen liegt.

Der Host schlussfolgert, dass das Problem in der Universe-Server-Software liegt. Die Redstone-Berechnung im Nether ist fehlerhaft und führt zu Neighbor-Updates. Der Host bittet die Entwickler, das Problem zu untersuchen, und plant, das Limit für Redstone-Events zu erhöhen, um die Tests fortzusetzen.

Der Host testet das Kaktus-basierte Reparatur-System und stellt fest, dass es zuverlässig funktioniert. Clocks, die durch Neighbor-Updates blockiert sind, werden automatisch repariert, sobrn ein Kaktus in der Nähe wächst. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

TPS-Bar: Überwachungsinstrument

02:19:35

Der Host verwendet eine TPS-Bar, um die Server-Leistung in Echtzeit zu überwachen. Er zeigt, wie die TPS-Werte sinken, wenn Redstone im Nether aktiv ist, und steigen, wenn die Aktivität gestoppt wird. Der Host betont, dass die TPS-Bar ein wichtiges Instrument für die Fehlerbehebung ist.

Der Host führt einen entscheidenden Test durch, bei dem eine Zero-Tick-Maschine im Nether aktiviert wird. Er stellt fest, dass dies sofort Neighbor-Updates auslöst und die TPS auf unter 10 drückt. Der Host bestätigt, dass das Problem in der Nether-Redstone-Verarbeitung liegt.

Kaktus-Update-Mechanismus: Reparatur-Test

02:24:01

Der Host testet den Kaktus-Update-Mechanismus als Reparurlösung. Er zeigt, dass Clocks, die durch Neighbor-Updates blockiert sind, automatisch repariert werden, sobald ein Kaktus in der Nähe wächst. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

Der Host schlussfolgert, dass das Problem in der Universe-Server-Software liegt. Die Tick-Synchronisation zwischen Overworld und Nether ist fehlerhaft und führt zu Neighbor-Updates. Der Host bittet die Entwickler, das Problem zu untersuchen, und plant, das Limit für Redstone-Events zu erhöhen.

Workaround: Kaktus-basierte Clock-Stabilität

02:28:27

Der Host testet das Kaktus-basierte Reparatur-System und stellt fest, dass es zuverlässig funktioniert. Clocks, die durch Neighbor-Updates blockiert sind, werden automatisch repariert, sobald ein Kaktus in der Nähe wächst. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

Der Host führt einen Reproduktionstest durch, um den Neighbor-Update-Fehler zu verifizieren. Er stellt fest, dass das Problem in 100% der Fälle auftritt, wenn Redstone im Nether aktiv ist. Der Host bestätigt, dass das Problem in der Nether-Redstone-Verarbeitung liegt und nicht in der Overworld-Aktivität.

Der Host führt einen Live-Test des Kaktus-Update-Mechanismus durch. Er zeigt, wie ein Kaktus, der in der Nähe einer fehlerhaften Clock wächst, das Redstone-Update auslöst und die Clock automatisch repariert. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

Universe-Software-Bug: Tick-Synchronisation

02:34:35

Der Host schlussfolgert, dass das Problem in der Universe-Server-Software liegt. Die Tick-Synchronisation zwischen Overworld und Nether ist fehlerhaft und führt zu Neighbor-Updates. Der Host bittet die Entwickler, das Problem zu untersuchen, und plant, das Limit für Redstone-Events zu erhöhen.

Workaround: Kaktus-basierte Reparatur

02:36:38

Der Host testet das Kaktus-basierte Reparatur-System und stellt fest, dass es zuverlässig funktioniert. Clocks, die durch Neighbor-Updates blockiert sind, werden automatisch repariert, sobald ein Kaktus in der Nähe wächst. Der Host betont, dass dies die beste Lösung für alle Redstone-Systeme ist.

Es wurde ein neues Spam-Proof-System vorgestellt, das verhindert, dass Redstone-Schaltungen durch wiederholtes Drücken eines Schalters beschädigt werden. Selbst bei schnellem Ein- und Ausschalten bleibt die Technik stabil. Das System nutzt Kabel mit zeitversetztem Timing und integriert Verzögerungen, die eine Wartezeit von etwa einer Minute ermöglichen. Dadurch ist sichergestellt, dass die Schaltung nicht innerhalb kurzer Zeit erneut ausgelöst werden kann – ein sogenanntes „Save-by-Design“-Prinzip.

Da die Schaltung mit TNT arbeitet, ist es entscheidend, dass sie nicht versehentlich selbst zerstört. Der Spam-Schutz verhindert, dass die Technik durch wiederholtes Auslösen in die Luft gesprengt wird. Der Streamer erklärte, dass ähnliche Gedanken hinter allen Schaltungen stehen, insbesondere wenn sie mit explosiven Elementen interagieren. Zudem wurde besprochen, wie wichtig es ist, die Eingaben zu kontrollieren, um ungewollte Auslösungen zu vermeiden.

Es wurde darüber diskutiert, die aktuelle TNT-Technik später zu erweitern, sodass sie zwei statt einer TNT-Einheit pro Auslösung abfeuert. Eines soll nach oben und eines nach unten geschossen werden, um mehr Fläche abzudecken. Der Streamer betonte, dass dies möglich sei, aber noch eine größere Herausforderung darstelle. Gleichzeitig wurde erwähnt, dass später weitere Räume im Berg entstehen sollen, was die Notwendigkeit erhöht, die Technik flexibel zu gestalten.

Der Streamer beschrieb seine Vision, im Berg mehrere ausklappbare Mechanismen zu bauen, darunter einen kleinen Garten, einen Swimmingpool und Lampen, die sich öffnen. Diese sollen durch Sulphurdinger („Sulphurlings“) gesteuert werden. Zudem wurde eine Idee erwähnt, bei der sich ein Raum nach innen einklappt und eine riesige Flugmaschine freilegt – inspiriert von früheren Basteleien wie der Hero Brine-Bewegung im Freizeitpark. All dies soll später realisiert werden.

Um die Schaltungen automatisch aktivieren zu können, wurden Chunkloader geplant. Sobald der Spieler sich einloggt, aktiviert eine Enderperle die Chunkloader. Diese senden ihre Items zurück, woraufhin eine Detektionsschaltung erkennt, dass alle bereit sind. Anschließend wird die Technik für 16 Sekunden freigegeben und darf arbeiten. Danach überprüft sie sich selbst und deaktiviert sich erneut, bis erneut eingeloggt wird.

Vor allem beim Arbeiten mit TNT ist es wichtig, die Schaltung gründlich zu testen, da sonst die Technik selbst zerstört werden könnte. Der Streamer betonte, dass man durch das Testen lernt, wo Blöcke platziert werden können und wo nicht. Er erwähnte, dass er in der Testwelt bereits Erfahrung mit ähnlichen Konstruktionen gesammelt hat – manchmal sogar mehrere Male um die Ohren geschlagen, bis sie funktionierten. Diese Erfahrung hilft beim Verständnis für Redstone-Logik.

Während des Streams wurde deutlich, dass Schaltungen nicht auf einmal perfekt entstehen, sondern durch wiederholte Anpassungen verfeinert werden. Jede kleine Änderung am Kabelverlauf oder an der Timing-Einstellung führt zu Compacting – dem Zusammenpacken der Schaltung. Der Streamer betonte, dass dies ein natürlicher Prozess ist und dass man mit der Zeit ein Gespür dafür entwickelt, wie kompakt man bauen kann. Pure Routine und Wiederholung seien entscheidend.

Geheime Türen, Tunnel und versteckte Räume planen

04:24:51

Neben den TNT-basierten Mechaniken wurden auch einfache, aber kreative Ideen diskutiert, wie geheime Türen, Tunnel, die sich öffnen, oder Jeb-Türen im Boden. Der Streamer erwähnte, dass er manchmal sogar Konstruktionen plant, die am Ende mit TNT zerstört werden sollen – entweder zum Öffnen oder zum Abbauen. Diese Ideen entstanden oft während des Baus selbst, da neue Möglichkeiten durch kreative Kombinationen von Redstone und Pistons entdeckt wurden.

Da die Schaltung momentan in einem hohen Tempo gebaut wird, besteht das Risiko, dass Fehler auftreten. Der Streamer warnte, dass es möglicherweise zu Fehlern kommen könnte, die sogar zum sofortigen Zerstören der Konstruktion führen. Wichtig sei daher, konzentriert zu bleiben. Glücklicherweise habe er inzwischen ein gutes Gespür dafür, was funktioniert und was nicht. Wenn etwas nicht klappt, liege es meist an einem ernsthaften Fehler – nicht an Unwissen.

Ein vorheriges Problem im Nether wurde thematisiert, das zunächst nach einem Kompetenzproblem aussah, aber in Wahrheit auf ein unbekanntes Hindernis zurückzuführen war. Es wurde erkannt, dass das Problem weiterhin bestehen bleibt und sich nicht ohne Weiteres lösen lässt. Der Streamer bemerkte zudem einen neuen Fehler in seiner aktuellen Schaltung, was typisch für Redstone-Projekte sei. Dennoch blieb die Motivation hoch, da die Idee funktionieren würde.

Feinschliff an den TNT-Dubern und Target-Repeater

04:29:21

Nachdem einige Komponenten fehlten, wurde getestet, ob die Schaltung ohne sie noch funktioniert. Der Streamer stellte fest, dass sie weiterhin läuft und gezielt ein Trigger-Signal abgeben kann. Mit diesem Signal lassen sich verschiedene Aktionen auslösen. Er experimentierte mit Targets und Repeater-Linien, um die Logik zu vereinfachen. Gleichzeitig wurde festgestellt, dass einige Materialien knapp sind, was geplante Erweiterungen bisher verzögert.

Der Streamer sprach offen über die Emotionen, die beim Bau von Redstone-Konstruktionen entstehen. Einerseits das tolle Gefühl, wenn alles funktioniert und die Kettenreaktionen perfekt ablaufen. Andererseits aber auch die Frustration, wenn Dinge nicht wie gewünscht funktionieren. Er betonte jedoch, dass beides Teil des Prozesses sei. Das endgültige Ergebnis mache alle Mühe wert, und das Erlebnis der perfekten Ausführung sei unbezahlbar.

Für die nächste Stufe der Schaltung wurden vier leere Wassereimer benötigt. Der Streamer bat um Unterstützung im Trading Hall, um diese zu beschaffen. Nach einigem Hin und Her wurde klargestellt, dass es um vier echte Wassereimer ging. Diese würden später in Dispensern eingesetzt, die Wasser aufnehmen oder abgeben können. Gleichzeitig wurde überprüft, ob alle vorhandenen Komponenten korrekt positioniert waren, da ein kleiner Bau-Fehler entdeckt wurde.

Feinabstimmung der Verzögerungen mit Repeatern

04:34:08

Die Verzögerungen in der Schaltung wurden mit Repeatern eingestellt. Der Streamer betonte, dass alle Repeater auf maximaler Stufe stehen müssen, damit die Timing-Kette korrekt funktioniert. Nach einigem Zählen stellte sich heraus, dass genau sechs Repeater benötigt wurden – nicht fünf. Dieser kleine Fehler hatte zuvor zu einer unnötigen Verzögerung geführt. Nach der Korrektur wurde ein Trockentest durchgeführt, der alles bestätigte.

Nachdem alle Verzögerungen korrekt eingestellt waren, wurde die Schaltung Schritt für Schritt getestet. Zuerst feuerte ein Dispenser, dann die anderen. Jeder einzelne TNT-Duper löste seine Sequenz aus, bis schließlich alle fünf hintereinander feuerten. Der Streamer jubelte: „Geil! Hat funktioniert!“ Der erfolgreiche Test markierte einen Meilenstein im Bau der komplexen TNT-Kettenreaktion. Alles war like clockwork – bis auf ein kleines Detail.

Der Streamer erklärte, dass später eine Bergwand hinzukommt, in die die TNTs Löcher sprengen. Zudem plant er, die Mechanik so zu modifizieren, dass sie zwei verschiedene TNT-Höhen abfeuert – einmal hoch, einmal tiefer. Dies würde die Fläche noch effizienter abdecken. Er betonte, dass dies alles machbar sei, aber noch weitere Anpassungen erfordern würde. Dennoch sei die aktuelle Version schon beeindruckend und ein großer Schritt vorwärts.

Integration von Triggern und Signalverzweigungen

04:38:38

Ein neues Feature soll es ermöglichen, ein Trigger-Signal abzulenken, das erkennt, ob die Haupt-Schaltung bereits einmal gelaufen ist. Dadurch könnten zwei unterschiedliche Aktionen ausgeführt werden – abhängig davon, ob die Schaltung gerade aktiv ist oder nicht. Der Streamer testete dies live, indem er Blöcke und Redstone-Signale anpasste. Glücklicherweise funktionierte die Schaltung weiterhin stabil, was ermöglicht, dass externe Trigger nahtlos integriert werden können.

Während eines Tests trat ein Problem auf, das auf einen User-Error zurückzuführen war. Der Streamer drückte den Auslöseknopf zu schnell hintereinander, was dazu führte, dass die Schaltung nicht korrekt reagierte. Obwoohl die Technik grundsätzlich funktionierte, verursachte die Mehrfacheingabe einen Fehler. Der Streamer witzelte: „Twitch ClipNet!“ und erklärte, dass dies typisch für Redstone sei. Es sei wichtig zu lernen, mit solchen Situationen umzugehen.

Obwohl der Stream endete, wurde klar, dass die Schaltung noch weiter gebaut und verfeinert werden wird. Der Streamer betonte, dass die Grundidee funktioniert hat und das Konzept valide ist. Für kommende Streams, insbesondere am Freitag, war ein weiterer Bau geplant. Zudem wurde angekündigt, dass am Wochenende ein besonderer Geburtstags-Stream stattfinden könnte. Der Stream endete mit einem Raid auf einen anderen Streamer und einem finalen Gruß an die Community.

Abschluss des Streams – Reflection und Outlook

04:43:08

Zum Abschluss des Streams wurde reflektiert, dass Redstone-Bau nicht immer geradlinig verläuft. Es gehören Frustration, Fehler und Überraschungen dazu – aber auch Freude und Stolz auf das Ergebnis. Der Streamer betonte, dass das Team gut zusammengearbeitet habe und dass die Community-Feedback stets hilfreich sei. Er kündigte an, dass der nächste Stream am Freitag stattfinden würde, wo die Schaltung weiter verfeinert und erweitert werden soll. Gute Nacht wurde ausgesprochen.