Advies waarom ik dat denk 1.20 zou de definitieve versie van Minecraft moeten zijn. Discussie – Minecraft: Java Edition – Minecraft Forum – Minecraft Forum,

Om updates vrij te geven die de lag -pieken op zelfs pc’s op zelfs PC’s verminderen met mid -tier of hardware die in de afgelopen 5 jaar is vrijgegeven,

Minecraft -forums

[Mening] Waarom ik dat denk 1.20 zou de definitieve versie van Minecraft moeten zijn.

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen
  • Tree Puncher
  • Join Date: 11/1/2021
  • Berichten: 20
  • Lidgegevens

Er zijn een aantal verschillende redenen waarom ik dit denk, althans naar mijn mening. Hier zijn mijn top vijf redenen waarom.

    Je zou denken met een indie -studio zoals Mojang, ze zouden meer betekenisvolle inhoud bieden dan wat we eigenlijk hebben. Dit bewijst alleen maar waarom AAA -games naar mijn mening altijd superieur zijn aan indie -games, en dat is niet om de schaduw te gooien bij de laatste. Toen ik deze game echter voor het eerst kocht (ik kreeg eigenlijk de Bedrock Pocket Edition voor het eerst op Kerstmis van 2012, tien jaar geleden, terwijl ik zeven dagen later de originele Java -editie kreeg op de eerste dag van 2013, 1 januari), had ik verwacht veel meer van die titel. Als gamer die Lego Creator en Dino Island speelde (ja, dat spel bestaat), verwachtte ik echt dat Minecraft die formules nog meer zou uitbreiden, met de mogelijkheid om zowel in vorm als functie volledig te bouwen. Leuk weetje: ik heb eigenlijk een recensie achtergelaten op Metacritic op Minecraft waarin zijn fouten minstens twee jaar geleden zijn gebreken, en ik zou moeten gaan met de mening van whitelight over het feit dat het idee “je kunt alles bouwen wat je wilt” slechts halftijd is.

Ik verwachtte blokken te kunnen draaien met behulp van motoren en hefbomen, en zelfs sets blokken te roteren om dynamiek te creëren zoals grote schepen en robotarmen. Dit was echter helaas niet het geval voor mij. Door Minecraft te stoppen na 1.20, we hoeven ons geen zorgen te maken over functies die we eigenlijk nooit wilden worden geïmplementeerd, omdat de ontwikkeling helemaal zou zijn gestopt. Ik denk dat Mojang een vakantie verdient, misschien een permanente daarbij.

Een ander kenmerk dat niet alleen in 1 was “beloofd”.5, de Redstone -update, maar niet geleverd tot 1.8, maar zelfs toen was het zo moeilijk te begrijpen dat je zou denken dat het gebroken was, was Minecart -koppeling. Om nog erger te maken, is deze functie volledig afwezig in de gesteente -editie – mijn favoriete editie van Minecraft om op te spelen – en dat geldt ook voor de oven Minecart. Hoewel persoonlijk, is dit meer een zegen dan een vloek, omdat er niets ingewikkeld is om hier te “leren”, dat woord dat losjes wordt gebruikt omdat het praktisch onmogelijk is om erachter te komen zonder een gids of YouTube -video.

Met andere woorden, de lelijke waarheid is dat indie -games gebaseerd zijn op veel valse informatie die je misschien op het nieuws ziet, of van wat je dacht dat een “goede vriend” van je was. De waarheid is dat AAA nog steeds net zo goed is als altijd; Ze proberen nog steeds nieuwe ideeën te vinden voor hun spellen en inhoud. Door door te gaan en de ontwikkeling van Minecraft te beëindigen op 1.20, het spel kan niet alleen worden beschouwd als “voltooid”, zoals we in het laatste bullet -punt zullen zien, maar we hoeven ons geen zorgen meer te maken over enige teleurstelling meer. En zoals ik al eerder zei, het spel voelde me hier nooit een goed gepolijste ervaring.

Over het algemeen lijkt het jammer dat Minecraft naar mijn bescheiden mening de ontwikkeling met 1 zou moeten beëindigen.20, maar de waarheid is dat veel van mijn vrienden zoals Ryan en Mason permanent zijn verhuisd van Minecraft, en sindsdien niet meer teruggekeken. Dit komt omdat ze soortgelijke problemen hebben gezien met het spel naast waar ik zojuist jullie over heb verteld, en ik zou het van harte met hen moeten eens zijn.

Het is ook de moeite waard om mijn mod te bekijken voor het Bedrock Minecraft genaamd Order of the Stone, die te vinden is in mijn handtekening. Hartelijk dank.

    “Minecraft verdient het om op de hoogte te blijven, misschien voor altijd.” Dit leidt tot mijn disclaimer: ik ben persoonlijk helemaal in orde als het spel nog steeds wordt bijgewerkt na 1.20; Ik heb gewoon persoonlijk het gevoel dat Minecraft beter af is om niet meer te worden bijgewerkt na 1.20. Als je niet begrijpt waar ik het over heb, lees dan het bericht opnieuw door.

Roldback -post om terugdraaien te herzien

Orde of the Stone – Een mod -idee van wat Minecraft had kunnen zijn geweest als het door een team met meer expertise was ontwikkeld; door professionele ontwikkelaars en producenten.

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen
  • Enterdragon Slayer
  • Deelnemende datum: 10/6/2013
  • Berichten: 13,160
  • Minecraft: ThemasterCaver
  • Lidgegevens

Ik weet dat het is om te helpen voorkomen dat mensen het spel gratis pireren of kraken

Ironisch genoeg hoef je niet eens het werkelijke spel te modelleren om het te piraten – de launcher zelf is wat het daadwerkelijk afdwingt, zowel door een “-demo” -parameter aan de game toe te voegen als je het niet hebt gekocht (leuk feit: versies: versies: versies: versies Vóór 1.3 Herken dit niet, dus ze stellen je in staat om de volledige game te spelen – zoals zelfs gedocumenteerd op de wiki – alle “gebarsten” launchers hoeven dit weg te laten om een ​​versie in de non -demo -modus te laten spelen).

Wat betreft de server zelf, het is helemaal gratis te downloaden (zoals alle gamebestanden zijn, eigenlijk – bekijk gewoon https: // mcversions.Net/, dat rechtstreeks linkt naar de bestanden op de servers van Mojang) – en er is eigenlijk een instelling waarmee u online authenticatie kunt uitschakelen – die allemaal een “gebarsten” server is, is eigenlijk en is ook duidelijk gedocumenteerd op de wiki en elders ( Waarom Mojang niet zo’n gemakkelijk geëxploiteerde instelling heeft verwijderd, is mij te boven, ik heb gehoord dat het zo is dat serverbeheerders kunnen doorgaan in het geval ze om een ​​of andere reden niet normaal inloggen; zoals voor pre-1.3 versies, het kan ze misschien niet schelen, omdat ze zo verouderd zijn dat ze net zo goed een uitgeklede demo-versie kunnen zijn, anders kunnen ze gewoon voorkomen dat je versies verandert als je een demo-account hebt):

Als men voor 1 een demo -versie probeert te spelen.3 Uit de Launcher met behulp van een niet-premiumaccount kunnen ze de volledige versie spelen. Dit komt omdat 1.3 is de versie die de demo -modus aan Minecraft heeft toegevoegd, dus eerdere versies hebben niet de code die nodig is om te herkennen dat ze in de demo zijn.

Het instellen van deze variabele om met opzet uit te zetten wordt “Cracking” een server genoemd, en servers die aanwezig zijn met online modus UIT worden “gebarsten” servers genoemd, waardoor spelers met niet -vergunde kopieën van Minecraft kunnen deelnemen.

Dus, obfuscatie doet letterlijk helemaal niets om het spel te beveiligen tegen gebruik zonder vergunning. Mijn belangrijkste probleem ermee is dat het (vanille) crashrapporten onmogelijk te begrijpen maakt, tenzij u toegang hebt tot deobfuscatie -toewijzingen, of iemand anders had ontdekt wat het probleem is, of het foutbericht is duidelijk genoeg; Wat betekent dit zelfs (divisie door nul – maar waar? Wat is “bit.B”?))

Java.Lang.ARITHMETICEXCEPTEING: / door nul
bij BLT.B (SourceFile: 814)
bij Bao.AK (SourceFile: 801)
bij Bao.F (SourceFile: 728)
op het net.Minecraft.cliënt.voornaamst.Voornaamst.Main (SourceFile: 148)

Anders heeft het me niet gestoord, omdat ik gewoon stopte met updaten op 1.6.4, met alles daarna in principe een apart spel (als je bedenkt hoe ik mijn eigen mods versie, gebaseerd op grote updates voor wereldgeneratie, 1.0.0-1.6.4 zou “Minecraft 1 zijn.0 “, 1.7-1.17 is “Minecraft 2.0 “, en 1.18+ is “Minecraft 3.0 “), dus er is geen probleem met het bijwerken van mods, die ook moeten worden bijgewerkt vanwege interne wijzigingen in de code van de game; de ​​belangrijkste reden waarom zoveel mods zijn gestopt met updaten op of langzaam zouden worden bijgewerkt.7.10 is niet vanwege verduistering, maar vanwege grote interne veranderingen, hetzelfde voor 1.13.

Ook denk ik niet dat het correct is om Minecraft meer een “indie” -spel te noemen, het is al meer dan tien jaar niet door een enkele persoon ontwikkeld (er is een subset van spelers die versies overwegen tot bèta 1.7.3, toen Notch nog steeds dominant was, “Gouden Eeuw”, met alles sindsdien in een compleet andere richting dan zijn oorspronkelijke visie). Anderen beschouwen de Microsoft -buy -out als het einde van het indie -tijdperk; door deze maat 1.8 was de laatste “indie” -versie (hoewel ik het op 1 zou plaatsen.7 op het laatste moment vanwege grote veranderingen in de manier waarop het spel is gecodeerd sinds 1.8).

Roldback -post om terugdraaien te herzien

De eerste wereld van ThemasterCaver – misschien wel de meest ingetogen wereld in de geschiedenis van Minecraft – omvat werelddownload.
ThemasterCaver’s World – mijn eigen versie van Minecraft grotendeels gebaseerd op mijn opvattingen over hoe het spel had moeten evolueren sinds 1.6.4.
Waarom speel ik nog steeds in 1.6.4?

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen
  • Nieuw voortgebracht
  • Deelnemende datum: 3/3/2012
  • Berichten: 1.830
  • Minecraft: Princess_Garnet
  • Lidgegevens

Je eerste punt lijkt een beetje overal en verwart me. Het lijkt bijna tegenstrijdig, dus kan ik om wat duidelijkheid vragen?

