GTAMulti - GTA Türkiye

---

---

• Global Ölçeklenebilirlik: Sunucu altyapısı, bölgesel sunucu kümeleriyle desteklenecek ve oyunculara en yakın noktadan hizmet verecektir.
  
• eNet Tabanlı Bağlantı Sistemi: Düşük gecikmeli, kararlı UDP katmanlı ağ yapısı.
  
• Konsol Sunucu Motoru: Bağımsız .exe dosyası üzerinden çalıştırılan özel geliştirilmiş sunucu sistemi.
  
• JSON API Altyapısı: Tüm oyun içi veri ve eventler dışarıya açılabilir formatta aktarılır.
  
• Tamamen Bağımsız Mimari: Her sunucu kendi lifecycle'ına sahiptir, dış sistemlere ihtiyaç duymaz.
  
• Sunucu Geliştirici Kontrolü: Başlatma parametreleri, loglar, oturum kontrolü geliştiriciye açıktır.
  
• Harita Dinamikleri: Oyuncu pozisyonları, araç etkileşimleri ve zonelere dayalı testler aktif olarak yürütülüyor.
  
  

---

Alıntı

L4MP şu an kapalı geliştirme aşamasındadır. Beta süreci henüz başlamamıştır. Sistem halen çekirdek mimari testleri ve protokol sabitleme süreçlerinden geçmektedir.

Geliştiriciler için sınırlı erişim test sunucuları oluşturulmuştur ancak herkese açık bir istemci sürümü yayınlanmamıştır.

---

---

• Çekirdek protokol kararlılığı ve geniş çaplı ağ testleri
• Serverside modül yapısının tamamlanması ve geliştirici SDK yayınlanması
• Küresel veri merkezi entegrasyonları ve sunucu kümelerinin devreye alınması
• İstemci launcher ve içerik senkronizasyon sisteminin geliştirilmesi
• Web tabanlı yönetim paneli ve oyuncu istatistik modüllerinin hazırlanması
• Beta testleri ve topluluk geri bildirimleri ile sürekli iyileştirme

---

Bu platform, 5 buçuk aydır @Warning ve benim tarafımdan geliştirilmekte olup geliştirilmeye devam etmektedir. Her şey sıfırdan yazılıyor. Yakında birkaç görüntü de paylaşacağız. O zamana kadar, bu projenin ülkemiz adına öne çıkması için destek olursanız seviniriz.

Çok heyecan verici duruyor umarım tutar, başarılar dilerim.  :helal:

güzel duruyor elinize sağlık. çok low-level kısımları olmasa bile çalışacak olan client'i open source yapabilirseniz daha iyi olur. hem community desteği olur hem de güven verir  :serefe:

Alıntı yapılan: Amper - 17 Temmuz 2025, 23:01:54

güzel duruyor elinize sağlık. çok low-level kısımları olmasa bile çalışacak olan client'i open source yapabilirseniz daha iyi olur. hem community desteği olur hem de güven verir  :serefe:

Teşekkürler, düşüncelerini ve geri bildirimini gerçekten önemsiyoruz.

Client tarafını açık kaynak yapmak fikri, geliştirme sürecinin başından beri masamızda olan ve ekip içinde sık sık tartıştığımız bir konu. Güven şeffaflıktan doğar, biz de bu prensiple hareket ediyoruz. Ancak şu anda client yapısı hala temel bazı mimari geçişler ve güvenlik katmanları üzerinde yoğunlaşmış durumda. Bunlar tamamlandığında, belli başlı kısımları - özellikle ağ yönetimi, UI modülü ve event sistemleri gibi kritik olmayan bölgeleri - open source haline getirmek önceliklerimiz arasında.

Bu sayede hem topluluktan doğrudan katkı almayı hem de bizim gözden kaçırabileceğimiz sorunları daha erken fark etmeyi hedefliyoruz. Aynı zamanda, bu adım potansiyel geliştiricilerin de platforma olan güvenini artıracaktır, buna eminiz.

Ama şunu da belirtmeliyim: 

Her şeyi açık kaynak yapmak özellikle anti-cheat, doğrulama mekanizmaları ve sunucu istemci iletişiminde koruma gerektiren bazı modüller için şu an riskli olabilir. Bu yüzden yapacağımız open-source geçiş, modüler ve sınırlı olacak - yani sadece topluluk katkısını güçlendirecek, sistemin güvenliğini riske atmayacak şekilde tasarlanacak.

İlerleyen sürümlerde bu konuda net bir plan ve zaman çizelgesi de yayınlayacağız. Takipte kalman yeterli. Fikrin için tekrardan teşekkürler :serefe:

Güzel gözüküyor, ellerinize sağlık.  :serefe:

eline sağlık cnm

Alıntı yapılan: laéx - 18 Temmuz 2025, 13:39:59

Güzel gözüküyor, ellerinize sağlık.  :serefe:

Alıntı yapılan: DracDonix - 18 Temmuz 2025, 16:21:45

eline sağlık cnm

:kalp:

L4MP, yüzeyde iddialı gözükse de, derinlemesine incelendiğinde teknik yetersizliklerin, yanlış tercihlerin ve eksik vizyonun şöyle iyi bi' yansıması olmuş. ;) "Bağımsız mimari", "sıfırdan yazılmış sistem" gibi terimlerle süslenmiş olsa da gerçekte tekerleği yeniden keşfetmeye benziyor.

