Metin2 Veritabanları: account, common, player ve log Tabloları

Metin2 sunucusu beş MySQL veritabanı kullanır: account hesapları, common ortak ayarları ve GM listesini, player karakterleri, eşyaları ve proto tablolarını, log oyun içi kayıtları tutar. Beşinci veritabanı hotbackup'tır; db çekirdeği ona bağlanmadan açılmaz ama varsayılan ayarla içine hiçbir şey yazılmaz. Hesapları auth çekirdeği okur, karakter ve eşya verisini db çekirdeği önbellekte tutar ve aralıklarla MySQL'e yazar.

Şemalar sunucu paketinin sql klasöründen gelir. Aşağıdaki tablo ve sütun adları bu şemalara, hangi çekirdeğin neyi okuduğu ise kaynak koda dayanır; tabloları değiştirmemiş sunucularda yapı aynıdır.

Metin2 hangi veritabanlarını kullanır?

Bütün tablolar MyISAM motoru ve latin1 karakter kümesiyle tanımlıdır.

Hangi çekirdek hangi veritabanına bağlanır?

Auth çekirdeğinde PLAYER_SQL satırının account veritabanını göstermesi bilerek yapılır: auth giriş sorgularını bu bağlantıdan account tablosuna yollar. Auth log veritabanına bağlanmaz. db çekirdeği account veritabanını yalnız ülke engeli (iptocountry, block_exception) ve bakiye güncellemesi için kullanır; karakter verisinin hepsi player'dadır. conf.txt ve CONFIG'deki SQL satırlarının sırası farklıdır, ayrıntısı db conf.txt yazısında.

Paketin oluşturduğu mt2 kullanıcısı yalnız localhost'tan bağlanır ve beş veritabanında yalnız SELECT, INSERT, UPDATE ve DELETE yapabilir. Çekirdeklerin günlük işleyişi için bu yetkiler yeterlidir.

account veritabanı

account tablosu

Giriş sırasında kontroller şu sırayla yapılır: parola yanlışsa "Hesap ismi veya şifre yanlış.", availDt ileri bir tarihse "Bu hesap kullanılamıyor.", hesap zaten oyundaysa "Hesabın zaten bağlı.", status OK değilse o değere karşılık gelen ileti. BLOCK için istemci "Bu hesap engellendi." yazar.

Hesap açmak, banlamak ve parola değiştirmek

-- yeni hesap
INSERT INTO account.account (login, password, social_id, status)
VALUES ('hesapadi', CONCAT('*', UPPER(SHA1(UNHEX(SHA1('GucluBirParola'))))), '1234567', 'OK');

-- kalıcı engel
UPDATE account.account SET status = 'BLOCK' WHERE login = 'hesapadi';

-- 3 günlük kapatma
UPDATE account.account SET availDt = DATE_ADD(NOW(), INTERVAL 3 DAY) WHERE login = 'hesapadi';

-- parola değiştirme
UPDATE account.account SET password = CONCAT('*', UPPER(SHA1(UNHEX(SHA1('YeniParola'))))) WHERE login = 'hesapadi';

Parola özeti oyun çekirdeğinde hesaplanır, bu yüzden MySQL'in PASSWORD() fonksiyonunun bulunup bulunmaması fark etmez; yukarıdaki ifade aynı özeti verir. Auth çekirdeği parolanın yalnız ilk 16 karakterini kullanır.

Diğer account tabloları

GameTime, GameTimeIP ve GameTimeLog eski ücretli oyun süresi sistemine aittir. iptocountry ülke bazlı IP engeli için IP aralıklarını, block_exception bu engelden muaf hesapları tutar. string adlı tablo player veritabanında da bulunan anahtar ve metin tablosudur.

common veritabanı

locale tablosundaki LOCALE değeri sunucunun hangi yerel ayarla çalışacağını belirler; turkey yazılıyken çekirdekler locale/turkey klasörünü ve locale_name sütununu kullanır. exp_table ve priv_settings paketin updates klasöründen gelir; priv_settings'te süresi geçmiş satırlar db çekirdeği açılırken silinir. Krallık bonuslarının ve tecrübe oranlarının ayarlanması oranlar ayarı yazısında. GM tablolarının kullanımı GM yapma yazısında.

player veritabanı

Karakter ve hesap verisi

item.window eşyanın nerede olduğunu söyler: INVENTORY, EQUIPMENT, SAFEBOX, MALL, DRAGON_SOUL_INVENTORY, BELT_INVENTORY. Envanterdeki ve üstteki eşyalarda owner_id karakter numarasıdır; depo (SAFEBOX) ve Nesne Market deposu (MALL) eşyalarında ise hesap numarasıdır.

Karakter silinince satır player_deleted tablosuna SELECT * ile kopyalanır. Bu yüzden player'a sütun ekleyen her güncelleme aynı sütunu player_deleted'a da eklemelidir; paketteki kuşak sistemi betiği ikisine de part_acce ekler. Seviyesi conf.txt'deki PLAYER_DELETE_LEVEL_LIMIT (pakette 70) ya da üstünde olan karakter silinemez.

