-.-

Hmm komisch.. Als ich die untersucht hab, haben einige ihre Items bis zu 5 Ticks lang behalten.

Ja ich würde nur an den betroffenen Stellen eingreifen, man kann aber natürlich auch einfach jedes Item "absichern". Zudem mache ich am Anfang eine Schaltung hin, damit der erste Hopper immer einige Ticks wartet zwischen den Itemabgaben. Ansonsten gibt es Stau bei den eingebauten Reparaturen.

Zitat von roflloler

Hmm komisch.. Als ich die untersucht hab, haben einige ihre Items bis zu 5 Ticks lang behalten.

Ja ich würde nur an den betroffenen Stellen eingreifen, man kann aber natürlich auch einfach jedes Item "absichern". Zudem mache ich am Anfang eine Schaltung hin, damit der erste Hopper immer einige Ticks wartet zwischen den Itemabgaben. Ansonsten gibt es Stau bei den eingebauten Reparaturen.

Wie gesagt, hab ich von dieses Problem in einem anderen Forum gelesen. Die Fehlerbeschreibung in dem Thread passte irgendwie auch zu dem Problem, daß ich mit meiner Maschine hatte.
Daraufhin habe ich erstmal weitere Bauweisen ausprobiert (habe in den letzten 14 Tagen die Maschine mehrfach abgerissen und neu gebaut) Flip-Flop Bauweise,Überlaufschutz mit 3 Block langem Signal,mit 2 Block langem Signal und abstand zwischen den Kisten und ganz ohne Überlaufschutz.
Das Problem besteht bis Heute und mein Lösungsansatz war, einfach die Items die nicht gefiltert werden am Schluß von Hand zu sortieren
Auserdem konnte ich Beobachten, daß wenn man den Trichter, der Streikt, solange abreißt und neu setzt bis er geht, plötzlich ein anderer Tricher den Dienst verweigert, weshalb ich diese Methode nur kurz versucht habe.

@roflloler Deine Sicherung würde mich brennend interresieren auch wenn dies bedeuten würde wieder alles abreisen, Platz nach oben schaffen und neu bauen.
Eine Itemdrossel habe ich auch gleich bei der Eingangskiste aber die brauch ich sogar im Singleplayer da die Maschine sonst nicht sauber läuft, müßte ich sowas dann vor jeden Trichter setzen?

Und noch eins an alle die schreiben "sortiert doch von Hand".
Ja natürlich geht das, aber ich wollte mal was neues lernen und bauen. Redstone ist für mich noch immer Neuland und so eine Sortiermaschine ist ein nettes Übungsobjekt.
Also ich will eine solche Maschine nicht weil ich zu Faul bin sondern weil ichs kann (wenn ichs denn mal kann).

Zitat von _Malaclypse_

@roflloler Deine Sicherung würde mich brennend interresieren auch wenn dies bedeuten würde wieder alles abreisen, Platz nach oben schaffen und neu bauen.
Eine Itemdrossel habe ich auch gleich bei der Eingangskiste aber die brauch ich sogar im Singleplayer da die Maschine sonst nicht sauber läuft, müßte ich sowas dann vor jeden Trichter setzen?

Und noch eins an alle die schreiben "sortiert doch von Hand".
Ja natürlich geht das, aber ich wollte mal was neues lernen und bauen. Redstone ist für mich noch immer Neuland und so eine Sortiermaschine ist ein nettes Übungsobjekt.
Also ich will eine solche Maschine nicht weil ich zu Faul bin sondern weil ichs kann (wenn ichs denn mal kann).

Meine Lösung wäre der Überlaufschutz mit 8 Ticks, habs auch mit weniger versucht, aber da keinen Erfolg gehabt. Der Abstand zwischen den Truhen ist nicht prinzipieller Natur, sondern kommt daher, dass ich noch an einem kompakteren Überlaufschutz arbeite

Kann es sein, dass durch die künstlich schnelleren Ticks der Server nicht die Zeit hat für alle Hopper zu prüfen,ob sie ein Item ansaugen oder weitergeben müssen?
Das würde erklären, wieso die einen immer verpennen^^ auch wenns komisch ist, dass sie immer relativ genau 4-6 Ticks verpennen (als würde es einen Mastertick geben, den keiner verpennt)

Es gilt ja schon noch 1 "Hoppertick" = 1 Redstonetick = 2 Gameticks , da wurde nichts auseinander genommen/neueingeführt?
Um wieviel wurden die Ticks erhöht?

edit:
1 RSTick ist natürilich = 2 Gameticks Sry für die Verwirrung

Ach so

Und fürs Ansaugen wurden die Ticks genau gleich verändert? Das ist ja das was nicht richtig funzt soweit ich das beurteilen kann.

Edit:
Langsam kapier ichs auch noch die "Transfer Cooldown Time" wurde auf 24 Gameticks = 12 Redstone Ticks erhöht

Das lässt allerdings die Suche nach der Ursache neu beginnen..

