Es wurde ein neues Transportsystem für den Minecraft-Freizeitpark konzipiert. Eine Ringbahn mit vier Stationen und zwei Zügen in entgegengesetzter Richtung soll die Besucher im Park bewegen. Dabei wird ein zentraler Amor-Block und ein Ressource Pack mit einem Custom-Item-Modell als technische Basis eingesetzt.

Minecraft
00:00:00

Minecraft

Serverumbenennung und Streambeginn

00:00:00

Der Stream startet mit der Ankündigung einer Serverumbenennung von 'thejoecraft.net' zu 'Froglight'. Der Server bleibt derselbe, aber der Name wurde geändert, um die Infrastruktur unabhängiger zu gestalten und eine kleinere, persönlichere Community zu föhren. Nach technischen Verbindungsproblemen zum Server, die auf ein Herunterfahren zurückzuführen sind, gelingt es dem Streamer, die Verbindung wiederherzustellen und mit dem Hauptprojekt fortzufahren.

Konzept für eine Ringbahn im Freizeitpark

00:09:53

Das Hauptziel für den Stream ist die Planung und der Bau eines neuen Transportsystems im Minecraft-Freizeitpark. Anstelle des bestehenden Konzepts, bei dem sich nur die Umgebung bewegt, soll eine echte Ringbahn entstehen. Hierfür ist vorgesehen, die runde Insel des Parks mit vier Stationen (Nord, Ost, Süd, West) auszustatten. Zwei Züge sollen auf einer kreisförmigen Strecke in entgegengesetzten Richtungen fahren, um eine durchgehende Anbindung zu gewährleisten.

Technische Lösung mit Amor-Block und Modell-Anzeige

00:11:11

Die technische Realisierung der Ringbahn basiert auf einem zentralen, sich drehenden Amor-Block. Dieser Block fungiert als Motor und Anzeiger. Wenn ein Spieler in die Blickrichtung des Blocks blickt, wird an dieser Stelle (444 Blöcke entfernt) ein Zug-Modell als Partikelwolke angezeigt, die sich mit dem Block bewegt. Dieses Konzept wird erfolgreich getestet, um die grundsätzliche Funktionsfähigkeit zu demonstrieren, auch wenn die Performance bei der Darstellung der Wolke als zu schnell eingestuft wird.

Herausforderungen bei der Umsetzung mit Zug-Wagen

00:39:11

Während die grundlegende Rotations- und Anzeigetechnik funktioniert, ergeben sich erhebliche Probleme bei der Umsetzung mit einem vollständigen, begehbaren Zug-Wagen. Ein als Block-Entity oder Entität generierter Wagen würde in nicht geladenen Chunks verbleiben und nicht mit dem zentralen Amor-Block synchron bleiben. Die komplexen Anforderungen an das Spawnen, Bewegen und Entfernen der Wagen-Einheiten bei Annäherung oder Entfernung des Spielers stellen eine immense Herausforderung dar.

Wechsel zu Item-Modellen und Ressource Pack

00:43:23

Aufgrund der enormen Komplexität der Block-Entity-Lösung wechselt der Streamer den Plan. Statt einzelne Blöcke für den Zug zu verwenden, soll das gesamte Zug-Modell als einheitliches Item-Modell implementiert werden. Dies erfordert die Arbeit am Ressource Pack des Freizeitparks, um ein Custom-Model für einen Zug zu erstellen. Gleichzeitig wird eine bestehende, kaputte Technik der Wasserbahn als Testfall für die Item-Model-Implementierung genutzt.

Erfolgreiche Implementierung der Item-Models

00:55:29

Nach intensiver Recherche und Diskussion im Chat gelingt es dem Streamer, das Prinzip der Item-Models in Minecraft zu verstehen. Durch die korrekte Namensgebung der Model-Dateien (z.B. 'item_stamm_zu') und den Einsatz von Custom Model Data im Befehlsblock kann er ein erfolgreiches Item-Modell im Spiel platzieren und anzeigen. Dies ist ein entscheidender Durchbruch für das Projekt.

Reparatur der Wasserbahn als Nebeneffekt

00:57:39

