Kodların arasında sessizce duran Metin2 detayları

Hepimiz o dönemlerde Metin2 oyuncusu olarak çoğu gelişmeyi takip etmişizdir. Dediğin gibi, bir şeylerin önüne geçebilmek adına yapılan anlaşmanın ters teptiği ve kamudan bu konu ile ilgili bir özür dilenmesi durumu herkes tarafından biraz detaylı araştırma ile bulunabilir. Ben biraz baktım ofiste olduğumdan çok detaya giremedim ama biraz biraz kalıntılar var gibi duruyor. Sen bulabilirsen gönderir misin? Bir kaç eski çalışan alman arkadaştan net bilgi alabilir ve iletebilirim ben de izinleri olursa eğer. GameForge'in kendi News kısmı kaldırıldığı için dış haber kaynaklarına biraz detaylı bakmak gerek.

Olayın daha derinine inersen, dünya çapında milyonlarca oyuncu reklamının yapılmadan önce botlarla anlaşma yapıldığı biliniyor ve o anlaşma sonrası çok sayıda bot artışı olduğunu daha sonra bu dünya çapında milyonlarca oyuncu reklamı yapıldığını sen de biliyorsundur. Devamı zaten söylediğin gibi. Şirketin Metin2 kanadı zaten bir çok entrika dolu. Bir gün Derindarbe tarafından, Kronos ablamızın zamanında bir admine bot yapımcıları tarafından bir çanta dolusu para ile hesapların açılma gibi (banlanmama da olabilir) bir teklif gittiği anlatılmıştı. Farklı konularda verilen açıklar ve entrikalar sonrası da toplu istifa döneminin yaşandığını topluluk da farkındadır o dönemin sağlam takipçileri olan.

Bot olaylarının büyük bir sebebi ve bot sektörünün Metin2'de gelişmesinin sebeplerinden en büyük sorumlu GameForge'dir ve buna bizzat izin veren ortak çalışma yürüten de kendileridir. Kamudan özür konusu da bunun en büyük itirafıdır. Bu söylediklerim anlaşma süresinde çok sayıda botla ilgili şikayet dönerken, şirketin şöyle çalışıyoruz böyle engelleyecek şeyler üretiyoruz diye boş duyurularla topluluğun gazını alıp daha sonra ya biz anlaştık bir şeyleri düzeltmek için ama ters gitti bize kelek attılar kafasında özür dilemesi bunu doğruluyor. Bu bilgi bu sıkıntılarla hala günümüzde uğraşan ve geçmişte Kronos döneminden sonra (tarihi hatırlamanız için) uğraşmış tüm üst yöneticilerin şikayetleri ile biliniyor zaten.

Random hesap ve karakter adı oluşturma çok uzun zaman sonra bot kullanıcılarına "bir icat" adı altında duyurularak botcular tarafından sunuldu. Oysaki yıllar öncesinde bunu yapan zaten çinli botlar vardı. O dönemde görev alan ve bilgisi olan bir kaç abimizin/ablamızın da bir yerde şirketin bu konuda bilgisi olduğunun itirafını yapmıştı ama birilerine ama bir yerlere.

M2Bob'un konusuna gelirsek, Slait yani by banjo zaten topluluğun Multihack ile en büyük hile geliştiricilerinden biri. Multihack'ı hangimiz kullanmadık ki? Multihack, muz hilesi gibi bir çok farklı şeyi hepimiz biliyoruz. Resmini bırakayım biraz nostalji olsun :)

17925 eklentisini görüntüle



Test ekibinin dosyaları yüklediği FTP sunucusunda bizzat M2Bob'un test süreçleri, betaları ile ilgili dosya ve video içerikleri vardı. Hatta şöyle bir şey de söyleyelim, Hidra haritasının tasarımı size tanıdık gelecektir çünkü 4 farklı görselden örnek alınarak çizildi ve görsellerden biri ve en çok örnek alınanı da buydu. Karakterlerin bossların tasarımlarında örnek alınan diğer oyunlar anlatımlar kurulan mantıklar hepsi test birimlerinde bir seviye üst ekip ile paylaşılıyordu. Beta ve Omega sunucuları arasında da ilk inceleyecekler, son ve en son yayıncılar olmak üzere farklı farklı sunucular da vardı.

