PaperSpigot denen şey, orjinal Spigot'un aslında sadece bir çakmasıdır, sadece sözde olarak abartıldığından dolayı kullanılıyor.
Ve Spigot yapımcıları da bu durumdan hoşnut değil.
Genellikle Spigot yapımcılarının yaptığı pluginler PaperSpigot sürümünde çalışmaz, çalışmaması için ayarlanır.
Hatta başka kullanıcılar o pluginlerin altına yorum yapar "PaperSpigot'da çalışmıyor plugin bozuk" diye.
Onlar da derki "Bir Spigot eklentisi, Spigot olmayan bir sürümde çalışmıyorsa burada hata nerde?" der.
Spigot yapımcılarının yaptığı eklentiler göz ardı edilemeyecek ve bir alternatifi bulunamayacak türde büyük eklentiler. BungeeCord gibi. Eğer waterfall gibi enteresan eklentilere sunucunu emanet etmek istemiyorsan elbet.
Dolayısıyla Spigot'da kalmanı şiddetle tavsiye ediyorum.
Benim bildiğim kadarıyla "çakma" denemezde ingilizcedeki "fork" tabiri, spigot, bukkit, craftbukkit açık kaynak projeler, zamanında Bukkit ve CraftBukkit vardı herkes onları kullanırdı, Bukkit DMCA nedeniyle kapanınca onun bir forku olan ve bugün günümüzde aşikar olduğumuz /tps ve /timings gibi komutları ve bir sürü yeni API'leri ekleyen Spigot onun yerini aldı, kendi bünyesinde Bukkit ve CraftBukkit'i de geliştirdi.
Şuanda da Paper Spigot'un bir forku, çakma kelimesinin Paper'a pek uygun olduğunu düşünmüyorum şahsen patch denen bir sistem sayesinde upstream yani Spigot güncellemeleri kısa süreler içerisinde Paper'a geliyor ve kendi ekledikleri bir sürü performans, özellik ve API patch'i var. Bunlara örnek vermek gerekir ise:
Timings V2:
Bukkit#getTPS:
Oyuncu ayarlardan dil değiştirdiğinde tetiklenen event:
Oyuncuların view distancelarını ayarlama ve setleme:
Genelde geliştiriciler CommandMap'i SimpleCommandMap olarak reflection ile alıyor mesela onun API'si yapılmış:
Mesela yine oyuncunun üstünde duran okları temizlemek/ayarlamak için reflection'suz bir API eklenmiş:
Armor standların hareket edip edemeyeceğini belirleyebileceğimiz API'ler:
Ve gelelim benim en çok beğendiğim performans patchine, eventleri çağırırken reflection kullanmak yerine Java 7/8'de gelen Method Handle kullanıyor, buda büyük bir performans artışı sağlıyor, özellikle de PlayerMoveEvent, InventoryMoveItemEvent gibi çok tetiklenen eventlerde.
Bir diğer çok beğendiğim patch ise sunucu donduğunda stack trace'i printliyor, spigot'un 60 saniyelik timeoutunun 5-10 saniye limiti olanı fakat sunucuyu kapatmıyor sadece donmaya hangi kodun neden olduğunu görebileceğimiz bir stack trace printliyor:
Bunlar dışında async chunk loading ve async lightning gibi bir çok patchi de var. Yani gerek performans açısından, gerek ekstra özellik ve konfigüre edilebilme açısından, gerek ise yeni sürümlerden backportlanan düzeltmeler açısından ben Paper tavsiye ediyorum herkese.
Tabii ki bu patchler sadece bir kısmı daha bir sürü şey var, ek olarak sadece API-Patch'lerini koydum implementationlar için Server-Patches klasöründe aynı addaki patchlere bakılabilir.
Yani kısaca demem o ki Paper bana kalırsa Spigot'dan daha iyi şuanda, abartı veya çakma olduğunu sanmıyorum, uyumluluk konusunda da eğer 1.8.8 kullanmıyorsanız (ki 1.8.8 kullanıyorsanız bile sırf şu patch'den dolayı geçmeniz tavsiyem
- bir CPU açığı çözülüyor:
) geçmenizi öneririm 1.13 ve üstünde Paper olmadan çok daha düşük TPS ve yavaş chunk yüklemesi alınıyor.
Ek olarak BungeeCord ve Waterfall eklenti değiller (bunu bildiğinize eminim muhtemelen lafın gelişi dediniz veya gözünüzden kaçtı sadece düzeltme), alternatifi bulunuyor tabii ki BungeeCord'un, tıpkı zamanında BungeeCord'ûn da başka bir şeylerin alternatifi (BungeeCord'un sloganı "BungeeCord, the 6th in a generation of server portal suites." yani 6. nesil, muhtemelen BungeeCord ilk veya tek değil), (
), Bukkit'in de
gibi, PaperMC'de şuanda Paper ve Waterfall ile bir çok performans, bug ve iyileştirme eklemesi yapıyor, ingilizcedeki "fork" tabirinin "çakma" olarak çevrilebileceğini düşünmüyorum.
Örneğin Waterfall paket oluştururken BungeeCord'un kullandığı reflection yerine constructor method reference kullanıyor (java 8) ve bunun aşağıdaki link de benchmarklara göre 6x daha hızlı olduğu söyleniyor:
Paper'da çalışmayan eklentiler genelde eklenti geliştiricilerinin kendi hataları oluyor, mesela bir komutu async olarak başka bir threadde yürüttüğünüzde spigot hata vermiyor fakat daha sonrasında bu synchronization bozukluğuna, buglara veya crashlara sebep olabiliyor, Paper ise direkt hata verererek hatayı/bugu geliştiricinin direkt gözüne sokuyor ve düzeltmesini söylüyor.
Spigot yapımcısı md_5'in kasıtlı olarak böyle bir şey yaptığını sanmıyorum ama bunu yaparsa kendisi de kaybeder, Paper ayrı forumlar açar, zamanı geldiğinde nasıl Spigot CraftBukkit'in yerini aldıysa Paper'da onun yerini alır. Tabii şuanki Paper Spigot bazlı yani yeni MC sürümlerine güncelleme işini md_5 ve spigot ekibi yapıyor, sanırım buda işin zor kısmı mappingler mojangın kodunu decompile etme aşaması vesaire.
Ekstra olarak yine bir çok yeni pluginin Paper API'lerine dayandığını veya sadece Paper'da çalıştığını, veyahut Spigot desteğini sadece popüler olduğu için verip Paper önerdiğini görebilirsiniz. Eğer md_5'in Paper'ı bitirmek gibi bir derdi olsa aşağıdaki BestViewDistance gibi sadece Paper'da çalışan eklentileri siteden kaldırırdı muhtemelen. (
)
(Bir diğer örnek olarak WorldEdit'in
bu linkteki son sürüm dosyasının açıklamasına bakarsanız "Paper recommended" yazıyor ve eklentiyi Spigot'da çalıştırdığınızda
kullanarak Paper kullanmanızı öneren
çıkıyor.)
Spigot'da Paper (ve diğer forklar) ile alakalı tek kural Paper kullanırken Spigot'dan yardım alamazsınız bu kadar (tıpkı Spigot'daki sorunları Mojang'a raporlayamadığınız gibi), Paper kullanıyorsanız sorunlarınızı Paper'a raporlamalısınız onun dışında md_5'in özel bir yaptırımı veya kendi eklentilerini uyumsuz yapma gibi bir durumu olduğunu düşünmüyorum.
Sadece "PaperSpigot denen şey, orjinal Spigot'un aslında sadece bir çakmasıdır,
sadece sözde olarak abartıldığından dolayı kullanılıyor." dediğiniz için, buna katılmadığımdan kendi fikirlerimi belirttim, bunlar benim bildiklerim sizi çok eskiden bilirim takip ederim zamanında ben daha Skript ile uğraşırken siz eklenti yazıyordunuz ama yine de Paper konusunda size katılmıyorum, sadece bunu belirtmek istedim.
Ek olarak yukarıda dediğim gibi async komut yürütme vs. durumda Spigot'un daha esnek ve uyumlu davranması yüzünden uyumluluğu daha yüksek olabilir (konunun uyumluluk hakkında olduğunu yeni farkettim kusura bakmayın) fakat bu Paper'ı abartı veya çakma yapmaz. (bence)
