Çözüldü Modlu Minecraft optimizasyon seçenekleri

Bu konu çözüldü olarak işaretlenmiştir. Çözülmediğini düşünüyorsanız konuyu rapor edebilirsiniz.

Mucosoft

Megapat
Katılım
5 Mart 2014
Mesajlar
5.508
Makaleler
12
Çözümler
41
Modlu Minecraft paketi hazırlıyorum. Bu paketi benden başka diğer oyuncuların da oynaması muhtemel. Bundan dolayı optimizasyon yapmayı düşünüyorum. Hangi ayarları yapmamı önerirsiniz? Bu sorum modlar için de geçerli.

"Minecraft\Instances\RPG\config" yolunda neleri güncellemeliyim? Özellikle popüler modlar var, siz istediğiniz mod için öneri sunabilirsiniz.
 
Çözüm
Mod paketlerini bilinçli bir şekilde optimize etmek biraz psikopat işi açıkçası. Modları eklerken hepsini bir anda atarak değil 5'er 5'er vs kadar mod atarak her seferinde performansta büyük bir düşüş olup olmadığını gözlemlemek ve eğer oluyorsa sorumlu modu/modları bulup bunun kaynağı acaba modun dünya üzerinde sürekli kaynak harcamasını gerektiren bir şey mi, eklediği bir blok veya mob mu, yeni chunkların oluşturulması esnasında eklediği bir ekstra yük mü onu bulmak lazım, eğer bu çok önemli bir özellik değilse ve mümkün ise config dosyasından kapatmak bir adım. Veya onun yaptığı işi alternatif ve daha az kaynak harcayan, daha verimli yazılmış bir mod yapıyorsa birbiriyle değiştirmek de yapılabilir. Modların GitHub hata izleyici sayfalarında da performansta sıkıntı çıkaran özellikleri incelemek ayrıca düzgün bir optimizasyon için önemli.

LagGoogles veya Spark gibi modlarla yine dünya üzerinde hangi blok vs ne kadar lag oluşturuyor gözlemleyip yine configlerden kapatmak gerekebilir. Aslında configlerden kapatmak işin "basit" kısmı, mod yapımcısının sunduğu seçenekler ve eğer bu seçeneği vermemişse o zaman bu basitlikte engellenemez. Mesela inanılmaz bir tersine mühendislik geliştirici ekibi olan GT:NH mod paketinde (kendisi bir 1.7.10 mod paketi ve 5 veya 6 yıldır geliştiriliyor) mod paketinin temasına uyacak ise 1.12'den ve 1.16'dan mod özelliklerini, artık oldukça eski bir sürüm olan 1.7.10 paketlerine yazılımsal olarak entegre ediyorlar. Ayrıca kullandıkları modlarda eğer verimsiz yazılmış, bug oluşumuna açık yazılımsal kısımlar varsa oraları bayağı bayağı baştan yazıyorlar veya kod optimizasyonları yapıyorlar, veya kendileri ekstra yardımcı modlar yazıyorlar. 1.7.10 üzerindeki bu mod paketi hala üzerine en çok emek verilmiş, optimizasyon ve yenilik olarak uğraşılmış, en "geek" paketlerden bir tanesi. Ancak dediğim gibi bu basit seviyede bilgiyle yapılabilecek bir optimizasyon vs değil, iyi Java bilgisine sahip tamamen gönüllü geliştiricileriyle binlerce saatlik emekle ve bunca yılda bu hale gelmiş.

Java'nın farklı runtime environment'ları bulunuyor, Java'nın sitesinden indirilen Oracle olan veya Red Hat, OpenJ9 gibi farklı JRE'ler bulunuyor. Mod paketi çalışırken arkaplanda Java'nın "garbage collection" (GC) isminde bir "hafıza yönetimi zımbırtısı" bulunuyor, ancak düzgün yapılmadığı takdirde bazı paketlerde görülen arada bir 3-5 saniye tamamen donma gibi durumlara yol açabiliyor. Bunun için doğru Java argümanlarıyla GC işini optimize etmek ve bahsettiğim JRE'leri tek tek deneyip sizin paketinizle en doğru çalışanı bulmak gerekebilir. (bu mesele hakkında ufak bir yazı)

