Mening om, hvorfor jeg tror, at 1.20 skal være den endelige version af Minecraft. Diskussion – Minecraft: Java Edition – Minecraft Forum – Minecraft Forum,
For at frigive opdateringer, der massivt reducerer lagspidser på jævn pc’er med midten af niveau eller hardware frigivet i de sidste 5 år,
Minecraft -fora
[Mening] Hvorfor tror jeg, at 1.20 skal være den endelige version af Minecraft.
- Se brugerprofil
- Se indlæg
- Send besked
- Tree Puncher
- Deltag i dato: 11/1/2021
- Indlæg: 20
- Medlemsdetaljer
Der er et par forskellige grunde til, at jeg tror dette, i det mindste efter min mening. Her er mine top fem grunde til at.
-
Du skulle tro med et indie -studie som Mojang, de ville tilbyde mere meningsfuldt indhold end hvad vi faktisk fik. Dette beviser bare, hvorfor AAA -spil efter min mening altid vil være bedre end indie -spil, og det er ikke at kaste nogen skygge ved sidstnævnte. Men da jeg først købte dette spil (jeg fik faktisk Bedrock Pocket Edition først i julen 2012, for ti år siden, mens jeg fik den originale Java -udgave syv dage senere på den allerførste dag i 2013, 1. januar), forventede jeg meget mere fra den titel. At være en spiller, der har spillet som Lego -skaberen og Dino Island (ja, det spil eksisterer), forventede jeg virkelig Minecraft at udvide disse formler endnu mere, med evnen til fuldt ud at bygge både i form og funktion. Sjov kendsgerning: Jeg efterlod faktisk en gennemgang af Metacritic på Minecraft med angivelse af dets mangler for mindst to år siden, og jeg bliver nødt til at gå med Whitelhts mening om, at “du kan bygge alt, hvad du vil”, kun er halvt spor.
Jeg forventede at være i stand til at dreje blokke ved hjælp af motorer og håndtag og endda rotere sæt blokke for at skabe dynamik såsom store skibe og robotarme. Dog var dette desværre ikke tilfældet for mig. Ved at afbryde Minecraft efter 1.20, vi behøver ikke at bekymre os om funktioner, som vi faktisk ville have, at vi aldrig blev implementeret, fordi udviklingen ville have stoppet helt. Jeg tror, at Mojang fortjener en ferie, måske en permanent på det.
En anden funktion, der ikke kun blev “lovet” tilbage i 1.5, Redstone -opdateringen, men alligevel ikke leveret før 1.8, men selv da, var så svært at forstå, at du skulle tro, at det var brudt, var Minecart -kobling. For at tilføje fornærmelse mod skader er denne funktion helt fraværende i Bedrock Edition – min foretrukne udgave af Minecraft at spille på – og det samme er ovnen Minecart. Selvom det personligt er mere en velsignelse end en forbandelse, da der ikke er noget kompliceret at “lære” her, det ord, der bruges løst, fordi det er praktisk talt umuligt at finde ud af uden en guide eller YouTube -video.
Med andre ord, den grimme sandhed er, at indie -spil er baseret på en masse falske oplysninger, du måske kan se på nyhederne, eller se af, hvad du troede var en “god ven” af dig. Sandheden er, at AAA stadig er lige så god som nogensinde; De prøver stadig at finde nye ideer til deres spil og indhold. Ved at gå videre og afslutte Minecrafts udvikling den 1.20 kan spillet ikke kun betragtes som “færdigt”, som vi vil se i det sidste kuglepunkt, men vi behøver ikke at bekymre os om nogen skuffelse længere. Og som jeg sagde før, har spillet aldrig følt mig som en ordentligt poleret oplevelse her.
Generelt virker det som en skam, at Minecraft efter min ydmyge mening bør afslutte udviklingen med 1.20, men sandheden er, at mange af mine venner som Ryan og Mason er permanent gået videre fra Minecraft og har ikke set tilbage siden. Dette er fordi de har set lignende problemer med spillet ud over det, jeg lige har fortalt dig om, og jeg bliver nødt til at være enig med dem helhjertet.
Det er også værd. Mange tak.
-
“Minecraft fortjener at fortsætte med at blive opdateret, måske for evigt.” Dette fører til min ansvarsfraskrivelse: Jeg er personligt helt fin, hvis spillet stadig opdateres over 1.20; Jeg føler bare personligt, at Minecraft er bedre stillet til ikke at blive opdateret mere over 1.20. Hvis du ikke forstår, hvad jeg taler om, skal du læse gennem indlægget igen.
Rollback Post til revision af rollback
Order of the Stone – En modidee om, hvad Minecraft kunne have været, hvis det var blevet udviklet af et team med mere ekspertise; af professionelle udviklere og producenter.
- Se brugerprofil
- Se indlæg
- Send besked
- Enderdragon Slayer
- Deltag i dato: 10/6/2013
- Indlæg: 13.160
- Minecraft: THEMASTERCAVER
- Medlemsdetaljer
Jeg ved, at det er for at hjælpe med at forhindre folk i at pirere eller knække spillet gratis
Ironisk nok behøver du ikke engang at modere det faktiske spil for at pirat det – selve løfteraketten er det, der faktisk håndhæver det, enten ved at tilføje en “-demo” -parameter til spillet, hvis du ikke har købt det (sjov kendsgerning: versioner Før 1.3 Genkender ikke dette, så de faktisk giver dig mulighed for at spille det fulde spil – som endda dokumenteret på wiki – alle “knækkede” lanceringer skal gøre er at udelade dette for at lade enhver version spilles i ikke -DEMO -tilstand).
Hvad angår selve serveren, er det helt gratis at downloade (som alle spilfiler faktisk er – bare tjek https: // mcversions.net/, der direkte linker til filerne på Mojangs servere) – og der er faktisk en indstilling, der giver dig mulighed for at deaktivere online -godkendelse – som alt sammen er en “revnet” server faktisk er og er også klart dokumenteret på wiki og andre steder ( Hvorfor Mojang ikke har fjernet en så let udnyttet indstilling er uden for mig, jeg har hørt, at det er, at serveradministratorer kan komme videre, hvis de normalt ikke kan logge ind af en eller anden grund; som for før-1.3 versioner, de er måske bare ikke ligeglade, da de er så forældede, at de lige så godt kan være en afdæmpet demo-version, ellers kunne de bare forhindre dig i at ændre versioner, hvis du har en demokonto):
Hvis man prøver at spille en demoversion før 1.3 Fra launcher ved hjælp af en ikke-premium-konto kan de spille den fulde version. Dette er fordi 1.3 er den version, der tilføjede demo -tilstand til Minecraft, så tidligere versioner har ikke den nødvendige kode for at erkende, at de er i demoen.
Indstilling.
Således gør tilsløring bogstaveligt talt intet for at sikre spillet mod ulicenseret brug. Mit vigtigste problem med det er, at det gør (vanilje) crashrapporter umulige at forstå, medmindre du har adgang til deobfuscation -kortlægninger, eller en anden havde fundet ud af, hvad problemet er, eller fejlmeddelelsen er klar nok; Hvad betyder dette endda (division med nul – men hvor? Hvad er “lidt.b “?)
Java.lang.Arithmeticexception: / af nul
hos BLT.B (SourceFile: 814)
hos Bao.AK (SourceFile: 801)
hos Bao.F (SourceFile: 728)
på nettet.Minecraft.klient.hoved.Hoved.Main (SourceFile: 148)
Ellers har det ikke generet mig, siden jeg simpelthen stoppede med at opdatere kl. 1.6.4, med alt efter det dybest set et separat spil (hvis du overvejer, hvordan jeg version af mine egne mods, baseret på større opdateringer til verdensgenerering, 1.0.0-1.6.4 ville være “Minecraft 1.0 “, 1.7-1.17 er “Minecraft 2.0 “og 1.18+ er “Minecraft 3.0 “), så der er ikke noget problem med at skulle opdatere mods, som også skal opdateres på grund af interne ændringer i spillets kode; hovedårsagen til, at så mange mods stoppede med at opdatere eller var langsomme med at opdatere forbi 1.7.10 er ikke på grund af tilsløring, men på grund af større interne ændringer, det samme for 1.13.
Jeg tror heller ikke, det er korrekt at kalde Minecraft et “indie” -spil, det er ikke blevet udviklet af en enkelt person i godt over et årti (der er en undergruppe af spillere, der betragter versioner op til beta 1.7.3, når hakken stadig var dominerende, “gylden tidsalder”, med alt siden da gik i en helt anden retning end sin oprindelige vision). Andre betragter Microsoft Buyout som slutningen på indie -æraen; Ved denne foranstaltning 1.8 var den sidste “indie” -version (skønt jeg havde lagt den på 1.7 senest på grund af større ændringer i, hvordan spillet er kodet siden 1.8).
Rollback Post til revision af rollback
THEMASTERCAVERs første verden – muligvis den mest havede verden i Minecraft History – inkluderer verdens download.
THEMASTERCAVER’S WORLD – Min egen version af Minecraft stort set baseret på mine synspunkter på, hvordan spillet skulle have udviklet sig siden 1.6.4.
Hvorfor spiller jeg stadig i 1.6.4?
- Se brugerprofil
- Se indlæg
- Send besked
- Nyligt spawned
- Deltag i dato: 8/3/2012
- Indlæg: 1.830
- Minecraft: Princess_Garnet
- Medlemsdetaljer
Dit første punkt virker lidt overalt og forvirrer mig. Det virker næsten modstridende på nogle måder, så kan jeg bede om en vis klarhed?
Du siger, at Mojang er et indiefirma. Jeg er uenig med dette. Det er ikke helt indie længere. Mojang og Riot er to eksempler, der måske begge har været indiefirmaer i starten af 2010’erne, men ikke rigtig mere. Faktisk er en af de ting, du angiver på samme punkt vækst. Det er et separat emne på egen hånd, men virksomhedsstørrelsen er ikke lineært lige stor ændringspotentiale.
Alligevel angiver du, at Mojang er en lille virksomhed, er grunden til, at vi bør forvente hurtigere indholdsændringer. Dette kan også gå den anden vej. Mens indietitler måske er mere tilbøjelige til at tage risici (i modsætning til store udgivere, der tager den sikrere, mere fortjeneste sandsynligvis rute, hvilket resulterer i mindre originalitet), er det sjældent, at en fuldt poleret idé kommer ud af en indietitel, der perfektionerer en udvikling af den formel. Det er et meget højt spørgsmål, og jeg tror, du undervurderer gennemførelsen af Minecraft, alligevel. Dengang blev sådan noget ikke set før, og teknikken for det var ikke rigtig der før (i det mindste ikke på den måde Minecraft gjorde det). Der er en grund til, at et simpelt koncept med et simpelt look kom relativt sent.
Husk; Dette startede lige som et projekt af en person. Det sprang bare op. Du lægger mange forventninger til, hvad det skulle have været efter min mening.
Også en stor uenig om indie versus tredobbelt a. Indiescenen trives og har båret pc -spil det sidste årti eller deromkring, og derefter nogle. Triple A spil er blevet mere hit eller savner for mig over tid. Det er okay i de senere år, men tilbage, før ting som Steam virkelig muliggjorde større muligheder med indieudviklere, var spilmarkedet meget mere intetsigende og begrænset efter min mening. Jeg finder det meste af vægten af (efter min mening) nuværende velsignelse af pc -spil bæres af indie -segmentet, og det er ikke engang tæt på.
Jeg kan ikke tale meget til de modding/kodende dele af punkt to.
Hvad angår tre, er jeg uenig. Version 1.19 er temmelig berygtet for det (men det bliver også trukket ned af chat -tinget), men det til side er jeg uenig. Jeg siger ikke, at det aldrig skete bortset fra da, bare at jeg ikke tror, det var overhovedet et stort problem udover det ene punkt. Og Mojang har udtrykt læring af det den gang. Minecraft har en historie omtrent et dusin år med at fremstille. Der er uundgåeligt nogle ting, der er antydet på det tidspunkt, som ikke ender med at blive tilføjet. Det er bare uundgåeligt.
For punkt fire, enorme uenige, og jeg sagde ovenfor, da du nævnte dette ved åbningen af dit indlæg (jeg svarer, mens jeg læste det). Jeg spiller ikke på konsolsiden, hvis det hjælper med at forklare min holdning, men på pc -siden trives indie -spil, og efter min mening gennemgår pc. Triple A spil? Lad os se, genindspilninger, genindspilninger, fattige havne, samme formel igen og igen, flere dårlige porte, der får Minecraft til. Remakes osv. Og som dig “kaster jeg ikke skygge” på alle disse ting. Jeg har faktisk ikke noget imod den nylige “remake” boom. Der er en vis æra med spil (nemlig PlayStation/PlayStation 2 -æra, så slutningen af 1990’erne og begyndelsen af 2000’erne), der står for at vinde så meget fra remakes på grund af det faktum, at disse spil er i denne æra var mange af dem havde lav opløsning, ikke -Widescreen aktiver og alderen dårligt. Gå nyere og ting går hd/widescreen, og super gamle pixel ting ældes heller ikke lige så dårlige. Så der er begrundelse for genindspilninger. Jeg elskede genindspilningen af Resident Evil 2 (og endda til en vis grad 3, selvom den var undervejrende relativt). Begge er spil, jeg betalte fuld pris for foran, og det gør jeg ikke for tredobbelt A -spil ofte i disse dage. Mit største spil ønsker lige nu er den Final Fantasy IX (helt ikke det bedste spil nogensinde eller noget. ) Remake -rygter går i opfyldelse. Og der har også været nogle originale ideer om tredobbelt et landskab. Men jeg kan sige dette. Gudskelov, at tredobbelt et landskab er ikke det eneste, vi har. Faktisk købte et stort firma en mindre her, og du så, hvad der skete. Det blev lige monetiseret mere, og du kan argumentere for, at originaliteten blev bremset endnu mere. Store budgetter kan undertiden bringe flere muligheder, men jeg tror, du afviser potentialet for indie -titler ved direkte at angive Triple A titler bare gør tingene bedre. De ikke nødvendigvis, og at blive set til store, børsnoterede udgivere/virksomheder kommer med sit eget sæt ulemper.
Dette lyder bare som en “Jeg er skuffet over det, men kan ikke gå videre, så jeg vil hellere dens udvikling stoppet”. Det er din mening. Der er masser af mennesker, der ikke er skuffede over moderne versioner. Version 1.18 (og til en vis grad 1.16) genoplivede min lidenskab for dette spil. 1.13+ er bare en anden æra og en meget bedre efter min egen mening. Ikke alle synes, at moderne versioner er perfekte. Langt fra. Men heller ikke alle synes, det er en skuffelse, der skal slutte. Igen, langt fra det. Men hvis du er skuffet over det, skal du bare erkende det og blive i versioner, du nyder og/eller gå videre fra spillet. Det behøver ikke formelt at stoppe for at det kan ske. Andre spil er derude.
Hvad angår bonuspunkt 6, er det godt! Hver gang noget stort kommer (den originale Doom antager jeg), skynder alle disse kloner at prøve deres optagelse af ideen. Minecraft står på ingen måde over alt andet i sandkassen i hver eneste henseende. Langt fra. Men jeg er uenig i, at bare fordi det er ældre eller fordi andre ting gør tingene bedre på nogle måder, at det skal stoppe. Sagen er, at et kontinuerligt udviklende spil for denne længe er sådan en sjælden ting, at det er svært at sige, hvad Minecraft skal være. Det er for det meste spil som en service (League of Legends) eller MMOS (som også er spil som en service), der får kontinuerlig udvikling så længe. Men et enkelt købsspil, der opdateres, og konstant i over et årti? Det er en sjældenhed. Så der er ikke meget etableret i den henseende til at sammenligne med, hvad Miencraft skal være. Nogle synes, det er ændret for meget, ikke for lidt.
Hvad angår folk, der går videre, ja? Det sker. Ting ebb og flow, spids og tilbagegang. Det er alt. Folk sagde de samme slags ting tilbage i de tidligere 2010’ere om Minecraft. Folk, der ønsker at komme videre fra det, er anekdotisk, og spillet, der har brug for bare.
Undskyld, hvis det virker lidt spredt, men jeg læste det i bidder og sendte derefter mine tanker, da jeg ville give input om, hvad der virkede som et konstruktivt emne, der havde nogen tid lagt i det. Jeg er ikke enig med mange af dine punkter, men jeg tror ikke nødvendigvis, at du heller ikke tager fejl, og slags kommer, hvor du kommer fra. Men det lyder som om du lige er begyndt at gå videre, men har ikke været i stand til det. Dine tanker om, at spillet er, at det falder, fører dig til at føle, at det bare skal stoppe og ende på en højere note snarere end en lavere note, for at gøre det lettere for dig at gå videre og leve med ting. Jeg er dog ikke enig i det. Masser af mennesker, selv inkluderet, nyder stadig det moderne spil.
Rollback Post til revision af rollback
- Se brugerprofil
- Se indlæg
- Send besked
- Glowstone Miner
- Deltag i dato: 10/18/2019
- Indlæg: 3.009
- Medlemsdetaljer
Jeg synes, opdateringer skal stoppe, indtil de fikser den dårlige præstation, så mange mennesker har på deres pc’er med dette spil
De ser ikke ud til at fokusere på at optimere spillet, og hvordan det kører på forskellige sæt hardware længere, de skynder sig bare delvis ud på grund af utålmodighed af andre mennesker, der forventer, at de kommer hurtigere ud, men jeg synes, det er forkert, Jeg synes, det er langt vigtigere at give udviklere tid til at afslutte et produkt, før de frigiver det.
Hvis de ikke kan eliminere præstationsproblemerne på folks pc’er, der opfylder eller overskrider de anbefalede krav, skal de ansætte nogle mennesker, der kan, mens jeg ikke er programmerer, ved jeg, at der er andre mennesker i Minecraft -samfundet, der har oprettet mods , folk, der har benchmarks for at vise, hvad der kunne gøres for at sikre, at spillet kører med spillbare billedhastigheder uanset hvad der foregår i spillerverdener.
Selvom det er en gamers ansvar at sikre den normale drift af deres enhed, kan de ikke rigtig gøre noget ved software, som ikke er effektiv med den hardware, de kører den på, undtagen at blot ikke bruge den. Og alle pc’er, uanset hardware, har grænser, vi kan ikke bare bebrejde folks pc’er, hver gang de klager over et FPS -fald i et spil, nogle gange er det undertiden ikke så simpelt, da de kunne have high end -maskiner og stadig have den Samme problem. Som Princes_Garnet har forklaret i en anden tråd, har folk haft disse slags problemer med Minecraft, selv på pc’er med de hurtigste desktop CPU’er i dem, så det er helt klart ikke noget at gøre med hardware mere, det er mere tilfældet, at Mojang bare er ineffektivt med deres softwareteknik eller udskæring af ting, der ikke behøver at køre i spillet til enhver tid.
Men hvis de ikke optimerer deres spil, hjælper det ikke rigtig, at vi får mere indhold tilføjet til spillet,
Det kan potentielt gøre tingene værre, og indtil der er nok pres fra fandom til at tilskynde til Mojang
For at frigive opdateringer, der massivt reducerer lagspidser på jævn pc’er med midten af niveau eller hardware frigivet i de sidste 5 år,
Vi vil fortsætte med at have den samme samtale. Det er bare stumt, at vi bliver nødt til at forklare dette for udviklere, når det er dem
ansvarlig og har magten/evnen til at tackle den.
Rollback Post til revision af rollback
- Se brugerprofil
- Se indlæg
- Send besked
- Nyligt spawned
- Deltag i dato: 8/3/2012
- Indlæg: 1.830
- Minecraft: Princess_Garnet
- Medlemsdetaljer
Resultatforbedringer skaffer ikke opmærksomhed som funktionsændringer gør desværre. Se på 1.15; Det ignoreres ofte i velsignelsen af ros 1.13+ bliver simpelthen fordi det “kun tilføjede bier” eller “løste ikke engang alle de problemer, spillet har”.
Det kan være uheldigt, men det er sådan, vores verden fungerer. “God nok” er godt. godt nok.
Det skal også påpeges, at mange mennesker sandsynligvis spiller et spil, der typisk er meget CPU -tungt på sandsynligvis ældre, langsomme, ofte mobile (og lave urhastighed) CPU’er/pc’er. Ofte sandsynligvis under minimumskrav. De minimale/anbefalede krav kræver henholdsvis en lavende Ivy Bridge/Mid Range Haswell på Intels side eller for-ryzen ting på AMDs side (og AMD tilbød kun langsommere ting på dette tidspunkt). Sådanne CPU’er er temmelig gamle nu, og Windows 10, der mister støtte på mindre end et par år, vil (i det mindste officielt) afskære noget før den 8. generation på Intels side og den anden Ryzen -generation på AMDs side (og om tre år vil disse også være ældre og langsommere).
Intet af dette er at sige, at jeg ikke gerne vil se, at præstationen får mere fokus. Det er en af de ting, jeg gerne vil se. Men jeg forklarer bare, hvorfor en sådan opdatering kun fokuserede på, at det usandsynligt vil ske. Det ville være rart, hvis Minecraft var helt stutterfri uanset omstændighederne og løb ved 32 til 48 gengivelsesafstand på nye ting og spillede glat på Old Core 2s med kun 4 GB eller 8 GB RAM, og så videre. Men jeg forventer ikke, at udviklingen nogensinde vil skifte til at fokusere i den retning.
Vi bør dog ikke overse de ændringer, der kan ske undervejs, selvom de ikke er i en dedikeret opdatering bare for den slags ting. Jeg har bemærket mange dårlige opførsler fra ældre versioner, der forbedres i senere versioner.
Det er forståeligt, at du har dine egne grunde til, hvorfor du synes, Mojang skal afbryde udviklingen på Minecraft. Det er dog værd at bemærke, at andre spillere måske har forskellige perspektiver og præferencer med hensyn til spillet. Nogle nyder måske spillet som det er, mens andre kan have specifikke funktionsanmodninger eller modding behov, der holder dem investeret i Minecraft.
Derudover er det værd at bemærke, at spilindustrien er enorm og forskelligartet, hvor både indie- og AAA -studios producerer en lang række spil, der serverer forskellige publikum. Hvad der kan fungere for en spiller eller studie fungerer muligvis ikke for andre, og omvendt. Det er ikke nødvendigvis et spørgsmål om, hvilken type studie der er “overlegen”, men snarere hvilken type spil eller studie passer til en bestemt spillers behov og præferencer.
Til sidst er det op til Mojang og Minecraft -samfundet at beslutte, om og hvornår de vil afbryde udviklingen på spillet. Selvom det er forståeligt, at nogle spillere måske føler sig skuffede over visse aspekter af spillet, er det vigtigt at huske, at spillet konstant udvikler sig og ændrer sig, og det er op til udviklerne at beslutte det bedste handlingsforløb for spillets fremtid.
[Med venlig hilsen]
Olivia Devid
Dette er et pokker af et godt første indlæg, og jeg er helt enig i det. Det opsummerer tingene meget godt.
Intet af dette er at sige, at emnets starter er forkert. Alle har meninger, og de er trods alt det.
Men jeg fik indtrykket af at læse det, at nogen er “over”, hvad Minecraft i øjeblikket er, er at indse, at det er usandsynligt, at det ændrer sig nok til at blive, hvad de synes, det burde være, og ønsker at se udviklingen stopper for at hjælpe dem med at komme videre.
Og den del I er uenig med. Hvis det er tilfældet, skal du bare gå videre. Spillet behøver ikke at ophøre med at ændre sig for at komme videre. Spilllandskabet er meget bredt (og efter min mening bredere og endnu rigere end det nogensinde har været), så hvis man er “over” et givet spil, er der utallige andre derude, der sandsynligvis er tilstrækkeligt.
Rollback Post til revision af rollback
- Se brugerprofil
- Se indlæg
- Send besked
- Glowstone Miner
- Deltag i dato: 10/18/2019
- Indlæg: 3.009
- Medlemsdetaljer
Resultatforbedringer skaffer ikke opmærksomhed som funktionsændringer gør desværre. Se på 1.15; Det ignoreres ofte i velsignelsen af ros 1.13+ bliver simpelthen fordi det “kun tilføjede bier” eller “løste ikke engang alle de problemer, spillet har”.
Det kan være uheldigt, men det er sådan, vores verden fungerer. “God nok” er godt. godt nok.
Det skal også påpeges, at mange mennesker sandsynligvis spiller et spil, der typisk er meget CPU -tungt på sandsynligvis ældre, langsomme, ofte mobile (og lave urhastighed) CPU’er/pc’er. Ofte sandsynligvis under minimumskrav. De minimale/anbefalede krav kræver henholdsvis en lavende Ivy Bridge/Mid Range Haswell på Intels side eller for-ryzen ting på AMDs side (og AMD tilbød kun langsommere ting på dette tidspunkt). Sådanne CPU’er er temmelig gamle nu, og Windows 10, der mister støtte på mindre end et par år, vil (i det mindste officielt) afskære noget før den 8. generation på Intels side og den anden Ryzen -generation på AMDs side (og om tre år vil disse også være ældre og langsommere).
Intet af dette er at sige, at jeg ikke gerne vil se, at præstationen får mere fokus. Det er en af de ting, jeg gerne vil se. Men jeg forklarer bare, hvorfor en sådan opdatering kun fokuserede på, at det usandsynligt vil ske. Det ville være rart, hvis Minecraft var helt stutterfri uanset omstændighederne og løb ved 32 til 48 gengivelsesafstand på nye ting og spillede glat på Old Core 2s med kun 4 GB eller 8 GB RAM, og så videre. Men jeg forventer ikke, at udviklingen nogensinde vil skifte til at fokusere i den retning.
Vi bør dog ikke overse de ændringer, der kan ske undervejs, selvom de ikke er i en dedikeret opdatering bare for den slags ting. Jeg har bemærket mange dårlige opførsler fra ældre versioner, der forbedres i senere versioner.
Dette er et pokker af et godt første indlæg, og jeg er helt enig i det. Det opsummerer tingene meget godt.
Intet af dette er at sige, at emnets starter er forkert. Alle har meninger, og de er trods alt det.
Men jeg fik indtrykket af at læse det, at nogen er “over”, hvad Minecraft i øjeblikket er, er at indse, at det er usandsynligt, at det ændrer sig nok til at blive, hvad de synes, det burde være, og ønsker at se udviklingen stopper for at hjælpe dem med at komme videre.
Og den del I er uenig med. Hvis det er tilfældet, skal du bare gå videre. Spillet behøver ikke at ophøre med at ændre sig for at komme videre. Spilllandskabet er meget bredt (og efter min mening bredere og endnu rigere end det nogensinde har været), så hvis man er “over” et givet spil, er der utallige andre derude, der sandsynligvis er tilstrækkeligt.
Jeg ser dog dit punkt, men ingen, der forstår det grundlæggende i tech -verdenen, og du ved også, forventer virkelig, at et Intel Core 2 Duo -system vil køre nyere versioner af Minecraft Well. Minecraft plejede at køre med spillbare billedhastigheder på pc’er med dobbeltkerne CPU’er og 4 GB RAM, men så vidt vi kan fortælle, bruger spillet multitråd til chunk -belastningsoperationer, eller når spillet indlæses. Selv efter at chunk -belastningen er færdig, vil jeg ikke anbefale noget mindre end en quad -kerne -CPU til spillet, og selv da skal disse kerner være magtfulde, ikke alle quad -kerner er lavet lige, de har alle forskellige arkitekturer såvel som urhastigheder, da godt som L3 -cache -størrelser. Vi er også nødt til at overveje, at baggrundsapplikationer også bruger CPU -tråde/kerner, ikke kun selve spillet og en quad -kerne -CPU kan hjælpe med at forhindre, at disse baggrundsapps griber ind i den app, du bruger.
Men enhver ny pc, der i høj grad overskrider de anbefalede krav fra Microsoft, ikke kun at møde dem, for dette spil bør ikke være overhovedet med en 32 bunker, der giver afstand, det første problem er disse pc -bygninger er ikke billige og er bestemt ikke Budget bygger.
Den anden er 32 bidder Render afstand er ikke noget specielt mere som det plejede at være, for ca. 5 år siden eller mere kunne vi have fremsat det argument med et lige ansigt, men ikke i dag, og der er gameplay -fordele ved øget gengivelsesafstand, Til at starte.
16 eller mindre bidder giver afstand bare suger for nogen, jeg ville kun foreslå at gøre det som en sidste udvej.
Men det er ikke god indikation af en pc -håndtering af Minecraft, den eneste grund tablet eller konsolenheder som Nintendo Switch
Ville være begrænset til dette er fordi det er, hvad vi ville forvente af en mobil enhed.
Rollback Post til revision af rollback
- Se brugerprofil
- Se indlæg
- Send besked
- Nyligt spawned
- Deltag i dato: 8/3/2012
- Indlæg: 1.830
- Minecraft: Princess_Garnet
- Medlemsdetaljer
Jeg ser dog dit punkt, men ingen, der forstår det grundlæggende i tech -verdenen, og du ved også, forventer virkelig, at et Intel Core 2 Duo -system vil køre nyere versioner af Minecraft Well.
Åh, kerne 2 -eksemplet var slags trukket fra luften, fordi spillet plejede at køre godt på dem, så jeg regnede med, at det kunne være et godt basislinjeeksempel for, hvad folk kunne pege på og sige, skulle være muligt. Selvfølgelig forventer jeg ikke, at de forbliver relevante for evigt. Jeg ved, at ting går videre.
Når det er sagt, mens det nævnes.
Jeg fandt spillet “slags” løber på dem, men har selvfølgelig tunge vanskeligheder, når jeg beskæftiger sig med terrænbelastning/gengivelse.
Jeg ændrede CPU til en Core 2 Quad Q9550, og det gør faktisk meget lille forskel. Hvilket overraskede mig, fordi den dobbelte kerne maksimerede på begge kerner (og enhver musik, der kørte i en ekstern applikation, pausede konstant på og slukket, da jeg indlæste terræn), så jeg forventede lidt mere en forbedring.
Men disse kerne 2 quads var ikke monolitiske quad -kerner. De var bare et par Core 2 Duos på en CPU, der kommunikerede over FSB, hvilket sandsynligvis bremser dem kraftigt her.
Uanset hvad var de praktisk talt for langsomme til spillet selv da, og jeg ville især endnu mere nu for 1.18 og derover.
Den anden er 32 bidder Render afstand er ikke noget specielt mere som det plejede at være, for ca. 5 år siden eller mere kunne vi have fremsat det argument med et lige ansigt, men ikke i dag, og der er gameplay -fordele ved øget gengivelsesafstand, Til at starte.
Det er kun ikke specielt til grundfjorden. Det har været vanskeligt på Java for det meste fra opfattelsen af spillet indtil nu.
Jeg kørte på en gengivelsesafstand på op til 32 for mange år siden, startende med version 1.7 eller deromkring, og indtil 1.10. Billedhastigheder var til tider nede, men jeg valgte at spille på den måde.
Ironisk nok havde jeg den bedste præstation, jeg nogensinde har haft på højere gengivelsesafstande med version 1.16, som et barn af 1.8+ kodningspraksis.
Ikke nødvendigvis god præstation. Sandsynligvis ikke rundt omkring spillbar. Men det er en gengivelsesafstand på 64, over hvad spillet naturligt understøtter i Java. Så en gengivelsesafstand på 32 eller endda da nogle var stort set spillbart, hvis jeg ville have det.
Men jeg var ligeglad med det mere. Hvis du havde spurgt mig for 5+ år siden, ville jeg sige, at jeg ikke ville have mindre end 32 gengivelsesafstand og 24 minimum. Men da jeg opdaterede og startede en ny verden i en nuværende (på det tidspunkt, 1.16) Version, jeg vælger en gengivelsesafstand på omkring 20, senere 16 (de buskede blade gjorde det, og jeg har brug for dem!), i stedet nu på grund af skygger (og performance). En meget høj gengivelsesafstand giver dig lidt mere udsigt over en smal strimmel af horisonten det meste af tiden. Og jeg følte mig at forskønte det samlede billede mere end det. Indrømmet, jeg ville elske mindst 20 eller 24 over 16 år, og jeg ville muligvis endda tage 32 til tider (når jeg flyver eller op i bjergene, bemærkes den høje afstand mere). Men ud over det synes jeg, det faktisk begynder at se fjollet ud. Jeg ville kun spille over 32, hvis jeg også spillede med store biome. At se over op til et halvt dusin biome påvirker verdens fordybelse for mig, og jeg ville aldrig lide det.
Og du kan gå ind i slutningen og dreje renderafstanden let op på Java for at finde slutbyer. Det er intet i nærheden så krævende som de andre to dimensioner.
Alligevel, ja, jeg ville absolut elske en performanceopdatering. Men i betragtning af hvordan grundfjeld og Java er forskellige spil nedenunder, og hvordan 1.15 var tilsyneladende ikke så værdsat, jeg er ikke sikker på, om vi ser det igen. Spillere er mere modtagelige for funktioner, så jeg gætter på, at det er, hvad nye opdateringer vil fokusere på (og forhåbentlig kommer opdateringer, fordi jeg ikke er enig i, at de skal stoppe). Jeg ville have det godt, hvis de fortsætter med at forbedre tingene, når de går i baggrunden for at være ærlige. Husk, hvornår belysningen bare ville ødelægge? Eller var det ikke en ting i grundfjorden? Men det er bare ikke noget i Java mere, og takk og lykke. Forbedringer, når de går, er også fine af mig. Behøver ikke at være en hel opdatering.
Sidste redigeret af Princess_Garnet: 15. april 2023
Rollback Post til revision af rollback
- Se brugerprofil
- Se indlæg
- Send besked
- Glowstone Miner
- Deltag i dato: 10/18/2019
- Indlæg: 3.009
- Medlemsdetaljer
Åh, kerne 2 -eksemplet var slags trukket fra luften, fordi spillet plejede at køre godt på dem, så jeg regnede med, at det kunne være et godt basislinjeeksempel for, hvad folk kunne pege på og sige, skulle være muligt. Selvfølgelig forventer jeg ikke, at de forbliver relevante for evigt. Jeg ved, at ting går videre.
Når det er sagt, mens det nævnes.
Jeg fandt spillet “slags” løber på dem, men har selvfølgelig tunge vanskeligheder, når jeg beskæftiger sig med terrænbelastning/gengivelse.
Jeg ændrede CPU til en Core 2 Quad Q9550, og det gør faktisk meget lille forskel. Hvilket overraskede mig, fordi den dobbelte kerne maksimerede på begge kerner (og enhver musik, der kørte i en ekstern applikation, pausede konstant på og slukket, da jeg indlæste terræn), så jeg forventede lidt mere en forbedring.
Men disse kerne 2 quads var ikke monolitiske quad -kerner. De var bare et par Core 2 Duos på en CPU, der kommunikerede over FSB, hvilket sandsynligvis bremser dem kraftigt her.
Uanset hvad var de praktisk talt for langsomme til spillet selv da, og jeg ville især endnu mere nu for 1.18 og derover.
Det er kun ikke specielt til grundfjorden. Det har været vanskeligt på Java for det meste fra opfattelsen af spillet indtil nu.
Jeg kørte på en gengivelsesafstand på op til 32 for mange år siden, startende med version 1.7 eller deromkring, og indtil 1.10. Billedhastigheder var til tider nede, men jeg valgte at spille på den måde.
Ironisk nok havde jeg den bedste præstation, jeg nogensinde har haft på højere gengivelsesafstande med version 1.16, som et barn af 1.8+ kodningspraksis.
Ikke nødvendigvis god præstation. Sandsynligvis ikke rundt omkring spillbar. Men det er en gengivelsesafstand på 64, over hvad spillet naturligt understøtter i Java. Så en gengivelsesafstand på 32 eller endda da nogle var stort set spillbart, hvis jeg ville have det.
Men jeg var ligeglad med det mere. Hvis du havde spurgt mig for 5+ år siden, ville jeg sige, at jeg ikke ville have mindre end 32 gengivelsesafstand og 24 minimum. Men da jeg opdaterede og startede en ny verden i en nuværende (på det tidspunkt, 1.16) Version, jeg vælger en gengivelsesafstand på omkring 20, senere 16 (de buskede blade gjorde det, og jeg har brug for dem!), i stedet nu på grund af skygger (og performance). En meget høj gengivelsesafstand giver dig lidt mere udsigt over en smal strimmel af horisonten det meste af tiden. Og jeg følte mig at forskønte det samlede billede mere end det. Indrømmet, jeg ville elske mindst 20 eller 24 over 16 år, og jeg ville muligvis endda tage 32 til tider (når jeg flyver eller op i bjergene, bemærkes den høje afstand mere). Men ud over det synes jeg, det faktisk begynder at se fjollet ud. Jeg ville kun spille over 32, hvis jeg også spillede med store biome. At se over op til et halvt dusin biome påvirker verdens fordybelse for mig, og jeg ville aldrig lide det.
Og du kan gå ind i slutningen og dreje renderafstanden let op på Java for at finde slutbyer. Det er intet i nærheden så krævende som de andre to dimensioner.
Alligevel, ja, jeg ville absolut elske en performanceopdatering. Men i betragtning af hvordan grundfjeld og Java er forskellige spil nedenunder, og hvordan 1.15 var tilsyneladende ikke så værdsat, jeg er ikke sikker på, om vi ser det igen. Spillere er mere modtagelige for funktioner, så jeg gætter på, at det er, hvad nye opdateringer vil fokusere på (og forhåbentlig kommer opdateringer, fordi jeg ikke er enig i, at de skal stoppe). Jeg ville have det godt, hvis de fortsætter med at forbedre tingene, når de går i baggrunden for at være ærlige. Husk, hvornår belysningen bare ville ødelægge? Eller var det ikke en ting i grundfjorden? Men det er bare ikke noget i Java mere, og takk og lykke. Forbedringer, når de går, er også fine af mig. Behøver ikke at være en hel opdatering.
Jeg kan godt lide afstande med høj render af de grunde, du ville, det giver os mulighed for lettere at få øje på, hvad biomer er foran os, i oververden har det været en stor fordel for mig og andre mennesker, der spiller på min hjemmeoverlevelsesserver.
32 bunker giver afstand svarer til 1024 blokke firkantet eller 512 fra midten i alle retninger, det er en masse blokke, spillet skal indlæses i hukommelsen, men vi er nødt til at huske tick eller simuleringsafstand er en anden indstilling/funktion helt og helt og helt gengivne blokke påvirker kun, hvad der kan ses af spilleren. Men disse blokke opdaterer ikke et Redstone -kryds, medmindre en spiller er tæt nok på dem.
Jeg ville ønske, at Minecarts var i stand til at omgå krydsradiusen eller i det mindste for Mojang at give os en variant af en Minecart, der ville holde 1 chunk indlæst, da dette ville give spillerne mulighed for at sende varer til hinanden på tværs af lange afstande ved hjælp af et Minecart -tog eller Shulker i brystsystemet.
Med en præstationsopdatering, der har en sådan funktion, som måske en dag bliver praktisk, har jeg mistanke om den (ironiske) grund, at de ikke har tilføjet denne funktion med Minecarts har ikke at gøre med balance eller bekymre mig for, at det ville blive misbrugt af auto -slibere, ( Hvilket desværre også eksisterer for Shulker Farms, og efter min mening skal dette erstattes af kontinuerligt gydende shulkers i slutbyer for at kompensere for allerede plyndrede slutbystrukturer for andre spillere på en server, selvom alle Shulkers allerede var blevet dræbt af Tidligere spillere, en meget bedre måde at lave shulkerskaller og kasser vedvarende), er det mere tilfældet med det, der forårsager forsinkelse på servere.
Rollback Post til revision af rollback
- Se brugerprofil
- Se indlæg
- Send besked
- Enderdragon Slayer
- Deltag i dato: 10/6/2013
- Indlæg: 13.160
- Minecraft: THEMASTERCAVER
- Medlemsdetaljer
Jeg ser dog dit punkt, men ingen, der forstår det grundlæggende i tech -verdenen, og du ved også, forventer virkelig, at et Intel Core 2 Duo -system vil køre nyere versioner af Minecraft Well
Ikke mig; Som en meget kyndig modder ved jeg nøjagtigt, hvor meget af en indflydelse tilføjelse af nyt indhold skulle have, baseret på det faktum, at jeg næsten ikke har observeret nogen påvirkninger for mindst tusind nye funktioner (over 350 blokke og genstande, 100 biome, 45 Nye pøbel/enhed og/eller varianter af disse, snesevis af ny verdensgenerering inklusive snesevis af nye typer huler, træer, strukturer osv.).
Vanilla 1.6.4 Ved maksimale indstillinger (bemærk, at gengivelsesafstanden faktisk kun er 10 bidder, fordi den interne server kun indlæses så mange, uanset hvad gengivelsesafstanden er):
TMCWV5 ved maksimale indstillinger (16 Chunk Render -afstand, der indlæser ca. 2.5 gange så mange bidder, 1089 mod 441; Jeg satte udsigten, så det samme antal bidder gengives, 842, skønt dette ikke er den eneste faktor, der påvirker FPS):
Det eneste, der virkelig har indflydelse Har to eksemplarer af verden indlæst, selv i singleplayer), som kræver ca. 106 MB hukommelse (for begge sider). Her er en sammenligning af VisualVM Profiler -resultater for 1.6.4 og TMCWV5 (igen, bemærk forskellene i belastede bidder):
Vanilla 1.6.4; Begge disse løb i cirka 5 minutter:
Tmcwv5; Bemærk, at jeg øgede gengivelsesafstanden fra 8 til 16 nær starten, hvilket fik CPU -brugen til at spike til ca. 40%; Bagefter falder det meget hurtigere end i vanilje, som stadig gjorde en masse chunkopdateringer i ganske lang tid efter, mens det falder meget hurtigere i TMCW, og på trods af at have belastet over dobbelt så mange bidder var der færre indsamlingscyklusser, hvilket indikerer, at TMCW er tildeling af hukommelse til en lavere sats – og bruger også mindre CPU på trods af igen, indlæser langt flere data – det er optimeringskraften og 1.6.4 er meget let sammenlignet med moderne versioner:
Faktisk var dette systemkravene fra 1.6 – som kan forventes at stadig gælde for TMCW, selvom det har mange store opdateringer værd af nyt indhold:
Sidste opdateret: 06. juli 2013 23:47 CEST CEST
Minimumskrav:
CPU: Intel P4/Netburst Architecture eller dets AMD -ækvivalent (AMD K7)
RAM: 2 GB
GPU: Intel GMA 950 eller AMD ækvivalent med OpenGL 1.2 Support
HDD: Mindst 90 MB til spilkerne og lydfiler
Java Runtime Environment (JRE) 6 eller UP er påkrævet for at kunne køre spillet.
Anbefalede krav:
CPU: Intel Pentium D eller AMD Athlon 64 (K8) 2.6 GHz
RAM: 4 GB
GPU: GeForce 6XXX eller ATI Radeon 9XXX og op med OpenGL 2 -support (ekskl. Integrerede chipsæt)
HDD: 150MB
Hvor gammel er den anbefalede hardware?
Mærkets første processor, kodenavnet Smithfield og fremstillet på 90 nm -processen, blev frigivet den 25. maj, 2005, efterfulgt af 65 nm presler ni måneder senere.
Lanceret den 14. april, 2004, Familien GeForce 6 introducerede PureVideo efterbehandling til video, SLI-teknologi og Shader Model 3.0 Support (kompatibel med Microsoft DirectX 9.0c Specifikation og OpenGL 2.0).
Hvordan sammenligner indlæsningstid og verdensoprettelse? 1.6.4 skal være langt hurtigere, da verdensgenerationen er relativt så enkel, og det har meget mindre ting at indlæse, rigtigt?
[19:11:13] 2023-04-15 19:11:13 [Klient] [Info] Indstilling af bruger: THEMASTERCAVER
[19:11:13] 2023-04-15 19:11:13 [klient] [info] (session ID er null)
[19:11:13] 2023-04-15 19:11:13 [klient] [info] LWJGL Version: 2.9.0
)
[19:11:14]
[19:11:14] Start af Soundsystem.
[19:11:14] Initialisering af LWJGL Openal
[19:11:14] (LWJGL -bindingen af Openal. For mere information, se http: // www.lwjgl.org)
[19:11:14] Openal initialiseret.
[19:11:15]
[19:11:15] 2023-04-15 19:11:15 [klient] [Svær] Realms: Server ikke tilgængelig!
[19:11:48] 2023-04-15 19:11:48 [Server] [Info] Start Integreret Minecraft Server version 1.6.4
[19:11:48] 2023-04-15 19:11:48 [Server] [Info] Genererende tastar
[19:11:49] 2023-04-15 19:11:49 [Server] [Info] Konvertering af kort!
[19:11:49] 2023-04-15 19:11:49 [Server] [Info] Scanningsmapper.
[19:11:49] 2023-04-15 19:11:49 [Server] [Info] Total konverteringstælling er 0
[19:11:49] 2023-04-15 19:11:49 [Server] [Info] Forberedt startregion til niveau 0
[19:11:50] 2023-04-15 19:11:50 [Server] [Info] Forberedt spawnområde: 12%
[19:11:52] 2023-04-15 19:11:52 [Server] [Info] Forberedt spawnområde: 60%
[19:11:53] 2023-04-15 19:11:53 [Server] [Info] Forberedt spawnområde: 86%
[19:11:54] 2023-04-15 19:11:54 [Server] [info] THEMASTERCAVER [/127.0.0.1: 0] Logget ind med Entity ID 266 på (-94.5, 64.0, 244.5)
[19:11:54] 2023-04-15 19:11:54 [Server] [Info] THEMASTERCAVER sluttede sig til spillet
[18:21:25] 2023-04-15 18:21:25 [Klient] [Info] Indstilling af bruger: THEMASTERCAVER
[18:21:25] 2023-04-15 18:21:25 [klient] [info] (session-id er null)
[18:21:26] 2023-04-15 18:21:26 [klient] [info] LWJGL Version: 2.9.0
[18:21:26] 2023-04-15 18:21:26 [Klient] [Info] Genindlæsning ResourceManager: Standard, Modtextures
[18:21:27]
[18:21:27] Start af Soundsystem.
[18:21:27] Initialisering af LWJGL Openal
. For mere information, se http: // www.lwjgl.org)
[18:21:27] Openal initialiseret.
[18:21:27]
[18:22:04] 2023-04-15 18:22:04 [Server] [INFO] Start Integreret Minecraft Server version 1.6.4
[18:22:04] 2023-04-15 18:22:04 [Server] [Info] Genererende tastar
[18:22:04] 2023-04-15 18:22:04 [Server] [Info] Forberedt startregion til niveau 0
[18:22:05] 2023-04-15 18:22:05 [Server] [Info] Forberedt spawnområde: 19%
[18:22:06] 2023-04-15 18:22:06 [Server] [Info] Forberedt spawnområde: 58%
[18:22:07] 2023-04-15 18:22:07 [Server] [Info] Forberedt spawnområde: 99%
[18:22:07] 2023-04-15 18:22:07 [Server] [info] THEMASTERCAVER [/127.0.0.1: 0] Logget ind med Entity ID 137 på (-245.5, 70.0, -253.5)
[18:22:07] 2023-04-15 18:22:07 [Server] [Info] THEMASTERCAVER sluttede sig til spillet
Alligevel på en eller anden måde (!) TMCW tog kun halvdelen så meget tid på at generere en ny verden på trods af at være meget mere kompleks – igen, optimeringskraften. .13 er absolut skræmmende til sammenligning, i betragtning af at den har multithreaded chunk -generation, men alligevel tog langt længere tid end vanilje 1.6.4:
[17:55:31] [Server Thread/Info]: Start Integrated Minecraft Server version 1.13.2
[17:55:31] [Servertråd/info]: Generering af tastatur
[17:55:31] [Servertråd/info]: Fundet ny datapakke vanilje, indlæser den automatisk
[17:55:31] [Servertråd/info]: Genindlæsning ResourceManager: Standard
[17:55:32] [Servertråd/info]: Indlæst 524 opskrifter
[17:55:33] [Servertråd/info]: Indlæst 571 fremskridt
[17:55:36] [Servertråd/info]: Forberedelse af startregion til dimension Minecraft: Overworld
[17:55:37] [Servertråd/info]: Forberedelse af spawnområde: 0%
[17:55:37] [Servertråd/info]: Forberedelse af spawnområde: 4%
[17:55:38] [Servertråd/info]: Forberedelse af spawnområde: 8%
[17:55:38] [Servertråd/info]: Forberedelse af spawnområde: 12%
[17:55:38] [Servertråd/info]: Forberedelse af spawnområde: 16%
[17:55:39] [Servertråd/info]: Forberedelse af spawnområde: 20%
[17:55:39] [Servertråd/info]: Forberedelse af spawnområde: 24%
[17:55:39] [Servertråd/info]: Forberedelse af spawnområde: 28%
[17:55:40] [Servertråd/info]: Forberedelse af spawnområde: 32%
[17:55:40] [Servertråd/info]: Forberedelse af spawnområde: 36%
[17:55:40] [Servertråd/info]: Forberedelse af spawnområde: 40%
[17:55:40] [Servertråd/info]: Forberedelse af spawnområde: 44%
[17:55:41] [Servertråd/info]: Forberedelse af spawnområde: 48%
[17:55:41] [Servertråd/info]: Forberedelse af spawnområde: 52%
[17:55:41] [Servertråd/info]: Forberedelse af spawnområde: 56%
[17:55:41] [Servertråd/info]: Forberedelse af spawnområde: 60%
[17:55:42] [Servertråd/info]: Forberedelse af spawnområde: 64%
[17:55:42] [Servertråd/info]: Forberedelse af spawnområde: 68%
[17:55:42] [Servertråd/info]: Forberedelse af spawnområde: 72%
[17:55:43] [Servertråd/info]: Forberedelse af spawnområde: 76%
[17:55:43] [Servertråd/info]: Forberedelse af spawnområde: 80%
[17:55:43] [Servertråd/info]: Forberedelse af spawnområde: 84%
[17:55:43] [Servertråd/info]: Forberedelse af spawnområde: 88%
[17:55:44] [Servertråd/info]: Forberedelse af spawnområde: 92%
[17:55:44] [Servertråd/info]: Forberedelse af spawnområde: 96%
[17:55:44] [Servertråd/info]: forløbet tid: 8520 ms
[17:55:45] [Servertråd/info]: Ændring af visningsafstand til 12, fra 10
).5, 71.0, -104.5)
[17:55:46] [Servertråd/info]: THEMASTERCAVER sluttede sig til spillet
Det eneste sted, hvor TMCW er mærkbart tyngre, er i redningsstørrelsen, hvilket er på grund af den stærkt øgede kompleksitet i verden, som indikeret af Mcedit -analyserne efter (begge områder er i samme størrelse):
Den venstre kolonne er fra en verden oprettet i 1.6.4; I begge tilfælde repræsenterer disse fuldt udforskede regioner (belysning af huler øger kompleksiteten af data på grund af bloklyskortet, mere end udlignet enhver reduktion fra den relativt lille mængde malm, der er udvindet):
1.6.4; 138 blokke / blokvarianter og 347 enheder:
(0: 0), Air, 25735948
(2: 0), græs, 84800
(3: 0), snavs, 754782
(4: 0), brostensbelagt, 3178
(5: 0), træplanker, 3435
(7: 0), Bedrock, 406323
(8: 1), vand (aktiv), 41072
(10: 0), lava (aktiv), 78740
(12: 0), sand, 145920
(13: 0), grus, 229644
(14: 0), guldmalm, 4276
(15: 0), jernmalm, 46358
(16: 0), kulmalm, 87467
(17: 0), træ, 1526
(17: 1), Pine Wood, 1692
(17: 2), bjørkræ, 320
(17: 3), Jungle Wood, 7596
(17: 4), træ, 73
(17: 8), træ, 52
(18: 0), blade, 29834
(18: 1), Pine Leaves, 7836
(18: 2), Birch Leaves, 2202
(18: 3), Jungle Leaves, 20209
(18: 8), blade (forfald), 8805
(18:10), birkblade (forfald), 663
(18:11), jungleblade (forfaldne), 6796
(21: 0), Lapis Lazuli Ore, 1784
(24: 0), Sandstone, 48869
(30: 0), web, 343
(31: 1), Tall Grass, 19371
(31: 2), bregne, 828
(32: 0), Dead Busk, 74
(35:15), sort uld, 1
(37: 0), blomst, 348
(38: 0), Rose, 90
(39: 0), Brown Mushroom, 53
(40: 0), Red Mushroom, 35
(43: 0), dobbelt stenplade, 22
(48: 0), Moss Stone, 497
(49: 0), Obsidian, 808
(50: 1), fakkel, 12
(50: 2), fakkel, 10
(50: 3), fakkel, 12
(50: 4), fakkel, 4
(52: 0), Monster Spawner, 14
(53: 0), trætrapper, 116
(53: 1), trætrapper, 89
(53: 2), trætrapper, 130
(53: 3), trætrapper, 83
(54: 2), bryst, 3
(54: 3), bryst, 5
(54: 4), bryst, 2
(54: 5), bryst, 4
(56: 0), diamantmalm, 1610
(59: 2), afgrøder, 7
(59: 3), afgrøder, 11
(59: 4), afgrøder, 16
(59: 5), afgrøder, 17
(59: 6), afgrøder, 14
(60: 7), landbrugsjord, 168
(64: 0), trædør, 1
(64: 1), trædør, 7
(64: 2), trædør, 4
(64: 8), trædør, 12
(65: 2), stige, 8
(65: 4), stige, 9
(66: 0), jernbane, 312
(66: 1), jernbane, 217
(66: 2), jernbane, 1
(66: 7), jernbane, 1
(66: 9), jernbane, 1
(67: 0), stentrapper, 1
(67: 1), stentrapper, 2
(67: 3), stentrapper, 3
(72: 0), trætrykplade, 5
(73: 0), Redstone Ore, 12837
(78: 0), Snow Layer, 13325
(81: 0), kaktus, 53
(81: 1), kaktus, 2
(81: 2), kaktus, 2
(81: 3), kaktus, 2
(81: 4), kaktus, 3
(81: 5), kaktus, 7
(81: 6), kaktus, 8
(81: 7), kaktus, 3
(81: 9), kaktus, 4
(81:11), kaktus, 2
(81:12), kaktus, 1
(82: 0), ler, 626
(83: 0), sukkerrør, 46
(83: 2), sukkerrør, 1
(83: 4), sukkerrør, 1
(83: 6), sukkerrør, 1
(83: 7), sukkerrør, 1
(85: 0), hegn, 1463
(102: 0), glasrude, 76
(106: 0), vinstokke, 8
(106: 1), vinstokke, 5448
(106: 2), vinstokke, 4611
(106: 3), vinstokke, 13
(106: 5), vinstokke, 4
(106: 6), vinstokke, 13
(106: 8), vinstokke, 4345
(106: 9), vinstokke, 7
(106: 10), vinstokke, 1
(106: 11), vinstokke, 1
(106: 12), vinstokke, 12
(111: 0), Lilypad, 6
(127: 0), kakaoanlæg, 5
(127: 1), kakaoanlæg, 4
(127: 2), kakaoanlæg, 7
(127: 3), kakaoanlæg, 3
(127: 4), kakaoanlæg, 6
(127: 5), kakaoanlæg, 2
(127: 6), kakaoanlæg, 4
(127: 7), kakaoanlæg, 6
(127: 8), kakaoanlæg, 4
(127: 9), kakaoanlæg, 7
(127: 10), kakaoanlæg, 5
(127: 11), kakaoanlæg, 13
(141: 2), gulerødder, 2
(141: 3), gulerødder, 6
(141: 6), gulerødder, 7
(141: 7), gulerødder, 9
(142: 2), kartofler, 3
(142: 3), kartofler, 3
(142: 4), kartofler, 4
(142: 5), kartofler, 5
(142: 6), kartofler, 5
(142: 7), kartofler, 8
,,
,,347
Flagermus, flagermus, 22
Kylling, kylling, 52
Ko, ko, 28
Creeper, creeper, 29
Vare, æg, 13
Vare, grus, 1
Vare, jernbane, 5
Vare, frø, 1
Minecartchest, Minecartchest, 9
Gris, gris, 77
Får, får, 31
Skelet, skelet, 30
Edderkop, edderkop, 2
Blæksprutte, blæksprutte, 8
Landsbyboer, landsbyboer, 18
Zombie, Zombie, 20
,,
,,28
Bryst, bryst, 14
Mobspawner, Mobspawner, 14
Tmcwv5; 283 blokke / blokvarianter og 351 enheder; Der er også cirka dobbelt så mange kister og pøbel spawners, hovedsageligt på grund af tilfældig variation; Bemærk, at trods terræn, der i gennemsnit er højere, er der flere luftblokke, end vaniljeverdenen havde (der er kun omkring halvdelen så mange lavablokke på grund af det faktum, at hulen lavalag kun er 3 lag dybt, også muligvis variation som disse områder var Kun 368×368 blokke):
(0: 0), luft, 26155281
(1: 0), Stone, 4762059
(1: 1), Stone, 219949
(1: 3), Stone, 391886
(1: 5), sten, 618613
(1: 8), sten, 6143
(1:15), sten, 27
(2: 0), græs, 87200
(2: 1), græs, 272
(3: 0), snavs, 685957
(3: 1), snavs, 134
(4: 0), brostensbelagt, 1205
(5: 0), træplanker, 1355
(5: 1), træplanker, 3961
(5: 3), træplanker, 179
(5: 4), træplanker, 3
(7: 1), Bedrock, 117204
(7: 2), Bedrock, 2019
(7: 8), Bedrock, 16201
(9: 0), vand, 126756
(11: 0), lava, 38922
(12: 0), Sand, 19473
(12: 1), sand, 134652
(13: 0), grus, 110853
(13: 1), grus, 76175
(14: 0), guldmalm, 3957
(14: 2), guldmalm, 534
(15: 0), jernmalm, 40795
(16: 0), kulmalm, 75301
(16: 2), kulmalm, 9427
(17: 0), træ, 3237
(17: 1), Pine Wood, 3799
(17: 2), Birk Wood, 1142
(17: 3), Jungle Wood, 3517
(17: 4), træ, 13
(17: 5), træ, 12
(17: 6), træ, 4
(17: 7), træ, 9
(17: 8), træ, 4
(17: 9), træ, 5
(17:10), træ, 5
(17:12), Wood, 1196
(17:13), træ, 802
(17:14), træ, 186
(17:15), træ, 1356
(18: 0), blade, 47912
(18: 1), Pine Leaves, 36424
(18: 2), Birch Leaves, 9357
(18: 3), Jungle Leaves, 18138
(21: 0), Lapis Lazuli Ore, 1930
(21: 2), Lapis Lazuli Ore, 227
(24: 0), sandsten, 273
(24: 4), Sandstone, 15955
(30: 0), web, 1067
(31: 0), (ubrugt busk), 11305
(31: 1), højt græs, 1580
(31: 2), bregne, 58
(31: 3), (ubrugt busk), 52
(32: 0), Dead Busk, 97
(35:15), sort uld, 3
(37: 0), blomst, 215
(37: 1), blomst, 53
(37: 2), blomst, 83
(37: 3), blomst, 61
(37: 4), blomst, 20
(37: 7), blomst, 43
(37: 8), blomst, 42
(37: 9), blomst, 53
(37:10), blomst, 44
(37:11), blomst, 52
(37:12), blomst, 49
(37:13), blomst, 59
(37:14), blomst, 26
(37:15), blomst, 37
(38: 0), Rose, 181
(39: 0), Brown Mushroom, 296
(39: 1), Brown Mushroom, 77
(39: 2), Brown Mushroom, 86
(39: 3), Brown Mushroom, 69
(39: 4), Brown Mushroom, 90
(43: 0), dobbelt stenplade, 11
(48: 0), Moss Stone, 875
(49: 0), Obsidian, 2156
(52: 0), Monster Spawner, 35
(53: 8), trætrapper, 77
(53: 9), trætrapper, 92
(53:10), trætrapper, 58
(53:11), trætrapper, 39
(54: 2), bryst, 9
(54: 3), bryst, 8
(54: 4), bryst, 5
(54: 5), bryst, 9
(56: 0), Diamond Ore, 1026
(56: 2), diamantmalm, 133
(59: 2), afgrøder, 5
(59: 3), afgrøder, 7
(59: 4), afgrøder, 5
(59: 5), afgrøder, 13
(59: 6), afgrøder, 6
(59: 7), afgrøder, 20
(60: 7), landbrugsjord, 112
(64: 0), trædør, 3
(64: 1), trædør, 7
(64: 2), trædør, 1
(64: 8), trædør, 10
(64: 9), trædør, 1
(65: 2), stige, 4
(65: 4), stige, 9
(66: 0), jernbane, 466
(66: 1), jernbane, 517
(72: 2), trætrykplade, 4
(73: 0), Redstone Ore, 8080
(73: 2), Redstone Ore, 1062
(75: 1), Redstone Torch (OFF), 25
(75: 2), Redstone fakkel (off), 16
(75: 3), Redstone fakkel (off), 17
(75: 4), Redstone Torch (OFF), 24
(75: 9), Redstone Torch (OFF), 12
(75:10), Redstone Torch (OFF), 7
(75:11), Redstone Torch (OFF), 7
(75:12), Redstone fakkel (off), 8
(75:13), Redstone Torch (OFF), 8
(81: 0), kaktus, 18
(81: 5), kaktus, 1
(81: 8), kaktus, 11
(81: 9), kaktus, 1
(81:10), kaktus, 1
(81:13), kaktus, 1
(82: 0), Clay, 2141
(83: 0), sukkerrør, 65
(83: 1), sukkerrør, 1
(83: 3), sukkerrør, 1
(83: 4), sukkerrør, 1
(83: 5), sukkerrør, 2
(83: 6), sukkerrør, 1
(85: 1), hegn, 2244
(85: 3), hegn, 116
(85: 4), hegn, 4
(98: 0), Stone Bricks, 1613
(98: 1), Mossy Stone Bricks, 153
(98: 2), revne stensten, 478
(98: 3), Circle Stone Bricks, 55
(99: 1), enorm brun svamp (nordvest), 68
(99: 2), enorm brun svamp (nord), 49
(99: 3), enorm brun svamp (nordøst), 68
(99: 5), enorm brun svamp (øverst), 141
(99: 6), enorm brun svamp (øst), 45
(99: 7), Enorm Brown Mushroom (Southwest), 54
(99: 8), enorm brun svamp (syd), 41
(99: 9), enorm brun svamp (sydøst), 54
(99:10), enorm brun svamp (STEM), 79
(99:11), enorm brun svamp, 13
(100: 1), enorm rød svamp (nordvest), 47
(100: 2), enorm rød svamp (nord), 43
(100: 3), enorm rød svamp (nordøst), 47
(100: 4), enorm rød svamp (vest), 40
(100: 5), enorm rød svamp (øverst), 162
(100: 6), enorm rød svamp (øst), 39
(100: 7), enorm rød svamp (sydvest), 45
(100: 8), enorm rød svamp (syd), 39
(100: 9), enorm rød svamp (sydøst), 43
(100: 10), enorm rød svamp (stilk), 76
(100: 11), enorm rød svamp, 33
(102: 0), glasrude, 57
(103: 0), vandmelon, 2
(106: 0), vinstokke, 37
(106: 1), vinstokke, 2615
(106: 2), Vines, 1981
(106: 3), vinstokke, 11
(106: 4), vinstokke, 2570
(106: 5), vinstokke, 8
(106: 6), vinstokke, 14
(106: 8), vinstokke, 2034
(106: 9), vinstokke, 15
(106: 10), vinstokke, 4
(106: 12), vinstokke, 14
(109: 0), Stone Brick Trappy, 1
(109: 1), Stone mursten trapper, 2
(109: 2), Stone mursten trapper, 2
(109: 3), Stone mursten trapper, 5
(127: 0), kakaoanlæg, 2
(127: 1), kakaoanlæg, 5
(127: 2), kakaoanlæg, 2
(127: 4), kakaoanlæg, 3
(127: 5), kakaoanlæg, 3
(127: 6), kakaoanlæg, 2
(127: 7), kakaoanlæg, 2
(127: 8), kakaoanlæg, 6
(127: 9), kakaoanlæg, 5
(127: 10), kakaoanlæg, 4
(127: 11), kakaoanlæg, 11
(141: 2), gulerødder, 2
(141: 3), gulerødder, 2
(141: 4), gulerødder, 6
(141: 5), gulerødder, 6
(141: 6), gulerødder, 5
(141: 7), gulerødder, 7
(142: 2), kartofler, 3
(142: 3), kartofler, 4
(142: 4), kartofler, 6
(142: 5), kartofler, 4
(142: 6), kartofler, 5
(142: 7), kartofler, 6
(161: 3), fremtidig blok!,759
(162: 0), fremtidig blok!,503
(164: 1), fremtidig blok!,56
(164: 2), fremtidig blok!,52
(164: 3), fremtidig blok!,56
(164: 4), fremtidig blok!,52
(164: 5), Future Block!,248
(164: 6), fremtidig blok!,52
(164: 7), fremtidig blok!,54
(164: 8), fremtidig blok!,49
(164: 9), fremtidig blok!,54
(164: 10), fremtidig blok!,98
(164: 11), fremtidig blok!,48
!,73
(165: 2), fremtidig blok!,60
(165: 3), fremtidig blok!,72
(165: 4), fremtidig blok!,55
(165: 5), fremtidig blok!,136
(165: 6), fremtidig blok!,55
(165: 7), fremtidig blok!,
(165: 8), fremtidig blok!,53
(165: 9), fremtidig blok!,67
(165: 10), fremtidig blok!,95
(165: 11), fremtidig blok!,32
(166: 1), fremtidig blok!,40
(166: 2), fremtidig blok!,41
(166: 3), fremtidig blok!,41
(166: 4), fremtidig blok!,41
(166: 5), Future Block!,180
(166: 6), fremtidig blok!,41
(166: 7), fremtidig blok!,41
(166: 8), fremtidig blok!,41
(166: 9), fremtidig blok!,41
(166: 10), fremtidig blok!,82
(166: 11), fremtidig blok!,18
(167: 7), fremtidig blok!,5
(167: 8), fremtidig blok!,5
(167: 10), fremtidig blok!,7
(168: 1), fremtidig blok!,744951
(175: 0), fremtidig blok!,238
(175: 1), fremtidig blok!,50
(175: 2), fremtidig blok!,5923
(175: 3), fremtidig blok!,1527
(175: 4), fremtidig blok!,64
(175: 5), fremtidig blok!,88
(180: 0), fremtidig blok!,59
(180: 4), fremtidig blok!,71
(180: 8), fremtidig blok!,26
(181: 0), fremtidig blok!,391
(185: 0), fremtidig blok!,314
(185: 2), fremtidig blok!,62
(185: 8), fremtidig blok!,803
(185: 10), fremtidig blok!,97
(186: 0), fremtidig blok!,190
(186: 2), fremtidig blok!,56
(186: 8), fremtidig blok!,550
!,106
(187: 0), fremtidig blok!,21
(187: 2), fremtidig blok!,4
(187: 8), fremtidig blok!,73
(187: 10), fremtidig blok!,23
(188: 0), fremtidig blok!,2256
(188: 1), fremtidig blok!,8
(188: 2), fremtidig blok!,3
(188: 3), fremtidig blok!,10
(188: 4), fremtidig blok!,8
(188: 5), Future Block!,5
!,2
(188: 7), fremtidig blok!,6
(188: 8), fremtidig blok!,8
(188: 9), fremtidig blok!,10
(188: 10), fremtidig blok!,6
(200: 0), fremtidig blok!,202
(200: 2), fremtidig blok!,24
,,
,,351
Flagermus, flagermus, 22
Cavespider, Cavespider, 5
Kylling, kylling, 32
Ko, ko, 22
Creeper, creeper, 15
Fisk, fisk, 10
Hest, hest, 6
Vare, brun svamp, 15
Vare, jernbane, 2
Vare, rådne kød, 1
Vare, frø, 16
Vare, pind, 1
Minecartchest, Minecartchest, 25
Ozelot, Ozelot, 2
Gris, gris, 38
Kanin, kanin, 22
Får, får, 48
Skelet, skelet, 22
Edderkop, edderkop, 4
Blæksprutte, blæksprutte, 15
Landsbyboer, landsbyboer, 13
Heks, heks, 2
Zombie, Zombie, 13
,,
,,66
Bryst, bryst, 31
Mobspawner, Mobspawner, 35
Fakta er, det Blæser mit sind, hvor ressourceintensive moderne versioner er, endnu mere så traditionelle modded versioner – absolut sindssyge; Bare hvad der bruger alt dette?! Nej, jeg vil ikke installere en modpack eller endda en moderne version, bare så jeg kan analysere dens ressourceforbrug:
De fleste modpacks kun har brug for 6-8 GB RAM tildelt
At sige “kun” som om 6-8 GB er intet, når jeg kun havde 512 MB tildelt i eksemplerne ovenfor, og denne tråd hævder, at selv modded 1.3 kræver i det mindste så meget bare for at komme i gang, meget mindre indlæse en verden i en højere udsigt afstand end understøttet af spillet, medmindre du bruger Optifine (igen, 10 bidder indlæser 441 bidder, mens 16 bidder belastes 1089 bidder; 1089 /441):
1.3 Opdel serveren og klientlogikken. Pludselig skal du fordoble spillet fodaftryk – en kopi af alle spilobjekter til serveren, en kopi til klienten. 1.3 har brug for 500 MB, før du endda kører.
Her er flere VisualVM -analyser, denne gang sammenligner de øverste objekter med hukommelsesbrug (“tilbageholdt størrelse”, som inkluderer al hukommelse, der henvises til af eventuelle objekter, de har; summen af søjlen er ikke det samlede ved den øverste post):
1.6.4; Den samlede hukommelsesforbrug var omkring 111.3 MB, med 61.5 mb (55.3%) brugt af belastede bidder og 49.8 MB brugt af alt andet (bemærk, at der faktisk er 1066 bunker indlæst, ikke 882 eller 441 x 2, da spawnbunkerne er 625 bidder, men kun serversiden; antallet ville være endnu højere, hvis jeg var uden for spawn-området ):
Tmcwv5; Total hukommelsesforbrug var omkring 164.4 MB, med 137.6 MB (83.7%) brugt af belastede bidder og 26.8 MB brugt af alt andet (i dette tilfælde det samme antal bidder, 1089 eller 2178 i alt, er indlæst på begge sider, da der ikke er indlæst nogen spawnbunker, undtagen under den første verdensoprettelse, så det betyder heller ikke noget, hvor jeg er i verden):
Ja, du læser det rigtigt – når du udelukker indlæste bidder, bruger TMCW kun om halvt så meget hukommelse! Dette er tydeligt synligt i nogle af klasserne; Renderglobal er 2.84 MB i vanilje, men TMCWs renderglobaltmcw -klasse er kun 2.18 MB, og det kombinerer to store gengivelsesklasser (Renderglobal og EntityRenderer). Ligeledes tager Vanilla’s WorldRenderer 2.56 MB, mens TMCWs chunkrenderer kun tager 1..61 gange flere tilfælde på grund af den højere gengivelsesafstand (med andre ord hver mindre end halvdelen så meget hukommelse, 106 mod 248 byte)! Dette delvis fordi jeg fjernede flere objekter til fordel for enklere felter, hvilket også betyder, at der er titusinder mindre objekter, end der ellers ville være (det er grunden til, at “størrelsen” er den samme som “bevaret”, mens sidstnævnte i vanilje er meget større. Selv hvis du bare sammenligner “størrelsen” -vanillaen har stadig brug for 126 byte pr. Instans). Det samme gælder for mange andre klasser, som alle tilføjer op til en 50% reduktion i baseline -hukommelsesforbruget – hvis jeg i stedet havde sat TMCW til 10 bidder, for at indlæse det samme antal som vanilje, ville det bruge mindre hukommelse generelt og lige Mindre CPU (som allerede var lavere).
Sikker på, der er stadig tilfælde, hvor noget kan bruge en masse hukommelse, for eksempel, se på, hvor meget hukommelse der bruges af mineshafts, og der var kun 10 indlæst – men i det mindste indlæser jeg ikke eller gemmer dataene for hver eneste Mineshaft i hele verden, som vanilje gør, og de er kun skabt, hvis en del er befolket med en del af dem (hvis jeg genindlæste verden og tog en anden bunke dump, ville det vise 0 tilfælde, så kun mængden af nyt terræn, der genereres I en given session betyder det plus Vanillas “Mapgenstructuredata” -klasse sine egne data separat fra “Mapgenmineshaft” -klassen, der allerede bruger 1/6 så meget hukommelse på trods af kun en enkelt landsby, som stadig bruger dem, der er til stede):
MC-33134 Mineshaft.DAT bruger for meget CPU (dette skal være “for meget hukommelse, hvilket tvinger høj CPU -brug via affaldssamlinger)
Uanset om du kunne sige, at jeg virkelig fikseret dette eller ej, vil det aldrig blive et sådant problem, medmindre du gjorde noget urealistisk som kontinuerligt at flyve i flere dage eller holdt spillet i gang med en verden indlæst, når du ikke spillede. For at mineshaft -data kan bruge en mængde hukommelse, der kan sammenlignes med indlæste bidder, skal du indlæse i størrelsesordenen 10.000 af dem, eller 1.8 millioner bidder (på grund af Vanillas ineffektive gemte strukturdataformat Det kan kun håndtere en lille brøkdel af dette; kommentarer antyder, at kun ca. 600 mineshafts eller 60.000 bidder i vanilje, brug den samme mængde hukommelse – så jeg kan hævde at have optimeret dem med en faktor 30. Dette betyder også, at min første verden, omkring 135.000 bidder, ville bruge flere gange mere hukommelse, hvis jeg ikke havde deaktiveret strukturbesparelse for mineshafts – som den er, den bruger ikke mere end en brand -0new -verden).
Ligeledes er jeg sikker på, at der er måder til i høj grad Jeg får stadig nok FPS til at forblive stabil med en ramtgrænse / vsync (hvilket sandsynligvis er det, som de fleste udviklere er tilfredse med, idet de ignorerer det faktum, at de måske har en computer over gennemsnittet – jeg koder endda stadig dele af TMCW, som om jeg stadig havde Et 32 bit system, som jeg gjorde i de første par år, jeg spillede):
Bemærk, at hukommelsesforbruget, der er vist af VisualVM Nye funktioner fra opdateringer så nylige som 1.19, inklusive før dens officielle frigivelse, som en hurtig snegning (som kun krævede et par kodelinjer – når du først har basiskoden til en generel type funktion (enheder, blokke, genstande, fortryllelser, biome osv.) Hver ny Forekomst har brug for meget mindre for at blive tilføjet*). Mine modded krukker inkluderer også en masse ubrugte vaniljeklasser, siden jeg omdøbte mange af dem i stedet for bare.8, den første opdatering, hvor Mojang vedtog deres nuværende programmeringspraksis, i det mindste i stor skala, er større på trods af at kun har en lille brøkdel af indholdet (min egen kode har også langt færre klasser, ca. 1/3 så mange sammenlignet med den samme samlede kilde størrelse på vanilje 1.6.4; Omvendt 1.8 har langt flere små klasser og er langt mere kompliceret internt som et resultat):
*Dette er al den kode, der er involveret i min “Swift Sneak” -fortryllelse, eksklusive ikke -relaterede dele af eksisterende klasser, der blev ændret til at omfatte koden til den (kun “EnchantmentswiftSneak” er helt ny):
Public Class EnchantmentswiftsNeak udvider fortryllelse < public EnchantmentSwiftSneak(int par1, int par2) < super(par1, par2, EnumEnchantmentType.armor_legs); this.setName("swiftSneak"); >// returnerer omkostninger pr. Niveau i ambolten; Niveau 3 koster 9 niveauer public int getanvilcost () < return 3; >// Indstil, så kun niveauer 1-2 er sandsynligvis opnået fra fortryllelsstabellen Public Int GetMinenchantability (INT PAR1) < return 10 + 20 * (par1 - 1); >Offentlig int getMaxenchantability (int par1) < return super.getMinEnchantability(par1) + 50; >offentlig int getMaxLevel () < return 3; >// Reducerer chance for at blive valgt i en fortryllelsesbord med yderligere 75% (effektiv vægt er 0.25) offentlig float getAdditionRarity () < return 0.25F; >> offentlig abstrakt klasse fortryllelse < public static final Enchantment swiftSneak = new EnchantmentSwiftSneak(28, 1); static < // Initializes list of enchantments used by villager trading and fishing ArrayListtradeList = new ArrayList(); for (int i = 0; i < 2; ++i) < for (int e = 0; e > > EnchantmentsBookList = (Enchantment []) Tradelist.toArray (ny fortryllelse [0]); >> offentlig klasse Customenchantmenthelper < // Adds information on armor and Protection enchantment values private static final void addArmorTooltips(ItemStack itemStack, ItemArmor item, ArrayList list) < level = getEnchantmentLevel(Enchantment.swiftSneak, itemStack); if (level >0) Liste.Tilføj (enumchatformating.Blå + " +" + heltal.ToString (niveau * 15) + "% sneak hastighed"); > Offentlig statisk finale Int GetSwiftsNeakModifier (EntityLivingBase Par0EntityLivingBase) < return getMaxEnchantmentLevel(Enchantment.swiftSneak, par0EntityLivingBase.getLastActiveItems()); >// returnerer en fortryllet bog med lang fald eller hurtig snig. Niveaufordeling er indstillet, så der er 40% chance for // det maksimale niveau; For lang efterårsniveauer 1-4 har en 11/19/29/40 chance, mens for Swift Sneak Level 1-3 har en // 26/33/40 chance. Offentlig statisk endelig ItemStack GetRandomrarebook (Random64 Par1random) < Enchantment enchant = (par1Random.nextBoolean() ? Enchantment.longFall : Enchantment.swiftSneak); int value = (enchant.getMaxLevel() == 4 ? 5 : 16); int level; do < level = enchant.getMaxLevel() - par1Random.nextInt(par1Random.nextInt(value) + par1Random.nextInt(2) + 1); >mens (niveau> public class bevægelsesinputfix udvider bevægelsesinput < public void updatePlayerMoveState() < if (this.sneak) < // Swift Sneak increases movement speed while sneaking by 15% per level (30%, 45%, 60%, 75% for levels 0-3) float factor = (float)CustomEnchantmentHelper.getSwiftSneakModifier(this.thePlayer) * 0.15F + 0.3F; if (factor < 1.0F) < this.moveStrafe *= factor; this.moveForward *= factor; >>>>
Rollback Post til revision af rollback
THEMASTERCAVERs første verden – muligvis den mest havede verden i Minecraft History – inkluderer verdens download.
THEMASTERCAVER’S WORLD – Min egen version af Minecraft stort set baseret på mine synspunkter på, hvordan spillet skulle have udviklet sig siden 1.6..
.6.4?