eNet kullanmak...  :helal: Başlangıçtan sorgulanması gerekilen bir tercih olmuş. Ağ katmanı olarak eNet kullanmak çağın gerisinde kalmış bir "mühendislik" tercihi olmuş. Temel düzeyde güvenilir UDP sağlar ama modern oyun ağları için gereken connectionless güvenlik, delta-compression, otomatik channel prioritization, NAT traversal ya da latency compensation gibi gelişmiş sistemleri barındırmaz. Barındırmayacak da, SDK'yı ne kadar evirsen de, çevirsen de. R* bile RAGE üzerinden replikasyon ve prediksiyon modeline geçerken, burada hâlâ 2004'ten kalma eNet ile "optimizasyon" yapılmasından söz etmişsin. Neden RakNet değil? Neden Lidgren, ENet++ ya da Quiche gibi daha çağdaş protokoller değil? Çünkü sistem "tam kontrol" bahanesiyle primitif kalmayı seçmiş. Sunucu motorunun ".exe olarak bağımsız çalışması" modern çok oyunculu mimaride övünülecek bir şey değil, aksine teknik borcun açık ilanı değil mi? :maalesef: Docker desteği, orchestration (kubernetes, nomad), hot-reloadable script engine, module sandboxing? Hiçbiri yok. JSON API? Ne harika mk*  :) 2010'ların başına hoş geldiniz. GTA 4 milenyumun başlarında çıktı diye siz de onun patikasını takip edip vulgar sistemler kullanmayı seçmişsiniz herhalde. gRPC ve Protobuf varken hâlâ plaintext üzerinde veri aktarmak ciddi bir mimari hata. Oyun içi event sistemi dış dünyaya "JSON ile açılıyor" diyorsan, latency-sensitive bir uygulamada verimsizliği tercih etmişsin demek. "Her sunucu kendi lifecycle'ına sahiptir" ifadesiyle anlatılmak istenen şey belirsiz. Bağımsız instance yönetiminden mi bahsediliyor, yoksa crash sonrası otomatik recovery mi? Eğer bu kadar övülen lifecycle mantığı basit bir process restart'tan ibaretse, bu yazılımsal bir breakthrough değil, sadece bir while(true) loop'una try-catch eklemek. Gerçek zamanlı ve tutarlı senkronizasyon kelimeleri kulağa hoş gelse de, arkasında bir determinism modeli, entity interpolation/extrapolation sistemi, client-side öngörü algoritmaları veya snapshot delta compression gibi mekanizmalar yapıldı mı? Bahsedilmemiş. Bunlar olmadan senkronizasyon eNet ile lafta olmaz; sadece laglı bir eşleşme deneyimi sunarsın. Modül sistemiyle ilgili tek bilgi "tamamlanacak" olması. Ne tür bir scripting dili desteklenecek? eNet kadar ilkel bir middleware tercih ettiyseniz galebe scripting'i de Turbo Pascal ile yaptıracaksınız. Native API binding desteği de olmaz herhalde. Roadmap sadece vaatten ibaret. Bicameral sistemlerde daha ilk meclisten geçemeyen bill'ler neyse bu da öyle. Mod değil demekle mod olmaktan çıkmıyor yani. Sonuçta GTA 4'ün üzerine inşa edilmiş üçüncü parti bir yazılım. Lisanssız içerik kullanımı, memory patching ya da injection gibi yöntemler içeriyorsa (ki içermeli, yoksa client'i unutun. ha aynı zamanda t2 sizi izlerken de dikkatli olun  :P happinessmp, ivmp, gtac kapılarına koşarsınız) bu teknik olarak hâlâ bir modifikasyondur.

- raknet worshipper 3000, öyle rastgele bi' network specialist, 20 yıldır tersine mühendislikle gta açan tipten

Alıntı yapılan: spirit - 01 Ağustos 2025, 14:19:36

L4MP, yüzeyde iddialı gözükse de, derinlemesine incelendiğinde teknik yetersizliklerin, yanlış tercihlerin ve eksik vizyonun şöyle iyi bi' yansıması olmuş. ;) "Bağımsız mimari", "sıfırdan yazılmış sistem" gibi terimlerle süslenmiş olsa da gerçekte tekerleği yeniden keşfetmeye benziyor.

eNet kullanmak...  :helal: Başlangıçtan sorgulanması gerekilen bir tercih olmuş. Ağ katmanı olarak eNet kullanmak çağın gerisinde kalmış bir "mühendislik" tercihi olmuş. Temel düzeyde güvenilir UDP sağlar ama modern oyun ağları için gereken connectionless güvenlik, delta-compression, otomatik channel prioritization, NAT traversal ya da latency compensation gibi gelişmiş sistemleri barındırmaz. Barındırmayacak da, SDK'yı ne kadar evirsen de, çevirsen de. R* bile RAGE üzerinden replikasyon ve prediksiyon modeline geçerken, burada hâlâ 2004'ten kalma eNet ile "optimizasyon" yapılmasından söz etmişsin. Neden RakNet değil? Neden Lidgren, ENet++ ya da Quiche gibi daha çağdaş protokoller değil? Çünkü sistem "tam kontrol" bahanesiyle primitif kalmayı seçmiş. Sunucu motorunun ".exe olarak bağımsız çalışması" modern çok oyunculu mimaride övünülecek bir şey değil, aksine teknik borcun açık ilanı değil mi? :maalesef: Docker desteği, orchestration (kubernetes, nomad), hot-reloadable script engine, module sandboxing? Hiçbiri yok. JSON API? Ne harika mk*  :) 2010'ların başına hoş geldiniz. GTA 4 milenyumun başlarında çıktı diye siz de onun patikasını takip edip vulgar sistemler kullanmayı seçmişsiniz herhalde. gRPC ve Protobuf varken hâlâ plaintext üzerinde veri aktarmak ciddi bir mimari hata. Oyun içi event sistemi dış dünyaya "JSON ile açılıyor" diyorsan, latency-sensitive bir uygulamada verimsizliği tercih etmişsin demek. "Her sunucu kendi lifecycle'ına sahiptir" ifadesiyle anlatılmak istenen şey belirsiz. Bağımsız instance yönetiminden mi bahsediliyor, yoksa crash sonrası otomatik recovery mi? Eğer bu kadar övülen lifecycle mantığı basit bir process restart'tan ibaretse, bu yazılımsal bir breakthrough değil, sadece bir while(true) loop'una try-catch eklemek. Gerçek zamanlı ve tutarlı senkronizasyon kelimeleri kulağa hoş gelse de, arkasında bir determinism modeli, entity interpolation/extrapolation sistemi, client-side öngörü algoritmaları veya snapshot delta compression gibi mekanizmalar yapıldı mı? Bahsedilmemiş. Bunlar olmadan senkronizasyon eNet ile lafta olmaz; sadece laglı bir eşleşme deneyimi sunarsın. Modül sistemiyle ilgili tek bilgi "tamamlanacak" olması. Ne tür bir scripting dili desteklenecek? eNet kadar ilkel bir middleware tercih ettiyseniz galebe scripting'i de Turbo Pascal ile yaptıracaksınız. Native API binding desteği de olmaz herhalde. Roadmap sadece vaatten ibaret. Bicameral sistemlerde daha ilk meclisten geçemeyen bill'ler neyse bu da öyle. Mod değil demekle mod olmaktan çıkmıyor yani. Sonuçta GTA 4'ün üzerine inşa edilmiş üçüncü parti bir yazılım. Lisanssız içerik kullanımı, memory patching ya da injection gibi yöntemler içeriyorsa (ki içermeli, yoksa client'i unutun. ha aynı zamanda t2 sizi izlerken de dikkatli olun  :P happinessmp, ivmp, gtac kapılarına koşarsınız) bu teknik olarak hâlâ bir modifikasyondur.

- raknet worshipper 3000, öyle rastgele bi' network specialist, 20 yıldır tersine mühendislikle gta açan tipten

