Vanilla hoppers

Jag tror faktiskt att inställningen "ticks-per.hopper-check = 24" är fel. Skulle snarare varit "ticks-per.hopper-check = 3".

Men bästa är att återgå till standardinställningarna.

Inställningen "hopper-amount = 3" är det som ställer till det med craftern så den inte tar in items som tänkt från en hopper.

Det vore toppen om det gick att lösa!

Jag är ganska övertygad om att det skulle fungera rent tekniskt att bara köra så. Det skulle alltså inte visa så mycket annat än att det fungerar och det i sig har vi kanske ingen jättestor nytta av eftersom jag redan är övertygad om att det går. Det man skulle kunna göra är förstås att testa ändå bara för att se att det inte påverkar prestandan negativt, vilket det inte borde göra (detta är inte helt fastställt).

Grundproblemet finns dock kvar hur man än gör, alla konstruktioner som bygger på trattar som byggts på KC någonsin är anpassad och skulle behöva byggas om. Det räcker alltså inte med att några få vill genomföra denna stora förändring, en överväldigande majoritet måste vilja det. Jag har personligen inga väldigt stora invändningar om det skulle visa sig att "alla andra" vill ändra denna inställning.

Visa mig en konstruktion som går sönder av att återgå till standardinställningarna. En.

Jag har sagt det förut och jag säger det igen. Redstone har justerats med uppdateringar så spelare har ändå varit tvungna att uppdatera sina redstones efter en uppdatering, Hoppers borde inte vara något undantag när möjligheten finns att köra vanilla.

Men jag är öppen för att en omröstning genomförs i servern, så kan vi se hur spelare känner sig för en sådan justering.

så hur får vi det underlaget som du önskar? att en överväldigande majoritet vill ha ändrade inställning för trattarna? sätta upp en röstning om saken i t.ex discord kanske?

TraderPigskrev den 16 nov 2025, 16:57

Visa mig en konstruktion som går sönder av att återgå till standardinställningarna. En.

Kommer alla dina fungerande konstruktioner att fortsätta fungera utan ombyggnation efter en sådan ändring?

Nej, den typen av omvänd bevisbörda tänker jag inte ta på mig. Det har jag varken tid, ork eller kunskap för. Vad jag däremot kan göra är att, när det blir så dags, skruva på inställningarna på testservern så att de som vill där kan testa sina (omodifierade) maskiner för att utreda eventuella konsekvenser.

morpheus74skrev den 16 nov 2025, 16:58

så hur får vi det underlaget som du önskar? att en överväldigande majoritet vill ha ändrade inställning för trattarna? sätta upp en röstning om saken i t.ex discord kanske?

Det jag jag inte på rak arm svara på. En omröstning känns dock fel i nuläget eftersom det råder delade meningar om konsekvenserna och detta måste i så fall först utredas.

Jag ville bara se en konstruktion som inte kommer att fungera med normala hoppers.

Det är inte nån omvänd bevisbörda alls i detta.

En folkomröstning som visar vad folk anser är helt rätt!

Sen vill jag bara säga det att en folkomröstning inte automatiskt ska leda till förändring. Det kan finnas skäl som folk inte vet om. Kanske inte ska veta om?
Och då måste ledningen ha friheten att bestämma annat. För det är ju dom som får stå för konsekvenserna om det blir fel ju.

Dels finns det dom som är väldigt insatta, och som vet exakt vad förändringen innebär. Och dels dom som tror sig vara berörda, men som inte alls vet om dom kommer att få problem eller inte. Och sen finns det de spelare som helt enkelt inte bryr sig. Som inte kommer närmare rödsten än att hönga upp röda facklor i källaren.

En folkomröstning är på sin plats.

Men kanske ett första steg är att testa. Se27213 erbjöd sig ju ovan att skruva på inställningarna på testservern så att de som vill där kan testa sina (omodifierade) maskiner för att utreda eventuella konsekvenser.

Det låter som en mycket bra början.

Testa ska man göra innan designen är färdig i utvecklingsstadiet för att säkerställa kritisk funktion innan designen fastställs och därmed undvika att felet sprider sig till följande processer. En lärdom man får om man annars väljer den hårda vägen.

