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.
