Yardım TCPState bugu

  • Konuyu açan Konuyu açan victory
  • Açılış Tarihi Açılış Tarihi
  • Yanıt Yanıt 6
  • Gösterim Gösterim 208
Konu sahibi bu konuda soru soruyor. Sorusu ile ilgili bilgisi olanların yanıtlamasını bekliyor.
victory

victory

Üye
Üye
Mesaj
34
Beğeni
11
Puan
661
Ticaret Puanı
0
Merhaba,

Bir süredir ekte paylaşacağım videoda da görüldüğü gibi 'karakter hareketsizliği & ölü client' sorunuyla boğuşuyorum. Oyun clientim saatlerce açık kaldıktan sonra diğer oyuncular hatta moblar hareketi kesiyor. Sanki herkes bir anda 7x açmış gibi bir ortam oluyor çünkü hareket yok ama insanlar birbirlerine damage atıyorlar. Oyuncularım için bu açıklanması zor bir bug.

Yaptığım çalışmalar sonrasında sorunun CInstanceBase::StateProcess() içerisindeki bir return statement'dan kaynaklandığını gördüm. Serverden gelen hareket, attack paketleri m_kQue_kCmdNew içerisinde düzgünce birikiyor birikmesine de, StateProcess içerisindeki döngü eritmesi gereken bu listeyi bu return statement yüzünden eritemiyor ve liste şişiyor da şişiyor yani server hareket paketi işlenmiyor.
1762123300128.webp


Bu statement'in neden konulduğunu, ne işe yaradığını henüz bilemiyorum. Ama tahminim client saatinin bir şekilde şaştığı.
Sizlere sorup aranızda fikri olan belki bu sorunu yaşamış ve çözmüş olan birileri var mı diye öğrenmek istedim. Şimdiden teşekkürler.

Video:
Linkleri görebilmek için giriş yap veya kayıt ol.
 
Tarihe göre sırala Oy skoruna göre sırala
yaşadığınız sorun genel olarak metin2'de ki genel bir senkronize problemliyle alakalı. kısaca özetlemek gerekirse; oyun clienti stateful çalışabilmek için servera bağlantı aşamasında sunucu saati ile client saatini eşitleyip sonrasında gelen bazı hesaplamaları bunun üzerinden yapıyor ancak burada sorun şu ki bu hesaplamayı SADECE giriş aşamasında yapıyor, sonrasında kaynaklanan desync kaynaklı kaymaları, render aşamasında oluşabilecek kaymaları ya da SkipRenderBuffering kaynaklı oluşabilecek kaymaları hesaplamadığı için kontrol edilen süre bozulabiliyor ve bu da belli bir zamandan sonra hesaplamanın düzgün çalışmamasına sebep oluyor, mevcut haliyle hardcoded bir ping değeri üzerinden hesaplama yaptığı için zaten normaldede ne kadar stabil çalışıyor o da ayrı bir konu...

senkronize'de genel birden fazla alanda problem var, burada yaşanılan ana sorunlar ise;
1) yukarıda bahsettiğim server süresi eşitleme sorunu
2) m_dwChkTime hesaplaması
3) StateProcess koşulundaki early return

ne yapmak gerekir derseniz;
1) server tarafından attack, move ve sync gibi paketlerde client ile server zamanlarını kontrol edip anormal çıkan durumlarda SendHandshake ile client zamanını tekrar eşitlemeniz gerekiyor
2) m_dwChkTime yukarıdada dediğim gibi hardcoded bir ping değeri kullanıyor, aşağıda hesaplaması mevcut
m_nAverageNetworkGap=(m_nAverageNetworkGap*70+nNetworkGap*30)/100;
kCmdNew.m_dwChkTime = dwCmdTime+m_nAverageNetworkGap;
bunu daha düzgün bir hesaplama ile değiştirmeniz gerekiyor, local için örnek olarak;
kCmdNew.m_dwChkTime = m_dwBaseChkTime + (dwCmdTime - m_dwBaseCmdTime);
aktif live serverda lokasyon ve yoğunluğa bağlı olarak deneyerek daha uygun şekilde değiştirebilirsiniz
3) StateProcess işlemindeki queue kontrolden sonra temizlendiği için koşul eşleşmezse sürekli olarak tekrar aynı değeri işlemeye çalışacak ve işlem queuedan silinmediği sürece(oyundan çıkılana kadar) queue'u kitlemeye ve paket işlememeye devam edecek. bunun önüne geçebilmek için komutun eklenme süresine göre çok önceden queue'a alınmışsa return'dan önce silmeniz gerekiyor
 