17926 eklentisini görüntüle

Ya demek istediğim şu, bu adamlar bir şekilde belirli test ve incelemelere katılmış. İşin içerisinde var ya da yoklar ancak konu çok farklı şekilde anlaşılabilecek düzeyde o FTP sunucusunda duruyor. Test ekibinden bazı kişilere de incelemeleri için hesaplar verilmiş M2Bob'un ve GF'nin kendi mail sunucu uzantıları ile kayıtlı hesaplardan, full ücretsiz botu kullanabilen hesaplardan bahsediyorum o dönem için. Gidip M2Bob satın alıp engellemek için incelediğini düşünmek isterim ama süreli botun süresiz kullanılabilmesi ve GF'nin kendi mail sunucuları ile üyelik oluşturulmuş olması bu düşüncemi de engelliyor.

Mattermost'da Alman comasına bizzat sorumu iletmiştim ancak o da bir şey söyleyememişti. Cheat Blocker ile ilgili Product Manager ile tartışırken de ona bunları iletmiştim, o da cevap vermekten kaçınmıştı.
bana bütün bu yazılanlar komplo teorisi gibi geliyor

"Bot olaylarının büyük bir sebebi ve bot sektörünün Metin2'de gelişmesinin sebeplerinden en büyük sorumlu GameForge'dir ve buna bizzat izin veren ortak çalışma yürüten de kendileridir" -> Oyunun server client kodları internette var bot yapılmaması için herhangi bir sebep yok? Hile yapımcısı GF ile çalışmak zorunda falan değil.

Yazdıkların tamamen varsayımlardan ve teorilerden oluşuyor ama kendinden çok emin yazmışsın, söylediklerine kaynak belirtebilir misin?

İşin aslı şu, GameForge ile Çinli bir firma olması gerek kendi aralarında anlaşıyorlar. Oyun için full gelişmiş bir bot yapıyorlar. Bu ilk full fonksiyon EasyMetin2 botundan önce gerçekleşiyor ve botları başlatan akım oluyor. Vadide vs bir sürü bot görüyorduk sıralı bir şekilde gezen, işte onlar GF ile çin merkezli bir firma olması gerek belkide koredir tam hatırlamıyorum ama onlar arasındaki bir anlaşma ile ortaya çıkıyor. Tüm sunucular dolduruluyor. Sonra GameForge'nin her yerde dünya çapında 7 milyon oyuncu reklamlarını görüyorsunuz zaten.

Dönemi hatırlamanız için :
2 T 'nin %1500 kazanç ile çinden epincilerin aldığı ve 6 TL ye sattığı dönemden bahsediyorum. Derindarbe öncesidir.

Daha sonra işler bizim diyeceğimiz dilde boka sarıyor, önünü alamıyorlar. Hatta bir aralar basın toplantısı mı ne vardı, topluluktan özür dilemişlerdi konu ile ilgili yazışmalara kadar sızdırıldığında. Bugün A to Z her şeyi yapan botlar bir şekilde türediyse, bunun sebebi GameForge.

Bu arada M2Bob'un ilk testlerinin, çalışma mantığının ve videosunun GameForge test sunucularında olduğunu biliyor muyudunuz? Biraz susalım bence :D
"Vadide vs bir sürü bot görüyorduk sıralı bir şekilde geze"-> Ben 2008 yılında oynarken bu sıralı botlardan oyunda yoktu, bunlar zaten m2bob değil, clientless paket üzerinden çalışan botlar, packet encryption ile çözüldü artık yoklar.U Uğraşan yine yapar ama mtls'e geçildiği anda bu işte biter.