U zegt dat Mojang een indie -bedrijf is. Ik ben het hier niet mee eens. Het is niet helemaal indie meer. Mojang en Riot zijn twee voorbeelden die mogelijk indiefbedrijven zijn geweest aan het begin van de jaren 2010, maar niet echt meer. In feite is een van de enige dingen die u op hetzelfde punt vermeldt het trage tempo van inhoud/verandering in de loop van de tijd, en het bedrijf wordt groter, is uitgekocht door een moederbedrijf, en het hebben van zijn processen is een resultaat hiervan groei. Dat is op zichzelf een afzonderlijk onderwerp, maar de bedrijfsgrootte is niet lineair gelijk aan wijzigingspotentieel.

Hoe dan ook, je vermeldt dat Mojang een klein bedrijf is, is waarom we snellere contentwijzigingen moeten verwachten. Dit kan ook de andere kant op gaan. Hoewel indiemitels meer kans hebben om risico’s te nemen (in tegenstelling tot grote uitgevers die de veiliger, meer winst waarschijnlijke route nemen, wat resulteert in minder originaliteit), is het zeldzaam dat een volledig gepolijst idee komt uit een indie -titel die een evolutie van de perfectioneert formule. Dat is een heel lange vraag, en ik denk dat je de prestatie van Minecraft toch onderschatte. Destijds was zoiets niet eerder gezien, en de technologie want het was er niet echt eerder (althans niet in de manier waarop Minecraft het deed). Er is een reden waarom een ​​eenvoudig concept met een eenvoudige look relatief laat kwam.

Herinneren; Dit is net begonnen als een project door één persoon. Het is toevallig opgeblazen. Je stelt veel verwachtingen over wat het naar mijn mening had moeten zijn.

Ook enorm oneens op indie versus triple a. De indiescène bloeit en heeft het afgelopen decennium pc -gaming gedragen, en nog wat. Drievoudige gaming is in de loop van de tijd meer geworden of mis. Het is oké in de afgelopen jaren, maar voordat dingen zoals Steam echt meer mogelijkheden mogelijk maken met indie -ontwikkelaars, was de gamemarkt naar mijn mening veel flauwer en beperkt. Ik vind het grootste deel van het gewicht van de (naar mijn mening) huidige zegen van pc -gaming wordt gedragen door het indiesegment, en het is niet eens in de buurt.

Ik kan niet veel spreken over de modding/coderende delen van punt twee.

Wat betreft drie, ik ben het daar niet mee eens. Versie 1.19 is daar nogal berucht voor (maar het wordt ook naar beneden gesleept door het chat -ding), maar dat afgezien, ben ik het daar niet mee eens. Ik zeg niet dat het nooit afgezien van die tijd is gebeurd, alleen dat ik denk dat het helemaal niet een groot probleem was naast dat ene punt. En Mojang heeft er die tijd van uitgesproken. Minecraft heeft een geschiedenis ongeveer een dozijn jaar bij het maken. Er zullen op dat moment onvermijdelijk een aantal dingen zijn die niet worden toegevoegd die niet worden toegevoegd. Het is gewoon onvermijdelijk.

Voor punt vier, enorm oneens, en ik zei hierboven omdat je dit bij de opening van je bericht noemde (ik antwoord terwijl ik het lees). Ik speel niet aan de consolekant als dat helpt mijn houding te verklaren, maar aan de pc -kant bloeit indie -gaming en naar mijn mening gaat pc -gaming de laatste tijd door een soort gouden eeuw. Triple A Games? Laten we eens kijken, remakes, remakes, arme poorten, dezelfde formule keer op keer, meer arme poorten die Minecraft blos, niet-technisch-een-remake-but-but-the-same-formula, en. remakes, enz. En net als jij, gooi ik niet “schaduw” voor al die dingen. Ik vind de recente “remake” -boom eigenlijk niet erg. Er is een bepaald tijdperk van gaming (namelijk PlayStation/PlayStation 2 ERA, dus eind jaren negentig en begin 2000) die zoveel van remakes zullen halen vanwege het feit dat die spellen in dat tijdperk waren, hadden veel van hen een lage resolutie, niet -widescreen activa en slecht verouderd. Ga nieuwer en dingen gaan HD/breedbeeld, en super oude pixel -dingen zijn ook niet zo slecht ouder. Dus er is een rechtvaardiging voor remakes. Ik hield van de remake van Resident Evil 2 (en zelfs tot op zekere hoogte, 3, zelfs als het relatief overweldigend was). Beide zijn games waarvoor ik van tevoren de volledige prijs heb betaald en dat doe ik tegenwoordig niet vaak voor drievoudige games. Mijn grootste gamingwens op dit moment is die Final Fantasy IX (helemaal niet de beste game ooit of zo. ) Remake geruchten komen uit. En er zijn ook enkele originele ideeën over het drievoudige landschap geweest. Maar ik kan dit zeggen. Godzijdank het drievoudige een landschap is niet het enige dat we hebben. In feite heeft een groot bedrijf hier een kleinere gekocht en je zag wat er gebeurde. Het is net meer in liefde gekoppeld en je kunt beweren dat de originaliteit nog meer vertraagde. Grote budgetten kunnen soms meer mogelijkheden bieden, maar ik denk dat je potentieel van indietitels afwijst door Triple een titels te vermelden, doen gewoon dingen beter. Ze zijn niet noodzakelijkerwijs, en dat ze worden verplicht aan grote, beursgenoteerde uitgevers/bedrijven komt met zijn eigen set van nadelen.

Dit klinkt gewoon als een “Ik ben er teleurgesteld over, maar kan niet verder gaan, dus ik heb liever dat de ontwikkeling de ontwikkeling is gestopt”. Dat is jouw mening. Er zijn genoeg mensen die niet teleurgesteld zijn in moderne versies. Versie 1.18 (en tot op zekere hoogte, 1.16) Mijn passie voor dit spel nieuw leven in. 1.13+ is slechts een ander tijdperk, en een veel betere naar mijn mening. Niet iedereen denkt dat moderne versies perfect zijn. Verre van. Maar ook niet iedereen denkt dat het een teleurstelling is die moet eindigen. Nogmaals, verre van. Maar als je er teleurgesteld over bent, erken dat en blijf dan aan versies die je leuk vindt en/of ga verder met het spel. Het hoeft niet formeel te stoppen om dat te laten gebeuren. Andere games zijn er.

Wat betreft bonuspunt 6, dat is goed! Wanneer er iets groots komt (de originele doom denk ik), haasten al deze klonen zich om hun mening te geven over het idee. Minecraft staat geenszins boven al het andere in de Sandbox -ruimte in elk opzicht. Verre van. Maar ik ben het er niet mee eens dat alleen omdat het ouder is of omdat andere dingen dingen op sommige manieren beter doen, dat het zou moeten stoppen. Het ding is, een voortdurend ontwikkelend spel voor zo lang is zo zeldzaam dat het moeilijk is om te zeggen wat Minecraft zou moeten zijn. Het is voornamelijk games als een service (League of Legends) of MMO’s (die ook games zijn als een service) die zo lang voortdurend ontwikkeling krijgen. Maar een enkele aankoopspel wordt meer dan tien jaar bijgewerkt en constant,? Het is een zeldzaamheid. Dus er is in dat opzicht niet veel vastgesteld om te vergelijken met wat Miencraft zou moeten zijn. Sommigen denken dat het te veel is veranderd, niet te weinig.

Wat betreft mensen die verder gaan, ja? Dat gebeurt. Dingen eb en stromen, piek en achteruitgaan. Dat is alles. Mensen zeiden in de vroegere jaren 2010 hetzelfde soort dingen over Minecraft. Mensen die verder willen gaan, is anekdotisch, en de game die gewoon de winkel moet inpakken, omdat sommige mensen het gevoel hebben dat ze nu niet noodzakelijkerwijs niet meer waar zijn dan toen was.

Sorry als dat een beetje verspreid lijkt, maar ik lees het in brokken en plaatste toen mijn gedachten, omdat ik input wilde geven over wat leek op een constructief onderwerp dat er wat tijd in had gestopt. Ik ben het niet eens met veel van je punten, maar ik denk ook niet noodzakelijkerwijs dat je het mis hebt, en kom een ​​beetje waar je vandaan komt. Maar het klinkt alsof je net bent begonnen met verder gaan, maar dat je dat niet hebt kunnen doen. Je mening over het spel is dat het afneemt, leidt ertoe dat het vindt dat het gewoon op een hogere noot moet stoppen en eindigen in plaats van een lagere noot, om het gemakkelijker te maken om verder te gaan en met dingen te leven. Ik ben het er echter niet mee eens. Veel mensen, waaronder ikzelf, genieten nog steeds van het moderne spel.

Roldback -post om terugdraaien te herzien

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen

Bekijk het profiel van Agtrigormortis

  • Glowstone mijnwerker
  • Deelnemende datum: 18-10-2019
  • Berichten: 3.009
  • Lidgegevens

Ik denk dat updates moeten stoppen totdat ze de slechte prestaties oplossen die zoveel mensen op hun pc’s hebben met deze game

Ze lijken zich niet te concentreren op het optimaliseren van de game en hoe het op verschillende sets hardware loopt, ze haasten gewoon updates gedeeltelijk uit vanwege ongeduld van andere mensen die verwachten dat ze sneller naar buiten komen, maar ik denk dat dit verkeerd is, Ik denk dat het veel belangrijker is om ontwikkelaars de tijd te geven om een ​​product af te maken voordat ze het vrijgeven.

Als ze de prestatieproblemen op pc’s van mensen die aan de aanbevolen vereisten voldoen niet kunnen elimineren, dan moeten ze sommige mensen inhuren die dat kunnen, terwijl ik geen programmeur ben, weet ik dat er andere mensen in de Minecraft -gemeenschap zijn die mods hebben gemaakt , mensen die benchmarks hebben om te laten zien wat er nog meer kan worden gedaan om ervoor te zorgen.

Hoewel het de verantwoordelijkheid van een gamer is om de normale werking van hun apparaat te garanderen, kunnen ze niet echt niets doen aan software die niet efficiënt is met de hardware waarop ze het uitvoeren, behalve om het gewoon niet te gebruiken. En alle pc’s, ongeacht de hardware, hebben limieten, we kunnen de pc’s van mensen niet alleen de schuld geven elke keer dat ze klagen over een FPS -druppel in een game, soms is het soms niet zo eenvoudig omdat ze high -end machines kunnen hebben en nog steeds het kunnen hebben hetzelfde probleem. Zoals princes_garnet in een andere thread heeft uitgelegd, hebben mensen dit soort problemen gehad met Minecraft, zelfs op pc’s met de snelste desktop -CPU’s erin, dus het is duidelijk niet meer met de hardware meer, het is meer het geval dat Mojang gewoon inefficiënt is Hun software -engineering of het wegsnijden van dingen die niet te allen tijde in het spel hoeven te draaien.