(https://pbs.twimg.com/media/E--ix7HXIAQrYNc.jpg)
şu şekil okuduk

@spirit Teknik terimlerle dolu, ukalalıkla süslenmiş ama pratikten tamamen uzak bir metin yazmışsın. RFC ezberleyip, whitepaper okuyarak gerçek dünya sistem mimarileri üzerine hüküm veremezsin.

eNet tercihi çağın gerisinde falan değil. 50+ farklı senaryoda, yüksek paket kaybı ve jitter altında yapılan testlerde en stabil sonucu verdiği için kullanıldı. Raknet ya da Lidgren gibi daha featurerich görünen alternatifler özellikle yoğun trafik altında daha fazla bellek tüketimi ve delay oluşturuyor. Quiche gibi QUIC tabanlı çözümler ise oyun içi delay toleransı için değil, veri güvenliği odaklı. Bunuda öğrenmiş oldun  :helal:  yani teknik gerçeklik senin masa başı teorilerinden biraz daha farklı işliyor.

Json api tercihi debug kolaylığı, erişilebilirlik ve 3rd party sistemlere entegrasyon önceliğiyle yapıldı yani gRPC elbette daha verimli ama bizim önceliğimiz sıkıştırmadan çok geliştirilebilirlik ve erişim kolaylığıydı. Bu arada, Json api dışa açık değil. Kapsülleme içeride. Dış servisler erişemez. Bunuda öğrenmiş oldun.

Lifecycle konusu da process restart değil. Her instance kendi başına decision alabilir, izolasyon yapabilir, başka sunucularla senkronize olabilir. Her sunucu bağımsız çalışır lafı yazılımsal olarak sadece bir while[true] değil, kendi kaynaklarını yöneten izole birimlerdir. Yani microservice değil ama ona yakın mantıkla işliyor.

Bağımsız mimari dediğimiz şey, GTA 4 ün kendi client senkronizasyon sistemini hooklamayıp, sıfırdan UDP tabanlı senkron bir protokol kurmak. Yani mod değil. DLL injection ya da memory patching yöntemleri modifikasyon aracı olabilir ama biz, oyunun orijinal sistemine override yapmıyoruz. Ayrı bir bağlantı katmanı kuruyoruz. Bu da teknik olarak mod değil, harici multiplayer framework.

Son olarak da teoride çok şey yazmak kolay. Ama şu an o sistem çalışıyor. Oyuncu bağlanıyor, araç sürüyor, dünya senkronize oluyor. Yani senin sayfalarca yazdığın şeyi biz çoktan uyguladık. Sadece senin bilgin dışında gelişmiş olması, onun yanlış olduğunu göstermez.

Sen teknik konuşmaya devam et, biz de yazmaya ve test etmeye devam edelim. Sayemde çok şey öğrendin baksan.  :D

Alıntı yapılan: Krips Je - 01 Ağustos 2025, 18:33:52

@spirit Teknik terimlerle dolu, ukalalıkla süslenmiş ama pratikten tamamen uzak bir metin yazmışsın. RFC ezberleyip, whitepaper okuyarak gerçek dünya sistem mimarileri üzerine hüküm veremezsin.

eNet tercihi çağın gerisinde falan değil. 50+ farklı senaryoda, yüksek paket kaybı ve jitter altında yapılan testlerde en stabil sonucu verdiği için kullanıldı. Raknet ya da Lidgren gibi daha featurerich görünen alternatifler özellikle yoğun trafik altında daha fazla bellek tüketimi ve delay oluşturuyor. Quiche gibi QUIC tabanlı çözümler ise oyun içi delay toleransı için değil, veri güvenliği odaklı. Bunuda öğrenmiş oldun  :helal:  yani teknik gerçeklik senin masa başı teorilerinden biraz daha farklı işliyor.

Json api tercihi debug kolaylığı, erişilebilirlik ve 3rd party sistemlere entegrasyon önceliğiyle yapıldı yani gRPC elbette daha verimli ama bizim önceliğimiz sıkıştırmadan çok geliştirilebilirlik ve erişim kolaylığıydı. Bu arada, Json api dışa açık değil. Kapsülleme içeride. Dış servisler erişemez. Bunuda öğrenmiş oldun.

Lifecycle konusu da process restart değil. Her instance kendi başına decision alabilir, izolasyon yapabilir, başka sunucularla senkronize olabilir. Her sunucu bağımsız çalışır lafı yazılımsal olarak sadece bir while[true] değil, kendi kaynaklarını yöneten izole birimlerdir. Yani microservice değil ama ona yakın mantıkla işliyor.

Bağımsız mimari dediğimiz şey, GTA 4 ün kendi client senkronizasyon sistemini hooklamayıp, sıfırdan UDP tabanlı senkron bir protokol kurmak. Yani mod değil. DLL injection ya da memory patching yöntemleri modifikasyon aracı olabilir ama biz, oyunun orijinal sistemine override yapmıyoruz. Ayrı bir bağlantı katmanı kuruyoruz. Bu da teknik olarak mod değil, harici multiplayer framework.

Son olarak da teoride çok şey yazmak kolay. Ama şu an o sistem çalışıyor. Oyuncu bağlanıyor, araç sürüyor, dünya senkronize oluyor. Yani senin sayfalarca yazdığın şeyi biz çoktan uyguladık. Sadece senin bilgin dışında gelişmiş olması, onun yanlış olduğunu göstermez.

Sen teknik konuşmaya devam et, biz de yazmaya ve test etmeye devam edelim. Sayemde çok şey öğrendin baksan.  :D

Yuh!!! :(
Gerçekten, teknik bir mimari eleştirisini "whitepaper ezberlemekle" geçiştirmeye çalışmak, aslında ne kadar savunmasız olduğunun ilk belirtisi değil mi pre-middleware specialist ağabey! Üstünkörü bir benchmark anekdotu atarak eNet tercihini rasyonalize etmek, veriyle değil "kendi yazdım, mecbur savunayım" dürtüsüyle hareket ettiğini açıkça gösteriyor yani, haberin ola. "50+ farklı senaryo", "yüksek jitter", "stabilite", kusura bakma ama bu açıklamalar, modern oyun mühendisliğinde "anlamlı" sayılmaz. Çünkü hangi tür jitter altında ne tür trafik modellerinde hangi parametrelerle test ettiğini belirtmeden söylenen her şey pazarlama kelimesinden öteye geçmez. IVMP'nin R* sunucularını lağvettikten sonra yaptığı zayıf reklam hilelerine benziyor. TCP'de bile "stabilite" diye tabir edilen şey UDP tabanlı oyun protokollerinde "false positive safety" ile cezalandırılır. eNet gibi 20 yıl önce yazılmış bir kütüphane, retransmission politikasında hala stop-and-wait hybrid kullanırken, sen çıkıp 2025'te bunu "en stabil" diye yutturuyorsan, ya konuyu bilmiyorsun ya da işine öyle geliyor. Raknet delay oluşturuyor, Lidgren bellek tüketiyor. Evet, çünkü onlar oyun içi davranışı stabilize etmeye çalışan middle-layer çözümler. Zaten "hafif" olması gereken UDP üzerine yazılan bu sistemlerin, belirli layer'lar eklemesi sistematik bir tradeoff. eNet'in "lightweight" olması bir meziyet değil, çünkü hiçbir şey yapmıyor. Prediction? Yok. Fragmentation compensation? Yok. NAT hole punching? Primitive. Senin tercihinin "light" olması senin çözümünün "iyi" olduğu anlamına gelmiyor. Üzgünüm, lightweight != rightweight. Json API erişilebilirlik için tercih edildi falan demişsin. Allah... :P Buna da artık "aha bir start-up cümlesi daha" diyeceğim. JSON'un debug kolaylığı diye savunduğun şey, latency-sensitive bir real-time sistemde CPU-bound dönüşüm overhead'i yaratıyor. Yani senin geliştiriciye "kolaylık" diye sunduğun şey, oyuncuya "gecikme" olarak dönüyor. Geliştirilebilirlik falan diyorsun ama ortada geliştirilebilecek bir event registry bile yok. O "kapsülleme içeride" cümlesi de komik, çünkü sen dış dünyaya "JSON API" tanımı yaptıysan, ister istemez dış sistem uyumluluğu, schema güvenliği, contract binding gibi dertlerin var. Şu an "değil" diyorsun, ama günün sonunda o API dışa açılacak. Aksi halde "API" değil, sadece lokal bir dispatchEvent() handler'ı olur. Lifecycle process restart değil, izole birimler.. Evet, e madem öyle sandboxing mi var (ikinciye sordum he, değerimi bil. tekrar cevaplamazsan var diyim)? Resource cgroup izolasyonu mu yapıyorsun? Yoksa senin "izolasyon" dediğin şey port range'leri ayırıp "her biri kendi portunda çalışıyor abi ya" demek mi? Stateless bir yapıda instance başlatmak "izolasyon" değil, "bağımsız çalıştırma". Mesela process crash sonrası persist edilen bir state var mı? Konsistent shared state replication? Var mı consensus algorithm ile senkronizasyon (Raft, Paxos)? Yoksa "birbirinden haber alıyorlar" mı? Kusura bakma ama bu tam olarak distributed sistem sandığını centralized config propagation yapmaktan ibaret. Override yapmıyoz, framework falan filan. Evet, Orange:MP hatta, değil mi? Şimdi işin en komik kısmına geldik. Hooklamadığın sistemde senkronizasyon kuruyorsan, bu doğrudan memory layer dışından replicate etmeye çalışma anlamına gelir. Yani senin client, oyunun kendi tick sistemine paralel bir layer yaratıyor. Ve bu layer native clock cycle ile uyumlu değilse, her zaman ghost input, unsynced entity ve visual de-sync üretir. Eğer "mod değil" diyorsan, oyunun kendi koduna erişmiyorsan, asla tam bir eşleşme sağlayamazsın. Ve "tam bir eşleşme" olmadan da bu, real-time multiplayer framework değil; sadece gecikmeli bir kontrol proxy'sidir.

Son olarak,

> Sen teknik konuş, biz çalıştırıyoruz.

Evet. Ama işte mesele de burada başlıyor. Çalıştırmak kolay, çalıştırdığın şeyi doğru yapmak mesele. Rust'la yazsan ne olur, eNet'i gömüp stabil desen ne olur? Mimaride temel problemler varsa, sistem değil tabela inşa ediyorsun. Ve evet, çalışıyor olabilir. Ama nerenin standardına göre çalışıyor? 2006'daki SA-MP kafasına göre mi, yoksa 2025'in ECS, deterministic rollback ve delta state compression çağına göre mi? Senin yaptığın şey, bir çölde yürüyüp ısıya alışınca "burası yaşam alanı" demek gibi. Oysa çölde yaşanmaz, sadece hayatta kalınır. Mühendislik de "ayağa kalktı" diye bitmez. Doğru ayağa kalktı mı, asıl soru bu. Ha tamam ya, boşversene; her şeyi yaptın, Meta'dan RakNet'in NCIP+ versiyonunu falan aldın, ara yazılım derdi falan, hiçbir şey yok. Yağ gibi akıp gidiyor, MTA:SA Blue'nun en stabil versiyonun da daha iyi. RevIVal dedikleri toplulukta bile 100 kişi anca yılda bir toplanıp GTA IV minigame'i oynuyor. Sen bu client'i kime sunuyorsun? Üç hafta sonra kaybolacak altmış oyuncuya mı? Yol yakınken vazgeç, çok istiyorsan böyle laga luga client işlerini RAGE için GTA VI projesinde project process manager ol. Cfx.Re ile rekabet edersiniz, en azından orada altmış değil de yüz binlerce oyuncu olacak, milyonlar hatta.

"sayemde çok şey öğrendin baksan"
evet ya, özellikle UDP'yi JSON'la sarınca hızlanıyor sanmak kısmı çok ufuk açıcıydı. 2004'te yazılmış bir kütüphaneyi 2025 mimarisine "bilerek" seçmek gibi ileri görüşlülüğü de ancak senin gibi birinden öğrenebilirdim. RFC değil, Reddit yorumu ezberleyenler için teknik rehberlik sağladığın için gerçekten minnettarım. Bir dahaki derste belki try-catch'in Kubernetes alternatifi olduğunu da öğreniriz senden -- sonuçta "çalışıyor" değil mi? :*


- yalnızca RFC ezberlemeyen, latency'nin ne zaman latency olduğunu bilen biri

zamanla.. benim fikirlerime hak vereceksiniz..

Alıntı yapılan: Krips Je - 01 Ağustos 2025, 18:33:52

Sayemde çok şey öğrendin baksan.

Visual Basic'de combobox koymayı da öğretir misin? Launcher yapıyorum da.

Bir de şey, LinkedIn hesabına neden erişemiyorum? Bağlantın olmak isterdim, belki endorse bile ederdim profilini. Lütfen profilini açar mısın?

Spirit sanırım gerekli cevabı vermiş  :serefe:

Alıntı yapılan: favdrizz - 01 Ağustos 2025, 19:09:49

Spirit sanırım gerekli cevabı vermiş  :serefe:

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Alıntı yapılan: spirit - 01 Ağustos 2025, 19:12:25

Alıntı yapılan: favdrizz - 01 Ağustos 2025, 19:09:49

Spirit sanırım gerekli cevabı vermiş  :serefe:

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

Alıntı yapılan: deksdeveloper - 01 Ağustos 2025, 19:26:59

Alıntı yapılan: spirit - 01 Ağustos 2025, 19:12:25

Alıntı yapılan: favdrizz - 01 Ağustos 2025, 19:09:49

Spirit sanırım gerekli cevabı vermiş  :serefe:

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

Niye buraya özel olsun, mühendislik terimleriyle GTAMulti ahalisine hava mı atayım... İş.. eskiden bu sektördeydim. Şimdi de bir butik kafe açsam iyi olur aslında

Alıntı yapılan: spirit - 01 Ağustos 2025, 19:32:05

Alıntı yapılan: deksdeveloper - 01 Ağustos 2025, 19:26:59

Alıntı yapılan: spirit - 01 Ağustos 2025, 19:12:25

Alıntı yapılan: favdrizz - 01 Ağustos 2025, 19:09:49

Spirit sanırım gerekli cevabı vermiş  :serefe:

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

Niye buraya özel olsun, mühendislik terimleriyle GTAMulti ahalisine hava mı atayım... İş.. eskiden bu sektördeydim. Şimdi de bir butik kafe açsam iyi olur aslında

kafe sarar da butik sıktı

Alıntı yapılan: xeoNNN - 01 Ağustos 2025, 21:30:44

Alıntı yapılan: spirit - 01 Ağustos 2025, 19:32:05

Alıntı yapılan: deksdeveloper - 01 Ağustos 2025, 19:26:59

Alıntı yapılan: spirit - 01 Ağustos 2025, 19:12:25

Alıntı yapılan: favdrizz - 01 Ağustos 2025, 19:09:49

Spirit sanırım gerekli cevabı vermiş  :serefe:

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

Niye buraya özel olsun, mühendislik terimleriyle GTAMulti ahalisine hava mı atayım... İş.. eskiden bu sektördeydim. Şimdi de bir butik kafe açsam iyi olur aslında

kafe sarar da butik sıktı

Hayırlısı..

bence iki tarafın da haklı olduğu yerler var, baştan okudum şakasız. ancak @Krips Je, burada söylediğin şeylerin değerli olabilmesi için net metrikler paylaşman gerekiyor bence. bu alanda daha bilgili biri metrikleri daha iyi söyleyecektir ama loss değerlerini görmek isterim en azından, ortalama bir sunucuda olacak oyuncu sayısıyla. (ve realistik ortalama bir sunucunun içerebileceği trafiği yaratmalı içinde çalışan oyun modu)

ben network uzmanı değilim ama sadece teknik terimleri arka arkaya dizip birbirinizi ezmeye çalıştığınız bir tartışma ortamı çok mantıklı değil ve şahsen ben bu konuyu ilk okuduğumda oyuncu sayısının 50'yi geçeceğini pek düşünmemiştim. "çok modern teknolojiler kullanılacak bir proje" diye düşünmemiştim. gerçekten scale ettiniz mi kendi kafanızda projeyi? aktif trafiği sıradan bir web uygulamasına göre bile düşük kalır gibi geliyor bana.

ayrıca modding konusuyla ilgili ifşalama hoş olmamış. şeytan şirketin politikasını desteklemeyin yahu :D

Alıntı yapılan: spirit - 01 Ağustos 2025, 18:59:50

Alıntı yapılan: Krips Je - 01 Ağustos 2025, 18:33:52

@spirit Teknik terimlerle dolu, ukalalıkla süslenmiş ama pratikten tamamen uzak bir metin yazmışsın. RFC ezberleyip, whitepaper okuyarak gerçek dünya sistem mimarileri üzerine hüküm veremezsin.

eNet tercihi çağın gerisinde falan değil. 50+ farklı senaryoda, yüksek paket kaybı ve jitter altında yapılan testlerde en stabil sonucu verdiği için kullanıldı. Raknet ya da Lidgren gibi daha featurerich görünen alternatifler özellikle yoğun trafik altında daha fazla bellek tüketimi ve delay oluşturuyor. Quiche gibi QUIC tabanlı çözümler ise oyun içi delay toleransı için değil, veri güvenliği odaklı. Bunuda öğrenmiş oldun  :helal:  yani teknik gerçeklik senin masa başı teorilerinden biraz daha farklı işliyor.

Json api tercihi debug kolaylığı, erişilebilirlik ve 3rd party sistemlere entegrasyon önceliğiyle yapıldı yani gRPC elbette daha verimli ama bizim önceliğimiz sıkıştırmadan çok geliştirilebilirlik ve erişim kolaylığıydı. Bu arada, Json api dışa açık değil. Kapsülleme içeride. Dış servisler erişemez. Bunuda öğrenmiş oldun.

Lifecycle konusu da process restart değil. Her instance kendi başına decision alabilir, izolasyon yapabilir, başka sunucularla senkronize olabilir. Her sunucu bağımsız çalışır lafı yazılımsal olarak sadece bir while[true] değil, kendi kaynaklarını yöneten izole birimlerdir. Yani microservice değil ama ona yakın mantıkla işliyor.

Bağımsız mimari dediğimiz şey, GTA 4 ün kendi client senkronizasyon sistemini hooklamayıp, sıfırdan UDP tabanlı senkron bir protokol kurmak. Yani mod değil. DLL injection ya da memory patching yöntemleri modifikasyon aracı olabilir ama biz, oyunun orijinal sistemine override yapmıyoruz. Ayrı bir bağlantı katmanı kuruyoruz. Bu da teknik olarak mod değil, harici multiplayer framework.

Son olarak da teoride çok şey yazmak kolay. Ama şu an o sistem çalışıyor. Oyuncu bağlanıyor, araç sürüyor, dünya senkronize oluyor. Yani senin sayfalarca yazdığın şeyi biz çoktan uyguladık. Sadece senin bilgin dışında gelişmiş olması, onun yanlış olduğunu göstermez.

Sen teknik konuşmaya devam et, biz de yazmaya ve test etmeye devam edelim. Sayemde çok şey öğrendin baksan.  :D

Yuh!!! :(
Gerçekten, teknik bir mimari eleştirisini "whitepaper ezberlemekle" geçiştirmeye çalışmak, aslında ne kadar savunmasız olduğunun ilk belirtisi değil mi pre-middleware specialist ağabey! Üstünkörü bir benchmark anekdotu atarak eNet tercihini rasyonalize etmek, veriyle değil "kendi yazdım, mecbur savunayım" dürtüsüyle hareket ettiğini açıkça gösteriyor yani, haberin ola. "50+ farklı senaryo", "yüksek jitter", "stabilite", kusura bakma ama bu açıklamalar, modern oyun mühendisliğinde "anlamlı" sayılmaz. Çünkü hangi tür jitter altında ne tür trafik modellerinde hangi parametrelerle test ettiğini belirtmeden söylenen her şey pazarlama kelimesinden öteye geçmez. IVMP'nin R* sunucularını lağvettikten sonra yaptığı zayıf reklam hilelerine benziyor. TCP'de bile "stabilite" diye tabir edilen şey UDP tabanlı oyun protokollerinde "false positive safety" ile cezalandırılır. eNet gibi 20 yıl önce yazılmış bir kütüphane, retransmission politikasında hala stop-and-wait hybrid kullanırken, sen çıkıp 2025'te bunu "en stabil" diye yutturuyorsan, ya konuyu bilmiyorsun ya da işine öyle geliyor. Raknet delay oluşturuyor, Lidgren bellek tüketiyor. Evet, çünkü onlar oyun içi davranışı stabilize etmeye çalışan middle-layer çözümler. Zaten "hafif" olması gereken UDP üzerine yazılan bu sistemlerin, belirli layer'lar eklemesi sistematik bir tradeoff. eNet'in "lightweight" olması bir meziyet değil, çünkü hiçbir şey yapmıyor. Prediction? Yok. Fragmentation compensation? Yok. NAT hole punching? Primitive. Senin tercihinin "light" olması senin çözümünün "iyi" olduğu anlamına gelmiyor. Üzgünüm, lightweight != rightweight. Json API erişilebilirlik için tercih edildi falan demişsin. Allah... :P Buna da artık "aha bir start-up cümlesi daha" diyeceğim. JSON'un debug kolaylığı diye savunduğun şey, latency-sensitive bir real-time sistemde CPU-bound dönüşüm overhead'i yaratıyor. Yani senin geliştiriciye "kolaylık" diye sunduğun şey, oyuncuya "gecikme" olarak dönüyor. Geliştirilebilirlik falan diyorsun ama ortada geliştirilebilecek bir event registry bile yok. O "kapsülleme içeride" cümlesi de komik, çünkü sen dış dünyaya "JSON API" tanımı yaptıysan, ister istemez dış sistem uyumluluğu, schema güvenliği, contract binding gibi dertlerin var. Şu an "değil" diyorsun, ama günün sonunda o API dışa açılacak. Aksi halde "API" değil, sadece lokal bir dispatchEvent() handler'ı olur. Lifecycle process restart değil, izole birimler.. Evet, e madem öyle sandboxing mi var (ikinciye sordum he, değerimi bil. tekrar cevaplamazsan var diyim)? Resource cgroup izolasyonu mu yapıyorsun? Yoksa senin "izolasyon" dediğin şey port range'leri ayırıp "her biri kendi portunda çalışıyor abi ya" demek mi? Stateless bir yapıda instance başlatmak "izolasyon" değil, "bağımsız çalıştırma". Mesela process crash sonrası persist edilen bir state var mı? Konsistent shared state replication? Var mı consensus algorithm ile senkronizasyon (Raft, Paxos)? Yoksa "birbirinden haber alıyorlar" mı? Kusura bakma ama bu tam olarak distributed sistem sandığını centralized config propagation yapmaktan ibaret. Override yapmıyoz, framework falan filan. Evet, Orange:MP hatta, değil mi? Şimdi işin en komik kısmına geldik. Hooklamadığın sistemde senkronizasyon kuruyorsan, bu doğrudan memory layer dışından replicate etmeye çalışma anlamına gelir. Yani senin client, oyunun kendi tick sistemine paralel bir layer yaratıyor. Ve bu layer native clock cycle ile uyumlu değilse, her zaman ghost input, unsynced entity ve visual de-sync üretir. Eğer "mod değil" diyorsan, oyunun kendi koduna erişmiyorsan, asla tam bir eşleşme sağlayamazsın. Ve "tam bir eşleşme" olmadan da bu, real-time multiplayer framework değil; sadece gecikmeli bir kontrol proxy'sidir.

Son olarak,

> Sen teknik konuş, biz çalıştırıyoruz.

Evet. Ama işte mesele de burada başlıyor. Çalıştırmak kolay, çalıştırdığın şeyi doğru yapmak mesele. Rust'la yazsan ne olur, eNet'i gömüp stabil desen ne olur? Mimaride temel problemler varsa, sistem değil tabela inşa ediyorsun. Ve evet, çalışıyor olabilir. Ama nerenin standardına göre çalışıyor? 2006'daki SA-MP kafasına göre mi, yoksa 2025'in ECS, deterministic rollback ve delta state compression çağına göre mi? Senin yaptığın şey, bir çölde yürüyüp ısıya alışınca "burası yaşam alanı" demek gibi. Oysa çölde yaşanmaz, sadece hayatta kalınır. Mühendislik de "ayağa kalktı" diye bitmez. Doğru ayağa kalktı mı, asıl soru bu. Ha tamam ya, boşversene; her şeyi yaptın, Meta'dan RakNet'in NCIP+ versiyonunu falan aldın, ara yazılım derdi falan, hiçbir şey yok. Yağ gibi akıp gidiyor, MTA:SA Blue'nun en stabil versiyonun da daha iyi. RevIVal dedikleri toplulukta bile 100 kişi anca yılda bir toplanıp GTA IV minigame'i oynuyor. Sen bu client'i kime sunuyorsun? Üç hafta sonra kaybolacak altmış oyuncuya mı? Yol yakınken vazgeç, çok istiyorsan böyle laga luga client işlerini RAGE için GTA VI projesinde project process manager ol. Cfx.Re ile rekabet edersiniz, en azından orada altmış değil de yüz binlerce oyuncu olacak, milyonlar hatta.

"sayemde çok şey öğrendin baksan"
evet ya, özellikle UDP'yi JSON'la sarınca hızlanıyor sanmak kısmı çok ufuk açıcıydı. 2004'te yazılmış bir kütüphaneyi 2025 mimarisine "bilerek" seçmek gibi ileri görüşlülüğü de ancak senin gibi birinden öğrenebilirdim. RFC değil, Reddit yorumu ezberleyenler için teknik rehberlik sağladığın için gerçekten minnettarım. Bir dahaki derste belki try-catch'in Kubernetes alternatifi olduğunu da öğreniriz senden -- sonuçta "çalışıyor" değil mi? :*


- yalnızca RFC ezberlemeyen, latency'nin ne zaman latency olduğunu bilen biri

Yazdıklarını detaylıca inceledim. Teknik seviyen belli ve konuya yüzeysel yaklaşmadığın ortada. Bazı eleştirilerin yerinde, bazı tespitlerin eksik ya da bağlam dışı, bazıları ise hala geliştirme sürecinde olduğumuz kısımlarla çakışıyor. Ben de burada sistemin temellerini inşa eden kişi olarak, tercih ettiğimiz yaklaşımları doğrudan anlatayım istedim.

eNet meselesiyle başlayalım. "2004'ten kalma bir teknoloji" demek kolay ama her teknoloji yaşıyla değil, kullanıldığı bağlamla değerlendirilir. eNet bizim nihai ağ çözümümüz değil, yalnızca UDP üstü düşük seviyeli bir transport layer olarak yer alıyor. Üzerine inşa ettiğimiz scheduler, internal paket düzeni, veri öncelikleme sistemi ve latency-aware dispatch katmanı doğrudan bizim tarafımızdan yazıldı. Yani eNet bizim mimaride yalnızca en alt kabuk geri kalan kısımlar eNeti çoktan aşmış durumda :) bu yüzden daha ağır çözümler olan RakNet ya da Lidgren gibi sistemler yerine, daha hafif ama kontrol edilebilir bir yapı tercih edildi. Kendi çözümünü yazmak tekerleği yeniden icat etmek değil; neyi neden değiştirdiğini bilerek, elindeki altyapıyı yeniden şekillendirmektir.

"Bağımsız .exe çalıştırmak" meselesi için "teknik borç" tanımı fazla iddialı. Asıl amaç merkezi değil, yatayda ölçeklenebilir bir instance yönetimi kurmaktı. Evet, şu anda container tabanlı dağıtım Docker, Nomad, vb vb.. için doğrudan bir destek sunulmuyor ancak sistemin modüler mimarisi bu geçişi mümkün kılacak şekilde yapılandırıldı. Hatta modül motorunun iç yapısı da buna göre yeniden yazılıyor. Hot-reload, script izolasyonu, sandboxing gibi unsurlar şu anda aktif geliştirme başlıkları. Yani sistem olduğu yerde kalmayacak. Şu anki formu, temel sistemin stabilitesini ispatlamak için.

JSON API üzerinden vurmuşsun, doğal olarak. Haklı olduğun yer var. Performans kritik bir sistemde plaintext format ideal değil. Ancak JSON bu aşamada developer-facing bir çözüm olarak burada. CLI, dashboard ve webhook sistemleri için hızlıca adapte edilebilir ve okunabilir olması önceliklendirildi. Sistem içerisindeki ağ iletişimi ise JSON değil orası zaten binary layera taşınmış durumda. Yani dış API JSON, iç katman binary. Bu fark kritik. :)

"Her sunucunun kendi lifecycle ı vardır" cümlesiyle anlatmak istediğimiz şey, instance ların merkezi bir dependencye bağlı olmadan kendi yaşam döngülerini yöneten yapılar olması. Bu sadece try-catch değil, aynı zamanda kendi configi, event busı, local modül kontrolü ve mesaj kuyruğu olan micro-node mantığı. Crash sonrası kendi kendini ayağa kaldırma, log toplanması, modül yeniden çağırımı gibi mekanizmalar zaten var. Henüz orkestrasyon ortamlarına entegre edilmedi, ama kod seviyesi buna uygun inşa edildi.

Senin öne sürdüğün delta-compression, prediction modeli, latency hiding gibi advanced networking konularına gelirsek: Bunlar teoride çok şey vaat eder ama sahada büyük maliyet üretir. Bizim sistemde bunların bazılarına dair denemeler yapılmış durumda örnek;

entity snapshot,
tick history,
visual smoothing

gibi gibi alanlarda belirli çözümler var. Ancak bunlar hala test aşamasında ve productiona girmiş değil. Amacımız, bu tür optimizasyonları sadece şık görünmek için değil, gerçekten etkili olduklarında entegre etmek. Yani buradaki tercihimiz az ama sağlam.

Modül sistemiyle ilgili soru açık Lua mı, JS mi, yoksa C API binding mi? Şu an için gömülü bir script engine test ediliyor henüz final değil. Planlanan şey, dıştan yüklenebilir plugin mimarisi. Yani DLL seviyesinde API binding de dahil. Ancak bu da parça parça açılacak çünkü sandbox güvenliği ve kaynak izolasyonu gibi başlıklar daha öncelikli.

Son olarak mod olup olmadığımız meselesi. Teknik olarak, oyun içeriğiyle memory-level etkileşime girdiğiniz her yapı bir tür modifikasyon sayılır doğru. Ancak bizim yaklaşımımız, biz oyunun mantığına değil, çevresine etki ediyoruz. Client tarafında injection ya da memory patching gibi alanlara giriyoruz, evet, ama bu müdahaleler engine mantığını değil, client-server iletişimini hedefliyor. Yani biz kendimizi bir mod platformu değil, bir bağımsız multiplayer sistemi olarak tanımlıyoruz. Hukuki anlamda tabii ki gri alandayız bu işin doğasında var.

Eleştirilerinin altında ciddi bir birikim olduğunu inkar etmiyorum. Teknik olarak kafa yormuşsun. Bazı noktaları abartılı bulsam da, çoğunun ardında anlamlı bir perspektif var. Yazdığın şeyler doğrudan dikkate alındı, bazıları iç toplantılarda da gündem oldu zaten.

Ama şunu da eklemem gerekir ki, biz bu projeyi her şeyi baştan yazmak için değil eksik olanı tamamlamak için inşa ediyoruz. Her şey kusursuz değil. Ama her tercih bilinçli. :)