Bir başka optimizasyonda üst noktalarda olan paketlerden bir tanesi GreedyCraft. 500+ modlu olup da devasa optimizasyonu, kendi yükleme rehberi ve sunduğu Java argümanlarıyla beklenilenden çok daha yüksek performanslı çalışan bir paket, GC ve başka bazı ayarları ince bir şekilde yapılmış ve kendi mod paketinizde kullanabilirsiniz tabii ki RAM miktarı olarak deneme yanılmayla olacak iş ama onun dışındaki GC ayarları işinize yarayacaktır. Ve tabii ki buradan bir not, mod paketlerinin optimize çalışması için önemli olan en yüksek RAM'i vermek değildir, geliştirici ekibin mesela 6 GB RAM önerdiği bir pakete 32GB RAM verirseniz, GC bunu yönetmek için çok daha uğraşacaktır ve beklenmedik şekilde performans sıkıntıları yaşayabilirsiniz, bu yüzden yine deneme yanılmayla optimum bir RAM değeri bulabilirsiniz. (kurcalamak isterseniz bu da alternatif bir argüman rehberi)

Açıkçası ortada bu kadar sanat eseri gibi mod paketleri, binlerce saat ve yıllarca uğraş ile acayip optimize edilmiş paketler dururken kendi paketimde bu kadar işe girişmezdim. Sizin yerinizde olsam önce birbiriyle uyumlu performans modlarını eklerim, JRE'leri test eder ve argümanları ayarlardım. Eğer bu kendi başına tatmin etmiyorsa dediğim gibi modları azar azar ekleyip her seferinde performans durumunu kontrol eder, mod bloklarının, worldgen'in, mobların vs lag'a olan katkısını bahsettiğim yardımcı modlarla inceler ve gereksiz gördüklerimi veya performans uğruna feda edilebilecekleri configler el verdiğince kapatırdım veya alternatif modlarla değişim yapardım. Eğer bu da tatmin etmiyorsa dediğim gibi işin artık psikopatlık kısmına girer, Java'yı optimize bir şekilde kodlamayı öğrenir modlarla yazılım düzeyinde oynar veya kendi yardımcı modlarımı yazardım. Dediğim gibi GT:NH topluluğunda bu işe inanılmaz zamanını ayıran veya zamanında ayırıp artık bıkmış bilgili insanlar bulunuyor, eğer illa o kadar ileri gidecekseniz Discord server'ına girip (tabii ki İngilizce lazım, sadece bunun için değil bütün yukarıda dediklerim için doğru dürüst kaynaklar İngilizce) biraz biraz bilgi edinip öğrenmeye başlayıp geliştikçe yine merak ettiklerinizi sorabilirsiniz, illa yol gösteren olacaktır.
Mod paketlerini bilinçli bir şekilde optimize etmek biraz psikopat işi açıkçası. Modları eklerken hepsini bir anda atarak değil 5'er 5'er vs kadar mod atarak her seferinde performansta büyük bir düşüş olup olmadığını gözlemlemek ve eğer oluyorsa sorumlu modu/modları bulup bunun kaynağı acaba modun dünya üzerinde sürekli kaynak harcamasını gerektiren bir şey mi, eklediği bir blok veya mob mu, yeni chunkların oluşturulması esnasında eklediği bir ekstra yük mü onu bulmak lazım, eğer bu çok önemli bir özellik değilse ve mümkün ise config dosyasından kapatmak bir adım. Veya onun yaptığı işi alternatif ve daha az kaynak harcayan, daha verimli yazılmış bir mod yapıyorsa birbiriyle değiştirmek de yapılabilir. Modların GitHub hata izleyici sayfalarında da performansta sıkıntı çıkaran özellikleri incelemek ayrıca düzgün bir optimizasyon için önemli.