"İşin aslı şu, GameForge ile Çinli bir firma olması gerek kendi aralarında anlaşıyorlar. Oyun için full gelişmiş bir bot yapıyorlar".-> Kaynak?
"Bu arada M2Bob'un ilk testlerinin, çalışma mantığının ve videosunun GameForge test sunucularında olduğunu biliyor muyudunuz? Biraz susalım bence :D" -> kaynak?

"Bugün A to Z her şeyi yapan botlar bir şekilde türediyse, bunun sebebi GameForge." -> Sebebi gameforge değil, kodları kim sızdıran ise o.
 
5cf7092b-ee7a-4b7c-a2d0-13c92a53ae50.webp


Lonca Biligisi 😀 çeviren arkadaşın acelesi varmış kimse fark etmemiş
 
Tam olarak kodların arasından bir detay sayılmaz fakat ilginç bir bilgi olabilir;

Metin2 TR'de şuan aylık abonelik sistemine sahip bir server var (hala aktif mi bilmiyorum ama en son açmışlardı, Onyx sunucuları olması lazım), bu sunucular bizim hiç yabancı olmadığımız eski bir sistemi kullanıyor, billing sistemi. Aslında billing sistemi 2005 yılında VCard sistemi ile birlikte aktif edildi, bu iki sistem oyunun Çin, Tayvan ve Hong Kong versiyonlarında kullanılması için yapıldı, durum şu; VCard denilen bir kart vardı, bunu çeşitli internet kafelerden, lokal oyun satıcılarından vs. alabiliyordunuz, bu kartın içindeki kod size belirli bir oyun süresi veriyordu örneğin 96 saat, hesabınıza girip bu kodu girdiğiniz zaman accountunuza 96 saat oynama süresi ekleniyordu ve bu süre billing sistemi tarafından kontrol ediliyordu, süre bitince tekrar oyunu oynayabilmek için yeni bir kart almanız gerekiyordu, yani oyunu oynamak ücrete tabiydi ama yalnızca belirli sunucularda, hepsinde değil. (Bu bilgilere internet archiveden metin2 Çin'in eski sitesindeki bilgileri okuyarak erişmiştim bu arada merak edip bakmak isteyenler için söyleyeyim) Geçtiğimiz yılda Metin2 yine aylık ücrete tabi bir sunucu açmaya karar verdi, bu sunucu içinde aylık abonelik satıyorlar, bunu satın aldığınızda yine billing sistemini kullanarak hesaba süre ekliyorlar ve o süre zarfında oyunu oynayabiliyorsunuz, sonrasında giriş yapmanıza izin vermiyor.

Yani elimizdeki sistem ile Free To Play değil, abonelik sistemine sahip bir p-server yapılabilir, ama bunu kimse oynar mı onu bilmiyorum tabii, sevgiler. 😄
 
Tam olarak kodların arasından bir detay sayılmaz fakat ilginç bir bilgi olabilir;

Metin2 TR'de şuan aylık abonelik sistemine sahip bir server var (hala aktif mi bilmiyorum ama en son açmışlardı, Onyx sunucuları olması lazım), bu sunucular bizim hiç yabancı olmadığımız eski bir sistemi kullanıyor, billing sistemi. Aslında billing sistemi 2005 yılında VCard sistemi ile birlikte aktif edildi, bu iki sistem oyunun Çin, Tayvan ve Hong Kong versiyonlarında kullanılması için yapıldı, durum şu; VCard denilen bir kart vardı, bunu çeşitli internet kafelerden, lokal oyun satıcılarından vs. alabiliyordunuz, bu kartın içindeki kod size belirli bir oyun süresi veriyordu örneğin 96 saat, hesabınıza girip bu kodu girdiğiniz zaman accountunuza 96 saat oynama süresi ekleniyordu ve bu süre billing sistemi tarafından kontrol ediliyordu, süre bitince tekrar oyunu oynayabilmek için yeni bir kart almanız gerekiyordu, yani oyunu oynamak ücrete tabiydi ama yalnızca belirli sunucularda, hepsinde değil. (Bu bilgilere internet archiveden metin2 Çin'in eski sitesindeki bilgileri okuyarak erişmiştim bu arada merak edip bakmak isteyenler için söyleyeyim) Geçtiğimiz yılda Metin2 yine aylık ücrete tabi bir sunucu açmaya karar verdi, bu sunucu içinde aylık abonelik satıyorlar, bunu satın aldığınızda yine billing sistemini kullanarak hesaba süre ekliyorlar ve o süre zarfında oyunu oynayabiliyorsunuz, sonrasında giriş yapmanıza izin vermiyor.