Alıntı yapılan: Amper - 02 Ağustos 2025, 20:45:56

bence iki tarafın da haklı olduğu yerler var, baştan okudum şakasız. ancak @Krips Je, burada söylediğin şeylerin değerli olabilmesi için net metrikler paylaşman gerekiyor bence. bu alanda daha bilgili biri metrikleri daha iyi söyleyecektir ama loss değerlerini görmek isterim en azından, ortalama bir sunucuda olacak oyuncu sayısıyla. (ve realistik ortalama bir sunucunun içerebileceği trafiği yaratmalı içinde çalışan oyun modu)

ben network uzmanı değilim ama sadece teknik terimleri arka arkaya dizip birbirinizi ezmeye çalıştığınız bir tartışma ortamı çok mantıklı değil ve şahsen ben bu konuyu ilk okuduğumda oyuncu sayısının 50'yi geçeceğini pek düşünmemiştim. "çok modern teknolojiler kullanılacak bir proje" diye düşünmemiştim. gerçekten scale ettiniz mi kendi kafanızda projeyi? aktif trafiği sıradan bir web uygulamasına göre bile düşük kalır gibi geliyor bana.

ayrıca modding konusuyla ilgili ifşalama hoş olmamış. şeytan şirketin politikasını desteklemeyin yahu :D