Jag har varken negativ eller positiv inställning till detta, mestadels för jag inte använder redstone till den nivån där det gör skillnad för mig.
Skulle det ändras till normala är jag dock absolut inte emot det då det är något jag sett komma upp flertalet gånger som folk vill ha tillbaka.

Att fixa det på testservern nu i samband med förberedningar för 1.21.10 låter som en väldigt bra ide så det kan utvärderas och informera spelare om innan det blir bestämt så folk har tid på sig att testa och se hur saker påverkas!

POWERofMUFFINSskrev den 16 nov 2025, 21:09

Testa ska man göra innan designen är färdig i utvecklingsstadiet för att säkerställa kritisk funktion innan designen fastställs och därmed undvika att felet sprider sig till följande processer. En lärdom man får om man annars väljer den hårda vägen.

Att bygga i en testvärld hjälper inte om den kör i vanilla inställningar, vilket är fallet för min del. Jag brukar oftast antingen ta ett befintligt bygge från YT eller ta fram något själv, testar i servern med bra resultat. Bygger i kottcraft, och resultatet blir betydligt sämre.

Detta gäller framförallt farmer där gruvvagnar har varit en nyckel i farmarna. Jag har en väldigt låg output av bläcksäck t.ex. pga. fel konstruktionen av mina farmer, efter att jag missade att trattarna här på KC fungerar annorlunda jämfört med vanilla.

Det vi vill testa i testvärlden är hur befintliga konstruktioner på Kottcraft funkar med vanilla hopper-inställningar.

Minecart -> Hopper funkar ju inte så bra. Största anledningen till det är att hoppers inte hinner reagera när vagnen rullar över. Man måste ha tre trattar i rad under rälsen för att garanterat plocka en enda item även om vagnen rullar sakta.

Vill du ha tips om hur du fixar tömning av hopper minecart till hoppers så säg till i spelet.

Nu har vi chansen att testa vanilla hoppers på testservern. Jippie!

Lite testresultat då.

Komposter med trattar:
Fungerar helt som den ska, och är då tre gånger snabbare än den är på Kottcraft idag.

-

Delning av flödet från en dubbelkista till två hoppers.
På KC så fördelas inte flödet mellan två hoppers från samma kista jämnt. Det blir lite hipp som happ.
Men på testservern så delas items upp exakt lika mellan två hoppers. Som det är tänkt att fungera.
Om detta fungerar så möjliggör det en enkel och effektiv array med två ugnar.

-

Delning av flödet från hopper som matas in med 2x hopper speed, och sen töms både neråt och till sidan fördelar inte jämnt vare sig på KC eller på testservern. Detta beror på Paper. Där en hopper tillåts mata ner en item samtidigt som en hopper under den drar ner en item. Vilket är ett frånsteg från vanilla-beteende.

-

Matning rakt neråt i hopperkedja går med dubbel hopper speed. Detta förekommer både på KC och på testservern. Det beror på hur hoppers är implementerade i Paper, och berörs alltså inte av KC's ändringar av hoppers.

-

Prioritering mellan att hopper under hopper drar items ur vinklad hopper, eller att den vinklade hoppern matar ut items åt sidan. Används bland annat i sorterare, och även med kistor stackade på varandra, där kistorna förväntas fyllas underifrån och upp.

Fungerar nästan jämt på Kottcraft. Ibland blir det fel. Detta beror på buggar i Paper. Men buggarna berörs av de ändringar som gjorts för hoppers på KC.

På testservern har det hittills fungerat helt rätt varje gång.

-

Etho hopper clock:
Fungerar likadant på KC som med vanilla, med en enda skillnad. Då hoppers på KC skickar 3 items samtidigt, men bara gör det på tredjedels fart så kommer klockan att arbeta på en tid som är nästan samma.

Om man på KC lägger i ett antal items, (typ pinnar), för att bestämma tiden, så blir tidscykeln mindre noggrann på KC jämfört med vanilla.
En pinne, eller två pinnar, räknas som om det vore tre.

