Un quest care merge când îl faci frumos, de la cap la coadă, nu e încă un quest gata. Jucătorii ies din joc în mijlocul dialogului, schimbă canalul, au inventarul plin, apasă de cinci ori pe același buton. Iar serverul se mai repornește, uneori chiar fără să vrei. Majoritatea problemelor cu progres pierdut sau recompense dublate apar exact în aceste momente. În lecția asta faci un plan de test simplu pe care îl aplici fiecărui quest înainte să-l publici.
Cuvinte pe care le vei întâlni
| Cuvânt | Ce înseamnă |
|---|---|
| Relogare | Ieși din joc și intri din nou cu același personaj. |
| Restart curat | Oprești serverul cu scriptul de oprire, care salvează datele. |
| Crash | Oprire bruscă a unui proces game, fără salvare. |
| Plan de test | O listă de situații, fiecare cu rezultatul așteptat. |
Ce trebuie să știi despre salvare
Ca să înțelegi testele, trebuie să știi când se salvează datele. În sursa pachetului de referință:
- Quest flag-urile și etapele (
pc.setqf,set_state) se salvează odată cu personajul: periodic, la aproximativ 2 minute (valoarea implicită; în CONFIG există opțiuneasave_event_second_cycle), și la ieșirea din joc. - Itemele au propriul drum de salvare și ajung la procesul
dbaproape imediat. - Event flag-urile (
game.set_event_flag) se salvează imediat în baza de date, prindb. - Cronometrele (
timer,server_timer) nu se salvează deloc. Trăiesc doar în memorie.
Ce înseamnă asta în practică: la o ieșire normală sau un restart curat, totul se salvează. La un crash, ultimele minute de progres din questuri se pot pierde, în timp ce itemele date în acel interval pot rămâne. Un jucător care a primit recompensa chiar înainte de crash ar putea s-o mai poată lua o dată. De aceea, după orice crash, verifică logurile de recompense (rândurile QUEST [REWARD] din syslog), cum am arătat în lecția despre recompense în inventar.
Ce se întâmplă cu un dialog la relogare
Tot din sursa verificată: dacă jucătorul iese din joc în timp ce un dialog așteaptă (select(), wait()), questul care rula se anulează. Codul de după select() nu se mai execută. Asta e vestea bună: jucătorul nu primește recompensa „pe jumătate”.
Vestea proastă: dacă ai pus ceva înainte de select() care ia sau dă iteme, acel lucru s-a întâmplat deja. De aceea, în toate exemplele din capitol, confirmarea e prima, iar luarea și darea vin la final, în același bloc.
Planul de test (copiază-l pentru fiecare quest)
| Nr. | Situația | Ce faci | Ce trebuie să vezi |
|---|---|---|---|
| 1 | Relogare la mijlocul misiunii | Omori 4 din 10 monștri, ieși, revii | Progres 4 din 10, scrisoarea e acolo |
| 2 | Relogare în dialog | Deschizi predarea, la „Da / Nu” ieși din joc | Nu ai primit nimic, nu ți s-a luat nimic, poți preda din nou |
| 3 | Schimbare de canal | Treci de pe CH1 pe CH2 la mijlocul misiunii | Același progres, aceeași etapă |
| 4 | Inventar plin | Predai cu inventarul complet plin | Mesajul „Fă loc”, nimic luat, nimic pierdut |
| 5 | Apăsări repetate | Predai, apoi deschizi imediat din nou dialogul | Opțiunea de predare nu mai apare |
| 6 | Restart curat | Omori 4 monștri, aștepți 3 minute, restart, revii | Progres 4 din 10 |
| 7 | Restart în eveniment | Pornești evenimentul, restart | Ora de final păstrată, efectul se oprește singur |
| 8 | Party | Doi jucători în grup omoară monștri | Notezi cui i se numără (vezi mai jos) |
Situația 8 contează la misiunea de vânătoare: în pachetul verificat, kill ajunge doar la jucătorul cu cele mai multe daune. Dacă vrei alt comportament, ai nevoie de altă logică.
Pasul 1: pregătește serverul de test
- Folosește un server de test, nu serverul cu jucători. Situațiile 6 și 7 cer restart.
- Fă backup înainte.
- Fă-ți două personaje: un GM (pentru comenzi) și un personaj normal (pentru test). Testează întotdeauna și cu cel normal: unele opțiuni apar doar pentru GM.
- Pune questul, compilează și dă
/reload q, ca în primul quest Lua. În pachetul verificat,/reloadcere rangul cel mai mare de GM (IMPLEMENTOR).
Pasul 2: rulează testele și notează
Pentru fiecare rând din tabel, notează într-un document trei coloane: ce trebuia să se întâmple, ce s-a întâmplat, ok sau nu. Nu te baza pe memorie. Dacă un test pică, repari questul și reiei toate testele, nu doar pe cel care a picat: o reparație poate strica altceva.
Pasul 3: verifică direct în baza de date (doar pe test)
Uneori vrei să vezi exact ce e salvat. În pachetul verificat, flag-urile sunt în tabelul quest din baza player. Întâi afli numărul (ID-ul) personajului, apoi îi citești flag-urile. Doar SELECT, doar pe serverul de test:
SELECT id, name FROM player.player WHERE name = 'TestPlayer';
SELECT szName, szState, lValue FROM player.quest WHERE dwPID = 123 AND szName = 'vanatoare_lupi';| Bucată | Ce înseamnă |
|---|---|
player.player | Tabelul cu personajele. id e numărul personajului. |
dwPID = 123 | Numărul personajului găsit la primul pas (123 e un exemplu). |
szName | Numele questului. |
szState | Numele flag-ului (de exemplu ucisi) sau o valoare internă a etapei. |
lValue | Valoarea salvată. |
Event flag-urile sunt în același tabel, la dwPID = 0. Numele coloanelor sunt cele din pachetul verificat; la tine pot diferi, verifică întâi structura tabelului. Mai multe despre aceste tabele găsești în lecția despre tabelele player și account.
Nu modifica valorile din tabel cât timp personajul e conectat. Serverul ține flag-urile și în memorie și, la următoarea salvare, le scrie peste ce ai schimbat tu.
Ce ar trebui să vezi: un rând cu ucisi și valoarea progresului. Dacă flag-ul e 0, rândul lipsește: în pachetul verificat, valorile 0 se șterg din tabel.
Pasul 4: testul de crash (opțional, doar pe test)
Pe serverul de test poți simula o cădere oprind brusc procesul game al unui canal. Apoi verifică:
- Ce progres a rămas în quest după repornire.
- Dacă recompensa dată chiar înainte de cădere a rămas în inventar.
- Dacă jucătorul poate lua recompensa încă o dată.
Dacă la punctul 3 răspunsul e „da”, știi că ai o fereastră de risc. Pentru recompense mari, poți reduce riscul: o recompensă pe care o primește printr-un item-cufăr (care se poate verifica în loguri), sau un eveniment cu premii puține și verificate manual. Nu face acest test pe serverul cu jucători.
Greșeli des întâlnite
- Testezi doar „drumul fericit”. Questul merge de la cap la coadă, dar se strică la prima relogare.
- Testezi doar cu GM-ul. GM-ul vede opțiuni pe care jucătorii nu le văd.
- Faci restart imediat după test. Dacă n-ai așteptat salvarea și n-ai ieșit din joc, poți crede greșit că progresul se pierde.
- Repari un test și nu le mai rulezi pe celelalte.
- Editezi tabelul
questcu jucătorul conectat. Modificarea ta se pierde la următoarea salvare.
Întrebări frecvente
De ce progresul meu s-a pierdut după restart?
Cel mai des: serverul a fost oprit brusc, nu cu scriptul de oprire, iar ultimele 2 minute nu se salvaseră. Vezi cum oprești și repornești serverul corect.
/reload q șterge progresul jucătorilor?
Nu. Reîncarcă textul questurilor, nu flag-urile salvate. Dar dacă ai redenumit questul sau un flag, progresul vechi nu mai e găsit sub noul nume.
Cât de des trebuie să refac testele?
La orice modificare a questului și după orice update de server (fișiere de quest, sursă game). Durează 15–20 de minute și te scapă de zile întregi de reparații.
Ce urmează
Ai terminat capitolul despre questuri și evenimente. Următorul capitol folosește tot ce ai învățat aici (etape, flag-uri, timere, recompense sigure) pentru cele mai complexe questuri: cum proiectezi un dungeon pas cu pas.
Toate lecțiile sunt în lista tutorialelor Metin2.
Server Metin2 gata de joc
Găzduire Metin2 în România, cu instalare de serverfiles, bază de date MySQL și protecție Anti-DDoS inclusă.