konuya daha önce bunu yazdım mı bilmiyorum ama oyuna sms sistemi eklemiş adamlar, bildiğin arkadaş listende ki adamın telefonuna sms atabiliyormuşsun oyun içi
Kodların arasında sessizce duran Metin2 detayları
Ymir'den ders niteliğinde muhteşem faydalı ve açıklayıcı bir yorum satırı kullanımı örneği
Projedeki dosya sayısı arttıkça modülerlik zorlaşıyor. Kafada tasarlamak o anki ruh haline göre yetersiz kalabiliyor. Yeni bir class, birkaç fonksiyon yazmaya kalkışırsın, yazarken de istemsizce önceden yazdığı kodu okursun ve bunların gereksiz olduğunu farkedebilirsin. Bunun yerine kabaca yorum satırı ile pseudo code gibi konuşma diliyle yazarsın. Mantıksız bir şey gözükmüyorsa yazmaya başlarsın. Tahminimce o arkadaş da böyle bir düşüncedeydi.
Bu adamlar bu oyunu hazır bir oyun motoru olmadan 2004 yılında geliştirmiş. Yapay zeka yok, en büyük eksik belki de. Kodların önemli bir kısmını da C kafasıyla yazmışlar. Yargılanabilecek kısımlar olabilir ama kesinlikle aptal yerine konmaları bana daha komik geliyor
az önceki foto çok dandikti güneşi aşağı çektim bunu da açtım daha güzel duruyo sanki 
Bunu düzeltilmiş fix şeklinde paylaşma şansın var mı? Daha önce fix diye paylaşıldı ama işe yaramıyorduaz önceki foto çok dandikti güneşi aşağı çektim bunu da açtım daha güzel duruyo sanki27931 eklentisini görüntüle
nerde paylaşıldı görmedim de forumda paylaştım nasıl yapılacağınu
Herkesin genelde kaldırdığı Traffic Profiler sistemini denedim, aslında ilgi çekici raporlar veriyor, biraz geliştirilerek kullanışlı bir araç haline getirilebilir.
World Editor'un neden 2014 mob_proto'yu okuyamadığını araştırırken ilginç bir detaya denk geldim.
Sorunun kaynağı eski WorldEditor'deki TMobTable ile 2014 istemcisindeki TMobTable yapılarının tamamen farklı olmasıydı.
WorldEditor tarafında dikkatimi çeken alan şu oldu:
Yanındaki Korece yorum da:
yani kabaca:
anlamına geliyor.
İlginç olan kısım ise bunun sadece struct içinde bulunması değil.
WorldEditor'de doğrudan kullanılan fonksiyonlar mevcut:
ve
Bu değerler editör açılırken bütün mob listesine şu formatta yazdırılıyor:
Örneğin editörde bir mob şu şekilde görüntülenebiliyordu:
Aynı bilgi seçili bir spawn alanındaki yaratık gösterilirken de tekrar kullanılıyor.
Yani bu alan sadece struct içinde unutulmuş bir veri değil; editörün kullanıcı arayüzünde aktif olarak kullanılan bir özellik.
Daha da ilginci, 2014 istemcisinde bu sistem tamamen ortadan kalkmış durumda.
Eski yapı:
2014:
Yani iki byte'lık bir level aralığı yerine tek bir level değeri kullanılıyor.
Buradan kesin olarak söyleyebildiğimiz şeyler:
Eski WorldEditor moblar için tek level değil, bir level aralığı konsepti içeriyordu.
Bu aralık editör arayüzünde aktif olarak kullanılıyordu.
Daha sonraki sürümlerde bu sistem kaldırılmış ve tek level mantığına geçilmiş.
Asıl merak uyandıran kısım ise şu:
Bu sistem gerçekte ne için kullanılıyordu?
İlk akla gelen ihtimal, mobların belirli bir level aralığında spawn olabilmesiydi.
Örneğin:
olarak tanımlanıyor ve spawn olurken bu aralıktan bir level seçiliyor olabilirdi.
Fakat elimizdeki kodlar bunu henüz kanıtlamıyor.
Bunun doğrulanabilmesi için eski sunucu tarafındaki spawn veya mob oluşturma kodlarında abLevelRange kullanımını bulmak gerekiyor.
Bir başka ihtimal ise bunun gerçek bir gameplay sistemi değil, editöre yönelik bir metadata olması.
Örneğin mobun gerçek leveli sabit olsa bile:
şeklinde harita tasarımcısına o yaratığın hedef oyuncu seviyesini göstermek için kullanılmış olabilir.
Fakat burada ilginç olan nokta şu:
Bu bilgi spawn alanlarından değil, doğrudan mob datasından geliyor.
Yani Ymir'in bir dönem yaratıkları yalnızca tek bir level değeriyle değil, bir level aralığıyla tanımlamayı düşündüğünü veya kullandığını söylemek çok da uzak bir ihtimal değil.
Belki hiçbir zaman tamamlanmamış bir sistemdi.
Belki oyunun çok eski sürümlerinde gerçekten kullanıldı.
Belki de 2014'e kadar gelen süreçte tamamen terk edilip tek level mantığına geçildi.
Kodların arasında sessizce kalmış ilginç detaylardan biri daha.
Sorunun kaynağı eski WorldEditor'deki TMobTable ile 2014 istemcisindeki TMobTable yapılarının tamamen farklı olmasıydı.
WorldEditor tarafında dikkatimi çeken alan şu oldu:
C++:
BYTE abLevelRange[2];Yanındaki Korece yorum da:
C++:
// Level 결정 범위: [0] ~ [1]yani kabaca:
Kod:
Level belirleme aralığıanlamına geliyor.
İlginç olan kısım ise bunun sadece struct içinde bulunması değil.
WorldEditor'de doğrudan kullanılan fonksiyonlar mevcut:
C++:
void CNonPlayerCharacterInfo::GetLevelRangeByVID(...)
{
*pbyLowLevelLimit = p->abLevelRange[0];
*pbyHighLevelLimit = p->abLevelRange[1];
}ve
C++:
void CNonPlayerCharacterInfo::GetLevelRangeByMapIndex(...)
{
*pbyLowLevelLimit = p->abLevelRange[0];
*pbyHighLevelLimit = p->abLevelRange[1];
}Bu değerler editör açılırken bütün mob listesine şu formatta yazdırılıyor:
C++:
"%d:%s(%02d~%02d):%d"Örneğin editörde bir mob şu şekilde görüntülenebiliyordu:
Kod:
2:Wild Dog(01~04):101Aynı bilgi seçili bir spawn alanındaki yaratık gösterilirken de tekrar kullanılıyor.
Yani bu alan sadece struct içinde unutulmuş bir veri değil; editörün kullanıcı arayüzünde aktif olarak kullanılan bir özellik.
Daha da ilginci, 2014 istemcisinde bu sistem tamamen ortadan kalkmış durumda.
Eski yapı:
C++:
BYTE abLevelRange[2];2014:
C++:
BYTE bLevel;Yani iki byte'lık bir level aralığı yerine tek bir level değeri kullanılıyor.
Buradan kesin olarak söyleyebildiğimiz şeyler:
Eski WorldEditor moblar için tek level değil, bir level aralığı konsepti içeriyordu.
Bu aralık editör arayüzünde aktif olarak kullanılıyordu.
Daha sonraki sürümlerde bu sistem kaldırılmış ve tek level mantığına geçilmiş.
Asıl merak uyandıran kısım ise şu:
Bu sistem gerçekte ne için kullanılıyordu?
İlk akla gelen ihtimal, mobların belirli bir level aralığında spawn olabilmesiydi.
Örneğin:
Kod:
Yabani Köpek
Level 1~4olarak tanımlanıyor ve spawn olurken bu aralıktan bir level seçiliyor olabilirdi.
Fakat elimizdeki kodlar bunu henüz kanıtlamıyor.
Bunun doğrulanabilmesi için eski sunucu tarafındaki spawn veya mob oluşturma kodlarında abLevelRange kullanımını bulmak gerekiyor.
Bir başka ihtimal ise bunun gerçek bir gameplay sistemi değil, editöre yönelik bir metadata olması.
Örneğin mobun gerçek leveli sabit olsa bile:
Kod:
Yabani Köpek (1~4)
Ork (15~20)şeklinde harita tasarımcısına o yaratığın hedef oyuncu seviyesini göstermek için kullanılmış olabilir.
Fakat burada ilginç olan nokta şu:
Bu bilgi spawn alanlarından değil, doğrudan mob datasından geliyor.
Yani Ymir'in bir dönem yaratıkları yalnızca tek bir level değeriyle değil, bir level aralığıyla tanımlamayı düşündüğünü veya kullandığını söylemek çok da uzak bir ihtimal değil.
Belki hiçbir zaman tamamlanmamış bir sistemdi.
Belki oyunun çok eski sürümlerinde gerçekten kullanıldı.
Belki de 2014'e kadar gelen süreçte tamamen terk edilip tek level mantığına geçildi.
Kodların arasında sessizce kalmış ilginç detaylardan biri daha.
Görseli oluşturduktan sonra RAM'den tasarruf etmek için texture kalitesini düşürmeye çalışan YMIR:
Burada downgrade yazılmış
Ama sorun şu ki format değişkeni hiçbir yerde kullanılmıyor.
Texture burada çoktan oluşturulmuş:
Yani YMIR'in optimizasyon planı:
C++:
bool CGraphicImageTexture::CreateFromMemoryFile(UINT bufSize, const void* c_pvBuf, D3DFORMAT d3dFmt, DWORD dwFilter)
{
assert(ms_lpd3dDevice != NULL);
assert(m_lpd3dTexture == NULL);
static CDXTCImage image;
if (image.LoadHeaderFromMemory((const BYTE*) c_pvBuf)) // DDSÀΰ¡ È®ÀÎ
{
return (CreateDDSTexture(image, (const BYTE*) c_pvBuf));
}
else
{
D3DXIMAGE_INFO imageInfo;
if (FAILED(D3DXCreateTextureFromFileInMemoryEx(
ms_lpd3dDevice,
c_pvBuf,
bufSize,
D3DX_DEFAULT,
D3DX_DEFAULT,
D3DX_DEFAULT,
0,
d3dFmt,
D3DPOOL_MANAGED,
dwFilter,
dwFilter,
0xffff00ff,
&imageInfo,
NULL,
&m_lpd3dTexture)))
{
TraceError("CreateFromMemoryFile: Cannot create texture");
return false;
}
m_width = imageInfo.Width;
m_height = imageInfo.Height;
D3DFORMAT format = imageInfo.Format;
switch (imageInfo.Format)
{
case D3DFMT_A8R8G8B8:
format = D3DFMT_A4R4G4B4;
break;
case D3DFMT_X8R8G8B8:
case D3DFMT_R8G8B8:
format = D3DFMT_A1R5G5B5;
break;
}
}
m_bEmpty = false;
return true;
}Burada downgrade yazılmış
C++:
D3DFORMAT format = imageInfo.Format;
switch (imageInfo.Format)
{
case D3DFMT_A8R8G8B8:
format = D3DFMT_A4R4G4B4;
break;
case D3DFMT_X8R8G8B8:
case D3DFMT_R8G8B8:
format = D3DFMT_A1R5G5B5;
break;
}Ama sorun şu ki format değişkeni hiçbir yerde kullanılmıyor.
Texture burada çoktan oluşturulmuş:
C++:
D3DXCreateTextureFromFileInMemoryEx(..., &m_lpd3dTexture)Yani YMIR'in optimizasyon planı:
- Texture'ı oluştur.
- "Bunu 16-bit'e düşüreyim de RAM kazanalım" diye karar ver.
- Kararı bir değişkende sakla.
- O değişkeni bir daha asla kullanma.
- Return true.
Bugün locale_Ymir kodlarına bakarken farkettim. Server, aslında clientte gözüken Defans değerini kullanmıyor. Oyuncuya göstermeden azaltıyor.
fonksiyonunda böyle bir kod bloğu var:
YMIR branchi doğrudan defansı referans alırken genelde bizim kullandığımız branch başka bir hesap yapıyor.
Ben de basit bir sys_log ekledim test için:
Ve test için oyuns girdiğimde gördüm ki gerçekten de Clientte gözüken değerden daha düşük defans işliyor Server.
Serverdeki log:
DEF=877 SHOW=888 CLIENT=888
Yani 888 gözüken defansı server 877 olarak işliyor. Neden böyle bir şey yapılmış bilemedim. Ben bu mantığı kaldırdım.
C++:
void CHARACTER::ComputeBattlePoints()fonksiyonunda böyle bir kod bloğu var:
C++:
int iShowDef = GetLevel() + GetPoint(POINT_HT); // For Ymir(õ¸¶)
int iDef = GetLevel() + (int)(GetPoint(POINT_HT) / 1.25); // For Other
...
if (LC_IsYMIR())
{
PointChange(POINT_DEF_GRADE, iShowDef + iArmor);
}
else
{
PointChange(POINT_DEF_GRADE, iDef + iArmor);
PointChange(POINT_CLIENT_DEF_GRADE, (iShowDef + iArmor) - GetPoint(POINT_DEF_GRADE));
}YMIR branchi doğrudan defansı referans alırken genelde bizim kullandığımız branch başka bir hesap yapıyor.
Ben de basit bir sys_log ekledim test için:
C++:
sys_log(0, "DEF=%d SHOW=%d CLIENT=%d",
GetPoint(POINT_DEF_GRADE),
iShowDef + iArmor,
GetPoint(POINT_CLIENT_DEF_GRADE));Ve test için oyuns girdiğimde gördüm ki gerçekten de Clientte gözüken değerden daha düşük defans işliyor Server.
Serverdeki log:
DEF=877 SHOW=888 CLIENT=888
Yani 888 gözüken defansı server 877 olarak işliyor. Neden böyle bir şey yapılmış bilemedim. Ben bu mantığı kaldırdım.
Son düzenleme:
Oyuncular farklı bayrak köylere gidince -%10'luk bir hasar dezavantajı alıyormuş. Geçen gün ilk defa tesadüfen gördüm.
C++ Kodu:
if (pAttacker->IsPC())
{
int iEmpire = pAttacker->GetEmpire();
long lMapIndex = pAttacker->GetMapIndex();
int iMapEmpire = SECTREE_MANAGER::instance().GetEmpireFromMapIndex(lMapIndex);
if (iEmpire && iMapEmpire && iEmpire != iMapEmpire)
{
dam = dam * 9 / 10; // Hasarı %10 oranında azaltır (%90'a düşürür)
}
}Bu da YMIR localesinin kodu, sadece kore serverinde aktif
Benim eskiden almış olduğum mainline bir altyapıda aktif. Muhtemelen bence bir çok fileste aktiftir.
Hadi def i POINT_CLIENT_DEF_GRADE ile çekebiliyon Str hiç yok bu yüzden levelli petlerin verdiği def ve str bonusu hep yanlış. Şöyle bir çözüm bulmuştum ;
Çözüldü Konu 'point uyuşmazlığı'
pet sistemi yazdım buff verirken GetPoint kullanarak Def ve Str değerlerini çekiyorum ama "C" ekranında gösterilenle uyuşmuyor ve absürt değerlerde buff veriyor.
şu kodu kullanıyorum;
| 
|
şu kodu kullanıyorum;
C++:
void CNewPet::GiveBuff()
{
if (!m_pkChar || !m_petItem)
return;
// Buff uygulanacak temel değerler
int baseValues[3] =
{
m_pkOwner->GetMaxHP(), // Maksimum HP
m_pkOwner->GetPoint(POINT_DEF_GRADE), // Savunma değeri
m_pkOwner->GetPoint(POINT_ATT_GRADE) // Saldırı...
Bu her sunucuda aktif değiştirmedilerse ben ve çevremdeki bir çok oyuncu bunu biliyor bence çok da saçma bir durum değil gibi geldi bana.