Så det går att ange en noggrannare tid med vanilla hoppers. Men bortsett från det så blir tidscykeln samma.

-

Hopperklocka med två hoppers som kastar en pinne mellan varandra, och en komparator som läser av innehållet i en hopper. Denna klocka fungerar inte alls på Kottcraft, då den ger en klocka ut som är en tredjedel så snabb som den ska vara. Därför använder jag inte denna klocka alls på KC.
Men på testservern fungerar den precis som den ska.

-

ImpulseSV overflow protected stackable item sorter.
Detta är den vanligast förekommande sorteraren generellt i Minecraft.

Den går att få att fungera på Kottcraft. Men den är inte underhållsfri. Detta beror troligtvis på andra buggar. Då i servertillägget Paper. Det händer att hoppers helt slutar att fungera. Dom måste då knackas bort och sättas tillbaka för att börja fungera igen.

På testservern fungerar denna sorterare utmärkt. Har ännu inte lyckats provocera fram att en hopper slutar att mata. Men jag har svårt att se att den skulle bli helt fri från felfallen som är på huvudservern. Väntar fortfarande på att fel ska uppstå.

Jag har inte valt att testa den icke overflowskyddade versionen av ImpulseSV-sorteraren, då det inte är rekommenderat att använda den. Men jag är övertygad om att den fungerar på testservern eftersom den andra fungerar.

-

Mumbo Jumbo Unstackable Item Filter.
Denna fungerar inte alls på KC som det är nu.
På testservern fungerar den som den ska om man sätter dit en kista bredvid komparatorn. (Lösning från IlMango. En kista med en pinne i varje slot, och en hopper under med en sten i varje slot). Om man inte gör det så reagerar inte komparatorn alltid i tid. Detta är ett känt fel som är vanligt på servrar. I Paper finns denna bug som gör att komparatorer ibland reagerar för långsamt.

Jag har gjort ett synkront unstackable item filter som fungerar på KC. Denna fungerar precis lika bra på testservern. En nackdel med den är att den arbetar på tredjedels hopper speed, för att ta hänsyn till avstegen för hoppers på KC.

-

Allay-sorter.
Denna sorterare fungerar alldeles utmärkt på KC och så även på testservern.
Den tar tid att sätta upp, då man hanterar allays. Denna typ av sorterare kan även användas som unstackable item filter.

-

Furnace array med minecart som fördelar en item per ugn.
Detta har jag inte på något sätt fått att fungera som det ska på KC.
Men på testservern fungerar denna enkla lösning 100% perfekt.

Jag har kommit på en lösning med synkrona dropperkedjor som fungerar på KC. Men jämfört med en furnace array som använder minecarts så är denna konstruktion både mycket komplicerad och jättestor.

-

Frunocraft 6x hopper speed shulker unloader.
Fungerar utmärkt både på KC som det är nu, och på testservern.

-

Instant minecart unloader till vattenström, med ametistcluster och lavacauldron.

På KC så skickas minecarten aldrig i retur när den är tömd. Det beror på att hoppern reagerar alldeles för långsamt. Har man tur så ligger minecarten och väntar i dispensern och innehållet kommer i vattenströmmen.
Ibland förstörs minecarten i lavan.

På testservern så skickas minecarten i retur som den ska. Om den var tom. Men om den innehåller något så förstörs minecarten och/eller innehållet.

Kan sägas att detta inte fungerar alls på Paper. Då det är lite hit&miss vart innehållet i minecarten hamnar. Men en skillnad är att en tom minecart skickas tillbaka på rälsen som den ska på testservern.

-

IlMango vattenflaskpåfyllare.
Fungerar både på KC som det är nu och på testservern. Men den är tre gånger snabbare på testservern.

-

Vanlig enkel minecart loader och minecart unloader.

På Kottcraft så måste man lägga till en detector rail för att hoppern ska hinna plocka upp och registrera att den hämtar ut items från minecart i tid för att stoppa minecarten i avlastningsstället. Det är dessutom svårt att få minecarten att stanna i en backe över två hoppers så att avlastningen går dubbelt så fort. Detta fungerar utmärkt som det ska på testservern utan att lägga till en detector rail. Minecart loadern skickar iväg minecarten snabbare på testservern.