Maar als ze hun spel niet optimaliseren, helpt het niet echt dat we meer inhoud aan het spel krijgen,

het kan de zaken er erger nog erger maken en totdat er voldoende druk uit de fandom is om Mojang aan te moedigen

Om updates vrij te geven die de lag -pieken op zelfs pc’s op zelfs PC’s verminderen met mid -tier of hardware die in de afgelopen 5 jaar is vrijgegeven,

We blijven hetzelfde gesprek voeren. Het is gewoon dom, dat we dit aan ontwikkelaars moeten uitleggen als zij degenen zijn

verantwoordelijk en hebben de kracht/mogelijkheid om het aan te pakken.

Roldback -post om terugdraaien te herzien

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen
  • Nieuw voortgebracht
  • Deelnemende datum: 3/3/2012
  • Berichten: 1.830
  • Minecraft: Princess_Garnet
  • Lidgegevens

Prestatieverbeteringen krijgen de aandacht niet zoals functieveranderingen, helaas. Kijk naar 1.15; Het wordt vaak genegeerd in de zegen van lof 1.13+ krijgt simpelweg omdat het “alleen bijen toegevoegd” of “niet eens alle problemen oploste die de game heeft”.

Het kan jammer zijn, maar het is de manier waarop onze wereld werkt. “Goed genoeg” is, nou ja. goed genoeg.

Er moet ook op worden gewezen dat veel mensen waarschijnlijk een spel spelen dat doorgaans erg CPU zwaar is op waarschijnlijk oudere, langzame, vaak mobiele (en lage kloksnelheid) CPU’s/pc’s. Vaak waarschijnlijk onder de minimumvereisten. De minimale/aanbevolen vereisten vragen om een ​​low-end Ivy Bridge/Mid Range Haswell respectievelijk aan de zijde van Intel, of pre-ryzen spullen aan de zijde van AMD (en AMD bood op dit moment alleen maar langzamer dingen aan). Dergelijke CPU’s zijn nu vrij oud, en Windows 10 verliezen ondersteuning in minder dan een paar jaar zal (althans officieel) iets afsnijden vóór de 8e generatie aan Intel’s zijde en de tweede Ryzen -generatie aan AMD’s zijde (en in drie jaar, die zullen ook ouder en langzamer zijn).

Dit wil niets zeggen dat ik niet graag zou willen zien dat de prestaties meer focus krijgen. Het is een van de dingen die ik graag zou willen zien. Maar ik leg alleen uit waarom een ​​dergelijke update die alleen op dat is, dat waarschijnlijk niet zal gebeuren. Het zou leuk zijn als Minecraft helemaal vrij was, ongeacht de omstandigheden, en liep op 32 tot 48 render afstand op nieuwe dingen, en soepel gespeeld op oude kern 2s met slechts 4 GB of 8 GB RAM, enzovoort, enzovoort. Maar ik verwacht niet dat de ontwikkeling ooit zal verschuiven naar de focus in die richting.

We moeten echter de veranderingen die onderweg kunnen gebeuren niet over het hoofd zien, zelfs als ze niet in een speciale update zijn. Ik heb veel slecht gedrag opgemerkt van oudere versies die in latere versies worden verbeterd.

Het is begrijpelijk dat u uw eigen redenen hebt waarom u denkt dat Mojang de ontwikkeling op Minecraft zou moeten stopzetten. Het is echter vermeldenswaard dat andere spelers verschillende perspectieven en voorkeuren met betrekking tot het spel kunnen hebben. Sommigen genieten misschien van het spel zoals het is, terwijl anderen specifieke functieverzoeken of modding -behoeften hebben die hen in Minecraft houden.

Bovendien is het vermeldenswaard dat de game -industrie enorm en divers is, waarbij zowel indie- als AAA -studio’s een breed scala aan games produceren die voor een ander doelgroepen zijn gericht. Wat zou kunnen werken voor de ene speler of studio werkt mogelijk niet voor anderen, en vice versa. Het is niet noodzakelijk een kwestie van welk type studio “superieur” is, maar eerder welk type spel of studio past bij de behoeften en voorkeuren van een bepaalde speler.

Ten slotte is het aan Mojang en de Minecraft -gemeenschap om te beslissen of en wanneer ze de ontwikkeling op het spel willen stoppen. Hoewel het begrijpelijk is dat sommige spelers zich misschien teleurgesteld voelen over bepaalde aspecten van het spel, is het belangrijk om te onthouden dat het spel constant evolueert en verandert, en het is aan de ontwikkelaars om de beste manier van handelen te bepalen voor de toekomst van de game.

[Hartelijke groeten]
Olivia DeVid

Dit is een geweldige eerste post, en ik ben het er helemaal mee eens. Het vat de dingen heel goed samen.

Dit wil niets zeggen dat de mening van het onderwerp starter verkeerd is. Iedereen heeft meningen en dat zijn ze tenslotte precies.

Maar ik kreeg de indruk dat iemand “voorbij” is wat Minecraft momenteel is, beseft dat het onwaarschijnlijk is dat het genoeg zal veranderen om te worden wat ze denken dat het zou moeten zijn, en de ontwikkeling wil zien stoppen om hen te helpen verder te gaan.

En dat deel waar ik het niet mee eens ben. Als dat het geval is, ga dan gewoon verder. De game hoeft niet te stoppen met veranderen om iemand verder te gaan. Het speellandschap is erg breed (en naar mijn mening, breder en zelfs rijker dan het ooit is geweest), dus als iemand een “meer” een bepaald spel is, zijn er talloze anderen die waarschijnlijk beter zullen volstaan.

Roldback -post om terugdraaien te herzien

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen

Bekijk het profiel van Agtrigormortis

  • Glowstone mijnwerker
  • Deelnemende datum: 18-10-2019
  • Berichten: 3.009
  • Lidgegevens

Prestatieverbeteringen krijgen de aandacht niet zoals functieveranderingen, helaas. Kijk naar 1.15; Het wordt vaak genegeerd in de zegen van lof 1.13+ krijgt simpelweg omdat het “alleen bijen toegevoegd” of “niet eens alle problemen oploste die de game heeft”.

Het kan jammer zijn, maar het is de manier waarop onze wereld werkt. “Goed genoeg” is, nou ja. goed genoeg.

Er moet ook op worden gewezen dat veel mensen waarschijnlijk een spel spelen dat doorgaans erg CPU zwaar is op waarschijnlijk oudere, langzame, vaak mobiele (en lage kloksnelheid) CPU’s/pc’s. Vaak waarschijnlijk onder de minimumvereisten. De minimale/aanbevolen vereisten vragen om een ​​low-end Ivy Bridge/Mid Range Haswell respectievelijk aan de zijde van Intel, of pre-ryzen spullen aan de zijde van AMD (en AMD bood op dit moment alleen maar langzamer dingen aan). Dergelijke CPU’s zijn nu vrij oud, en Windows 10 verliezen ondersteuning in minder dan een paar jaar zal (althans officieel) iets afsnijden vóór de 8e generatie aan Intel’s zijde en de tweede Ryzen -generatie aan AMD’s zijde (en in drie jaar, die zullen ook ouder en langzamer zijn).

Dit wil niets zeggen dat ik niet graag zou willen zien dat de prestaties meer focus krijgen. Het is een van de dingen die ik graag zou willen zien. Maar ik leg alleen uit waarom een ​​dergelijke update die alleen op dat is, dat waarschijnlijk niet zal gebeuren. Het zou leuk zijn als Minecraft helemaal vrij was, ongeacht de omstandigheden, en liep op 32 tot 48 render afstand op nieuwe dingen, en soepel gespeeld op oude kern 2s met slechts 4 GB of 8 GB RAM, enzovoort, enzovoort. Maar ik verwacht niet dat de ontwikkeling ooit zal verschuiven naar de focus in die richting.

We moeten echter de veranderingen die onderweg kunnen gebeuren niet over het hoofd zien, zelfs als ze niet in een speciale update zijn. Ik heb veel slecht gedrag opgemerkt van oudere versies die in latere versies worden verbeterd.

Dit is een geweldige eerste post, en ik ben het er helemaal mee eens. Het vat de dingen heel goed samen.

Dit wil niets zeggen dat de mening van het onderwerp starter verkeerd is. Iedereen heeft meningen en dat zijn ze tenslotte precies.

Maar ik kreeg de indruk dat iemand “voorbij” is wat Minecraft momenteel is, beseft dat het onwaarschijnlijk is dat het genoeg zal veranderen om te worden wat ze denken dat het zou moeten zijn, en de ontwikkeling wil zien stoppen om hen te helpen verder te gaan.

En dat deel waar ik het niet mee eens ben. Als dat het geval is, ga dan gewoon verder. De game hoeft niet te stoppen met veranderen om iemand verder te gaan. Het speellandschap is erg breed (en naar mijn mening, breder en zelfs rijker dan het ooit is geweest), dus als iemand een “meer” een bepaald spel is, zijn er talloze anderen die waarschijnlijk beter zullen volstaan.

Ik zie je punt, maar niemand die de basisprincipes van de technische wereld begrijpt, en je weet ook dat dit echt verwacht dat een Intel Core 2 Duo -systeem nieuwere versies van Minecraft goed zal draaien. Minecraft draaide altijd om afspeelbare framesnelheden op pc’s met dubbele kern CPU’s en 4 GB RAM, maar voor zover we kunnen zien dat het spel multi -threading gebruikt voor chunk loading -bewerkingen of wanneer de game laadt. Zelfs nadat het laden van chunk is afgelopen, zou ik niets minder aanbevelen dan een quad core CPU voor het spel en zelfs dan moeten die kernen krachtig zijn, niet alle quad cores worden gelijk gemaakt, ze hebben allemaal verschillende architecturen en kloksnelheden, zoals evenals L3 -cachegroottes. We moeten ook overwegen dat achtergrondtoepassingen ook CPU -threads/cores gebruiken, niet alleen de game zelf en een quad core CPU kan helpen voorkomen dat die achtergrond -apps de app interfereren die u gebruikt.

Maar elke nieuwe pc die de aanbevolen vereisten van Microsoft sterk overschrijdt, niet alleen om hen te ontmoeten, want deze game mag helemaal niet achterblijven met een 32 brokken render -afstand, het eerste probleem is dat deze pc -builds niet goedkoop zijn en zeker niet zijn Budget bouwt.

De tweede is 32 brokken render -afstand niet meer iets speciaals zoals het vroeger was, ongeveer 5 jaar geleden of meer hadden we dat argument kunnen maken met een recht gezicht, maar niet vandaag en er zijn gameplay -voordelen voor een verhoogde renderafstand, Om te beginnen kun je verder zien in de einddimensie, belangrijk voor het zien van buitenste eilanden met eindsteden en om spelers te helpen hun risico op sterven in de leegte te verminderen.