Upvote 0 Downvote
pasha37 demiş ki:
yaşadığınız sorun genel olarak metin2'de ki genel bir senkronize problemliyle alakalı. kısaca özetlemek gerekirse; oyun clienti stateful çalışabilmek için servera bağlantı aşamasında sunucu saati ile client saatini eşitleyip sonrasında gelen bazı hesaplamaları bunun üzerinden yapıyor ancak burada sorun şu ki bu hesaplamayı SADECE giriş aşamasında yapıyor, sonrasında kaynaklanan desync kaynaklı kaymaları, render aşamasında oluşabilecek kaymaları ya da SkipRenderBuffering kaynaklı oluşabilecek kaymaları hesaplamadığı için kontrol edilen süre bozulabiliyor ve bu da belli bir zamandan sonra hesaplamanın düzgün çalışmamasına sebep oluyor, mevcut haliyle hardcoded bir ping değeri üzerinden hesaplama yaptığı için zaten normaldede ne kadar stabil çalışıyor o da ayrı bir konu...

senkronize'de genel birden fazla alanda problem var, burada yaşanılan ana sorunlar ise;
1) yukarıda bahsettiğim server süresi eşitleme sorunu
2) m_dwChkTime hesaplaması
3) StateProcess koşulundaki early return

ne yapmak gerekir derseniz;
1) server tarafından attack, move ve sync gibi paketlerde client ile server zamanlarını kontrol edip anormal çıkan durumlarda SendHandshake ile client zamanını tekrar eşitlemeniz gerekiyor
2) m_dwChkTime yukarıdada dediğim gibi hardcoded bir ping değeri kullanıyor, aşağıda hesaplaması mevcut
m_nAverageNetworkGap=(m_nAverageNetworkGap*70+nNetworkGap*30)/100;
kCmdNew.m_dwChkTime = dwCmdTime+m_nAverageNetworkGap;
bunu daha düzgün bir hesaplama ile değiştirmeniz gerekiyor, local için örnek olarak;
kCmdNew.m_dwChkTime = m_dwBaseChkTime + (dwCmdTime - m_dwBaseCmdTime);
aktif live serverda lokasyon ve yoğunluğa bağlı olarak deneyerek daha uygun şekilde değiştirebilirsiniz
3) StateProcess işlemindeki queue kontrolden sonra temizlendiği için koşul eşleşmezse sürekli olarak tekrar aynı değeri işlemeye çalışacak ve işlem queuedan silinmediği sürece(oyundan çıkılana kadar) queue'u kitlemeye ve paket işlememeye devam edecek. bunun önüne geçebilmek için komutun eklenme süresine göre çok önceden queue'a alınmışsa return'dan önce silmeniz gerekiyor
Hepsini görmek için tıklayın...
aklıma aslında client tarafındaki sizin de bahsettiğiniz local time hesaplama değerlerini DWORD'den uint64'e çekmek geldi ilk bakışta. Çünkü mantıken belirli bir süre sonra DWORD taşabilir. Ve bu sorun sadece client 10+ saat açık kaldıktan sonra yaşanıyor.
 
Upvote 0 Downvote
pasha37 demiş ki:
yaşadığınız sorun genel olarak metin2'de ki genel bir senkronize problemliyle alakalı. kısaca özetlemek gerekirse; oyun clienti stateful çalışabilmek için servera bağlantı aşamasında sunucu saati ile client saatini eşitleyip sonrasında gelen bazı hesaplamaları bunun üzerinden yapıyor ancak burada sorun şu ki bu hesaplamayı SADECE giriş aşamasında yapıyor, sonrasında kaynaklanan desync kaynaklı kaymaları, render aşamasında oluşabilecek kaymaları ya da SkipRenderBuffering kaynaklı oluşabilecek kaymaları hesaplamadığı için kontrol edilen süre bozulabiliyor ve bu da belli bir zamandan sonra hesaplamanın düzgün çalışmamasına sebep oluyor, mevcut haliyle hardcoded bir ping değeri üzerinden hesaplama yaptığı için zaten normaldede ne kadar stabil çalışıyor o da ayrı bir konu...

