Leistungskriterien von Schaltungen

Jede Schaltung ist unterschiedlich. Dabei unterscheiden sie sich nicht immer von der Größe oder von der Geschwindigkeit. Es gibt einige weitere Faktoren und am Ende ist es die Entscheidung des Konstrukteurs, welche bevorteilt und welche vernachlässigt werden. Hier sollte am besten bei der Planung schon damit begonnen werden, die richtigen „Kriterien“ für die eigene Schaltung festzulegen, damit während der Konstruktion keine aufwendigen Umbauarbeiten nötige sind. Welche Kriterien es alles gibt und wie man diese erfüllen kann wird in Folgenden ausführlich erklärt:

 

 

Funktionsumfang

 

Klar, keiner braucht eine Maschine, die zu nichts in der Lage ist. Die Redstone-Maschine sollte mindestens eine vernünftige Funktion haben – alles andere kann als „sinnloses Blockgestapel“ bezeichnet werden. Auch ist die Frage an welchen Stellen man Platz für Anschlüsse vorsieht, um den Funktionsumfang später leichter vergrößern zu können. Aber dazu gleich mehr.

 

Methoden Fehler in Schaltungen zu verhindern:

 

• gleichartige Schaltungs-Teile und Module einmal entwickeln und dann mit WorldEdit kopieren
• regelmäßiger Test einzelner Module und / oder Harmonie mehrerer Schaltungen miteinander
• vorher überlegen, was man bauen möchte und wie die Schaltung inklusive Logik ungefähr aussehen muss

 

Um die Funktionalität auch langfristig zu gewährleisten, müssen ebenso Sicherheitseinrichtungen verbaut werden, wo man wieder bei den Eventualitäten und den Idiotensicherungen ist. Oft wird man beim Entwicklen immer wieder neue Sonderfälle erkennen, die von bösen Spielern ausgenutzt werden können und gesichert werden müssen.

 

Herangehensweise an den Schaltungs-Bau Schritt 1: Planung Eventualitäten / Sicherheitseinrichtungen

 

 

Geschwindigkeit

 

Ewig lange warten, bis die Maschine seine Funktionalität zur Geltung bringt, möchte keiner. Die auch als „Laufzeit“ zu bezeichnende Verzögerung, bis das Eingangssignal verarbeitet am Ausgang wieder herauskommt, gibt es fast immer. Diese muss jedoch in Grenzen gehalten werden.

 

Methoden Schaltungen schneller zu bauen:

 

• beste Methoden für Leitungswege verwenden (zum Beispiel Repeater-Straßen vermeiden)

 

 

Größe

 

Man kann „Taschenrechner“ in Minecraft nicht in Taschenformat nachbauen, sollte sich aber dennoch überlegen, wie das eine oder andere etwas kleiner realisiert werden kann. Im Einzelspieler-Modus und bei den meisten Servern (sofern überhaupt erlaubt) ziehen die Minecraft-Chunks einem sonst einen Strich unter die Rechnung. Denn nach einer gewissen Entfernung lädt Minecraft dummerweise oft die Welt-Abschnitte („Chunks“ genannt) nicht mehr, da für ihn keinen Spieler in akzeptabler Reichweite ist. Somit ist eine Redstone-Signalübertragung unmöglich. Auch anwendungsbedingte Größeneinschränkungen für den späteren Ziel-Ort laufen unter dieser Kategorie.

 

Methoden Schaltungen kompakt zu bauen:

 

• gezieltes Platzieren von Modulen, um die Leitungswege dazwischen so gering, wie möglich zu halten
• unnötige Blöcke entfernen

 

Aber nicht, weil eine Schaltung laut Längen-, Breiten- und Höhen-Angabe etwas groß erscheint, muss es gleich größer sein, als eine andere Variante. So gibt es zum Beispiel in der Digitaltechnik Rechenmaschinen, die nicht kubisch-ähnliche Formen haben, sondern vielleicht schräg konstruiert wurden. Als eine Unterform solcher Größen-Leistungen gibt es Schaltungen, die in der Mehrheit durchschnittlich kleiner sind, als ein einzelnes alleinstehendes Modul: die „stackbaren Schalten“:

 

Stackbarkeit

 

Man kann Schaltungen so bauen, dass sie gestackt – also mehrmals hintereinander kopiert – werden können, ohne dass die zweite Kopie von der ersten beeinflusst wird. Ziel der Stackbarkeit ist es mehrere Module möglichst eng hintereinander bzw. nebeneinander zu bauen. Hier wird das letzte Stück Luft, wie bei einem Reißverschluss ausgenutzt: wo auf der einen Seite eine Ausbuchtung gebaut werden muss, bedarf die gegenüberliegende Seite der Schaltung den nötigen Platz.