item_award web sitesinden ya da yönetim panelinden eşya göndermek için kullanılır. db çekirdeği taken_time boş olan kayıtları bu kaynakta 5 saniyede bir okur. mall 1 ise eşya Nesne Market deposuna, 0 ise normal depoya, oyuncu depoyu açtığında yerleşir:

INSERT INTO player.item_award (login, vnum, count, given_time, why, mall)
VALUES ('hesapadi', 27001, 200, NOW(), 'etkinlik odulu', 1);  -- 200 adet Kırmızı İksir(K)

Proto ve oyun tabloları

Bu tablolar db çekirdeği açılırken bir kez okunup bütün çekirdeklere gönderilir. Değişiklikten sonra db çekirdeği yeniden başlatılmalıdır; oyunda IMPLEMENTOR yetkisiyle yazılan /reload p eşya, canavar, beceri ve yasaklı kelime tablolarını sunucuyu kapatmadan yeniler. Sütunların ayrıntısı item_proto ve mob_proto yazılarında.

item_proto ve mob_proto MySQL'den mi okunur, dosyadan mı?

Orijinal Metin2 kodunda eşya ve canavar tabloları yalnız db klasöründeki item_proto.txt ve mob_proto.txt dosyalarından okunur. Bu kaynakta ENABLE_PROTO_FROM_DB tanımı açıktır ve seçimi conf.txt'deki iki satır yapar:

Paketteki conf.txt'de PROTO_FROM_DB 0 ve MIRROR2DB 1 yazılıdır. Bu durumda MySQL'deki item_proto yalnız bir yansıdır: orada yapılan değişiklik oyuna geçmez ve db çekirdeği bir sonraki açılışta tabloyu txt'deki değerlerle ezer. Değişiklik txt dosyasında yapılmalı ya da PROTO_FROM_DB 1'e çekilmelidir. Hangi yol seçilirse seçilsin istemcinin kendi proto dosyası ayrıca güncellenmelidir. shop, refine_proto, skill_proto, item_attr gibi diğer tablolar her durumda MySQL'den okunur.

log veritabanı

Log tabloları hızla büyür. Bu kaynakta yazım miktarı CONFIG'deki DB_LOG_LEVEL satırıyla ayarlanır: 0 log veritabanına yazmayı kapatır, varsayılan 3'tür, paketin ortak ayar dosyasında 1 yazılıdır. Paketteki yedekleme betiği log veritabanının yalnız yapısını alır, içindeki kayıtları yedeklemez.

hotbackup veritabanı

db çekirdeği conf.txt'de SQL_HOTBACKUP satırı yoksa açılmaz, ama DISABLE_HOTBACKUP 1 iken bu veritabanına hiçbir şey yazmaz. Yedek açık olsaydı her saat için hb_ önekli yeni bir oyuncu tablosu oluşturulurdu; paketteki mt2 kullanıcısının tablo oluşturma yetkisi olmadığından bu özellik o kullanıcıyla çalışmaz. Boş da olsa veritabanı silinmemelidir.

Sunucu açıkken tabloları düzenlemek neden tehlikeli?

db çekirdeği karakterin player satırını ve eşyalarını MySQL'den bir kez okur, sonra önbellekteki kopya üzerinden çalışır. Değişen oyuncu verisini varsayılan ayarla yaklaşık 7 dakikada, eşyaları 5 dakikada bir MySQL'e yazar. Oyuncu oyundan çıktıktan sonra da önbellek 10 dakika daha tutulur; bu sürede oyuncu tekrar girerse veri MySQL'den değil önbellekten gelir, süre dolunca önbellekteki hali MySQL'e yazılır. quest ve affect satırları ise her girişte MySQL'den okunur, oyuncu oyundayken oyun çekirdeğinin belleğinde durur.

account, common ve log tabloları bu önbelleğe girmez. gmlist değişikliği için oyun çekirdeklerini yeniden başlatmak ya da oyunda /reload a yazmak, proto tablolarında db çekirdeğini yeniden başlatmak yeterlidir.

Şemaları yükleme sırası ve güncelleme dosyaları

Kurulum sırası sql/run.sh dosyasında yazılıdır: veritabanları ve kullanıcı, dört ana şema, updates klasörü (exp_table, priv_settings, chat_log, skill_proto, player güncellemeleri), en son kuşak sistemi tabloları. Adımların açıklaması server kurulumu yazısında.

• updates/player__updates.sql: player_index'e beşinci karakter yuvası (pid5), efsun tablolarına Lycan efsunları ve kostüm sütunları, item.window'a GROUND ekler.
• protos/: MySQL'e aktarılmış resmî protolardaki eksik değerleri (hasar çarpanı, Yang aralığı, binek kapasitesi vb.) düzelten UPDATE dosyaları; yalnız protolar MySQL'den okunacaksa gerekir.
• updates/post/: eski kemer envanteri konumlarını yeni pencereye taşıyan sorgular. Dosyaların kendi notu, ne yaptığını bilmeden çalıştırılmamasını söyler.

Kodda kullanılan ama paketteki şemalarda bulunmayan iki tablo vardır: highscore (questlerde highscore.register ve highscore.show kullanılırsa) ve guild_invite_limit (CONFIG'de GUILD_INVITE_LIMIT: 1 ise). Bu özellikleri açmadan önce tabloların oluşturulması gerekir, aksi halde ilgili sorgular hata verir.