senkronize'de genel birden fazla alanda problem var, burada yaşanılan ana sorunlar ise;
1) yukarıda bahsettiğim server süresi eşitleme sorunu
2) m_dwChkTime hesaplaması
3) StateProcess koşulundaki early return

ne yapmak gerekir derseniz;
1) server tarafından attack, move ve sync gibi paketlerde client ile server zamanlarını kontrol edip anormal çıkan durumlarda SendHandshake ile client zamanını tekrar eşitlemeniz gerekiyor
2) m_dwChkTime yukarıdada dediğim gibi hardcoded bir ping değeri kullanıyor, aşağıda hesaplaması mevcut
m_nAverageNetworkGap=(m_nAverageNetworkGap*70+nNetworkGap*30)/100;
kCmdNew.m_dwChkTime = dwCmdTime+m_nAverageNetworkGap;
bunu daha düzgün bir hesaplama ile değiştirmeniz gerekiyor, local için örnek olarak;
kCmdNew.m_dwChkTime = m_dwBaseChkTime + (dwCmdTime - m_dwBaseCmdTime);
aktif live serverda lokasyon ve yoğunluğa bağlı olarak deneyerek daha uygun şekilde değiştirebilirsiniz
3) StateProcess işlemindeki queue kontrolden sonra temizlendiği için koşul eşleşmezse sürekli olarak tekrar aynı değeri işlemeye çalışacak ve işlem queuedan silinmediği sürece(oyundan çıkılana kadar) queue'u kitlemeye ve paket işlememeye devam edecek. bunun önüne geçebilmek için komutun eklenme süresine göre çok önceden queue'a alınmışsa return'dan önce silmeniz gerekiyor
Hepsini görmek için tıklayın...
return olan kısımları break yada continue olarak yapsak ve loglar şişme yapmasın diye buna da bir koruma koysak client tarafına bir nevi çözülmüş olur gibi ne dersiniz ?
 
Upvote 0 Downvote
Ayni lanet sorun bendede mevcuttu hatta bu hatayi zamaninda actigim yapida farkettim isin kotu yani oyuncular hile videosu diye bana bu sorunu gosteriyorlardi halbuki hile degil senkrozisyon sorunu mevcuttu , duzelttim sayilir neler yaptim dersen client ve game tarafli packet.h move ve attack martynin 5.8 ile duzeltmeler yaptim ayni zamanda clientte pythonnetworkstream.cpp uzerinde move ve attack bazli statementleri degistirdim.
 

Dosya Eklentileri

  • movement.webp
    movement.webp
    953,3 KB · Gösterim: 35
Upvote 0 Downvote
meteek demiş ki:
Ayni lanet sorun bendede mevcuttu hatta bu hatayi zamaninda actigim yapida farkettim isin kotu yani oyuncular hile videosu diye bana bu sorunu gosteriyorlardi halbuki hile degil senkrozisyon sorunu mevcuttu , duzelttim sayilir neler yaptim dersen client ve game tarafli packet.h move ve attack martynin 5.8 ile duzeltmeler yaptim ayni zamanda clientte pythonnetworkstream.cpp uzerinde move ve attack bazli statementleri degistirdim.
Hepsini görmek için tıklayın...
yani movement paketlerde mi düzeltmeler yaptığınızı söylüyorsunuz? client time fonksiyonlarıyla alakalı çalışma olmadı mı?
 
Upvote 0 Downvote

Benzer konular

sharap
Öneri Çok takılıyorum
Yanıt
14
Gösterim
2K
sharap
sharap
servet7777
Yardım PET BUGU NAVİCATTAN new_petsystem İSİMİ CEKMİYOR MOB_PROTOTAN CEKİYO
Yanıt
2
Gösterim
589
servet7777
servet7777
E
Yardım Bir METİN2 Bugu Hakkında Yardım İstiyorum
Yanıt
3
Gösterim
699
Whistle
Whistle
cafer
Yardım Game.core içindeki detay yardım
Yanıt
4
Gösterim
669
Reached
Reached
Enes Deniz
  • Kilitli
  • Çözüldü
Çözüldü K Envanteri Great offline shopa uyarlama
Yanıt
17
Gösterim
2K
Enes Deniz
Enes Deniz
Geri
Üst