Yani elimizdeki sistem ile Free To Play değil, abonelik sistemine sahip bir p-server yapılabilir, ama bunu kimse oynar mı onu bilmiyorum tabii, sevgiler. 😄
Hilesiz ve kekosuz bir mmo'nun tek yolu abonelik sistemi bence
 
bana bütün bu yazılanlar komplo teorisi gibi geliyor

"Bot olaylarının büyük bir sebebi ve bot sektörünün Metin2'de gelişmesinin sebeplerinden en büyük sorumlu GameForge'dir ve buna bizzat izin veren ortak çalışma yürüten de kendileridir" -> Oyunun server client kodları internette var bot yapılmaması için herhangi bir sebep yok? Hile yapımcısı GF ile çalışmak zorunda falan değil.

Yazdıkların tamamen varsayımlardan ve teorilerden oluşuyor ama kendinden çok emin yazmışsın, söylediklerine kaynak belirtebilir misin?


"Vadide vs bir sürü bot görüyorduk sıralı bir şekilde geze"-> Ben 2008 yılında oynarken bu sıralı botlardan oyunda yoktu, bunlar zaten m2bob değil, clientless paket üzerinden çalışan botlar, packet encryption ile çözüldü artık yoklar.U Uğraşan yine yapar ama mtls'e geçildiği anda bu işte biter.

"İşin aslı şu, GameForge ile Çinli bir firma olması gerek kendi aralarında anlaşıyorlar. Oyun için full gelişmiş bir bot yapıyorlar".-> Kaynak?
"Bu arada M2Bob'un ilk testlerinin, çalışma mantığının ve videosunun GameForge test sunucularında olduğunu biliyor muyudunuz? Biraz susalım bence :D" -> kaynak?

"Bugün A to Z her şeyi yapan botlar bir şekilde türediyse, bunun sebebi GameForge." -> Sebebi gameforge değil, kodları kim sızdıran ise o.
coma fastfood ile silverhand aynı kişiler ondan dolayı

Burayı görüntülemek için üye girişi yapmalı veya kayıt olmalısınız.
 
ClientManagerPlayer.cpp de

C++:
Genişlet Daralt Kopyala
                CLoginData* pLoginData1 = GetLoginDataByAID(temp1->account_id);    //              
                //독일 선물 기능
                if( pLoginData1->GetAccountRef().login == NULL)
                    break;
                if( pLoginData1 == NULL )
                    break;

@MT2Dev ne diyo burda ben anlayamadım. :ROFLMAO::ROFLMAO:
Emeklilikte yaşa takılan developerın yazdığı kod
 
ClientManagerPlayer.cpp de

C++:
Genişlet Daralt Kopyala
                CLoginData* pLoginData1 = GetLoginDataByAID(temp1->account_id);    //              
                //독일 선물 기능
                if( pLoginData1->GetAccountRef().login == NULL)
                    break;
                if( pLoginData1 == NULL )
                    break;

@MT2Dev ne diyo burda ben anlayamadım. :ROFLMAO::ROFLMAO:

bunun yarattığı sorunu aktif oyunda yaşamış birisini görmüştüm, çok alakasız bir şekilde item award ile alakalı bir logdan sonra db çöküyordu
 
ClientManagerPlayer.cpp de

