Sitemizi ana ekranınıza bir web uygulaması olarak nasıl yükleyeceğinizi görmek için aşağıdaki videoyu izleyin.
Not: Bu özellik bazı tarayıcılarda kullanılamayabilir.
Merhaba, Hoşgeldin!
VSRO.org, Silkroad Online, Knight Online, Metin2 ve diğer çevrimiçi oyunlar için öncü bir yardım ve geliştirme platformudur. Misyonumuz, bilgi ve deneyim sahibi bireyleri, bilgiye ihtiyaç duyanlarla bir araya getirerek, zengin bir etkileşim ortamı yaratmak ve farklı bakış açılarını birleştirmektir. Topluluğumuzda güçlü bir işbirliği ve öğrenme kültürü oluşturarak, herkesin değerli katkılarda bulunmasını sağlıyoruz.
Çok eski bir web tarayıcısı kullanıyorsunuz. Bu veya diğer siteleri görüntülemekte sorunlar yaşayabilirsiniz.. Tarayıcınızı güncellemeli veya alternatif bir tarayıcı kullanmalısınız.
Üst üste post gönderildiği için tek mesajda birleştirildi:
@Promaker aslında tablo üzerinde yapılması daha mantıklı olacak benim prosedür tablo üzerinde yapmıştım hatta hangi unique kesildiğinde bildirim geçiyordu.
Bu forumdaki neredeyse bir çok üyeyin when case'ler le derdi ne anlamış değilim Tamam siz tablodan çekin.
Performans: CASE ifadesi, küçük ve sabit veri kümeleri için oldukça hızlı ve basit bir çözüm sunar. SQL sorgusunda sabit bir veri kümesi olduğu için ek bir tabloya erişim gerekmez, bu da küçük veri setleri için hızlı sonuçlar sağlayabilir.
Bu mantık ile 3-5 unique için if/else de iş görür ama kalkıp min 50 uniqueli bir pvp server açılacaksa tablodan çekmek daha mantıklı satır satır bütün uniqueleri caselemek gereksiz olur. Kaldı ki zaten backend te fazlasıyla queryler dönüyor burda yapacağımız kısayolun performansa çok katkısı olacağını sanmam modül sürümü eski ve 32bit yani kapasitesi zaten kısıtlı ona rağmen filter ile eklenen özellikler ortada ve çalışması için harcadığı işlem gücüde belli
darboğazlık bir sürüme yığınla sistem yüklerken performansın dikkate alındığını sanmıyorum
Filter tarafında bir çok işlemi modullerden bağımsız yani karakter adı ve eventidsini alıp filtrelemisini filter üzerinden sql ile yapıyor bu ap ayrı bir konu. Daha önce magic popda da paylaştıgım gibi, eğer orada da altını çizdim max 15 20 verinin olduğu işlemlerde tablo oluşturmak bana gereksiz ugraş geliyor. Kodun performansa ihtiyacı yok bile zaten. Onun için prosedürden tabloya gidip geri gelmesine gerek yok. İçerde halledip çıkıyor, ki perfomans testinde de aynı veriler dönüyor. Dediğin gibi veri 15 20 den fazlaysa iş tabloya dönebilir.
Filter özellikleri ile SQL e ek işlem yükü verilmesi ve çalışma gücünün daha fazla artmasını kastettim. Yani kısaca SQL i yormak. Mesela çoğunlukla return scroll ile bir uptade yaparız ama her tp sonrasında GS SQL i çalıştırıyor. Gift box ekli bir oyunda karakter başına 100 scroll ile 50 karakterin bunu yaptığını bir düşün döngü gibi sürekli item/char info yu sql den almak için query çalıştıracak. Günümüz filter özellikleri de her tp sonrasında data_refresh yapıyor... daha fazla örnek vermeye gerek varmı
Oyunun Orjinal prosedürlerini ve Triggerlerini İnceledikten sonra Yaptığımız Döngüler Vb Dediğin Gibi Parşömenler Fazlasıyla Basit Kaçıyor Biz Düşünüyoruz Sql Yorulur Adamlar 2005 de Prosedürlerle Oyun Yönetmişler Özellikle İlk Filesleri ve Sql DataBaselerini İnceledinmi bilmiyorum ama Şuanki Dediğimiz gibi sql yorulur derdik..