16 of minder brokken afstand van afstand zuigt gewoon voor iedereen, ik zou alleen maar aanraden om het als laatste redmiddel te doen.

Maar het is geen goede indicatie van een pc -afhandeling Minecraft, de enige reden waarom tablet- of console -apparaten zoals de Nintendo -schakelaar

zou hierop beperkt zijn, omdat het is wat we van een mobiel apparaat zouden verwachten.

Roldback -post om terugdraaien te herzien

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen
  • Nieuw voortgebracht
  • Deelnemende datum: 3/3/2012
  • Berichten: 1.830
  • Minecraft: Princess_Garnet
  • Lidgegevens

Ik zie je punt, maar niemand die de basisprincipes van de technische wereld begrijpt, en je weet ook dat dit echt verwacht dat een Intel Core 2 Duo -systeem nieuwere versies van Minecraft goed zal draaien.

Oh, het Core 2 -voorbeeld werd een beetje uit de lucht gehaald omdat het spel vroeger goed op hen liep, dus ik dacht dat het een goed baseline -voorbeeld zou kunnen zijn voor wat mensen kunnen wijzen en zeggen dat mogelijk zou moeten zijn. Natuurlijk verwacht ik echter niet dat ze voor altijd relevant blijven. Ik weet dat dingen verder gaan.

Dat gezegd hebbende, terwijl het wordt genoemd.

Ik vond het spel “soort van” erop, maar heeft natuurlijk een zware moeite bij het omgaan met het laden/renderen van terrein.

Ik heb de CPU gewijzigd in een Core 2 Quad Q9550 en het maakt eigenlijk heel weinig verschil. Dat verbaasde me omdat de dubbele kern op beide kernen maximaliseerde (en elke muziek die in een externe applicatie draaide, pauzeerde constant aan en uit bij het laden van terrein), dus ik verwachtte een beetje meer een verbetering.

Maar die Core 2 quads waren geen monolithische quad cores. Ze waren slechts een paar Core 2 -duo’s op één CPU die over de FSB communiceerde, die ze hier waarschijnlijk zwaar vertraagt.

Hoe dan ook, ze waren praktisch te traag voor het spel, zelfs toen, en ik zou vooral nog meer nu voor 1.18 en hoger.

De tweede is 32 brokken render -afstand niet meer iets speciaals zoals het vroeger was, ongeveer 5 jaar geleden of meer hadden we dat argument kunnen maken met een recht gezicht, maar niet vandaag en er zijn gameplay -voordelen voor een verhoogde renderafstand, Om te beginnen kun je verder zien in de einddimensie, belangrijk voor het zien van buitenste eilanden met eindsteden en om spelers te helpen hun risico op sterven in de leegte te verminderen.

Het is alleen niet speciaal voor het fundament. Het was voor het grootste deel moeilijk op Java uit de conceptie van het spel tot nu toe.

Vroeger liep ik op een renderafstand van maximaal 32 vele jaren geleden, te beginnen met versie 1.7 of zo, en tot 1.10. De framesnelheden waren af ​​en toe gedaald, maar ik koos ervoor om op die manier te spelen.

Ironisch genoeg had ik de beste prestatie die ik ooit heb gehad op hogere render -afstanden met versie 1.16, dat een kind van de 1.8+ coderingspraktijken.

Niet noodzakelijkerwijs geweldige prestaties. Waarschijnlijk niet rondom speelbaar. Maar dat is een render -afstand van 64, boven wat het spel native ondersteunt in Java. Dus een renderafstand van 32, of zelfs dan, was sommige grotendeels speelbaar als ik het wilde.

Maar ik gaf er niet meer om. Als je me 5+ jaar geleden had gevraagd, zou ik zeggen dat ik niet minder dan 32 render -afstand wilde, en 24 minimum. Maar toen ik bijgewerkt en een nieuwe wereld begon in een stroom (op dat moment, 1.16) Versie, ik kies een renderafstand van ongeveer 20, later 16 (die bossige bladeren deden het, en ik heb ze nodig!), in plaats daarvan nu vanwege shaders (en prestaties). Een zeer hoge renderafstand geeft u meestal een beetje meer uitzicht op een smalle strook van de horizon. En ik voelde het om het algemene imago te verfraaien, deed er meer toe dan dat. Toegegeven, ik zou graag minstens 20 of 24 over 16 houden, en ik zou soms zelfs 32 nemen (wanneer ik vliegen of omhoog in de bergen, de hoge afstand meer wordt opgemerkt). Maar verder denk ik dat het er echt gek uit begint te zien. Ik zou alleen boven 32 spelen als ik ook met grote biomen speelde. Het zien van maximaal een half dozijn biomen heeft invloed op de onderdompeling van de wereld voor mij, en ik zou het nooit leuk vinden.

En je kunt het einde ingaan en de renderafstand gemakkelijk op Java draaien om eindsteden te vinden. Het is lang niet zo veeleisend als de andere twee dimensies.

Hoe dan ook, ja, ik zou absoluut dol zijn op een prestatie -update. Maar gezien hoe gesteente en java verschillende spellen eronder zijn, en hoe 1.15 was schijnbaar niet zo gewaardeerd, ik weet niet zeker of we dat nog een keer zullen zien. Spelers zijn ontvankelijker voor functies, dus ik denk dat dat is waar nieuwe updates zich op zullen concentreren (en hopelijk komen updates, omdat ik het er niet mee eens ben dat ze moeten stoppen). Het komt wel goed als ze dingen blijven verbeteren als ze op de achtergrond gaan om eerlijk te zijn. Onthoud wanneer de verlichting het gewoon zou verpesten? Of was dat niets in het fundament? Maar dat is gewoon niets meer in Java, en godzijdank. Verbeteringen naarmate ze gaan is ook prima door mij. Hoeft geen hele update te zijn.

Laatst bewerkt door Princess_Garnet: 15 april 2023
Roldback -post om terugdraaien te herzien

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen

Bekijk het profiel van Agtrigormortis

  • Glowstone mijnwerker
  • Deelnemende datum: 18-10-2019
  • Berichten: 3.009
  • Lidgegevens

Oh, het Core 2 -voorbeeld werd een beetje uit de lucht gehaald omdat het spel vroeger goed op hen liep, dus ik dacht dat het een goed baseline -voorbeeld zou kunnen zijn voor wat mensen kunnen wijzen en zeggen dat mogelijk zou moeten zijn. Natuurlijk verwacht ik echter niet dat ze voor altijd relevant blijven. Ik weet dat dingen verder gaan.

Dat gezegd hebbende, terwijl het wordt genoemd.

Ik vond het spel “soort van” erop, maar heeft natuurlijk een zware moeite bij het omgaan met het laden/renderen van terrein.

Ik heb de CPU gewijzigd in een Core 2 Quad Q9550 en het maakt eigenlijk heel weinig verschil. Dat verbaasde me omdat de dubbele kern op beide kernen maximaliseerde (en elke muziek die in een externe applicatie draaide, pauzeerde constant aan en uit bij het laden van terrein), dus ik verwachtte een beetje meer een verbetering.

Maar die Core 2 quads waren geen monolithische quad cores. Ze waren slechts een paar Core 2 -duo’s op één CPU die over de FSB communiceerde, die ze hier waarschijnlijk zwaar vertraagt.

Hoe dan ook, ze waren praktisch te traag voor het spel, zelfs toen, en ik zou vooral nog meer nu voor 1.18 en hoger.

Het is alleen niet speciaal voor het fundament. Het was voor het grootste deel moeilijk op Java uit de conceptie van het spel tot nu toe.

Vroeger liep ik op een renderafstand van maximaal 32 vele jaren geleden, te beginnen met versie 1.7 of zo, en tot 1.10. De framesnelheden waren af ​​en toe gedaald, maar ik koos ervoor om op die manier te spelen.

Ironisch genoeg had ik de beste prestatie die ik ooit heb gehad op hogere render -afstanden met versie 1.16, dat een kind van de 1.8+ coderingspraktijken.

Niet noodzakelijkerwijs geweldige prestaties. Waarschijnlijk niet rondom speelbaar. Maar dat is een render -afstand van 64, boven wat het spel native ondersteunt in Java. Dus een renderafstand van 32, of zelfs dan, was sommige grotendeels speelbaar als ik het wilde.

Maar ik gaf er niet meer om. Als je me 5+ jaar geleden had gevraagd, zou ik zeggen dat ik niet minder dan 32 render -afstand wilde, en 24 minimum. Maar toen ik bijgewerkt en een nieuwe wereld begon in een stroom (op dat moment, 1.16) Versie, ik kies een renderafstand van ongeveer 20, later 16 (die bossige bladeren deden het, en ik heb ze nodig!), in plaats daarvan nu vanwege shaders (en prestaties). Een zeer hoge renderafstand geeft u meestal een beetje meer uitzicht op een smalle strook van de horizon. En ik voelde het om het algemene imago te verfraaien, deed er meer toe dan dat. Toegegeven, ik zou graag minstens 20 of 24 over 16 houden, en ik zou soms zelfs 32 nemen (wanneer ik vliegen of omhoog in de bergen, de hoge afstand meer wordt opgemerkt). Maar verder denk ik dat het er echt gek uit begint te zien. Ik zou alleen boven 32 spelen als ik ook met grote biomen speelde. Het zien van maximaal een half dozijn biomen heeft invloed op de onderdompeling van de wereld voor mij, en ik zou het nooit leuk vinden.

En je kunt het einde ingaan en de renderafstand gemakkelijk op Java draaien om eindsteden te vinden. Het is lang niet zo veeleisend als de andere twee dimensies.

Hoe dan ook, ja, ik zou absoluut dol zijn op een prestatie -update. Maar gezien hoe gesteente en java verschillende spellen eronder zijn, en hoe 1.15 was schijnbaar niet zo gewaardeerd, ik weet niet zeker of we dat nog een keer zullen zien. Spelers zijn ontvankelijker voor functies, dus ik denk dat dat is waar nieuwe updates zich op zullen concentreren (en hopelijk komen updates, omdat ik het er niet mee eens ben dat ze moeten stoppen). Het komt wel goed als ze dingen blijven verbeteren als ze op de achtergrond gaan om eerlijk te zijn. Onthoud wanneer de verlichting het gewoon zou verpesten? Of was dat niets in het fundament? Maar dat is gewoon niets meer in Java, en godzijdank. Verbeteringen naarmate ze gaan is ook prima door mij. Hoeft geen hele update te zijn.

Ik hou van hoge render -afstanden om de redenen die je zou doen, het stelt ons in staat om gemakkelijker te zien welke biomen ons voor zijn, in de overworld is het een groot voordeel geweest voor mij en andere mensen die op mijn thuisoverlevingsserver spelen.

