Kodların arasında sessizce duran Metin2 detayları

Locale.cpp:
Genişlet Daralt Kopyala
unsigned LocaleService_GetLastExp(int level)
{
    static const int GUILD_LEVEL_MAX = 20;
    static DWORD INTERNATIONAL_GUILDEXP_LIST[GUILD_LEVEL_MAX+1] =
    {
        0,            // 0
        6000UL,        // 1
        18000UL,    // 2
        36000UL,    // 3
        64000UL,    // 4
        94000UL,    // 5
        130000UL,    // 6
        172000UL,    // 7
        220000UL,    // 8
        274000UL,    // 9
        334000UL,    // 10
        400000UL,    // 11
        600000UL,    // 12
        840000UL,    // 13
        1120000UL,    // 14
        1440000UL,    // 15
        1800000UL,    // 16
        2600000UL,    // 17
        3200000UL,    // 18
        4000000UL,    // 19       
        16800000UL    // 20       
    };

    if (level < 0 && level >= GUILD_LEVEL_MAX)  // ??? :D
        return 0;
    
    return INTERNATIONAL_GUILDEXP_LIST[level];   
}

Ymir'den örnek teşkil edecek bir operatör kullanımı. :ROFLMAO:
 
Locale.cpp:
Genişlet Daralt Kopyala
unsigned LocaleService_GetLastExp(int level)
{
    static const int GUILD_LEVEL_MAX = 20;
    static DWORD INTERNATIONAL_GUILDEXP_LIST[GUILD_LEVEL_MAX+1] =
    {
        0,            // 0
        6000UL,        // 1
        18000UL,    // 2
        36000UL,    // 3
        64000UL,    // 4
        94000UL,    // 5
        130000UL,    // 6
        172000UL,    // 7
        220000UL,    // 8
        274000UL,    // 9
        334000UL,    // 10
        400000UL,    // 11
        600000UL,    // 12
        840000UL,    // 13
        1120000UL,    // 14
        1440000UL,    // 15
        1800000UL,    // 16
        2600000UL,    // 17
        3200000UL,    // 18
        4000000UL,    // 19       
        16800000UL    // 20       
    };

    if (level < 0 && level >= GUILD_LEVEL_MAX)  // ??? :D
        return 0;
    
    return INTERNATIONAL_GUILDEXP_LIST[level];   
}

Ymir'den örnek teşkil edecek bir operatör kullanımı. :ROFLMAO:
Yazar burada aslında ne yapmaya çalışmış peki? Düzeltelim
 
Yazar burada aslında ne yapmaya çalışmış peki? Düzeltelim
if (level < 0 && level >= GUILD_LEVEL_MAX) // ??? :D
return 0;

and operatörünün saçma salak kullanımı var :d lonca seviyesi hem 0 a eşit hem max seviyeden büyük olması mevzusunu sorgulatmış yani imkansız bi durum, illa sorgulayacaksak or operatörü koyabiliriz
if (level < 0 || level >= GUILD_LEVEL_MAX)
return 0;
 
Locale.cpp:
Genişlet Daralt Kopyala
unsigned LocaleService_GetLastExp(int level)
{
    static const int GUILD_LEVEL_MAX = 20;
    static DWORD INTERNATIONAL_GUILDEXP_LIST[GUILD_LEVEL_MAX+1] =
    {
        0,            // 0
        6000UL,        // 1
        18000UL,    // 2
        36000UL,    // 3
        64000UL,    // 4
        94000UL,    // 5
        130000UL,    // 6
        172000UL,    // 7
        220000UL,    // 8
        274000UL,    // 9
        334000UL,    // 10
        400000UL,    // 11
        600000UL,    // 12
        840000UL,    // 13
        1120000UL,    // 14
        1440000UL,    // 15
        1800000UL,    // 16
        2600000UL,    // 17
        3200000UL,    // 18
        4000000UL,    // 19       
        16800000UL    // 20       
    };

    if (level < 0 && level >= GUILD_LEVEL_MAX)  // ??? :D
        return 0;
    
    return INTERNATIONAL_GUILDEXP_LIST[level];   
}