Der Fokus auf das Ressource Pack und die Item-Models führt zu einem unerwarteten positiven Nebeneffekt: die reparatur der bisher defekten Wasserbahn. Da auch die Technik der Wasserbahn auf Custom Item-Models für ihre Körbe angewiesen ist, können die im Verlauf des Streams gewonnenen Erkenntnisse direkt angewendet werden, um die alte Attraktion wieder funktionsfähig zu machen und das Modell korrekt zu schließen.

Abschluss und nächste Schritte für die Bahn

01:03:51

Nachdem die technische Machbarkeit mit Item-Modellen bewiesen und die Wasserbahn repariert ist, fasst der Streamer den Plan zusammen. Zunächst wird ein provisorisches Zug-Modell (ein einfacher Baumstamm) für die Bahnen verwendet, um das System weiter zu testen. Langfristig ist der Bau eines eigenen, detaillierten Zug-Modells geplant, das später im Spiel als Ressource Pack bereitgestellt werden soll, um das Aussehen der endgültigen Bahn zu definieren.

Planungsphase und technische Herausforderung

01:07:13

Die Arbeit an der Freizeitparkbahn erfordert eine komplexe Planung. Insbesondere muss eine Lösung gefunden werden, wie fahrende Minecarts eingefügt und kontinuierlich bewegt werden können, ohne dass sie geladen oder entladen werden. Dies stellt eine erhebliche technische Herausforderung dar, die sorgfältige Überlegungen erfordert, insbesondere hinsichtlich der Dynamik der Minecarts und der Interaktion mit Spielern.

Lösungsansatz mit Armor Stands und Scoreboards

01:10:18

Um das Problem der persistenten Bewegung zu lösen, wird ein System mit Armor Stands als Markierungspunkte und einem Scoreboard zur Verwaltung der Entitäten entwickelt. Es wird geprüft, ob ein Spieler sich in einem bestimmten Radius um die Bahn befindet. Basierend auf dieser Prüfung wird ein neues Minecart gespawnt und teleportiert. Wird ein Spieler zu weit entfernt, wird der Wert im Scoreboard zurückgesetzt, wodurch das alte Minecart beim nächsten Laden des Bereichs automatisch gelöscht wird.

Implementierung und Performance-Optimierung

01:15:32

Die technische Lösung wird nun Schritt für Schritt umgesetzt und getestet. Es wird ein Kommando-Block-System erstellt, das dynamisch Minecarts erzeugt, teleportiert und löscht. Der entscheidende Vorteil dieses Systems ist die Performance-Optimierung: Minecarts tauchen nur in der Nähe von Spielern auf und werden, sobald diese sich entfernen, unsichtbar gemacht und aus der Welt entfernt. Dies verhindert Lade-Probleme und hält das Spiel flüssig.

Routenfindung und Entwurf der Parkbahn

01:43:36

Nachdem die grundlegende Technik funktioniert, konzentriert sich der Stream auf die konkrete Gestaltung der Bahntrasse. Es wird die ideale Höhe für die Fahrt festgelegt und die Route um den Park geplant. Die Bahn soll teils über Gelände führen, teils durch einen Bergtunnel. Die Trasse wird mit roter Wolle markiert, um den genauen Verlauf zu visualisieren und spätere Baupläne zu skizzieren. Die Entscheidung, ob es eine Schwebebahn oder eine U-Bahn wird, wird zunächst offen gelassen.

Ausgrabung der Trasse und Projekt-Backup

01:51:15

Um den geplanten Verlauf der Bahn besser beurteilen zu können, wird ein Befehl erstellt, der die Landschaft entlang der roten Markierung ausgräbt und so eine Schneise schafft. Dies gibt einen ersten konkreten Eindruck davon, wie die Strecke später aussehen könnte. Gleichzeitig wird ein Backup der Welt angefertigt, um diese wichtige Planungsphase zu sichern und spätere Änderungen rückgängig machen zu können.

Visualisierung und weitere Planungsschritte

01:54:06

Nachdem die Trasse ausgehoben wurde, werden die nächsten Schritte skizziert. Es wird darüber diskutiert, ob die Bahn auf Stelzen durch den Wald fahren oder eine unterirdische Alternative genutzt werden soll. Besonders der See stellt eine besondere Herausforderung für die Gestaltung dar. Abschließend wird eine Schienenführung aus Eisenstangen visualisiert, um den Fahrweg weiter zu verdeutlichen, bevor der Stream für den Tag beendet wird.