Auf vielen Kreativ-Servern hat man als Spieler (sofern man über die nötigen Rechte verfügt) die Möglichkeit mit dem Befehl //stack <Anzahl> die ausgewählte Fläche so oft in Blickrichtung zu kopieren, wie man möchte.

 

 

Lautstärke

 

Die Lautstärke spielt bei manchen Anwendungen eine entscheidende Rolle: In einer RPG-Map mit designtechnischen Konstruktionen ist sie ein Teil der Atmosphäre. Hier möchte man – je nach Belieben – Lautstärke oder Ruhe haben. Bei Fallen kann sie einen Spieler im entscheidenden Moment akustisch warnen und damit deren Funktion verhindern. Gleiches gilt für Code-Schlösser. Wird irgendwo mit Notenblöcken gearbeitet, ist eine Nebengeräusch-Reduzierung Gold wert. In der Digitaltechnik dagegen geht es primär um die durch Kolben verursachte Client-Lags, die man verhindern möchte – hier ist die Lautstärke nur ein Nebeneffekt.

 

Nur zwei Blöcke in Minecraft tragen das Aussenden akustischer Geräusche als hauptsächliche Funktion: der Plattenspieler und der Notenblock.

 

Es gibt eine Anzahl an Redstone-Objekten, die oft genutzt werden und Nebengeräusche ausgeben. Die Verwendung zu vermeiden oder gerade zu bevorzugen, gilt es dann zu entscheiden. Beispiele hierfür sind:

• Kolben
• kurzschließende Fackeln
• leere Werfer und Spender
• Falltüren und Zauntore
• Loren

 

 

Herstellbarkeit im Überlebens-Modus (ohne Cheats / Tools)

 

Es gibt Schaltungen, da benötigt man Blöcke und Items bestimmter NBT-Daten, die man gar nicht im Überlebens-Modus herstellen kann. Auch das Setzen von Item-Mengen in Inventar-Blöcke mit einer Menge, die in diesem Spielmodus nicht möglich ist herzustellen, erfüllt dieses Schaltungs-Kriterium nicht. Des Weiteren kann man Blöcke, wie Redstone-Leitungen oder Schienen auch ohne Träger-Blöcke „setzen“ und Schaltungen damit ggf. etwas kompakter bauen. – Jedoch benötigt man dafür das Plugin „WorldEdit“ oder andere Modifikationen / Tools.

 

 

Herstellungs-Kosten und Herstellungs-Zeit

 

Für den Nachbau im Überlebens-Modus ist es ratsam sich über die Art und Anzahl der benötigten Blöcke einer Schaltung Gedanken zu machen. Manche Blöcke und Items sind schließlich einfacher / schneller herzustellen und benötigen billigere Ressourcen, als andere.

 

Zudem kann für ein Projekt ein Zeitrahmen gesetzt wurden sein, oder man legt sich selber ein gewisses Zeit-Buget fest, das man verwenden möchte. Für eine spontale Falle innerhalb eines Kampfes hat man zum Beispiel schließlich nicht 2 Wochen Zeit, um diese zu entwickeln.

 

 

Übersichtlichkeit

 

Das Genie beherrscht das Chaos!

(Albert Einstein, 14. März 1879 bis 18. April 1955, theoretischer Physiker)

 

Sieht man jedoch einmal in der eigenen Schaltung nicht mehr durch, kann es schnell zur Verwirrung und Missverständnissen kommen, was bei der Entwicklung zu verheerenden Fehlern führen kann. Die Wartungs- und Reparatur-Arbeiten verbrauchen viel mehr Zeit. Und wehe man soll einem außenstehendem die Schaltung genauer erläutern – dann wird es kompliziert! Lieber das ganze etwas übersichtlicher halten und dafür in Windeseile mit neuen Funktionen prahlen.

 

 

Gestaltungsgesetze der Warnehmung

 

Einige Methoden Klarheit zu schaffen beruhen auf die so genannten „Gestaltungsgesetze der Wahrnehmung“.

