![Day[Z] Titan Launcher logo](/assets/img/logo2.webp?v=1781090027){kind=logo}
Day[Z] Titan Launcher
Ha valaha megnyitottál egy DayZ szerver-configot, és tagek, entryk, type-ok, eventek és protók repkedtek egy Discordon magyarázat nélkül, ez az útmutató neked szól. Sorra vesszük a fő economy XML-fájlokat, röviden és érthetően, hogy lásd, hogyan kapcsolódnak, és hol kell változtatni, ha „boostolni” akarod a lootot vagy a zombikat. Szándékosan kezdő szintű áttekintés - épp annyi, hogy a nagy összefüggések a helyükre kattanjanak.
Haladj végig rajtuk sorban. Minden fájlnak egy dolga van, és a trükk az, hogy meglásd, hogyan illeszkedik az egyik fájl egyik neve a másik fájl egy nevéhez - ez az illeszkedés az, ami valójában megjeleníti a lootot és az eventeket a világban.
Mielőtt bármihez hozzányúlnál, tisztázd a szavakat: tag, entry, type, event és proto. Ez az öt kifejezés állandóan visszatér, és pont ezek miatt tűnnek elsőre zavarosnak a fájlok. Mindegyik egy adott fájlban él és egy adott dologra utal; ha meg tudod nevezni őket, bármelyik tutorialt vagy Discord-szálat követni tudod anélkül, hogy elvesznél.
A gondolati modell, amitől minden más a helyére kattan: a DayZ Central Economy egy óriási „fogócska”. Az egyik fájlban definiált név egy másik fájl nevére hivatkozik, és amikor ezek a nevek egyeznek, valami megjelenik. Tartsd ezt fejben minden fájlnál - jórészt csak azt tanulod meg, hol születik egy név és hol használják fel.
A types.xml minden bejegyzése egy class name-et hív meg. Azért hívják class name-nek, mert a játék scriptjei osztály szerint hozzák létre a tárgyat - a bejegyzés csak közli az economyval, hogy ez az osztály létezik, és hogyan viselkedjen. Ezt a fájlt nyitják meg legtöbben elsőként, ha változtatni akarnak a spawnoló mennyiségen.
A két érték, amivel az economy a leginkább dolgozik, a nominal és a min: a nominal a célmennyiség, amit az economy a világban tartani próbál, a min pedig az a küszöb, ami új spawnt indít. A lifetime az, hogy hány másodpercig marad meg a tárgy a cleanup előtt. A quantmin és quantmax azt állítja, mennyire teli a tárgy spawnoláskor - egy kulacsnál ez nullától száz százalékig terjedhet.
Egy tárgy „boostolásához” általában a nominalt és a mint emeled. Ennyi elég ahhoz, hogy az economy többet tartson belőle életben, anélkül, hogy más fájlhoz nyúlnál.
Az összes taged, usage-ed és kategóriád a cfglimitsdefinition.xml-ben „születik”. Ez a definíciós fájljuk: amint egy név itt létezik, a játék minden más fájlban felismeri. Ezeket a neveket teszed rá egy types-bejegyzésre, hogy megmondd, hol és hogyan jelenhet meg az adott tárgy.
A usage-értékek például a Military, Medic, Police, Firefighter, Industrial, Farm, Coast, Town, Village, Hunting, Office, School, Prison és Lunapark. A kategóriák és a tier-flagek (tier egytől tier négyig, area flagek és így tovább) szintén itt vannak. A játékot egyáltalán nem érdekli, minek nevezed őket - akár „hostess snack cake”-nek is hívhatsz egy usage-et, és működni fog, amíg a pontos név rendesen rá van rakva egy tárgy bejegyzésére a lánc további részén.
Hova kerülnek hát a type-bejegyzések a világban? A proto a válasz. Egy proto megnevez egy tárgyat - mondjuk egy garbage pile-t -, és rárakod azokat a usage- és kategória-neveket, amiket a limits-fájlban definiáltál. A proto egyúttal koordinátákat is hordoz az egyes loot-pontokhoz, amik a tárgy középpontja köré vannak térképezve.
A proto neve bármi lehet. A lényeg a következő lépés: ennek a névnek egyeznie kell egy pozíció nevével máshol - ezt nézzük meg ezután. Önmagában a proto csak egy definíció, ami azt mondja: „ez az objektum így taggelt lootot tart”.
A mapgrouppos.xml tartja a pozíciókat. Amíg egy proto neve (egy mapping) egyezik egy pos nevével (egy pozícióval), addig az a proto ott áll azon a pozíción, és azt a lootot tartja, ami az egyező usage-eihez van taggelve. Ez a „fogócska” a gyakorlatban: a proto a fogó, a pos pedig a hely, ahol áll.
Egyszerűen: a proto azt mondja, „egy garbage pile vagyok, ami town és village lootot tart”, az egyező pos pedig azt, „rakd ide ezt a garbage pile-t”. Ha a két név teljesen egyezik, loot jelenik meg azon a ponton; ha az egyiket elgépeled, semmi sem spawnol. Innentől minden, amit eventekben használsz, ugyanezt az illeszkedési logikát követi.
Az events.xml és a cfgeventspawns.xml pontosan úgy tartoznak össze, mint a proto és a pos. Egy eventnek van neve, és ez a név egy prefixet hordoz: Item, Static vagy Vehicle. Az egyező event-spawn név felsorolja a térkép-pozíciókat, ahol az adott nevű event létezhet.
Egy eventen belül beállítod a minimum, maximum és nominal kimenetet, plusz egy radiust, amin belül a spawnolt objektumok (vagy zombik) mozoghatnak, és a children-t - magukat a dolgokat, amiket az event kibocsát. Három további mező szabályozza a viselkedést: a safe radius azt, milyen közel egy játékoshoz spawnolhat az event, a distance azt, milyen messze kell lennie egy másik eventtől, a cleanup pedig azt, milyen messzire kell elsétálnod, mire deaktiválódik.
Amikor maga a child a limit, a kimenetet az egyes childek saját minimuma és maximuma szabályozza az átfogó nominallal együtt - nincs szükség külön, eventszintű minimumra vagy maximumra.
Egy Vehicle-prefixű event ugyanúgy működik - az event neve egyezik egy event-spawn névvel, így az event azokra a pozíciókra kerül. Az új elem az „a=” érték, ami az irány, amerre a jármű néz. A motorháztető néz ebbe a szögbe: 0 vagy 360 az észak, 180 a dél, és egy kis fejszámolással bármelyik irány kiadódik a körön.
A vehicle eventek általában „mixed” limitet használnak. Ahelyett, hogy minden felsorolt childet minden pontos pozíción spawnoltatnál (ami feltornyozná az autókat), azt mondod az economynak, hogy az átfogó összeget tartsa egy min és max között a nominal körül - például összesen 11–15 jármű, cél nagyjából 13, és gyermektípusonként legfeljebb egy–három a keverékben.
A többi úgy viselkedik, mint bármelyik event: a lifetime szabja meg, meddig marad egy jármű, és ugyanazok a safe radius, distance és cleanup szabályok érvényesek. Ha egy jármű tönkremegy, az event eltávolítja, és a következő rotációnál újat pottyant.
Egy infected (zombi) event egy environment-fájllal, az úgynevezett territory-val beszél, ami megadja, hova tartozik az adott infected csoport. A territory oldal mélyebb téma, külön tutorialt érdemel, de az alapok elegendők a változtatáshoz.
A zombik egyszerű boostolásához emeld az infected event minimum és nominal kimenetét - a maximumhoz ehhez ritkán kell nyúlni. Különböző infected childeket más eventekbe is bekeverhetsz, hogy szétszórd őket a térképen, ahol több zombit szeretnél.
A random presetek a köztes ember a types.xml és a spawnable type-ok között. Egy preset egy nevesített cargo- vagy attachment-loot-poolt hoz létre: type-ok vagy osztályok listáját, mindegyikhez egy hit chance-szel. Amikor az az esély bejön, a pool egyik gyermeke kiválasztódik.
Így kapsz változatosságot egy objektumban vagy rajta - például egy cargo preset, ami megtölt egy tartót, vagy egy attachment preset, ami kalapot vagy hátizsákot tesz egy zombira. A preset csak a poolt definiálja; a következő, a spawnable type az, ami megmondja egy tárgynak, hogy ténylegesen használja.
A cfgspawnabletypes.xml az, ami megmondja egy type-nak, hogy más type-ok legyenek rácsatolva vagy benne. Ez fogyasztja az imént definiált random preseteket: egy spawnable type név szerint egy cargo- vagy attachment-presetre mutat, és a preset hit chance-ei döntik el, mi jelenik meg valójában.
Röviden: a types.xml azt mondja, hogy egy tárgy létezik, a random preset definiál egy lehetséges extrákból álló poolt, a spawnable type pedig összeköti a kettőt, hogy a frissen spawnolt tárgy a megfelelő cargóval és attachmentekkel érkezzen.
A globals.xml tartja a szerverszintű kapcsolókat, és erősebb, mint amilyennek látszik. Alul van az átfogó infected-számláló - emeld vagy csökkentsd, hogy beállítsd a megengedett maximális AI-t. A vanilla valahol 1000 és 1200 körül van; a forrás-buildben 850-re csökkentették. Mellette találod az animal countot és azt, milyen gyorsan takarítódik el egy holttest.
Egy kulcsfontosságú értékpár az idle-beállítások. Állítsd mindkét idle-értéket nullára, és az economy akkor is forog, ha senki sincs fent, így a loot és az eventek frissek maradnak egy 24/7-es szerveren. Az itteni további kapcsolók szabályozzák, hány darab loot spawnol kezdetben, és lehetővé teszik olyan rendszerek ki-be kapcsolását, mint a wet, a world és a tents.
Ez csak a kezdő áttekintés - több fájl és sokkal mélyebb videók is léteznek mindegyikhez. De ha tudod, hogyan hivatkoznak egymásra ezek a fő fájlok, az elég ahhoz, hogy biztonságosan elkezdd hangolni a saját szervered lootját és zombijait.
Kezdd a types.xml-ben, és emeld annak a tárgynak a nominal és min értékét, amiből többet szeretnél. A nominal a célmennyiség, amit az economy a világban tart, a min pedig a küszöb, ami friss spawnt indít.
Átfogó plafonhoz emeld az infected-számlálót a globals.xml-ben. Egy adott terület zsúfoltabbá tételéhez emeld a megfelelő infected event minimum és nominal értékét az events.xml-ben - a maximumhoz általában nem kell nyúlni.
Szinte mindig név-eltérés. Egy proto nevének pontosan egyeznie kell egy pos nevével, egy event nevének pedig pontosan egy event-spawn névvel. Ellenőrizd a helyesírást és a nagybetűket mindkét oldalon.
A random preset (cfgrandompresets.xml) egy nevesített poolt definiál lehetséges cargóból vagy attachmentekből, hit chance-ekkel. A spawnable type (cfgspawnabletypes.xml) megmondja egy tényleges tárgynak, hogy használja ezt a poolt - így a preset a köztes ember a types.xml és a tárgy által hordozott loot között.
A globals.xml-ben állítsd mindkét idle-értéket nullára. Az economy ekkor folyamatosan forog, így egy 24/7-es szerver friss loottal és eventekkel marad feltöltve.