Ymir'den örnek teşkil edecek bir operatör kullanımı. :ROFLMAO:
've' ymir zengin oldu. Mutlu Son.
 
Yazar burada aslında ne yapmaya çalışmış peki? Düzeltelim

Normalde yazarın yaptığı birden fazla hata var, level int tanımlı ve max lonca leveli 20, bu durumda level'in 0'dan az veya 20'den fazla (veya eşit) olmaması gerekir (bu fonksiyonun devreye girmesi için) bunu engellemek için kontrol koymuş ama "yada" operatörü yerine "ve" operatörü kullanmış yani bu kontrol eğer level 0'dan düşükse "ve" level 20'ye eşit veya 20'den yüksekse devreye girecek, yani bunun olma ihtimali yok çünkü level aynı anda hem 0'dan düşük hem de 20'den yüksek olamaz, aslında burada "yada(||)" operatörü kullanması gerekiyordu fakat yanlış yazmış. Ama burada ana problem farklı;

Sadece 20 seviye olabilecek bir veriye int tanımlamış yani 0'ın altında değer alabilir daha sonra bunu engellemek için kontrol koymuş onu da yanlış koymuş, benim eğitim hayatımda öğrendiğim stil mümkün olan en az kodu yazarak verilen işi yapmak üzerineydi o yüzden bu tarz durumlar çok absürt ve yanlış geliyor, bu veri tipi 0'ın altında olamaz değil mi mesela, tamam o zaman buna unsigned bir veri tipi tanımla böylece 0'ın altını kontrol etmene gerek kalmaz, int yerine unsigned short kullan mesela, problem bitti. Metin2'nin dev ekibinin ana olarak C dilinde profesyonel olan insanlardan oluştuğunu düşünüyorum, yazdıkları tüm fonksiyonlarda ezberlerini bozmayıp gerekli gereksiz demeden her şeyi int tanımlayıp geçmişler, bu nelere sebep oldu peki ? 0'ın altında değer almaması gereken fonksiyonlarda int tanımlayıp kontrol de eklemedikleri her yerde problem yaşattı, bir iki örnek; /war -111 açığı, /mob -1 açığı vs.

Bu sebeple siz siz olun yazdığınız sistemlerde de her zaman doğru veri tipini kullanın böylece hem daha az kod yazarsınız hem de hata şansınız azalır, sevgiler.
 
Normalde yazarın yaptığı birden fazla hata var, level int tanımlı ve max lonca leveli 20, bu durumda level'in 0'dan az veya 20'den fazla (veya eşit) olmaması gerekir (bu fonksiyonun devreye girmesi için) bunu engellemek için kontrol koymuş ama "yada" operatörü yerine "ve" operatörü kullanmış yani bu kontrol eğer level 0'dan düşükse "ve" level 20'ye eşit veya 20'den yüksekse devreye girecek, yani bunun olma ihtimali yok çünkü level aynı anda hem 0'dan düşük hem de 20'den yüksek olamaz, aslında burada "yada(||)" operatörü kullanması gerekiyordu fakat yanlış yazmış. Ama burada ana problem farklı;

Sadece 20 seviye olabilecek bir veriye int tanımlamış yani 0'ın altında değer alabilir daha sonra bunu engellemek için kontrol koymuş onu da yanlış koymuş, benim eğitim hayatımda öğrendiğim stil mümkün olan en az kodu yazarak verilen işi yapmak üzerineydi o yüzden bu tarz durumlar çok absürt ve yanlış geliyor, bu veri tipi 0'ın altında olamaz değil mi mesela, tamam o zaman buna unsigned bir veri tipi tanımla böylece 0'ın altını kontrol etmene gerek kalmaz, int yerine unsigned short kullan mesela, problem bitti. Metin2'nin dev ekibinin ana olarak C dilinde profesyonel olan insanlardan oluştuğunu düşünüyorum, yazdıkları tüm fonksiyonlarda ezberlerini bozmayıp gerekli gereksiz demeden her şeyi int tanımlayıp geçmişler, bu nelere sebep oldu peki ? 0'ın altında değer almaması gereken fonksiyonlarda int tanımlayıp kontrol de eklemedikleri her yerde problem yaşattı, bir iki örnek; /war -111 açığı, /mob -1 açığı vs.