Selam, mesajını okudum dostum. içtenlikle yazdığın belli, o yüzden aynı samimiyetle cevap vereyim istedim.

Öncelikle haklısın, bu tür konular sadece teknik terimleri art arda dizerek değil, bağlam ve kullanım senaryolarıyla birlikte konuşulmalı. Burada anlatılmak istenen şeyin özünü, yani aktif trafik içinde oyun içi senaryoları çalıştırabilecek gerçekçi bir sistem kurmak fikrini doğru yakalamışsın.

Oyuncu sayısı konusuna gelince evet, başlangıçta ortalama sunucu hedefiyle ilerliyoruz. Bu, bizim için 40-60 eş zamanlı oyuncu civarında bir yük anlamına geliyor. Elbette 50 yi geçecek mi? sorusu ciddi çünkü bu tarz sistemlerde eş zamanlılık arttıkça yalnızca ağ değil, script motoru, veri senkronizasyonu, entity yönetimi gibi sistemler de logaritmik şekilde zorlanıyor. Bizim amacımız da zaten bu sınırı hem teknik olarak hem de geliştirici dostu biçimde yukarı taşımak.

Gerçekten scale ettiniz mi? sorusuna gelirsek. Şu an için dikey ölçekleme yani tek makinada çekirdek kullanımına dayalı + modül izolasyonlu tasarımımız var. Yani her modül kendi lifecycleı ile çalışıyor. Bazıları multi-threaded, bazıları thread-safe tasarlandı. Şimdi sırada yatayda bölünebilir, hatta farklı fiziksel sunuculara dağıtılabilir modül kümeleri üzerine testler var. Kısacası ölçeklenebilirlik bizim roadmapimizin tam ortasında.