-

Vattenränna med hoppers under.
På KC så måste man ha tre hoppers i rad för att förhoppningsvis kunna plocka en item ur en vattenström.
Jag byggde ett litet test på testservern. En 8 block lång vattenränna med hoppers under.

Test 1: Slänga i en stack i första vattenblocket. Alldeles innan första hoppern.
Resultat: Första hoppern sög i sig hela stacken.

Test 2: Knäcka en kista med 27 stackar item i över första vattenblocket.
Resultat: Hopper 1 sög i sig kistan + 4 stackar och 39 items.
Hopper 2 tog emot 2 stackar + 63 items.
Hopper 3; 1 stack + 63 items.
Hopper 4; 1 stack + 60 items.
Hopper 5; 1 stack + 57 items.
Hopper 6; 1 stack + 54 items.
Hopper 7; 54 items.
Hopper 8 (utan vatten); 1 stack + 63 items.
Hopper 9 (utan vatten); 1 stack + 63 items.
Hopper 10 tog emot resten av stackarna då dom stannat.

En ganska dramatisk skillnad!
Det finns många vattenrännor på KC som har många hoppers för att ha en chans att suga upp items. Men allt sugs inte upp.
Med vanilla hoppers så tas lösa items om hand fort. Blir inte liggande och skapar lagg och sen eventuellt despawnar eller åker förbi en sorterare och bränns i lava.
Detta är nog i ganska hög grad beroende på den felaktiga inställningen av ticks.per-hopper.check till 24.

Detta är allt jag har testat hittills. Om någon kan visa på något som byggts på KC som skulle må dåligt av att återgå till vanilla hoppers så säg gärna till. Jag tittar gärna på ett sånt problem om det finns.

Lite mer testresultat:

Dags att titta på craftern.

Det är tänkt att om man matar en crafter med en hopper, så ska items fyllas på i craftern ett item i taget per slot. Börjar till vänster i översta raden. Fyller på till höger. Sen nästa rad. En item i taget.

Med nuvarande hopperinställningar på Kottcraft så läggs det i 3 items i taget i slottarna. Designen av craftern tar inte hänsyn till det, då den förväntar sig en item i taget.
Så för komplexa recept så kan inte craftern matas med en hopper.

Problem #2: När craftern har items ilagda så att ett fullt recept uppnåtts, och kan craftas, så ger den ut rödstenstyrka 9, som en komparator kan känna av och trigga craftern. Komparatorn ska då hinna stänga av signalen innan det matas in nya items i craftern. Detta funkar inte på KC, på grund av att servertilligget Paper inte hanterar timing av hoppers på korrekt sätt.
Detta problem löses inte av att återgå till vanilla hopperinställningar.
Signalen från komparatorn måste alltså generera en klocksignal så länge receptet är komplett för att det ska fungera.

Craftern kan alltid matas med en hopper på testservern, Men inte på KC med nuvarande hopperinställningar, för alla typer av craftingrecept. Då måste man använda en dropper att mata craftern med.

Däremot en crafter för exempelvis ben till benmjöl kan matas direkt med hopper, och sen bara ha en klocka som craftar hela tiden. Även med nuvarande hopperinställningar.

Det går generellt sett inte att bygga crafter utan en klocka på Kottcraft. Detta beror på hur Paper hanterar hoppers.

Detta gör att man inte kan bygga den minsta tileable craftern på KC på grund av att KC använder Paper. Något som skulle kräva synnerligen starka skäl att ändra på.

Om craftern däremot matas av t.ex en rökugn som torkar kelp, så levereras bara ett kelpblad per 10 sekunder. På testservern kan en crafter göras utan klocka, som matas med en hopper, som gör kelpblock.

De exempel på crafters som jag har satt upp så alla ska kunna se, fungerar precis lika bra både på vanliga servern som på testservern. Men de kan förenklas med vanilla hoppers.

Slutsats: Vanilla hopperinställningar gör det enklare att använda craftern. Men det löser inte alla problem.