Redstoneclock

[Blakwindo]

Wie baut man eine redstonecloc,die mit allen Redstone Items kompatibel ist,und sehr schnell ist?

[Tuxcraft32]

Redstone Items kompatibel

Ich versteh' nicht, was du damit meinst.

Ansonsten mit Command Block:

CMD-Block setzen und reinschreiben:setblock ~ ~ ~1 redstone_block 0 destroy

Ohne:

Hier kannst du dir die für deine Aufgabe am besten geeignete raussuchen.

LG

[Corona]

mit einem commandblock wo dieser command drinsteht: "/setblock ~ ~1 ~ minecraft:redstone_block 0 destroy"

Tuuuuux ._.

bearbeitet 22. Februar 2014 von Corona

[Derya001]

@Blakwindo hast du eine genaue Vorstellung was du mit der Clock machen willst, oder suchst du nur allgemein eine?

[LordRazen]

mal so ein tipp: die meisten redstoneclocks die "sehr schnell" sind sind ineffizient da sie nach kurzer zeit buggen.

nimm ne trichterclock, die ist schnell und bugfrei...

[Derya001]

nimm ne trichterclock, die ist schnell und bugfrei...

Das stimmt so nicht, Trichterclocks haben einen ganz entscheidenen Bug, welcher allerdings nicht vielen bekannt ist. Wenn ihr eure Welt bzw euren Server genau zu dem Zeitpunkt stoppt, an dem der Server gerade den Übergang des Items in den anderen Trichter berechnet, dann kann es passieren dass das Item doppelt in die Welt-Daten geschrieben wird, und sich somit beim Neustart des Servers/der Welt auf einmal 2 Items in der Trichterclock befinden, was dann natürlich ein fehlerhaftes Output auslöst.

Das ganze ist mir schon sehr oft passiert, ist sehr nervig weil man nicht genau weiß warum die Clock aufeinmal andere oder garkeine Impulse mehr sendet, was in einer großen Schaltung sehr verwirrend sein kann.

bearbeitet 19. April 2014 von Derya001

[LordRazen]

ui, gut zu wissen!

Gottseidank hab ich kaum welche...

[Derya001]

Dazu kommt noch dass Java es nicht auf die Kette bekommt die Trichter richtig zu berechnen. Schaltet man mehrere Trichterclocks in eine Reihe, startet alle gleichzeitig und sieht sich dann die Outputs an, so kann man feststellen dass diese völlig unregelmäßig ausgegeben werden, obwohl Sie eigendlich völlig synchron zueinander sein sollten. Je mehr Belastung der Server hat, desto öffter tritt dieses Phenomen auf, woraus man schließen kann dass Trichter nicht gerade den höchsten Stellenwert in der Berechnungsabfolge haben, da andere Mechanismen (Pistons, normale repeater-clocks usw) weiterhin synchron laufen.

bearbeitet 23. April 2014 von Derya001

[PsychoGear]

Jaja, mit Java-Fehlern auf überlasteten Servern kennen wir uns ja mittlerwiele (leider) schon ganz gut aus

Was die Clock angeht... Es kommt wirklich darauf an, was mit "kompatibel" gemeint ist. Wenn es bedeutet, dass alle angeschlossenen Items/Blöcke so funktionieren sollen wie es vorgesehen ist, dann muss das Signal in der Clock mindestens 2 Ticks lang sein und darf höchstens alle 5 Ticks wiederholt werden.

Ansonsten brennen angeschlossene Fackeln durch.

Ausser wenn das Eingangssignal durch einen relativ bekannten Glitch von einer Fackel erzeugt wird. Dann kann das Signal auch 1 Tick lang sein.

[Derya001]

Ich sage nur: "Warum zum *** geht diese *** Tür nicht zum richtigen Zeitpunkt auf???"

Als wir an unserem 3D-Scanner gearbeitet haben wurde unser Verständiniss von Logik und Zeitlichen Abfolgen komplett auf den kopf gestellt. Java hat damals einen Redstone-Kreislauf, der jedesmal gleich ablaufen müsste, nicht jedes mal gleich berechnet. Reapeater umstellen hat nicht die Bohne geholfen, Java hat sich einfach sein eigenes Ding zusammenberechnet, und uns fast an den Rand des Wahnsinns getrieben...