Modern teknolojiler kullanılacak bir proje gibi düşünmemiştim demen de anlaşılır çünkü biz görselde, dış katmanda, ön yüzde bling-bling şeyler sunmuyoruz. Ama alt katmanda işler değişiyor mesela low-level UDP optimizasyonları, aktör tabanlı concurrency, modüler runtime engine, plugin bridge katmanı, hepsi halihazırda yürürlükte ya da geliştirme aşamasında. Hedef, sadece göze değil, geliştiricinin beynine hitap eden bir şey inşa etmekti.

Modding konusundaki fikrine de katılıyorum. Bu işin politik tarafları her zaman gri kalıyor çünkü bizim hedefimiz şirket politikasına değil, geliştirici özgürlüğüne destek olmak. Ne bir oyunun içine sızmaya çalışıyoruz, ne de resmi olmayan açıkları zorlayarak var olmaya. Biz sadece o oyunun eksik bıraktığı alanı, saygı çerçevesinde tamamlıyoruz diyebilirim.

Yorumun için gerçekten teşekkür ederim. Eleştiri değil, katkı gibi geldi. Böyle yazıldığında her kelime gerçekten değerli oluyor. :kalp:

En sevdiğim GTA oyunuyla alakalı bu proje umarım başarılı olur, bu arada iki kullanıcının teknik bilgilerine hayran kaldım :D eleştirel ve konuya hakim yorumlara ve eleştiriyi kaldırabilen insanlara saygım sonsuz, yolunuz açık olsun umarım istediğiniz yerlere ulaşır proje.