32 brokken render afstand is het equivalent van 1024 blokken kwadraat of 512 uit het midden in elke richting, het zijn veel blokken die het spel in het geheugen moet laden, maar we moeten onthouden weergegeven blokken zelf hebben alleen invloed op wat de speler te zien is. Maar deze blokken zullen een Redstone -teken niet bijwerken, tenzij een speler dichtbij genoeg is.

Ik wou dat Minecarts de tekenradius konden omzeilen of in ieder geval voor Mojang om ons een variant van een minecart te geven die 1 brok laden zou houden, omdat dit spelers in staat zou stellen items naar elkaar te sturen over lange afstanden met een Minecart -trein of Shulker in borstsysteem.

Met een prestatie -update met zo’n functie kan ooit praktisch worden, heb ik vermoed dat de (ironische) reden dat ze deze functie niet bij Minecarts niet hebben toegevoegd, niet te maken heeft met evenwicht of zorgen dat deze zou worden misbruikt door autocrinders, (( Die helaas ook bestaat voor Shulker Farms, en naar mijn mening moet dit worden vervangen door continu te paaiende shulkers in eindsteden om al geplunderde eindstadstructuren voor andere spelers op een server te compenseren, zelfs als alle shulkers al waren vermoord door Eerdere spelers, een veel betere manier om Shulker Shells en Boxes hernieuwbaar te maken), het is meer het geval dat het vertraging op servers veroorzaakt.

Roldback -post om terugdraaien te herzien

  • Bekijk het gebruikersprofiel
  • Bekijk berichten
  • Bericht versturen
  • Enterdragon Slayer
  • Deelnemende datum: 10/6/2013
  • Berichten: 13,160
  • Minecraft: ThemasterCaver
  • Lidgegevens

Ik zie je punt, maar niemand die de basisprincipes van de technische wereld begrijpt, en je weet ook dat dit echt verwacht dat een Intel Core 2 Duo -systeem nieuwere versies van Minecraft goed zal draaien

Niet ik; Als een zeer deskundige modder weet ik precies hoeveel van invloed is op het toevoegen van nieuwe inhoud, gebaseerd op het feit dat ik vrijwel geen gevolgen heb waargenomen voor minstens duizend nieuwe functies (meer dan 350 blokken en items, 100 biomen, 45 Nieuwe mobs/entiteit en/of varianten hiervan, tientallen nieuwe wereldgeneratie, waaronder tientallen nieuwe soorten grotten, bomen, structuren, enz.).

Vanille 1.6.4 Bij maximale instellingen (merk op dat de renderafstand eigenlijk slechts 10 brokken is, omdat de interne server alleen maar veel laadt, ongeacht wat de render -afstand is):

TMCWV5 bij maximale instellingen (16 chunk render -afstand, die ongeveer 2 laadt.5 keer zoveel brokken, 1089 versus 441; Ik heb de weergave ingesteld zodat hetzelfde aantal brokken wordt weergegeven, 842, hoewel dit niet de enige factor is die FPS beïnvloedt):

Het enige dat echt invloed heeft op het gebruik van hulpbronnen is het aantal geladen blokken en entiteiten, en dat verklaart bijna alles wat de game nodig heeft omdat er zoveel zijn – zoiets als 22 miljoen bij 16 brokken (en eigenlijk twee keer dat aantal omdat de client en server Heeft twee exemplaren van de wereld geladen, zelfs in singleplayer), waarvoor ongeveer 106 MB geheugen vereist is (voor beide zijden). Hier is een vergelijking van VisualVM Profiler -resultaten voor 1.6.4 en TMCWV5 (nogmaals, let op de verschillen in geladen brokken):

Vanille 1.6.4; Beide liepen ongeveer 5 minuten:

TMCWV5; Merk op dat ik de renderafstand van 8 tot 16 verhoogd nabij het begin, waardoor het gebruik van CPU tot ongeveer 40%werd gestegen; Nadien daalt het veel sneller dan in vanille, wat nog steeds al geruime tijd veel chunk -updates deed, terwijl het veel sneller daalt in TMCW, en ondanks het laden van meer dan twee keer zoveel brokken waren er minder afvalcollectioncycli, wat aangeeft dat TMCW wijst het geheugen toe met een lager tempo – en gebruikt ook minder CPU ondanks het laden van veel meer gegevens – dat is het vermogen van optimalisatie, en 1.6.4 is erg licht in vergelijking met moderne versies:

In feite waren dit de systeemvereisten vanaf 1.6 – waarvan kan worden verwacht dat deze nog steeds van toepassing is op TMCW, zelfs omdat het veel grote updates heeft aan nieuwe inhoud:

Laatst bijgewerkt: 06 juli 2013 23:47 PM CEST

Minimale vereisten:
CPU: Intel P4/Netburst -architectuur of zijn AMD -equivalent (AMD K7)

RAM: 2 GB
GPU: Intel GMA 950 of AMD -equivalent met OpenGL 1.2 Ondersteuning
HDD: Minstens 90 MB voor gamekern- en geluidsbestanden
Java Runtime Environment (JRE) 6 of UP is vereist om het spel te kunnen uitvoeren.

Aanbevolen vereisten:
CPU: Intel Pentium D of AMD Athlon 64 (K8) 2.6 GHz
RAM: 4 GB
GPU: GeForce 6xxx of ATI Radeon 9xxx en op met OpenGL 2 -ondersteuning (exclusief geïntegreerde chipsets)
HDD: 150 MB

Hoe oud is de aanbevolen hardware?

De eerste processor van het merk, codenaam Smithfield en vervaardigd tijdens het 90 nm -proces, werd uitgebracht op 25 mei, 2005, Gevolgd door de 65 nm voorloper negen maanden later.

Gelanceerd op 14 april, 2004, De GeForce 6-familie introduceerde Purevideo na het werken voor video, SLI-technologie en Shader Model 3.0 Ondersteuning (compliant met Microsoft DirectX 9.0c Specificatie en OpenGL 2.0).

Hoe verhoudt de laadtijd en wereldcreatie zich? 1.6.4 zou veel sneller moeten zijn omdat de wereldgeneratie relatief zo ​​eenvoudig is en het heeft veel minder dingen te laden, goed?

[19:11:13] 2023-04-15 19:11:13 [Client] [Info] Gebruiker instellen: ThemasterCaver
[19:11:13] 2023-04-15 19:11:13 [client] [info] (sessie-ID is NULL)
[19:11:13] 2023-04-15 19:11:13 [Client] [Info] LWJGL-versie: 2.9.0
[19:11:14] 2023-04-15 19:11:14 [Client] [info] ResourcEmanager opnieuw laden: standaard, modtextures
[19:11:14]
[19:11:14] Soundsystem opstarten.
[19:11:14] LWJGL Openal initialiseren
[19:11:14] (De LWJGL -binding van openal. Zie http: // www voor meer informatie.lwjgl.org)
[19:11:14] Openal geïnitialiseerd.
[19:11:15]
[19:11:15] 2023-04-15 19:11:15 [Client] [Ernstige] Rijken: server niet beschikbaar!
[19:11:48] 2023-04-15 19:11:48 [server] [INFO] Integrated Minecraft Server Starting versie 1.6.4
[19:11:48] 2023-04-15 19:11:48 [server] [INFO] KEYPAIR genereren
[19:11:49] 2023-04-15 19:11:49 [Server] [Info] Kaart converteren!
[19:11:49] 2023-04-15 19:11:49 [server] [info] scanmappen.
[19:11:49] 2023-04-15 19:11:49 [server] [INFO] Totale conversie is 0
[19:11:49] 2023-04-15 19:11:49 [server] [INFO] Startregio voorbereiden voor niveau 0
[19:11:50] 2023-04-15 19:11:50 [Server] [Info] Spawn-gebied voorbereiden: 12%
[19:11:51] 2023-04-15 19:11:51 [Server] [Info] Spawn-gebied voorbereiden: 36%
[19:11:52] 2023-04-15 19:11:52 [server] [Info] Spawn-gebied voorbereiden: 60%
[19:11:53] 2023-04-15 19:11:53 [Server] [Info] Spawn-gebied voorbereiden: 86%
[19:11:54] 2023-04-15 19:11:54 [server] [info] ThemasterCaver [/127.0.0.1: 0] ingelogd met entiteit ID 266 op (-94.5, 64.0, 244.5)
[19:11:54] 2023-04-15 19:11:54 [Server] [Info] ThemasterCaver kwam bij het spel

[18:21:25] 2023-04-15 18:21:25 [Client] [Info] Gebruiker instellen: ThemasterCaver
[18:21:25] 2023-04-15 18:21:25 [client] [info] (sessie-ID is NULL)
[18:21:26] 2023-04-15 18:21:26 [Client] [Info] LWJGL-versie: 2.9.0
[18:21:26] 2023-04-15 18:21:26 [Client] [Info] ResourCemanager opnieuw laden: standaard, modtextures
[18:21:27]
[18:21:27] Soundsystem opstarten.
[18:21:27] LWJGL Openal initialiseren
[18:21:27] (De LWJGL -binding van openal. Zie http: // www voor meer informatie.lwjgl.org)
[18:21:27] Openal geïnitialiseerd.
[18:21:27]
[18:22:04] 2023-04-15 18:22:04 [server] [INFO] Integrated Minecraft Server Starting versie 1.6.4
[18:22:04] 2023-04-15 18:22:04 [server] [INFO] KEYPAIR genereren
[18:22:04] 2023-04-15 18:22:04 [server] [INFO] Startregio voorbereiden voor niveau 0
[18:22:05] 2023-04-15 18:22:05 [server] [INFO] Spawn-gebied voorbereiden: 19%
[18:22:06] 2023-04-15 18:22:06 [Server] [Info] Spawn-gebied voorbereiden: 58%
[18:22:07] 2023-04-15 18:22:07 [server] [Info] Spawn Area voorbereiden: 99%
[18:22:07] 2023-04-15 18:22:07 [server] [info] ThemasterCaver [/127.0.0.1: 0] ingelogd met entiteit ID 137 op (-245.5, 70.0, -253.5)
[18:22:07] 2023-04-15 18:22:07 [Server] [Info] ThemasterCaver kwam bij het spel

Maar op de een of andere manier (!) TMCW duurde slechts de helft zoveel tijd om een ​​nieuwe wereld te genereren, ondanks dat het veel complexer was – nogmaals, de kracht van optimalisatie. 1.13 is absoluut angstaanjagend in vergelijking, aangezien het multithreaded chunk -generatie heeft, maar veel langer duurde dan vanille 1.6.4:

[17:55:31] [Server thread/info]: Integrated Minecraft Server Starting versie 1.13.2
[17:55:31] [Server thread/info]: Keypair genereren
[17:55:31] [Server thread/info]: nieuw gegevenspakket vanille gevonden, automatisch laden
[17:55:31] [Server thread/info]: resourceManager opnieuw laden: standaard
[17:55:32] [Server thread/info]: geladen 524 recepten
[17:55:33] [Server Thread/Info]: Loaded 571 vooruitgang
[17:55:36] [Server Thread/Info]: Startgebied voorbereiden voor Dimension Minecraft: Overworld
[17:55:37] [Server thread/info]: Spawn -gebied voorbereiden: 0%
[17:55:37] [Server thread/info]: Spawn -gebied voorbereiden: 4%
[17:55:38] [Server thread/info]: Spawn -gebied voorbereiden: 8%
[17:55:38] [Server thread/info]: Spawn -gebied voorbereiden: 12%
[17:55:38] [Server thread/info]: Spawn -gebied voorbereiden: 16%
[17:55:39] [Server thread/info]: Spawn -gebied voorbereiden: 20%
[17:55:39] [Server thread/info]: Spawn -gebied voorbereiden: 24%
[17:55:39] [Server thread/info]: Spawn -gebied voorbereiden: 28%
[17:55:40] [Server thread/info]: Spawn -gebied voorbereiden: 32%
[17:55:40] [Server thread/info]: Spawn -gebied voorbereiden: 36%
[17:55:40] [Server thread/info]: Spawn -gebied voorbereiden: 40%
[17:55:40] [Server thread/info]: Spawn -gebied voorbereiden: 44%
[17:55:41] [Server thread/info]: Spawn -gebied voorbereiden: 48%
[17:55:41] [Server thread/info]: Spawn -gebied voorbereiden: 52%
[17:55:41] [Server thread/info]: Spawn -gebied voorbereiden: 56%
[17:55:41] [Server thread/info]: Spawn -gebied voorbereiden: 60%
[17:55:42] [Server thread/info]: Spawn -gebied voorbereiden: 64%
[17:55:42] [Server thread/info]: Spawn -gebied voorbereiden: 68%
[17:55:42] [Server thread/info]: Spawn -gebied voorbereiden: 72%
[17:55:43] [Server thread/info]: Spawn -gebied voorbereiden: 76%
[17:55:43] [Server thread/info]: Spawn -gebied voorbereiden: 80%
[17:55:43] [Server thread/info]: Spawn -gebied voorbereiden: 84%
[17:55:43] [Server thread/info]: Spawn -gebied voorbereiden: 88%
[17:55:44] [Server thread/info]: Spawn -gebied voorbereiden: 92%
[17:55:44] [Server thread/info]: Spawn -gebied voorbereiden: 96%
[17:55:44] [Server thread/info]: Spawn -gebied voorbereiden: 100%
[17:55:44] [Server thread/info]: tijd verstreken: 8520 MS
[17:55:45] [Server thread/info]: weergave van de weergave afstand naar 12, van 10
[17:55:46] [Server thread/info]: themasterCaver [lokaal: e: c0336e00] ingelogd met entiteit ID 754 op (58.5, 71.0, -104.5)
[17:55:46] [Server thread/info]: ThemasterCaver kwam bij het spel

De enige plaats waar TMCW merkbaar zwaarder is, is in de reddingsgrootte, wat te wijten is aan de sterk verhoogde complexiteit van de wereld, zoals aangegeven door de volgende MEDIT -analyses (beide gebieden hebben even groot):

De linkerkolom is van een wereld gemaakt in 1.6.4; In beide gevallen vertegenwoordigen deze volledig onderzochte regio’s (het verlichten van grotten verhoogt de complexiteit van gegevens vanwege de bloklichtkaart, waardoor elke reductie van de relatief kleine hoeveelheid ertsen wordt afgevoerd):

1.6.4; 138 blokken / blokvarianten en 347 entiteiten:

(0: 0), lucht, 25735948
(1: 0), steen, 6828349
(2: 0), gras, 84800
(3: 0), vuil, 754782
(4: 0), Cobblestone, 3178
(5: 0), houtplanken, 3435
(7: 0), Bedrock, 406323
(8: 1), water (actief), 41072
(10: 0), lava (actief), 78740
(12: 0), Sand, 145920
(13: 0), Gravel, 229644
(14: 0), Gold Ore, 4276
(15: 0), ijzererts, 46358
(16: 0), Coal Ore, 87467
(17: 0), Wood, 1526
(17: 1), dennenhout, 1692
(17: 2), Birch Wood, 320
(17: 3), Jungle Wood, 7596
(17: 4), hout, 73
(17: 8), hout, 52
(18: 0), bladeren, 29834
(18: 1), dennenbladeren, 7836
(18: 2), berkenbladeren, 2202
(18: 3), Jungle Leaves, 20209
(18: 8), bladeren (rottend), 8805
(18: 9), dennenbladeren (rottend), 5155
(18:10), berkenbladeren (rottend), 663
(18:11), Jungle Leaves (rottend), 6796
(21: 0), lapis lazuli erts, 1784
(24: 0), zandsteen, 48869
(30: 0), web, 343
(31: 1), Tall Grass, 19371
(31: 2), Fern, 828
(32: 0), dode struik, 74
(35:15), zwarte wol, 1
(37: 0), bloem, 348
(38: 0), Rose, 90
(39: 0), bruine paddenstoel, 53
(40: 0), rode paddestoel, 35
(43: 0), dubbele stenen plaat, 22
(48: 0), Moss Stone, 497
(49: 0), Obsidian, 808
(50: 1), Torch, 12
(50: 2), Torch, 10
(50: 3), Torch, 12
(50: 4), Torch, 4
(52: 0), Monster Spawner, 14
(53: 0), houten trappen, 116
(53: 1), houten trappen, 89
(53: 2), houten trappen, 130
(53: 3), houten trappen, 83
(54: 2), borst, 3
(54: 3), borst, 5
(54: 4), borst, 2
(54: 5), borst, 4
(56: 0), Diamond Ore, 1610
(59: 2), gewassen, 7
(59: 3), gewassen, 11
(59: 4), gewassen, 16
(59: 5), gewassen, 17
(59: 6), gewassen, 14
(59: 7), gewassen, 47
(60: 7), landbouwgrond, 168
(64: 0), houten deur, 1
(64: 1), houten deur, 7
(64: 2), houten deur, 4
(64: 8), houten deur, 12
(65: 2), ladder, 8
(65: 4), ladder, 9
(66: 0), Rail, 312
(66: 1), Rail, 217
(66: 2), Rail, 1
(66: 7), Rail, 1
(66: 9), Rail, 1
(67: 0), stenen trappen, 1
(67: 1), stenen trappen, 2
(67: 3), stenen trappen, 3
(72: 0), houten drukplaat, 5
(73: 0), Redstone Ore, 12837
(78: 0), sneeuwlaag, 13325
(79: 0), Ice, 850
(81: 0), Cactus, 53
(81: 1), Cactus, 2
(81: 2), Cactus, 2
(81: 3), Cactus, 2
(81: 4), Cactus, 3
(81: 5), Cactus, 7
(81: 6), Cactus, 8
(81: 7), Cactus, 3
(81: 9), Cactus, 4
(81:11), Cactus, 2
(81:12), Cactus, 1
(82: 0), klei, 626
(83: 0), Sugar Cane, 46
(83: 2), Sugar Cane, 1
(83: 4), Sugar Cane, 1
(83: 6), Sugar Cane, 1
(83: 7), Sugar Cane, 1
(85: 0), hek, 1463
(102: 0), glazen paneel, 76
(106: 0), wijnstokken, 8
(106: 1), wijnstokken, 5448
(106: 2), wijnstokken, 4611
(106: 3), wijnstokken, 13
(106: 4), wijnstokken, 5507
(106: 5), wijnstokken, 4
(106: 6), wijnstokken, 13
(106: 8), wijnstokken, 4345
(106: 9), wijnstokken, 7
(106: 10), wijnstokken, 1
(106: 11), wijnstokken, 1
(106: 12), wijnstokken, 12
(111: 0), Lilypad, 6
(127: 0), cacaoblant, 5
(127: 1), Cacao Plant, 4
(127: 2), Cacao Plant, 7
(127: 3), Cacao Plant, 3
(127: 4), cacaoblant, 6
(127: 5), Cocoa Plant, 2
(127: 6), cacaoblant, 4
(127: 7), cacaoblant, 6
(127: 8), Cacao Plant, 4
(127: 9), Cocoa Plant, 7
(127: 10), cacaoblant, 5
(127: 11), cacaoblant, 13
(141: 2), wortelen, 2
(141: 3), wortelen, 6
(141: 4), wortelen, 2
(141: 5), wortelen, 2
(141: 6), wortelen, 7
(141: 7), wortelen, 9
(142: 2), aardappelen, 3
(142: 3), aardappelen, 3
(142: 4), aardappelen, 4
(142: 5), aardappelen, 5
(142: 6), aardappelen, 5
(142: 7), aardappelen, 8
,,
,,347
Bat, Bat, 22
Kip, kip, 52
Koe, koe, 28
Creeper, Creeper, 29
Item, ei, 13
Item, grind, 1
Item, rail, 5
Item, zaden, 1
Item, string, 1
Minecartchest, Minecartchest, 9
Varken, varken, 77
Schapen, schapen, 31
Skelet, skelet, 30
Spider, Spider, 2
Inktvis, inktvis, 8
Villager, dorpsbewoner, 18
Zombie, Zombie, 20
,,
,,28
Borst, borst, 14
Mobspawner, Mobspawner, 14

TMCWV5; 283 blokken / blokvarianten en 351 entiteiten; Er zijn ook ongeveer twee keer zoveel kisten en mob -spawners, voornamelijk vanwege willekeurige variatie; Merk op dat, ondanks dat het terrein gemiddeld hoger is, er meer luchtblokken zijn dan de vanillewereld had (er zijn slechts ongeveer de helft van de lavablokken vanwege het feit dat de grotlaag van de grot slechts 3 lagen diep is, ook mogelijk variatie omdat deze gebieden waren slechts 368×368 blokken):

(0: 0), lucht, 26155281
(1: 0), steen, 4762059
(1: 1), steen, 219949
(1: 3), steen, 391886
(1: 5), steen, 618613
(1: 8), steen, 6143
(1:15), steen, 27
(2: 0), gras, 87200
(2: 1), gras, 272
(3: 0), vuil, 685957
(3: 1), vuil, 134
(4: 0), Cobblestone, 1205
(5: 0), houtplanken, 1355
(5: 1), houtplanken, 3961
(5: 3), Wood Planks, 179
(5: 4), houtplanken, 3
(7: 1), Bedrock, 117204
(7: 2), Bedrock, 2019
(7: 8), Bedrock, 16201
(9: 0), Water, 126756
(11: 0), Lava, 38922
(12: 0), Sand, 19473
(12: 1), zand, 134652
(13: 0), Gravel, 110853
(13: 1), Gravel, 76175
(14: 0), Gold Ore, 3957
(14: 2), Gold Ore, 534
(15: 0), ijzererts, 40795
(15: 2), ijzererts, 5478
(16: 0), Coal Ore, 75301
(16: 2), Coal Ore, 9427
(17: 0), Wood, 3237
(17: 1), dennenhout, 3799
(17: 2), Birch Wood, 1142
(17: 3), Jungle Wood, 3517
(17: 4), hout, 13
(17: 5), hout, 12
(17: 6), hout, 4
(17: 7), hout, 9
(17: 8), Wood, 4

(17:10), Wood, 5
(17:12), Wood, 1196
(17:13), Wood, 802
(17:14), Wood, 186
(17:15), Wood, 1356
(18: 0), bladeren, 47912
(18: 1), dennenbladeren, 36424
(18: 2), berkenbladeren, 9357
(18: 3), Jungle Leaves, 18138
(21: 0), lapis lazuli erts, 1930
(21: 2), lapis lazuli erts, 227
(24: 0), zandsteen, 273
(24: 4), zandsteen, 15955
(30: 0), web, 1067
(31: 0), (ongebruikte struik), 11305
(31: 1), hoog gras, 1580
(31: 2), varen, 58
(31: 3), (ongebruikte struik), 52
(32: 0), dode struik, 97
(35:15), zwarte wol, 3
(37: 0), Flower, 215
(37: 1), bloem, 53
(37: 2), bloem, 83
(37: 3), bloem, 61
(37: 4), bloem, 20
(37: 6), bloem, 42
(37: 7), Flower, 43
(37: 8), bloem, 42
(37: 9), bloem, 53
(37:10), Flower, 44
(37:11), Flower, 52
(37:12), Flower, 49
(37:13), Flower, 59
(37:14), Flower, 26
(37:15), Flower, 37
(38: 0), Rose, 181
(39: 0), bruine paddestoel, 296
(39: 1), bruine paddestoel, 77
(39: 2), bruine paddestoel, 86
(39: 3), bruine paddestoel, 69
(39: 4), bruine paddestoel, 90
(43: 0), dubbele stenen plaat, 11
(48: 0), Moss Stone, 875
(49: 0), Obsidian, 2156
(52: 0), Monster Spawner, 35
(53: 8), houten trappen, 77
(53: 9), houten trappen, 92
(53:10), houten trappen, 58
(53:11), houten trappen, 39
(54: 2), borst, 9
(54: 3), borst, 8
(54: 4), borst, 5
(54: 5), borst, 9

(56: 2), Diamond Ore, 133
(59: 2), gewassen, 5
(59: 3), gewassen, 7
(59: 4), gewassen, 5
(59: 5), gewassen, 13
(59: 6), gewassen, 6
(59: 7), gewassen, 20
(60: 7), landbouwgrond, 112
(64: 0), houten deur, 3
(64: 1), houten deur, 7
(64: 2), houten deur, 1
(64: 8), houten deur, 10
(64: 9), houten deur, 1
(65: 2), ladder, 4
(65: 4), ladder, 9
(66: 0), Rail, 466
(66: 1), Rail, 517
(72: 2), houten drukplaat, 4
(73: 0), Redstone Ore, 8080
(73: 2), Redstone Ore, 1062
(75: 1), Redstone Torch (uit), 25
(75: 2), Redstone Torch (uit), 16
(75: 3), Redstone Torch (uit), 17
(75: 4), Redstone Torch (UIT), 24
(75: 9), Redstone Torch (off), 12
(75:10), Redstone Torch (uit), 7
(75:11), Redstone Torch (uit), 7
(75:12), Redstone Torch (uit), 8
(75:13), Redstone Torch (off), 8
(81: 0), Cactus, 18
(81: 5), Cactus, 1
(81: 8), Cactus, 11
(81: 9), Cactus, 1
(81:10), Cactus, 1
(81:13), Cactus, 1
(82: 0), klei, 2141
(83: 0), Sugar Cane, 65
(83: 1), Sugar Cane, 1
(83: 3), Sugar Cane, 1
(83: 4), Sugar Cane, 1
(83: 5), Sugar Cane, 2
(83: 6), Sugar Cane, 1
(85: 0), hek, 880
(85: 1), hek, 2244
(85: 3), hek, 116
(85: 4), hek, 4
(98: 0), stenen bakstenen, 1613

(98: 2), gebarsten stenen stenen, 478
(98: 3), Circle Stone Bricks, 55
(99: 1), enorme bruine paddestoel (noordwest), 68
(99: 2), enorme bruine paddestoel (noord), 49
(99: 3), enorme bruine paddestoel (noordoostelijk), 68
(99: 4), enorme bruine paddestoel (west), 45
(99: 5), enorme bruine paddestoel (boven), 141
(99: 6), enorme bruine paddestoel (oost), 45
(99: 7), enorme bruine paddestoel (zuidwesten), 54
(99: 8), enorme bruine paddestoel (zuid), 41
(99: 9), enorme bruine paddestoel (zuidoosten), 54
(99:10), enorme bruine paddestoel (stengel), 79
(99:11), enorme bruine paddenstoel, 13
(100: 1), enorme rode paddestoel (noordwest), 47
(100: 2), enorme rode paddestoel (noord), 43
(100: 3), enorme rode paddestoel (noordoosten), 47
(100: 4), enorme rode paddestoel (west), 40
(100: 5), enorme rode paddestoel (boven), 162
(100: 6), enorme rode paddestoel (oost), 39
(100: 7), enorme rode paddestoel (zuidwesten), 45
(100: 8), enorme rode paddestoel (zuid), 39
(100: 9), enorme rode paddestoel (zuidoosten), 43
(100: 10), enorme rode paddestoel (stengel), 76
(100: 11), enorme rode paddestoel, 33
(102: 0), glazen paneel, 57
(103: 0), Watermelon, 2
(106: 0), wijnstokken, 37
(106: 1), wijnstokken, 2615
(106: 2), Vines, 1981
(106: 3), wijnstokken, 11
(106: 4), wijnstokken, 2570
(106: 5), wijnstokken, 8
(106: 6), wijnstokken, 14
(106: 8), wijnstokken, 2034
(106: 9), wijnstokken, 15
(106: 10), wijnstokken, 4
(106: 12), wijnstokken, 14
(109: 0), stenen bakstenen trappen, 1

(109: 2), stenen bakstenen trappen, 2
(109: 3), stenen bakstenen trappen, 5
(127: 0), Cocoa Plant, 2
(127: 1), cacaoblant, 5
(127: 2), Cacao Plant, 2
(127: 3), cacaoblant, 4
(127: 4), Cocoa Plant, 3
(127: 5), Cacao Plant, 3
(127: 6), Cocoa Plant, 2
(127: 7), Cocoa Plant, 2
(127: 8), cacaoblant, 6
(127: 9), Cacao Plant, 5
(127: 10), Cacao Plant, 4
(127: 11), cacaoblant, 11
(141: 2), wortelen, 2
(141: 3), wortelen, 2

(141: 5), wortelen, 6
(141: 6), wortelen, 5
(141: 7), wortelen, 7
(142: 2), aardappelen, 3
(142: 3), aardappelen, 4
(142: 4), aardappelen, 6
(142: 5), aardappelen, 4
(142: 6), aardappelen, 5
(142: 7), aardappelen, 6
(161: 3), toekomstig blok!,759
(162: 0), toekomstig blok!,503
(164: 1), toekomstig blok!,56
(164: 2), toekomstig blok!,52
(164: 3), toekomstig blok!,56
(164: 4), toekomstig blok!,52
(164: 5), toekomstig blok!,248
(164: 6), toekomstig blok!,52
(164: 7), toekomstig blok!,54
(164: 8), toekomstig blok!,49
(164: 9), toekomstig blok!,54
(164: 10), toekomstig blok!,98
(164: 11), toekomstig blok!,48
(165: 1), toekomstig blok!,73
(165: 2), toekomstig blok!,60
(165: 3), toekomstig blok!,72
(165: 4), toekomstig blok!,55
(165: 5), toekomstig blok!,136
(165: 6), toekomstig blok!,55
(165: 7), toekomstig blok!,67
!,53
(165: 9), toekomstig blok!,67
(165: 10), toekomstig blok!,95
(165: 11), toekomstig blok!,32
(166: 1), toekomstig blok!,40
(166: 2), toekomstig blok!,41
(166: 3), toekomstig blok!,41
(166: 4), toekomstig blok!,41
(166: 5), toekomstig blok!,180
(166: 6), toekomstig blok!,41
(166: 7), toekomstig blok!,41
(166: 8), toekomstig blok!,41
(166: 9), toekomstig blok!,41
(166: 10), toekomstig blok!,82
(166: 11), toekomstig blok!,18
(167: 7), toekomstig blok!,5
(167: 8), toekomstig blok!,5
(167: 10), toekomstig blok!,7
(168: 1), toekomstig blok!,744951
(175: 0), toekomstig blok!,238
(175: 1), toekomstig blok!,50
(175: 2), toekomstig blok!,5923
(175: 3), toekomstig blok!,1527
(175: 4), toekomstig blok!,64
(175: 5), toekomstig blok!,88
(180: 0), toekomstig blok!,59
(180: 4), toekomstig blok!,71
(180: 8), toekomstig blok!,26
(181: 0), toekomstig blok!,391
(185: 0), toekomstig blok!,314
(185: 2), toekomstig blok!,62
(185: 8), toekomstig blok!,803
(185: 10), toekomstig blok!,97
(186: 0), toekomstig blok!,190
(186: 2), toekomstig blok!,56
(186: 8), toekomstig blok!,550
(186: 10), toekomstig blok!,106
(187: 0), toekomstig blok!,21
(187: 2), toekomstig blok!,4
(187: 8), toekomstig blok!,73
(187: 10), toekomstig blok!,
(188: 0), toekomstig blok!,2256
(188: 1), toekomstblok!,8
(188: 2), toekomstig blok!,3
(188: 3), toekomstig blok!,10
(188: 4), toekomstig blok!,8
(188: 5), toekomstig blok!,5
(188: 6), toekomstig blok!,2
(188: 7), toekomstig blok!,6
(188: 8), toekomstig blok!,8
!,10
(188: 10), toekomstig blok!,6
(200: 0), toekomstig blok!,202
(200: 2), toekomstig blok!,24
,,
,,351
Bat, Bat, 22
CameSpider, CameSpider, 5
Kip, kip, 32
Koe, koe, 22
Creeper, Creeper, 15
Vis, vis, 10
Paard, paard, 6
Item, bruine paddenstoel, 15
Item, rail, 2
Item, rot vlees, 1
Item, zaden, 16
Item, stok, 1
Minecartchest, Minecartchest, 25
Ozelot, Ozelot, 2
Varken, varken, 38
Konijn, konijn, 22
Schapen, schapen, 48
Skelet, skelet, 22
Spider, Spider, 4
Inktvis, inktvis, 15
Villager, dorpsbewoner, 13
Heks, heks, 2
Zombie, Zombie, 13
,,
,,66
Borst, borst, 31

Feit is het, het volledig Blaast me aan hoe resource -intensieve moderne versies zijn, nog meer traditionele gemodificeerde versies – absoluut krankzinnig; precies wat dat allemaal gebruikt?! Nee, ik ga geen modpack of zelfs een moderne versie installeren, alleen zodat ik het resource -gebruik kan analyseren:

De meeste modpacks alleen nodig 6-8 GB RAM toegewezen

‘Alleen’ zeggen alsof 6-8 GB niets is als ik slechts 512 MB had toegewezen in de bovenstaande voorbeelden, en deze thread beweert dat zelfs 1.3 Vereist minstens zoveel om te beginnen, veel minder lading een wereld op een hogere weergave afstand dan ondersteund door het spel, tenzij je optifine gebruikt (nogmaals, 10 brokken laadt 441 brokken terwijl 16 brokken 1089 brokken laden; 1089 /441):

1.3 Split de server en de clientlogica. Plots moet je de voetafdruk van het spel verdubbelen – een exemplaar van alle game -objecten voor de server, één exemplaar voor de client. 1.3 heeft 500 MB nodig voordat je zelfs loopt.

Hier zijn meer VisualVM -analyses, dit keer vergelijken de topobjecten per geheugengebruik (“behouden grootte”, die alle geheugen omvat waarnaar wordt verwezen door eventuele objecten die ze hebben; de som van de kolom is niet het totaal, dat kan worden afgeleid uit het gebruikte percentage door de bovenste invoer):

1.6.4; Het totale geheugengebruik was ongeveer 111.3 MB, met 61.5 MB (55.3%) gebruikt door geladen brokken en 49.8 MB gebruikt door al het andere (merk op dat er eigenlijk 1066 brokken worden geladen, niet 882 of 441 x 2, omdat de spawn-brokken 625 brokken zijn, maar alleen server-side; het aantal zou nog hoger zijn als ik buiten het spawn-gebied was ):

TMCWV5; Het totale geheugengebruik was ongeveer 164.4 MB, met 137.6 MB (83.7%) gebruikt door geladen brokken en 26.8 MB gebruikt door al het andere (in dit geval wordt hetzelfde aantal brokken, 1089 of 2178 in totaal aan beide zijden geladen omdat er geen spawn -brokken worden geladen, behalve tijdens de initiële wereldcreatie, dus het maakt ook niet uit waar ik ben in de wereld):

Ja, je leest dat goed – bij het uitsluiten van geladen brokken TMCW gebruikt er alleen over Half zoveel geheugen! Dit is duidelijk zichtbaar in sommige klassen; Renderglobal is 2.84 MB in vanille maar TMCW’s RenderGloBalTMCW -klasse is slechts 2.18 MB, en het combineert twee belangrijke renderingklassen (Renderglobal en EntityRenderer). Evenzo neemt vanille’s WorldRenderer op 2.56 MB terwijl de chunkrenderer van TMCW slechts 1 inneemt.76 MB – en er zijn er 1.61 keer meer instanties vanwege de hogere renderafstand (met andere woorden, elk minder dan de helft zoveel geheugen, 106 versus 248 bytes)! Dit gedeeltelijk omdat ik verschillende objecten heb verwijderd ten gunste van eenvoudiger velden, wat ook betekent dat er tienduizenden minder objecten zijn dan anders (dit is waarom de “grootte” hetzelfde is als “behouden”, terwijl in vanille de laatste is veel groter. Zelfs als u gewoon de “maat” vanille vergelijkt, heeft vanille nog steeds 126 bytes per instantie nodig). Hetzelfde geldt voor veel andere klassen, die allemaal oplopen tot een vermindering van 50% in het baseline -geheugengebruik – als ik in plaats daarvan TMCW op 10 brokken had ingesteld, om hetzelfde aantal te laden als vanille, zou het in het algemeen minder geheugen gebruiken, en zelfs minder CPU (die al lager was).

Natuurlijk, er zijn nog steeds gevallen waarin iets veel geheugen kan gebruiken, bijvoorbeeld, kijk naar hoeveel geheugen wordt gebruikt door mijnschepen, en er werden er slechts 10 geladen – maar ik laad of sla de gegevens niet op voor elke single Moonshaft in de hele wereld, zoals Vanilla, en ze worden alleen gemaakt als een brok wordt bevolkt met een deel van hen (als ik de wereld opnieuw laadde en een nieuwe heap dump zou nemen, zou het 0 instanties laten zien, dus alleen de hoeveelheid nieuw terrein gegenereerd In een bepaalde sessie is belangrijk, plus vanille’s klasse “MapGenstructuredata” -klasse slaat zijn eigen gegevens los van de klasse “MapGenmineshaft”, die al 1/6 zoveel geheugen gebruikt ondanks slechts één dorp, dat het nog steeds gebruikt, aanwezig zijn):

MC-33134 MINSHASS.DAT gebruikt te veel CPU (dit moet “te veel geheugen zijn, waardoor een hoog CPU -gebruik wordt gedwongen via afvalcollecties)

Of je zou kunnen zeggen dat ik dit echt heb opgelost of niet, het zal nooit zo’n probleem worden, tenzij je iets onrealistisch hebt gedaan, zoals continu dagenlang vliegen, of het spel hardlijst hield met een wereld geladen toen je niet speelde. Om MinShaft -gegevens te gebruiken om een ​​hoeveelheid geheugen te gebruiken die vergelijkbaar is met geladen brokken die u in de volgorde van 10.000 daarvan moet laden, of 1.8 miljoen brokken (vanwege de inefficiënte opgeslagen structuurgegevensindeling van Vanilla kan het slechts een kleine fractie hiervan aan; opmerkingen suggereren dat slechts ongeveer 600 mijnen, of 60.000 brokken in vanille, dezelfde hoeveelheid geheugen gebruiken – dus ik kan beweren te hebben geoptimaliseerd hen met een factor 30. Dit betekent ook dat mijn eerste wereld, ongeveer 135.000 brokken, meerdere keren meer geheugen zou gebruiken als ik structuur niet had uitgeschakeld voor mijnschepen – zoals het is, gebruikt het niet meer dan een merk -0 nieuwe wereld).

Evenzo weet ik er zeker van dat er manieren zijn om de weergave van kisten aanzienlijk te optimaliseren, maar ik heb tenminste hun prestaties verdubbeld met enkele relatief kleine veranderingen, en er zijn tenminste vaten, die geen impact hebben dan het weergeven van een blok zoals steen, plus Ik krijg nog steeds genoeg FPS om stabiel te blijven met een framerate limiet / vsync (dat is waarschijnlijk waar de meeste ontwikkelaars blij mee zijn, waarbij ze het feit negeren dat ze misschien een bovengemiddelde computer hebben – ik coder zelfs nog steeds delen van TMCW alsof ik het nog had Een 32 -bits systeem, zoals ik de eerste paar jaar deed dat ik speelde):

Merk op dat het geheugengebruik dat wordt getoond door VisualVM niet de code zelf (of VRAM -gebruik) bevat, maar dit is vanzelfsprekend (de grootte van TMCWV5 is een beetje toegenomen sinds een jaar geleden, maar het is nog steeds minder dan 7 MB – ik heb zelfs toegevoegd Nieuwe functies van updates zo recent als 1.19, inclusief vóór de officiële release, zoals een Swift Sneak Enchantment (die slechts enkele regels code vereiste – zodra u de basiscode hebt voor een algemeen type functie (entiteiten, blokken, items, betoveringen, biomen, enz.) exemplaar moet veel minder worden toegevoegd*). Mijn gemodificeerde potten bevatten ook veel ongebruikte vanille-klassen, omdat ik veel van hen heb omgedoopt in plaats van alleen de originelen te wijzigen, terwijl het verwijderen van meta-INF de grootte verminderde, zelfs slechts 1.8, de eerste update waarbij Mojang hun huidige programmeerpraktijken heeft overgenomen, althans op grote schaal, is groter ondanks dat het slechts een klein deel van de inhoud heeft (mijn eigen code heeft ook veel minder klassen, ongeveer 1/3 zoveel in vergelijking met vergeleken met Dezelfde algemene brongrootte van vanille 1.6.4; Omgekeerd, 1.8 heeft veel meer kleine klassen en is daardoor veel complexer complexer):

*Dit is alle code die betrokken is bij mijn “Swift Sneak” betovering, met uitzondering van niet -gerelateerde delen van bestaande klassen die zijn gewijzigd om de code ervoor te omvatten (alleen “EnchantmentSwiftsNeak” is helemaal nieuw):

 < public EnchantmentSwiftSneak(int par1, int par2) < super(par1, par2, EnumEnchantmentType.armor_legs); this.setName("swiftSneak"); >// Retourneert kosten per niveau in het aambeeld; Niveau 3 kost 9 niveaus public int getanvilcost () < return 3; >// Stel dus alleen niveaus 1-2 worden waarschijnlijk verkregen uit de betoveringstabel public int getMinchantability (int par1) < return 10 + 20 * (par1 - 1); >public int getMaxenchantability (int par1) < return super.getMinEnchantability(par1) + 50; >Public int getMaxLevel () < return 3; >// Vermindert de kans om in een betoveringstabel met een extra 75% te worden gekozen (effectief gewicht is 0.25) Public Float GetadditionalRarity () < return 0.25F; >> Openbare abstracte klasse betovering < 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 []) Tradeelist.ToArray (nieuwe betovering [0]); >> Public Class 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) Lijst.add (enumchatformatting.Blauw + " +" + geheel getal.ToString (niveau * 15) + "% Sneak Speed"); > Public Static Final Int GetSwiftsNeakModifier (EntityLivingBase Par0entityLivingBase) < return getMaxEnchantmentLevel(Enchantment.swiftSneak, par0EntityLivingBase.getLastActiveItems()); >// retourneert een betoverd boek met een lange herfst of snelle sneak. Niveauverdeling is ingesteld, dus er is 40% kans op // het maximale niveau; Voor lange herfstniveaus 1-4 hebben een kans op 11/19/29/40, terwijl voor Swift Sneak-niveaus 1-3 A // 26/33/40 kans hebben. Public Static Final 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); >terwijl (niveau> openbare klasse MovementInputfix BEWEGINGSINPUT uitbreidt < 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; >>>>>

Roldback -post om terugdraaien te herzien

De eerste wereld van ThemasterCaver – misschien wel de meest ingetogen wereld in de geschiedenis van Minecraft – omvat werelddownload.
ThemasterCaver’s World – mijn eigen versie van Minecraft grotendeels gebaseerd op mijn opvattingen over hoe het spel had moeten evolueren sinds 1.6.4.
Waarom speel ik nog steeds in 1.6.4?