Unsere Wahrnehmung liebt die Einfachheit und Übersichtlichkeit und bevorzugt diese gerne gegenüber anspruchsvollen und komplexen Wahrnehmungs-Aufgaben. Unser Gehirn reduziert gerne wahrgenommenes. Manchmal ist dass sogar überlebenswichtig, um in Gefahrensituationen schnell durchzusehen und schnell handel zu können. Was Forschung und Wissenschaft hier zusammenstellt, lässt sich in die „Gesetze der Wahrnehmung“ zusammenfassen und diese sind auch für Schaltungs-Designer von Vorteil:

 

 

Die besten Methoden Übersichtlichkeit zu schaffen:

 

• Signal-Eingänge und Signal-Ausgänge beschriften (Leitungen, Hebel, Knöpfe, Lampen, etc. zu Beginn und am Ende), sowie das Bezeichnen der Schaltung an sich
• das Färben der Leitungen nach einem durchdachten Farbsystem (bestenfalls übereinstimmend mit dem anderer eigener Schaltungen)
• Abstand zwischen den einzelnen Modulen halten und zusammengehörigen naheliegend bauen ➔ (Gesetz der Nähe)
• einzelne, zueinander gehörende Bus-Leitungen gerade und parallel verlaufen lassen und Richtungswechsel beacht bauen ➔ (Gesetz der Parallelität, Gesetz der durchgehenden Linie und Gesetz der Kontinuität)
• parallele oder symmetrische Modul-Anordnungen für gleiche oder ähnliche Module bevorzugen ➔ (Gesetz der Parallelität und Gesetz der Symmetrie)
• ggf. Module (farbig) umrahmen ➔ (Gesetz der Geschlossenheit)
• gleiche und zusammengehörige Schaltungensteile gleich bauen ➔ (Gesetz der Gleichheit)
• unnötige Blöcke entfernen
• ggf. Farb-System, Module oder Leitungen beschriften

 

 

Wartungsfähigkeit

 

Wie im vorherigen Kriterium angemerkt ist, zieht die Übersichtlichkeit die Wartungsfähigkeit nach sich. Jedoch können auch unübersichtliche Schaltungen Wartungsfähig sein, in dem zum Beispiel irgendwo im Chaos ein freier Raum für die Wartung der wartungslastigsten Schaltungselemente herrscht – also eine leichte Zugänglichkeit besteht.

 

 

Kompatibilität mit Minecraft Versionen und Server-Systeme

 

Es gibt bei den vielen Blöcken, Items und Befehlen in Minecraft einige Funktionen, die eher unlogisch als nachvollziehbar sind. Manche davon sind von den Spiele-Entwicklern von Minecraft gewollte, manche wurden als Spiel-Fehler (auch „Bug“ genannt) deklariert und bei manchen ist man sich nicht so sicher. Zudem gibt es einige Fehler, die schnell behoben wurden, während andere Fehler über Minecraft Versionen hinweg bestehen bleiben. Und das in jeder Minecraft-Version aufs neue.

Insgesamt kann man sagen, dass alle Minecraft Survival-Anwendungen und Mechanismen eine eher geringere Kompatibilität mit anderen Versionen haben. TNT-Kanonen zum Beispiel schießen in jeder Minecraft Version völlig unterschiedlich weit oder müssen sogar komplett neu konstruiert werden. Auch das Verhalten von Mobs ist nicht in jeder Version genau gleich und in der 1.13 zum Beispiel wurde das komplette Wasser-Verhalten umgeändert, sodass es nun auch durch viele Blöcke fließen kann. Ganz geschweige von jeglichen Änderungen der Vanilla-Befehle in jeder neuen Version. Die Schaltungen aus der Digitaltechnik dagegen sind eher stabiler und funktionieren meist in nachfolgenden Versionen völlig problemlos. Digitale Schaltungen werden eher mit logischen Redstone-Signalübertragungen gebaut und Spielmechaniken von wenigen Redstone-Blöcken, die sich teilweise über viele Versionen hinweg nicht mehr geändert haben. Jedoch gibt es auch hier Schaltungen, die zum Beispiel besonders schnell oder klein sind, weil man zusätzlich ganz spezielle Spiel-Eigenheiten ausgenutzt hat. Hier muss man mit jeder neuen Minecraft-Version wieder damit rechnen, dass diese nicht mehr funktioniert, weil die genutzten „Spiel-Fehler“ behoben wurden.