C++:
Genişlet Daralt Kopyala
                CLoginData* pLoginData1 = GetLoginDataByAID(temp1->account_id);    //           
                //독일 선물 기능
                if( pLoginData1->GetAccountRef().login == NULL)
                    break;
                if( pLoginData1 == NULL )
                    break;

@MT2Dev ne diyo burda ben anlayamadım. :ROFLMAO::ROFLMAO:

Seviyorum bu kodları, 10 sene de baksan 11. yıl yeni bir şey fark edebiliyorsun, cevher gibi. 😅 Kendi dosyalarıma baktım şimdi, ben bu şekilde düzenlemişim;

C++:
Genişlet Daralt Kopyala
        case QID_QUEST:
        {
            sys_log (0, "QID_QUEST %u", info->dwHandle);
            RESULT_QUEST_LOAD (peer, pSQLResult, info->dwHandle, info->player_id);
            ClientHandleInfo* temp1 = info.get();
            if (!temp1)
            {
                break;
            }

            CLoginData* pLoginData1 = GetLoginDataByAID (temp1->account_id); // German giftbox feature. - [Ymir Dev Note]
            if (!pLoginData1)
            {
                break;
            }

            // GetAccountRef().login will never be nullptr, so we don't need to check this.. - [MT2Dev Note]
            sys_log (0, "info of pLoginData1 before call ItemAwardfunction %d", pLoginData1);
            ItemAward (peer, pLoginData1->GetAccountRef().login);
        }
        break;
 
Seviyorum bu kodları, 10 sene de baksan 11. yıl yeni bir şey fark edebiliyorsun, cevher gibi. 😅 Kendi dosyalarıma baktım şimdi, ben bu şekilde düzenlemişim;

C++:
Genişlet Daralt Kopyala
        case QID_QUEST:
        {
            sys_log (0, "QID_QUEST %u", info->dwHandle);
            RESULT_QUEST_LOAD (peer, pSQLResult, info->dwHandle, info->player_id);
            ClientHandleInfo* temp1 = info.get();
            if (!temp1)
            {
                break;
            }

            CLoginData* pLoginData1 = GetLoginDataByAID (temp1->account_id); // German giftbox feature. - [Ymir Dev Note]
            if (!pLoginData1)
            {
                break;
            }

            // GetAccountRef().login will never be nullptr, so we don't need to check this.. - [MT2Dev Note]
            sys_log (0, "info of pLoginData1 before call ItemAwardfunction %d", pLoginData1);
            ItemAward (peer, pLoginData1->GetAccountRef().login);
        }
        break;
Türkçe meali nedir hocam 🤣🤣
 
Benim de konuya ufak bir katkım olsun :D

Türlerine göre haritalara kimlik kazandırmak için client tarafında MapBase.cpp de şöyle bir kod mevcut:
C++:
Genişlet Daralt Kopyala
    if (0 == c_rstrMapType.compare("Indoor"))
        SetType(MAPTYPE_INDOOR);
    else if (0 == c_rstrMapType.compare("Outdoor"))
        SetType(MAPTYPE_OUTDOOR);
    else if (0 == c_rstrMapType.compare("Invalid"))
        SetType(MAPTYPE_OUTDOOR);
Fakat Indoor olması gereken haritaların neredeyse tamamı garip bir şekilde Outdoor türünde.. Harita dosyalarında Indoor tanımı kullanılmamış.
En azından mainline'da durum böyle. Marty vb. fileslerlarda nasıl olduğunu bilmiyorum.

Mesela örümcek zindanı haritasının mapproperty.txt içeriği:
Kod:
Genişlet Daralt Kopyala
ScriptType MapProperty

MapType "Outdoor"

Maymun zindanı, şeytan kulesi ve sürgün mağarası da aynı şekilde.

Oysa MapType "Indoor" olmalı. Böylelikle özellikle client tarafında zindanlar üzerinde özelleştirmeler yaparken map index veya harita klasör adını sorgulamak gibi manasız sorgular yerine doğrudan şöyle sorgulamalar yapılabilir:

C++:
Genişlet Daralt Kopyala
CMapOutdoor& rkMap = GetMapOutdoorRef();
if (CMapBase::MAPTYPE_INDOOR == rkMap.GetType()) // eğer harita zindan/dungeon ise...(indoor)
    [Yapılacak işlemler..]
else // değilse.. (açık hava haritalar ise..köyler gibi)
    [Yapılacak işlemler..]
 
Benim de konuya ufak bir katkım olsun :D

Türlerine göre haritalara kimlik kazandırmak için client tarafında MapBase.cpp de şöyle bir kod mevcut:
C++:
Genişlet Daralt Kopyala
    if (0 == c_rstrMapType.compare("Indoor"))
        SetType(MAPTYPE_INDOOR);
    else if (0 == c_rstrMapType.compare("Outdoor"))
        SetType(MAPTYPE_OUTDOOR);
    else if (0 == c_rstrMapType.compare("Invalid"))
        SetType(MAPTYPE_OUTDOOR);
Fakat Indoor olması gereken haritaların neredeyse tamamı garip bir şekilde Outdoor türünde.. Harita dosyalarında Indoor tanımı kullanılmamış.
En azından mainline'da durum böyle. Marty vb. fileslerlarda nasıl olduğunu bilmiyorum.

Mesela örümcek zindanı haritasının mapproperty.txt içeriği:
Kod:
Genişlet Daralt Kopyala
ScriptType MapProperty

MapType "Outdoor"

Maymun zindanı, şeytan kulesi ve sürgün mağarasına da aynı şekilde.

Oysa MapType "Indoor" olmalı. Böylelikle özellikle client tarafında zindanlar üzerinde özelleştirmeler yaparken map index veya harita klasör adını sorgulamak gibi manasız sorgular yerine doğrudan şöyle sorgulamalar yapılabilir:

C++:
Genişlet Daralt Kopyala
CMapOutdoor& rkMap = GetMapOutdoorRef();
if (CMapBase::MAPTYPE_INDOOR == rkMap.GetType()) // eğer harita zindan/dungeon ise...(indoor)
    [Yapılacak işlemler..]
else // değilse.. (açık hava haritalar ise..köyler gibi)
    [Yapılacak işlemler..]
Bu heralde harita türüne göre birşeyler yaparız diye eklemişler sonra kendiler de unutmuş
 
Client kaynak kodları içerisinde hakkında yerli yabancı bütün Metin2 forumlarında yalnızca bir kaç konu olan bir bölüm var, aslında işlevi büyük ve kurcalanırken dikkat edilmeli, bu yorumu dikkat etmeyen veya bunun işlevini bilmeyen arkadaşlara bilgilendirme olması için yapıyorum (nereden esti derseniz, client tarafı ile uğraşıyorum ilgili dosyayı düzenlerken görünce doğaçlama gelişti), nereye yazsam diye düşündüm, geliştirme günlüğüne yazıyordum ki burası daha mantıklı gibi geldi. 😄