Bu sebeple siz siz olun yazdığınız sistemlerde de her zaman doğru veri tipini kullanın böylece hem daha az kod yazarsınız hem de hata şansınız azalır, sevgiler.
Yani doğru yaklaşım bu mudur? Sizden öğrenecek çok şey var hakikatten.
1724589741595.webp
 
server tarafında hatalı bir durumda rastgele şekilde hata mesajı yazdıran bir koşul var;
18550 eklentisini görüntüle
Çok enteresan bir yöntem kullanmışlar, muhtemelen direkt logladıkları zaman sys_err'i çok şişiriyordu ama test aşamasında görmek zorunda hissetmişler o yüzden bari arada bir versin de varlığından haberimiz olsun demiş olabilirler, pek mantıksız gelmedi şaşırtıcı şekilde. 😅
 
Başka bir lüzumsuz hard-coding örneği

C++:
Genişlet Daralt Kopyala
enum EDragonSoulSubType
{
    DS_SLOT1,
    DS_SLOT2,
    DS_SLOT3,
    DS_SLOT4,
    DS_SLOT5,
    DS_SLOT6,
    DS_SLOT_NUM_TYPES = 6,
};
 
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.
 
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.

:flag:
1725371477073.webp
 
Otomatik item satışı yazarken PickupItem içerisinde bir şey fark ettim. Item in IsOwnership ise item i destroy ediyor, IsOwnership değilse hiç bir şey yapmıyor. Mantığı ne? Ben çözmedim bir türlü yani o itemi oluşturuyorsun ama IsOwnership i değilse ramki bu itemi ne destroy edecek?

1725588490312.webp

1725588297862.webp

1725588875989.webp
 
1:
Genişlet Daralt Kopyala
                if (FindAffect(AFFECT_EXP_BONUS_EURO_FREE, POINT_RESIST_MAGIC))
                {
                    ChatPacket(CHAT_TYPE_INFO, LC_TEXT("이미 효과가 걸려 있습니다."));
                }
                else
                {
                    AddAffect(affect_type, apply_type, apply_value, 0, apply_duration, 0, false);
                    item->SetCount(item->GetCount() - 1);
                }
            }
şebnem kullanırken diyor ki çicek sularında büyü savunması varsa hiç bir şebnemi kullanma çok saçma bir durum neden diğer şebnemlere engel konulsun ki?
 
Detaydan çok saçmalık var desem daha doğru olur. 😄 Tek tek incelerken o kadar fazla şeye denk geliyorsunuz ki yani bazılarını görünce gerçekten üstümü başımı yırtma aşamasına geldim. Tek tek çok fazla örnek verilebilir ama ben genel olarak metin2 projesinin kaynak kodları hakkında bir yorum yapayım;