Oder aber man muss davon ausgehen, dass die im Einzelspielermodus funktionierende Schaltung auf einem Minecraft-Server nicht mehr so, wie geplant, funktioniert. Eine Serversoftware arbeitet mit Minecraft zusammen, muss aber einige Dinge mehr berücksichtigen und berechnen, sodass sich minimale Unterschiede beim Verhalten und Updaten der Minecraft-Spielwelt ergeben. Hat man auf einem Minecraft-Server also eine unlogische Eigenschaft einer Schaltung entdeckt, sollte man dies im Einzelspieler nachstellen, bevor man von einer Minecraft-Bug ausgeht. Zudem gibt sie und die damit nutzbaren Server-Plugins eine unendliche Menge an Einstellmöglichkeiten her, die sich auf die Spielmechanik und damit negativ auf die Schaltungs-Funktionalität auswirken können. Damit ist auch erklärt, wieso manche Schaltungen auf dem einen Server funktionieren und auf dem anderen nicht. Auch dies alles betrifft eher Survival-Anwendungen und Mechanismen, als digitale Schaltungen.

 

 

Mojang.com – Ticket-System zum Melden von Spiel-Fehler: bugs.mojang.com/projects/MC/issues

 

Minecraft-Wiki (DE) – in Updates enthaltene Änderungen & Neuerungen für z.B. 1.13.1: minecraft-de.gamepedia.com/Versionen/Vollversion_1.13#1.13.1

Minecraft-Wiki (EN) – in Updates enthaltene Änderungen & Neuerungen für z.B. 1.13.1: minecraft.gamepedia.com/1.13.1

 

 

Rotations- und Spiegelungs-Unabhängigkeit

 

Das Spiel läuft mit 20 Minecraft-Ticks pro Sekunde. Wenn innerhalb eines solchen Ticks mehrere Updates gleichzeitig stattfinden müssen, ist die Position / Rotation des Blockes bzw. der Signaleingänge und Signalausgänge entscheidend, was dann intern von Minecraft zuerst berechnet wird. Das führt dazu, dass manche Schaltungen nicht mehr in bestimmten Rotationen oder in der spiegelverkehrten Variante funktionieren. Dies ist zudem nicht leicht mit den Problematiken der Reihenfolge der Update-Berechnungen zu unterscheiden, die durch die Positions-Abhängigkeit entsteht, wie es nachfolgend beschrieben wird.

 

YouTube Video „Redstone Dust Update Order“ by Earthcomputer: youtu.be/2mjZuWJDB0k

 

 

Positions-Unabhängigkeit

 

Wird das erste Mal eine Welt generiert, erhält jeder Block in der Welt eine Nummer, die der Priorität entspricht und entscheidet, wann im selben Minecraft-Tick dieser eine Block in der Welt geupdatet wird. So kann es vorkommen, dass der Redstone-Block auf dem ich mich befinde im selben Tick später aktualisiert wird, als der Block in 20 Blöcken Entfernung. Technisch gesehen wird sowas mit sogenannten „HashSets“ realisiert.

 

Dies ist ein technischer Umstand, der performancetechnisch nötig ist, um in allen geladenen Chunks jeden Block zu updaten. Zwar wurde es aufgrund der Tatsache, dass es nun mal für den Spieler nicht erwartet wird, als „Bug“ bei mojang.com gemeldet, jedoch sieht es nicht so aus, als ob die Spieleentwickler da noch irgendwas dran ändern möchten. Man kann nun mal nicht alles gleichzeitig aktualisieren.

Bug-Report auf bugs.mojang.com: bugs.mojang.com/browse/MC-11193

 

Ebenso gibt es wohl ein solches Priorisierungs – HashSet für das Laden und Entladen der Chunks. Dies führt aber bei Schaltungen eher selten zu Problemen. Von der 1.18 bis zur 1.12.2 bestand das Problem, dass Items beim Transportieren über Chunkgrenzen dupliziert wurden. Dieser Bug ist allerdings nun behoben worden.

(gefixt) Bug-Report auf bugs.mojang.com: bugs.mojang.com/browse/MC-79154

 

Welcher Block bzw. Chunk jetzt welche Priorität hat, ist allerdings nicht direkt von der Entfernung abhängig, sondern beruht auf einen Algorithmus, der schwer berechenbar und nachvollziehbar ist.

YouTube Video „Permanent and Remote Chunk Loading with Perma-Loader in Minecraft“ by gnembon: youtu.be/aeq5GZxRH9s?t=93 (startet bei 0:93)

 

weitere Videos:

 

YouTube Video „Redstone Update Issues and the Java HashSet“ by SethBling: youtu.be/Zt7YEYdx6RE