Nein, so einfach werden di nicht wieder funktionieren denke ich.

Habe wohl den Unterschied zwischen Server und SP gefunden (Screenshot). Das würde für mich erklären, wesshalb Hopper verpennen können, aber noch nicht, dass immer/oft die selben verpennen

[Blockierte Grafik: http://tapatalk.imageshack.com/v2/15/02/03/92b7df2a1e1d92da13612071d4126fe5.jpg]

[Blockierte Grafik: http://tapatalk.imageshack.com/v2/15/02/03/a82cdfc701ed8b4cf265864ae287c844.jpg]

@melks komm bloß nie wieder on ich schulde dir nen stack glowstone

Zitat von Soulseller

wenn du mit einsaugen das meinst wo du item auf nen hopper schmeißt und der ihn dann einsaugt, dann ist das gleich geblieben

Das Problem mit dem Hopper existierte auch schon vor der Veränderung. Wie gesagt wenn überhaupt hat es dem Bug entgegen gewirkt, da nun die Hopper mehr "Zeit" haben zu checken wo das Item hin muss

Jo genau das mein ich mit Einsaugen. Und auch das Abchecken von oberem Inventar. Bei der Sortiermaschine leitet ja (wenn Richtiges Item an richtiger Stelle angekommen) nicht der obere Hopper das Item weiter, sondern der untere checkt dem oberen sein Inventar und ziehts im raus.

Wie habt ihr die hopper-alt-ticking Einstellung (default: false)? die wurde ja mit dem Zweck eingeführt, wieder Hopperverhalten wie in Vanilla zu simulieren, saugt allerdings an der Performance, wenn über die Hälfte der Hopper arbeitet.

Gibt es iwo den Source Code der innersten Schlaufe (der Code, der bei jedem Tick ausgeführt wird)? Am besten unkompiliert, ich hab keine Java im Kopf und lese auch schlecht Maschinensprache

Ps. an der Serverperformance kann das Problem nicht liegen, hab es auch, wenn ich ganz alleine on bin.. Also wird es iwo im Code oder Einstellungen liegen.

Zitat von Soulseller

halt die itemweitergabe, von einem Hopper zum nächsten.
wenn du mit einsaugen das meinst wo du item auf nen hopper schmeißt und der ihn dann einsaugt, dann ist das gleich geblieben

Das Problem mit dem Hopper existierte auch schon vor der Veränderung. Wie gesagt wenn überhaupt hat es dem Bug entgegen gewirkt, da nun die Hopper mehr "Zeit" haben zu checken wo das Item hin muss

Mit einsaugen ist in diesem fall der Trichter gemeint, der die items "sortiert".
Also oben in der "Führungslinie" laufen die items waagerecht und der "Filtertrichter" soll das jeweils passende item, senkrecht aus der Führungslinie saugen.
So wie ich das verstanden habe funktionieren die Maschinen deshalb, weil das Saugen nach unten eine höhere Priorität hat als das seitliche Saugen.

@Serverbetreiber und alle die davon was verstehen.
Handelt es sich denn um den Bug, der in meinem gepostetem Link beschrieben wird?
Wenn ja, besteht die Möglichkeit die dort beschriebenen Einstellungen in der Spigot.yml anzupassen?
Also z.B. "hopper-alt-ticking" auf "true" setzen usw.
Wenn ich Souls Post richtig verstanden habe laufen die Trichter jetzt schon langsamer als in dem Lösungsvorschlag angegeben, also scheint die Geschwindigkeit nicht das einzige Problem zu sein.

Würde mich über eine Antwort. von jemandem der sich mit sowas auskennt und auch Einblick in die Einstellungen hat, sehr freuen.

Zitat von _Malaclypse_

@Serverbetreiber und alle die davon was verstehen.
Handelt es sich denn um den Bug, der in meinem gepostetem Link beschrieben wird?
Wenn ja, besteht die Möglichkeit die dort beschriebenen Einstellungen in der Spigot.yml anzupassen?
Also z.B. "hopper-alt-ticking" auf "true" setzen usw.
Wenn ich Souls Post richtig verstanden habe laufen die Trichter jetzt schon langsamer als in dem Lösungsvorschlag angegeben, also scheint die Geschwindigkeit nicht das einzige Problem zu sein.

Würde mich über eine Antwort. von jemandem der sich mit sowas auskennt und auch Einblick in die Einstellungen hat, sehr freuen.

- Nein, der Bug aus dem Link bezieht sich vorallem auf zu schnelle Hopper im Weiterleiten, unsere sind zu langsam im Ansaugen (zumindest die einen)
- Ich vermute mal hopper-alt-ticking ist bereits auf true (so wie ich die Einstellung verstanden habe, und was ich beobachtet habe)
- Spigot.yml kennen unsere Admins und Megaro vermutlich im Schlaf^^ deshalb wenig Hoffnung auf weitere Optimierung da --> wir haben bereits die best möglichen Einstellungen