UserInterface/PythonNetworkStreamPhaseGame.cpp:
Genişlet Daralt Kopyala
    /* INFO: Explanation is needed for MAX_RECV_COUNT and SAFE_RECV_BUFSIZE..                                                                             /
    /------  Ymir set it to 4 for recv packet count and set bufsize 8KB but it was 2004 when they were doing it,                                          /
    /------  We need keep this low still but 4 is too low for nowadays (Because internet speeds are much higher now).                                     /
    /------  But it doesn't make sense to make it something like 32, 50 or 64, because above 32 still too much even 2024,                                 /
    /------  And also thats still too much for live server too. (Ex; 5.000 online players and 1Gbit internet speed, it's still too much).                 /
    /------  This feature should definitely NOT BE REMOVED !!!                                                                                            /
    /------  If the restriction is removed on a server with high player counts, players may be kicked out of the game due to packet problems.             /
    /------  In my opinion, 8 Recv and 8KB Buf would be the ideal setting for now but you must check the other note too. - [MT2Dev Note] - 21/02/2024    */
    /*****************************************************************************************************************************************************/
    /* NOTE: We can extend it little more for the extreme scenarios,                                                                                      /
    /------  Example if you add something extra like big packets (Ex if just one packet over 8KB, potantially offline shop or some big system like this). /
    /------  Another example, if we have too much active packet in server,                                                                                /
    /------  (Scenarios like, if 8 recv packet count limit for each time not allow to game make the job done correctly, ultimatly rare scenario).         /
    /------  If so, we can extend it little more like * 2, thats why i added this new define for this job but you need to know something about this,      /
    /------  @@@ --->>> IMPORTANT: DO NOT ACTIVATE THIS DEFINE IF YOU NOT HAVE TOO BIG OR TOO MUCH PACKETS !!! - [MT2Dev Note] - 02/09/2024              */
    /*****************************************************************************************************************************************************/
    #ifdef EXTENDED_PACKET_RECV_LIMITS
    const DWORD MAX_RECV_COUNT    = 16;
    const DWORD SAFE_RECV_BUFSIZE = 16384;
    DWORD dwRecvCount             = 0;
    #else
    const DWORD MAX_RECV_COUNT    = 8;
    const DWORD SAFE_RECV_BUFSIZE = 8192;
    DWORD dwRecvCount             = 0;
    #endif //EXTENDED_PACKET_RECV_LIMITS

    while (ret)
    {
        if (dwRecvCount++ >= MAX_RECV_COUNT - 1 && GetRecvBufferSize() < SAFE_RECV_BUFSIZE
            && m_strPhase == "Game")  // phase_game doesn't have to be a game to get in here. - [Ymir Dev Note]
        {
            break;
        }
        
        // xxxxxx fonksiyonun devamı...

Buradaki 4-5 satır kod aslında oyunun sıkıntısız akması, güvenlik zafiyetleri, performans sıkıntıları gibi bir çok olaya doğrudan etki ediyor, İngilizce yorum satırını okumakla uğraşmayın kısaca bu kod ne işe yarıyor, neden burada anlatayım;

Ne işe yarıyor ?

Bu kodun kısaca işlevi paket alışverişini sınırlamak, böylece iletimdeki karışıklığın azalması, anlık performans kayıplarında paketlerin düzgün işlenmesi ve paketler üzerinden alınabilecek bir saldırı da bunun boyutunun sınırlandırılması gibi konularda avantaj sağlamış oluyor.

Dezavantajı ne ?

Bu sınırın düşük olması oyun içindeki bazı senaryolarda geç tepki verme veya genel olarak lag gibi olaylara sebebiyet veriyor, toplu bir savaşta yaşanan takılma ve gecikmeler, çok fazla hesaplama gereken işlemler yapılırken oyunun geç cevap vermesi gibi durumlar bunlara örnek olabilir, sınırı arttırdığınızda bu sorunlardan kurtulabilirsiniz ama her şeyin bir bedeli de vardır..

Sonuç ve Öneri

- Bu özelliği kesinlikle kaldırmayın! Düzensiz paket alışverişi, kayıp paketler, oyundan atılan oyuncular, spam koruması yoksa açılacak kapılar ve diğer saçma sorunlarla uğraşmak zorunda kalırsınız. (Örneğin Marty zamanında kaldırmayı denedi, şuan o da geri eklemiş durumda ve bu değeri 8 olarak -ki bence de en mantıklı değer- kullanıyor)

- Siz aktif sunucunuzda bu özelliği kaldırdınız, veya 32, 50, 64 vs. ayarlayıp sorun yaşamadınız diye başka birinin kendi sunucusunda sorun yaşamayacağı garanti değil, o yüzden dikkatli olun.

- Tek başına boyutu 8KB aşan bir paketiniz varsa (bazı durumlarda büyük paketler kullanılabilir) belki o zaman buffer sınırını arttırmayı düşünebilirsiniz aksi halde kesinlikle değiştirmeyin.

- Recv countu arttırmak lag gibi bazı can sıkıcı performans sorunlarını giderdiği için çok tatlı gelecektir fakat bir yeri düzeltirken geri kalan kısmı riske atmanızın bir manası yok, bu değeri Ymir zamanında 4 olarak belirlemiş, günümüz şartlarında ve teknolojisinde buffer boyutunun aynı kalması ve recv countun iki katı olan 8'e çıkartılması yeterlidir, performans olarak da yeterince iyileştirme sağlar. Eğer çok fazla sisteme, çok büyük paketlere vs. sahip bir sunucunuz varsa sağlıklı olarak yapabileceğiniz maksimum iyileştirme 16 olmalı, fazlasının riskli olduğunu düşünüyorum ayrıca gerekli spam korumalarını da kullanmayı unutmamak lazım, sevgiler.
Bunun nedenini biraz açmak istiyorum, eğer maks. buffer boyutuna limit konulmazsa, bağlantıyı manipüle eden kötü niyetli bir oyuncu pekala gigabytelarca veriyi tek paket(SAFE_RECV_BUFSIZE kontrol ediyor) olarak gönderebilir.[yanlış veri olsa bile transfer bitene kadar handle(*işleme alınmak) edilmeyeceğinden, transfer sürerken sunucu tarafı bunu önbelleğe almaya devam edecektir. (eğer ekstra bir önlem yoksa, kod bloğunu tam incelemedim)]
Sonuç sunucu, önbelleğinde bağlantın buffer'ında kalan veriler yüzünden şişecek, ve boom. Oyun kilit. Nedeni, ise ram yetersizliği gibi görünecek.

Bahsettiğiniz gibi bu konuda buffer boyutunun iyi ayarlanması çok önemlidir, fazla büyük olursa, transfer sırasında bufferde kalan boş bitler sıfırla doldurulup transfer edileceğinden, bu bant genişliğinin fazla kullanılması anlamına gelir, eğer çok küçük ayarlanırsa bu seferde işletim sistemi tarafından çok fazla bölümleme yapılarak(MAX_RECV_COUNT değeri tarafından kontrol ediyor burada), yine yoğun trafiğe, pinge ve gecikmelere neden olacaktır. MAX_RECV_COUNT değerinin çok küçük olması, oyuncunun ardarda paket gönderiği bir senaryoda, oyuncuyu oyundan disconnect edecektir. Aşırı yüksek olması veya hiç limit olmaması(korkunç senaryo) ise paket flooduna karşı sunucuyu savunmasız bırakacaktır.

Kısa Özet: Kapatmayın. :ROFLMAO: 8/16 / 8192 fazlasıyla uygun bir değer günümüzde. Fazlası için diğer sistemlerin buna uygun tasarlanması veya adapte edilmesi daha iyi bir çözüm olur diye düşünüyorum. 16knın bile fazla olduğunun düşünüyorum.
 
şu kod bana çok garip geliyor acaba birisi bilerek yazmış olabilirmi

PythonItem.cpp:
Genişlet Daralt Kopyala
    bool bStabGround = false;

    if (bDrop)
    {
        z = CPythonBackground::Instance().GetHeight(x, y) + 10.0f;

        if (pItemData->GetType()==CItemData::ITEM_TYPE_WEAPON &&
            (pItemData->GetWeaponType() == CItemData::WEAPON_SWORD ||
             pItemData->GetWeaponType() == CItemData::WEAPON_ARROW))
            bStabGround = true;//belirli bir koşul sonrası true yapmış

        bStabGround = false;//sonrada false çevirmiş
        pGroundItemInstance->bAnimEnded = false;
    }
    else
    {
        pGroundItemInstance->bAnimEnded = true;
    }
 
Geri
Üst