YouTube Video „Bugs and Ideas #03: Redstone Randomness and Lag“ by Panda4994: youtu.be/Zt7YEYdx6RE

 

 

Signal-Redundanz mit Minecraft Ressourcen-Management

 

 

Tile-Entity Maximum

 

Große Schaltungen mit zu vielen Blöcken, die bei Aktivierung Tile-Entities erzeugen müssen (z.B.: Repeater, Komparatoren, Redstone-Fackeln) können, unter dem Umstand auf dem Server über dem Limit zu liegen, nicht mehr vollständig funktionieren.

Technical Minecraft Wikia (EN) – Artikel „Tick“: technical-minecraft.wikia.com/wiki/Tick

Technical Minecraft Wikia (EN) – Artikel „Tile Tick Block“: technical-minecraft.wikia.com/wiki/Tile_Tick_Block

 

 

entladende Chunk

 

Chunks können sich entladen. Wenn die Schaltung sich in einem Chunk befindet, der sich entlädt, wird von Minecraft der sich darin befindliche Teil der Schaltung ignoriert.

Technical Minecraft Wikia (EN) – Kategorie-Seite „Chunks“: technical-minecraft.wikia.com/wiki/Category:Chunks

 

 

geringe client- und serverseitige Belastung

 

Bei einer laufenden Schaltung gibt es für dessen Berechnung, Blockaktualisierung und Darstellung auf Seite des Clients bzw. auf Seite des Servers einige Spiel-Elemente, die es ganz schön in sich haben. Spielelemente, die entweder zu viel RAM oder zu viel CPU-Leistung verbrauchen. Und wenn am Ende jene Stelle lagt und die Schaltung letzten Endes nicht wirklich genutzt werden kann ist das für niemanden vorteilhaft. Zumal im schlimmsten Fall der Spieler-Client oder der ganze Minecraft-Server abstürzen kann.

 

Lags können auf manchen Kreativ-Servern mit dem Befehl /tps überprüft und damit richtig zugeordnet werden. Es muss also nicht unbedingt am Server liegen, wenn man mit einem, für die Umgebung, mehr oder weniger schwachen Computer spielt.

Grund für Lags sind meist „Clocks“, also Taktgeber, die die leistungs-fressenden Spielelemente widerkehrend aktivieren. Auf einem Kreativ-Server, auf denen die die Spieler Redstone-Schaltungen bauen dürfen, sollte man daher zwar nicht Taktgeber allgemein verbieten, jedoch aber das dauerhafte Aktivieren dieser Taktgeber, um sich anhäufende Leistungs-Fresser zu vermeiden.

 

 

Redstone-Berechnung

 

= primär serverseitige Auslastung

 

Da eine Restone-Leitung nicht gleich deaktiviert wird, sondern von der Signalstärke bis zu 0 stufenweise herunterrechnen und die Umgebungsblöcke überprüfen muss, ist dies für den Server ziemlich ressourcen-lastig. Leitungen, die sich oft an und ausschalten sollten möglichst kurz gehalten werden. Zudem muss der Server weniger berechnen, wenn eine Leitung niedriger Signalstärke deaktiviert werden muss. Besonders große Redstone-Leitungs-Flächen sind zu vermeiden. Das Erhöhen der Redstone-Leitungs-Signalstärke ist weniger problematisch. Statt Redstone-Leitungen kann man auch Antriebsschinen mit Beobachter kombinieren. Hier können sogar Signalleitungen ohne Abstände direkt nebeneinander platziert werden.

 

 

Licht-Berechnung

 

= primär clientseitige Auslastung

 

Wenn sich bestimmte Schaltungs-Teile bewegen und das „Umgebungs-Licht“ aufgrund der neuen Block-Anordnung das darunter liegende Licht neu berechnen und anzeigen muss, ist das besonders für den Client sehr leistungsfressend. Des Weiteren senden ja auch einige Redstone-Objekte Licht aus: das sogenannte „Block-Licht“, was auch berechnet werden muss – hier aber in einem Radius. Auch hier gilt bei beidem: das Senken des Licht-Levels ist leistungs-fressender, als das Erhöhen.

 

 

Mob-Berechnung

 

= clientseitige und serverseitige Auslastung

 

Das Explodieren vieler TNT-Blöcke oder Mobs und Loren auf engem Raum sind nur ein paar Beispiele, die den Client und den Server stark auslasten. Der Grund dafür sind die Berechnungen für Blockupdates, Kollisionsberechnungen und Animations-Darstellungen (inkl. der Partikel).