Farklı şeyler görmek güzel, başarılar.

Alıntı yapılan: Impeccable - 03 Ağustos 2025, 01:32:25

En sevdiğim GTA oyunuyla alakalı bu proje umarım başarılı olur, bu arada iki kullanıcının teknik bilgilerine hayran kaldım :D eleştirel ve konuya hakim yorumlara ve eleştiriyi kaldırabilen insanlara saygım sonsuz, yolunuz açık olsun umarım istediğiniz yerlere ulaşır proje.

Alıntı yapılan: Krozfayer - 03 Ağustos 2025, 03:02:03

Farklı şeyler görmek güzel, başarılar.

:kalp:

ne anlatıyonuz olm gptye özet geç dedim o bile bişey anlamadı

basarilar btw

eNet kullanmak tabii ki de günümüzde eski bir teknoloji sayılsa da, düşük seviyeli projelerde hâlâ kullanılıyor. Tabii ki de kapsamlı bir proje yapılacaksa, eNet teknolojisi artık eskimiş sayılır. Güvenliğine kadar her şeyi geliştiricilerin yapması gerekiyor ve bu da uzun ve uğraştırıcı bir iştir.

Mantıklı mı?
Eğer ağ programlama yeteneğine güveniyorsan, evet, altyapı kurmak teknik olarak mümkün ve performanslıdır. Ancak eNet ile bir server-side geliştirmek, hazır altyapı kullanmadan ya da geniş bir network ekibin yoksa uğraştırıcı ve uzun zaman alacaktır.