LagGoogles veya Spark gibi modlarla yine dünya üzerinde hangi blok vs ne kadar lag oluşturuyor gözlemleyip yine configlerden kapatmak gerekebilir. Aslında configlerden kapatmak işin "basit" kısmı, mod yapımcısının sunduğu seçenekler ve eğer bu seçeneği vermemişse o zaman bu basitlikte engellenemez. Mesela inanılmaz bir tersine mühendislik geliştirici ekibi olan GT:NH mod paketinde (kendisi bir 1.7.10 mod paketi ve 5 veya 6 yıldır geliştiriliyor) mod paketinin temasına uyacak ise 1.12'den ve 1.16'dan mod özelliklerini, artık oldukça eski bir sürüm olan 1.7.10 paketlerine yazılımsal olarak entegre ediyorlar. Ayrıca kullandıkları modlarda eğer verimsiz yazılmış, bug oluşumuna açık yazılımsal kısımlar varsa oraları bayağı bayağı baştan yazıyorlar veya kod optimizasyonları yapıyorlar, veya kendileri ekstra yardımcı modlar yazıyorlar. 1.7.10 üzerindeki bu mod paketi hala üzerine en çok emek verilmiş, optimizasyon ve yenilik olarak uğraşılmış, en "geek" paketlerden bir tanesi. Ancak dediğim gibi bu basit seviyede bilgiyle yapılabilecek bir optimizasyon vs değil, iyi Java bilgisine sahip tamamen gönüllü geliştiricileriyle binlerce saatlik emekle ve bunca yılda bu hale gelmiş.

Java'nın farklı runtime environment'ları bulunuyor, Java'nın sitesinden indirilen Oracle olan veya Red Hat, OpenJ9 gibi farklı JRE'ler bulunuyor. Mod paketi çalışırken arkaplanda Java'nın "garbage collection" (GC) isminde bir "hafıza yönetimi zımbırtısı" bulunuyor, ancak düzgün yapılmadığı takdirde bazı paketlerde görülen arada bir 3-5 saniye tamamen donma gibi durumlara yol açabiliyor. Bunun için doğru Java argümanlarıyla GC işini optimize etmek ve bahsettiğim JRE'leri tek tek deneyip sizin paketinizle en doğru çalışanı bulmak gerekebilir. (bu mesele hakkında ufak bir yazı)

Bir başka optimizasyonda üst noktalarda olan paketlerden bir tanesi GreedyCraft. 500+ modlu olup da devasa optimizasyonu, kendi yükleme rehberi ve sunduğu Java argümanlarıyla beklenilenden çok daha yüksek performanslı çalışan bir paket, GC ve başka bazı ayarları ince bir şekilde yapılmış ve kendi mod paketinizde kullanabilirsiniz tabii ki RAM miktarı olarak deneme yanılmayla olacak iş ama onun dışındaki GC ayarları işinize yarayacaktır. Ve tabii ki buradan bir not, mod paketlerinin optimize çalışması için önemli olan en yüksek RAM'i vermek değildir, geliştirici ekibin mesela 6 GB RAM önerdiği bir pakete 32GB RAM verirseniz, GC bunu yönetmek için çok daha uğraşacaktır ve beklenmedik şekilde performans sıkıntıları yaşayabilirsiniz, bu yüzden yine deneme yanılmayla optimum bir RAM değeri bulabilirsiniz. (kurcalamak isterseniz bu da alternatif bir argüman rehberi)

Açıkçası ortada bu kadar sanat eseri gibi mod paketleri, binlerce saat ve yıllarca uğraş ile acayip optimize edilmiş paketler dururken kendi paketimde bu kadar işe girişmezdim. Sizin yerinizde olsam önce birbiriyle uyumlu performans modlarını eklerim, JRE'leri test eder ve argümanları ayarlardım. Eğer bu kendi başına tatmin etmiyorsa dediğim gibi modları azar azar ekleyip her seferinde performans durumunu kontrol eder, mod bloklarının, worldgen'in, mobların vs lag'a olan katkısını bahsettiğim yardımcı modlarla inceler ve gereksiz gördüklerimi veya performans uğruna feda edilebilecekleri configler el verdiğince kapatırdım veya alternatif modlarla değişim yapardım. Eğer bu da tatmin etmiyorsa dediğim gibi işin artık psikopatlık kısmına girer, Java'yı optimize bir şekilde kodlamayı öğrenir modlarla yazılım düzeyinde oynar veya kendi yardımcı modlarımı yazardım. Dediğim gibi GT:NH topluluğunda bu işe inanılmaz zamanını ayıran veya zamanında ayırıp artık bıkmış bilgili insanlar bulunuyor, eğer illa o kadar ileri gidecekseniz Discord server'ına girip (tabii ki İngilizce lazım, sadece bunun için değil bütün yukarıda dediklerim için doğru dürüst kaynaklar İngilizce) biraz biraz bilgi edinip öğrenmeye başlayıp geliştikçe yine merak ettiklerinizi sorabilirsiniz, illa yol gösteren olacaktır.
 
Çözüm

Geri
Yukarı