Hard-coded bölümlerle dolu (nerdeyse tamamı), yazılım eğitimi alan bir gence okulda gösterecekleri ve "sakın bunu yapma" diyecekleri bütün yanlış teknikleri içeren, projenin başlangıcında yer alan bir iki senior yazılımcının yaptığı işin üstüne ekleme yaparken çalışan hiçbir şeyi değiştirmeyip 20 yıl sonra bile 2004'e uygun yazılan demode her şeyi muhafaza eden (ki o ekipten hala devam edenler var diye biliyorum, onlarda kaçak kat çıkmaya devam ediyor), C++ bir projede C tipi çok fazla referans içeren, null pointer ve overflow kontrollerinin yüzlercesinin eksik olduğu ve bütün bunları göz önünde bulundurup okurken bu oyun bu altyapıyla tüm dünyada nasıl anlık 5 milyon oyuncuya ulaştı diye düşündüren bir proje, hem saygı duyup hem de lanet ettiren cinsten. :LOL:
Geçen gün telefondan temiz Source dosyalarına Github üzerinden bakayım dedim belki birşey bulurum diye birisi yüklemiş githuba. İnput_db.cpp sanırım PlayerLoad kısmıydı sanırım orada bir kod var eğer oyuncu yüklendiğinde bulunduğu haritada değilse PHASE_CLOSE ettiriyor. Onun hemen üstünde Korece yazılar vardı uzunca merak ettim ne anlatmak istemiş diye. Türkçeye çevirdiğimde ise şuna benzer bir yazı vardı.

Oyuncunun haritası yoksa neden başka bir haritaya yönlendirmeye çalışıyorsun çıkışa yönlendirmelisin.

Özetle böyle bir yazı vardı ama bu yazıyı sanki başkasına yazmış gibiydi yani A kişisi başka bir haritaya yönlendirmeye çalışmış sonra B kişisi böyle bir not bırakıp PHASE_CLOSE ettirip düzenlemiş. 🤣🤣
 
Otomatik item satışı yazarken PickupItem içerisinde bir şey fark ettim. Item in IsOwnership ise item i destroy ediyor, IsOwnership değilse hiç bir şey yapmıyor. Mantığı ne? Ben çözmedim bir türlü yani o itemi oluşturuyorsun ama IsOwnership i değilse ramki bu itemi ne destroy edecek?

18725 eklentisini görüntüle
18722 eklentisini görüntüle
18726 eklentisini görüntüle

Ben bu kodlarda item oluşturma göremedim sadece parametreden gelen (Sanırım ClientSourceden gelen) Itemin Vdini arıyor. Ona göre işlem yapılıyor. Eğer bu itemin sahibi ise ona göre işlem yapıyor. Zaten o item onun değilse diye birşey olamaz mutlak birisinin olmalı eğer o itemi yerden almazsa StartDestroyItem ile yerden silinir. Çok çok şu olur onun da engelini koymuş gelen vid’i eğer bulamazsa if (!item) yani null ise negatif döndürmüş.
 
Son düzenleme:
Ben bu kodlarda item oluşturma göremedim sadece parametreden gelen (Sanırım ClientSourceden gelen) Itemin Vdini arıyor. Ona göre işlem yapılıyor. Eğer bu itemin sahibi ise ona göre işlem yapıyor. Zaten o item onun değilse diye birşey olamaz mutlak birisinin olmalı eğer o itemi yerden almazsa StartDestroyItem ile yerden silinir. Çok çok şu olur onun da engelini koymuş gelen vid’i eğer bulamazsa if (!item) yani null ise negatif döndürmüş.
ramdan item olarak oluşturduğunu silmesini demek istemiştim ben. kodun komplesine bakarsan ne demek istediğimi daha iyi anlayacağını düşünüyorum.
 
ramdan item olarak oluşturduğunu silmesini demek istemiştim ben. kodun komplesine bakarsan ne demek istediğimi daha iyi anlayacağını düşünüyorum.
İtem yere düştüğü zaman zaten bellekte bir adrese giriyor. Sen o itemin üstüne tıkladığın zaman PickUp item çalışıyor ve ilk satırında parametreden gelen itemin vidini adreste arıyor. Sonra o adresteki item eğer sahibinin ise vs vs vs. diğer kodlar çalışıyor. Eğer sahibi bu itemi almazsa StartDestroyItem ile bu item adresten siliniyor.

İtemin vidinin arandığı yerin hemen altında if (!item) yapmış yani null ise demiş işlemi başarısızlıkla sonlandırmış. Orası zaten null(bellekte yok) ise kısacası bir sahibi de yok demektir.
 
Son düzenleme:
Üst