Şunu unutmamak lazım: UDP tabanlı projeler her zaman düşük gecikme ve daha hızlı paket alışverişi sağlar.
Dezavantajları da mevcut tabii ki; UDP'nin doğası gereği güvensiz olması, günümüzdeki modern network yapıları gereği güvenliğin en az performans kadar önemli olmasını beraberinde getiriyor.

eNet, WebSocket ve QUIC gibi modern protokolleri, eski olması sebebiyle sağlayamıyor. Ayrıca Wi-Fi gibi bağlantılarda eNet'in hata toleransı zayıftır. Günümüzde, güvenlik ve performans amacıyla daha güncel ve verimli networking kütüphanelerine yönelmek daha mantıklı olacaktır.

Umarım bizi yanıltırsınız, başarılarınızın devamını diliyorum.

Not: Bu yorumda tamamen kendi düşüncelerimi belirttim network öğrencisi olarak. Herhangi bir şekilde projeyi baltalamak gibi bir niyetim bulunmamaktadır, aksine desteklerimi iletiyorum.

Sırf bu sebeple bile Gta 4'ü tekrar indirebilirim.. (:

Alıntı yapılan: laéx - 04 Ağustos 2025, 02:29:45

eNet kullanmak tabii ki de günümüzde eski bir teknoloji sayılsa da, düşük seviyeli projelerde hâlâ kullanılıyor. Tabii ki de kapsamlı bir proje yapılacaksa, eNet teknolojisi artık eskimiş sayılır. Güvenliğine kadar her şeyi geliştiricilerin yapması gerekiyor ve bu da uzun ve uğraştırıcı bir iştir.

Mantıklı mı?
Eğer ağ programlama yeteneğine güveniyorsan, evet, altyapı kurmak teknik olarak mümkün ve performanslıdır. Ancak eNet ile bir server-side geliştirmek, hazır altyapı kullanmadan ya da geniş bir network ekibin yoksa uğraştırıcı ve uzun zaman alacaktır.

Şunu unutmamak lazım: UDP tabanlı projeler her zaman düşük gecikme ve daha hızlı paket alışverişi sağlar.
Dezavantajları da mevcut tabii ki; UDP'nin doğası gereği güvensiz olması, günümüzdeki modern network yapıları gereği güvenliğin en az performans kadar önemli olmasını beraberinde getiriyor.

eNet, WebSocket ve QUIC gibi modern protokolleri, eski olması sebebiyle sağlayamıyor. Ayrıca Wi-Fi gibi bağlantılarda eNet'in hata toleransı zayıftır. Günümüzde, güvenlik ve performans amacıyla daha güncel ve verimli networking kütüphanelerine yönelmek daha mantıklı olacaktır.

Umarım bizi yanıltırsınız, başarılarınızın devamını diliyorum.

Not: Bu yorumda tamamen kendi düşüncelerimi belirttim network öğrencisi olarak. Herhangi bir şekilde projeyi baltalamak gibi bir niyetim bulunmamaktadır, aksine desteklerimi iletiyorum.

Alıntı yapılan: M A T I Z - 04 Ağustos 2025, 16:11:05

Sırf bu sebeple bile Gta 4'ü tekrar indirebilirim.. (:

:kalp:

Başarılar Krips. Farklı projeleri her zaman desteklerim.

Başarılar dilerim eğer ki tanıdığım Warning bu projede ise katkı kesinlikle sağlamıştır.

Alıntı yapılan: Furkanulas - 05 Ağustos 2025, 20:08:44

Başarılar dilerim eğer ki tanıdığım Warning bu projede ise katkı kesinlikle sağlamıştır.

Değerli yorumun için teşekkür ederim evet tanıdıgın warning  :)

--