Server Files: ErklÀrung und Bedeutung

    Thema:



    economy.xml


    Hier geht es erst mal um ein relativ kleinen und einfachen Abschnitt,

    denn hier kann man im Grunde einfach nur vorab einstellen,

    ob z.B. Objekte, Tiere, Fahrzeuge, etc. ĂŒberhaupt gespawnt,

    Bzw. geladen oder gespeichert werden sollen.


    Wir haben zu aller erst einmal wieder unsere altbekannte Originaldatei

    und schauen anschließend die einzelnen Abschnitte an.


    Code
    <economy>
    <dynamic init="1" load="1" respawn="1" save="1"/>
    <animals init="1" load="0" respawn="1" save="0"/>
    <zombies init="1" load="0" respawn="1" save="0"/>
    <vehicles init="1" load="1" respawn="1" save="1"/>
    <randoms init="0" load="0" respawn="1" save="0"/>
    <custom init="0" load="0" respawn="0" save="0"/>
    <building init="1" load="1" respawn="0" save="1"/>
    <player init="1" load="1" respawn="1" save="1"/>
</economy>


    Wie wir sehen, ist es tatsÀchlich nicht viel und im Grunde auch alles relativ gleich oder Àhnlich.

    Jede Zeile hat einen Bereich, fĂŒr den sie verantwortlich ist und lĂ€sst somit fĂŒr jeden Abschnitt anpassen.


    Es gilt auch ĂŒberall nur der Wert "1" fĂŒr aktiviert oder "0" fĂŒr deaktiviert.


    Fangen wir aber mit den 4 Grundeinstellungen an, die in jeder Zeile gleich sind

    und auch immer dieselbe Funktion besitzen.

    Da ich immer noch kein IT oder Programmierprofi bin, kann ich mehr anhand der Bedeutung erahnen,

    wofĂŒr welche Einstellung gedacht ist und wie es am logischsten zusammen passt.

    Leider lÀsst sich da auch keine direkte ErklÀrung von Bohemia oder sonst wem finden,

    aber das soll uns nicht aufhalten und ggf. kann gern einer eine genaue ErklÀrung nachreichen

    oder ich schaffe es mal zu testen und berichtige ggf. meine aussagen😊.


    init = Initialisieren


    Hiermit wird festgelegt, ob der Server beim Starten mit den vorgegeben oder zugehörigen Dateien und Werten arbeiten soll.

    Einfach erklĂ€rt wĂ€re es an Objekten, wo wir dem Server hiermit z.B. sagen, ob er gleich zum Start die Map mit vorgegeben Werten fĂŒllen,

    oder es im Laufe der Zeit gespawnt werden soll. So wÀre es glaube am einfachsten erklÀrt.


    load = Laden


    Hier wird festgelegt, ob der Server SpeicherstĂ€nde laden soll oder nicht. In Kombination auch gern ein Wipe durchfĂŒhren,

    indem wir alte SpielstĂ€nde von z.B. Fahrzeugen nicht laden lassen, aber dafĂŒr neue speichern. Das hat zur Folge,

    dass die SpielstĂ€nde der alten Fahrzeuge ĂŒberschrieben werden.

    HierfĂŒr sollte aber der Server etwa 10-15 min arbeiten und am besten auch Spieler frei sein.


    respawn = Respawnen


    Mit dieser Einstellung kann festgelegt werden, ob z.B. Objekte respawnen oder nicht. Ist dies also deaktiviert,

    sollte man wohl mit seiner AusrĂŒstung vorsichtig sein 😜. Wenn alle dann alle đŸ€Ł.


    save = Speichern


    Hiermit können wir noch festlegen, ob der Server ĂŒberhaupt SpeicherstĂ€nde anlegen soll.

    Damit können wir also sagen, dass z.B. Spieler mit jedem Server Neustart von vorne anfangen sollen.



    Soweit sollte die Werte oder allgemeinen Einstellungen geklÀrt sein.

    Jetzt haben wir noch die einzelnen Bereiche, fĂŒr die wir die Einstellungen anpassen können.


    dynamic = Dynamische Objekte / Loot


    Hierunter wird also mit den o.g. Einstellungen alles fĂŒr den Normalen Loot bzw. Objekte angepasst.


    animals = Tiere


    Hier kann wie auch beim Loot das ganze fĂŒr Tiere angepasst werden.


    zombies = Infizierte


    Wie auch schon bei den Tieren, können hier die Einstellungen fĂŒr Infizierte / Zombies eingestellt werden.


    vehicles = Fahrzeuge


    Auch hier gelten die gleichen Möglichkeiten, nur eben auf Fahrzeuge bezogen.


    randoms = Events


    Hier nochmal dasselbe fĂŒr die Events.


    custom = Benutzerdefinierte Objekte


    FĂŒr benutzerdefinierte Objekte. Dazu kommen wir aber ggf. spĂ€ter noch.


    building = GebÀude


    Hier fĂŒr GebĂ€ude, wobei sich dies wohl eher auf die TĂŒren bezieht.


    player = Spieler / Charaktere


    Hier gilt dasselbe wie bei allem anderen.



    Wie man hoffentlich sieht, ist es eigentlich recht simpel, wenn man erst mal durch diese ganzen Einstellungen durchgewĂŒhlt hat.

    Obwohl es so wenig aussieht, können diese Einstellungen ganze Server zunichtemachen.

    Einmal in der falschen Zeile an der fachen Position die falsche der Falsche wert und schwupp sind alle Charaktere oder Basen weg.

    Daher ist also immer ein Backup wichtig und geht immer auf Nummer sicher und geht immer nochmal alles durch, bevor ihr etwas speichert.


    Das sollte aber bei diesem Thema ausreichen glaube ich und schlage vor, wir gehen zum nÀchsten,

    denn wie immer kann man mich gern berichtigen oder Änderungen vorschlagen 😊.

    Thema:



    globals.xml


    Hierbei handelt es sich um globale Einstellungen bezĂŒglich der gesamten Server Ökonomie.

    Es können einfache Einstellungen vorgenommen werden, wie das Verrotten von Lebensmitteln,

    wie viele Zombies es geben soll oder ob Objekte beim Spawnen beschÀdigt sein sollen.


    Fangen wir einfach wieder mit der Datei und der Grundkonfiguration an

    und kÀmpfen uns dann wieder bis zum Ende durch.



    Zu aller erst muss ich sagen, dass ich keine Ahnung habe, wofĂŒr genau das "type="0"" steht 😅.

    Aber tendenziell ist es fĂŒr das, was man mit seinen persönlichen Einstellungen machen möchte

    auch nicht so wichtig, denn hier sind es mehr die "values" auf die es tatsÀchlich ankommt.


    WICHTIG!!! Nicht jede Einstellung hat dieselbe Art von Wert. Sie können in "sec", "m", "%",

    der Anzahl oder wieder einfach nur die Werte "1" fĂŒr aktiviert und "0" fĂŒr deaktiviert angegeben werden.

    Es kommt einfach auf die jeweilige Einstellung an.


    Fangen wir also wieder mit den einzelnen Zeilen an.


    name="AnimalMaxCount" = max. Tierpopulation mit Wert in "Anzahl"


    Bei dieser Einstellung handelt es sich um die maximale Anzahl an Tieren, die auf dem Server gleichzeitig vorhanden sein darf.

    Hierbei sollte man beachten, dass dieser Wert sich nicht auf jedes einzelne, sondern alle Tiere gleichzeitig beruht.

    Mit jedem neu hin zu gefĂŒgten Tier wird dieser Wert eben auch mit diesen geteilt, wodurch die Anzahl der anderen Tiere weniger,

    und eben die der neuen einberechnet wird.


    "CleanupAvoidance" = Despawn Verbot von Objekten um den Spieler in "m"


    Hier kann ein Radius um einen Spieler in Metern angegeben werden, der verhindert, dass Objekte innerhalb dieses Radius verschwinden.

    WÀre dieser Wert auf "0" gesetzt, könnte es durchaus vorkommen, dass mal eben beim Looten das Objekt der Begierde

    vor dem Spieler einfach verschwindet als wĂŒrde Thanos mit dem Finger schnippen 😅.

    Wichtig ist hier zu beachten, dass es ein Radius ist, stellt man den Wert also auf "500" betrÀgt der Bereich also "1000" Meter,

    da "500" um den Spieler in jede Richtung gerechnet wird.


    "CleanupLifetimeDeadAnimal" = Verweildauer von toten Tieren in "s"


    Hierbei kann in Sekunden festgelegt werden, wie lange ein getötetes Tier liegen bleibt, bis es despawnt.

    Maximal wÀre hier zu beachten, ob die in der Types.xml hinterlegte Lebensdauer greift,

    wenn der hier eingetragene Wert diese ĂŒbersteigt. Tiere, die von Spielern bewegt werden mĂŒssten in der Theorie

    von diesem Wert abweichen und sollten auf den in der Types.xml hinterlegten Wert zurĂŒckgreifen.


    "CleanupLifetimeDeadInfected" = Verweildauer von getöteten Infizierten in "s"


    Wie bei den Tieren kann hier in Sekunden festgelegt werden, wie lange Leichen von Infizierten liegen bleiben, bis es despawnt.

    Maximal wÀre auch hier zu beachten, ob die in der Types.xml hinterlegte Lebensdauer greift,

    wenn der hier eingetragene Wert diese ĂŒbersteigt. Auch hier sollte in der Theorie der Wert der Types.xml genutzt werden,

    sobald ein Spieler mit einer Leiche bzw. ihrem Inventar interagiert hat.


    "CleanupLifetimeDeadPlayer" = Verweildauer von Spielerleichen in "s"


    Hier wird die Zeit in Sekunden festgelegt, wie lange die Leiche eines Spielers liegen bleibt, bevor diese verschwindet.

    Leider scheint dies aber aus irgendeinem Grund nicht so ganz zu funktionieren. Bei meinen ersten geh versuchen mit dieser Einstellung,

    Wurde der Wert immer wieder auf den Standardwert zurĂŒckgesetzt bzw. gar nicht erst gegriffen.


    Aber vlt. hat sich dies ja mittlerweile geĂ€ndert đŸ€”.


    "CleanupLifetimeDefault" = Verweildauer von allgemeinen Objekten in "s"


    Damit wird, wie auch bei den Vorherigen, die Lebensdauer in Sekunden angegeben, wie lange diese in der Welt verweilen dĂŒrfen.

    Wie auch bei den Kleintieren und den Infizierten sollte der in der Types.xml hinterlegte Wert

    nach der Interaktion mit einem Objekt gelten. Dieser Wert entspricht also nur Objekten, die von Spielern z.B. nicht in die Hand genommen wurden.


    "CleanupLifetimeLimit" = Anzahl an gleichzeitig zu löschenden Objekten


    Mit diesem Wert lÀsst sich die Anzahl an Objekten festlegen, die zur gleichen Zeit despawnen können.


    "CleanupLifetimeRuined" = Verweildauer von Ruinierten / Verrotteten Objekten in "s"


    Hier wird in Sekunden festgelegt, wie lange z.B. ein verrotteter Apfel liegen bleibt, bevor er verschwindet.

    Zu berĂŒcksichtigen ist natĂŒrlich, dass ein verrotteter Apfel, mit dem niemand interagiert hat,

    wieder auf den Wert von "CleanupLifetimeDefault" zurĂŒckgreift.


    "FlagRefreshFrequency" = Fahnenmast Auffrischungsrate in "s"


    Mit diesem Wert wird in Sekunden festgelegt, wie lange es dauert, bis die Lebensdauer von Objekten im Radius des Fahnenmastes wieder zurĂŒckgesetzt werden.


    "FlagRefreshMaxDuration" = Fahnenmast Lebensdauer in "s"


    Hiermit wird in Sekunden festgelegt, wie lange es dauert, bis der Fahnenmast seine Wirkung verliert

    und die Objekte im Radius wieder auf ihre ursprĂŒngliche Lebensdauer zurĂŒckgreifen.


    "FoodDecay" = Einstellung fĂŒr Verderben von Lebensmitteln


    Damit lÀsst sich verhindern, dass Lebensmittel in der Spielwelt verderben können.


    Auf "1" gesetzt können sie mit der Zeit verderben und auf "0" wiederum nicht.


    Wichtig hierfĂŒr ist die Einstellung "WorldWetTempUpdate", denn diese muss aktiviert sein,

    wenn man Lebensmittel verderben lassen möchte.


    "IdleModeCountdown" = Timer in "s" fĂŒr Server Ruhemodus


    Dies ist ein Countdown, der in Sekunden angegeben wird und nach Ablauf dieses Timers, den Server in einen Ruhemodus versetzt,

    sobald er merkt das keinerlei Spieler mehr auf dem Server sind.


    "IdleModeStartup" = Einstellung fĂŒr Server Ruhemodus


    Damit lÀsst sich mit "1" (Aktiviert) oder "0" (Deaktiviert) die Ruhefunktion des Servers ein oder ausschalten und

    ist auch erst mit dem nÀchsten Serverneustart eingestellt.


    "InitialSpawn" = Rate des ersten Lootspawns in "%"


    Hier wird mit einem prozentualen Wert die erste Loot Verteilung angegeben.

    Dies sorgt ggf. das beim in Betrieb nehmen des Servers,


    nicht gleich alles auf einmal, sondern erst im Laufe der Zeit nach spawnt

    und Spieler nicht beim ersten Betreten von Objekten erschlagen werden.


    "LootDamageMax" = max. Schadensrate von gespawnten Objekten in "%"

    "LootDamageMin" = min. Schadensrate von gespawnten Objekten in "%"


    Bei diesen beiden Werten handelt es sich um den minimalen und maximalen Schaden, den Objekte beim Spawnen haben können.

    Es handelt sich hierbei wieder um einen prozentualen Wert, zwischen dem sich anschließend Objekte per Zufall bewegen.

    Wenn min. auf "0.0" und max- auf "1.0" (1.0 = 100 %) gestellt, können Objekte von ruiniert bis makellos Spawnen.

    Wenn beides auf "1.0" gestellt, spawnen alle Objekte in einem makellosen Zustand.


    "LootProxyPlacement" = Einstellung fĂŒr Loot in Containern


    Hiermit lĂ€sst sich ganz einfach einstellen, ob Container (darunter ZĂ€hlen hierfĂŒr auch KleidungsstĂŒcke) Loot enthalten können.

    Mit dem Wert "1" kann Loot enthalten sein, mit "0" ist kein Loot mehr enthalten.


    "LootSpawnAvoidance" = Spawn Verbot von Objekten, um den Spieler in "m"


    Wie schon beim Despawnen, ist es eigentlich dasselbe, nur umgekehrt. In Metern wird somit angegeben,

    in welchem Radius um den Spieler kein Loot Spawnen darf.

    Auch hier gilt wieder der Thanos Finger Schnipper, nur dass Objekte in dem Falle nicht verschwinden, sondern vor dem Spieler

    aufploppen wĂŒrden, wenn der Wert "0" betragen wĂŒrde. Und das mit dem Radius muss ich glaube nicht nochmal erklĂ€ren 😅.


    "RespawnAttempt" = Respawnversuche von einzelnen Objekten


    Hier wird als Wert die Anzahl festgelegt, wie oft der Server versuchen soll ein Item zu Respawnen. Aufgrund der einzelnen Einstellungen,

    kommt es nun mal vor das z.B. ein Spieler in der NĂ€he ist oder sich in eine Ortschaft verirrt und somit kein Item Spawnen kann, da dieser das ganze Blockiert.

    Der Server versucht dies dann einfach noch einmal zu Spawnen, da es ja sein kann, dass der Spieler weiter gezogen ist.

    So in etwa kann man sich dies am leichteste Vorstellen glaube ich. Der Server versucht und ĂŒberprĂŒft einfach den gewĂ€hlten Punkt und wenn nach der Anzahl,

    der festgelegten Versuche das Item nicht Spawnen kann, sucht er sich eben einen neuen.


    "RespawnLimit" = Anzahl gleichzeitiger Spwans von Objekten des gleichen Typs


    Bei dieser Einstellung wird mit einem Wert die Anzahl festgelegt, wie viele Objekte vom selben Typ Spawnen dĂŒrfen.

    Ich bin mir unsicher, ob es sich hierbei um den Typ im Sinne von z.B. Kleidung oder um die explizite Bezeichnung eines Objektes wie z.B. einem grauen Hoodie handelt.

    WĂŒrde aber eher auf ersteres tippen, damit ggf. ein Ort nicht von Kleidung ĂŒberflutet wird.


    "RespawnTypes" = Anzahl gleichzeitiger Spwans von Objekten Arten


    Hier wird nochmal mit einem Wert die Anzahl an Objektarten festgelegt, die gleichzeitig spawnen können.

    Im Prinzip also wie die vorherige Einstellung, und insgesamt hat es wohl alles eher mit der Performance und dem Balancing zu tun.


    "RestartSpawn" = Rate des Lootspawns nach jedem Neustart in "%"


    Hier kann mit einem Wert festgelegt werden, zu wie viel Prozent sÀmtlicher Loot nach jedem Neustart wieder auf nominal bzw. auf maximal gesetzt wird.

    Also wird einfach nach jedem Neustart alles an Loot auf sein festgelegtes Maximum gespawnt, wenn der Wert z.B. "100" betragen wĂŒrde.


    "SpawnInitial" = Anzahl an Test Spwans von Objekten


    Hierbei wird wieder mit einem Wert die Anzahl festgelegt, wie oft der Server einen Spawn Test fĂŒr Objekte erlaubt sind.

    Es ist quasi wie mit Verbindungsversuchen fĂŒr das Internet, denn auch da macht man zwar seinen Browser an, aber die ganze Technik dahinter ist etwas komplizierter

    als nur eine Taste zu drĂŒcken. Und genau dasselbe passiert eben auch mit dem Server, er testet die Spawns von Objekten eben bis zu z.B. 1200-mal,

    bevor er ein Objekt am Ende tatsÀchlich spawnt.


    "TimeHopping" = Wartezeit fĂŒr Serverbeitritt bei Server Hopping in "s"


    Damit wird einfach nur in Sekunden festgelegt, wie lange man beim Server Hopping warten muss, bis man dem neuen Server beitreten darf.


    "TimeLogin" = Wartezeit fĂŒr Serverbeitritt in "s"


    Hier wird die Wartezeit in Sekunden festgelegt, wie lange ein Spieler warten muss, bis er dem Server beitritt.

    Und ja, wir kennen alle den Countdown, der nach den ersten Ladebildschirmen auftaucht, denn genau diese Zeit wird hier angegeben 😜.


    "TimeLogout" = Wartezeit fĂŒr den Logout in "s"


    Und auch hier wird wieder in Sekunden angegeben, wie lange wir warten mĂŒssen, bis wir endgĂŒltig ausgeloggt sind.

    Hier sollte nur beachtet werden, dass wÀhrend dieses Countdowns unser Charakter die ganze Zeit die bekannte Sitzposition einnimmt

    und wehrlos in der Welt sitzt, wĂ€hrend wir warten 😅.


    "TimePenalty" = Strafzeit fĂŒr Spieler, die noch in einer Sitzung sind in "s"


    Dies ist eine zusĂ€tzliche Zeit (natĂŒrlich wieder mit einem Wert in Sekunden), die wir z.B. warten mĂŒssen, wenn wir uns einfach Disconnecten oder Ausloggen

    aber die Zeit nicht abwarten und einfach einem anderen Server beitreten oder wieder neu Connecten.


    "WorldWetTempUpdate" = Einstellung fĂŒr Temperatur und Feuchtigkeit bei Objekten


    Hier kann zum Aktivieren mit dem Wert "1" und Deaktivieren mit dem Wert "0" festgelegt werden, ob die Umwelt Einfluss auf Objekte haben darf.

    Ist diese Einstellung deaktiviert, können Lebensmittel mit der Zeit nicht mehr schlecht werden.

    Wichtig ist hier in der Theorie, dass es sich dabei um ein Updaten der EinflĂŒsse hat, nicht, dass es gar nicht mehr funktioniert.

    Sollte es also passieren, dass ein Objekt schon gefroren Spawnt, könnte es unter UmstÀnden passieren, dass es gefroren bleibt.


    "ZombieMaxCount" = Anzahl an maximal gleichzeitigen Zombies auf der Map


    Hierbei wird mit einem Wert die maximale Zombieanzahl festgelegt, die ĂŒber die Map streifen.

    Dabei ist es egal, ob dynamische Zombies oder statische (Zombies, die auch spawnen, wenn kein Spieler in der NĂ€he ist).

    Hier sollte man es nicht ĂŒbertreiben, denn jeder Zombie benötigt Ressourcen, was wiederum die Performance des Servers beeintrĂ€chtigen kann.


    "ZoneSpawnDist" = Entfernung zum Spawnen von dynamischen Zombies in "m"


    Hier wird in Metern festgelegt, ab welcher Entfernung dynamische Zombies spawnen sollen,

    wenn sich ein Spieler einer solchen Spwan Zone nÀhrt.



    Dies sollte hoffentlich erst einmal genĂŒgen und hoffentlich wieder soweit verstĂ€ndlich sein 😅.

    Ist leider halt ein etwas trockenes Thema, aber spÀter eventuell wichtig, wenn man sich die Objekte oder allgemein nachfolgende Dateien anschaut.


    Thema:



    cfgeconomycore.xml


    Kommen wir zum nÀchsten Teil, allerdings muss ich hier sagen, gibt es eigentlich nicht so unbedingt viel,

    was fĂŒr den Standard Server, tatsĂ€chlich von Bedeutung ist.


    Von Interesse wird es erst, wenn es ein wenig um die Ordnung auf dem eigenen Server geht,

    denn hier lassen sich mit ein paar kleinen Handgriffen kleine Umstrukturierungen vornehmen.

    Aber dazu kommen wir etwas spÀter, denn wir fangen wie immer mit der Grunddatei an.



    Hier haben wir als allererstes die Einteilung in die "classes" und einmal in die "defaults".


    Unter den "classes" haben wir folgende EintrÀge, welche eine Art Grundklasse darstellt,

    welche von der Economy des Servers genutzt wird. Ob sich hier tatsÀchlich Sachen Àndern lassen,

    weiß ich leider nicht ganz genau, da ich insoweit noch keinerlei neue Grundklasse eingefĂŒgt habe 😅.

    Daher werde ich das auch nur mehr oder weniger der VollstÀndigkeit halber kurz anschneiden

    und fasse alles ein wenig mit den Bedeutungen der einzelnen Definitionen und Einstellungen zusammen,

    damit ich nicht jede Zeile einzeln aufschlĂŒsseln muss 😅.


    Macht es glaube auch etwas angenehmer.


    "name":

    Bei "name" handelt es sich um die einzelnen Namen der Grundklassen.

    Dies hat alles eher was mit den ganzen Scripts und allem was hinter der ganzen Programmierung steckt zu tun.

    Unterteilt werden sie in "DefaultWeapon" fĂŒr Waffen, "DefaultMagazine" fĂŒr die entsprechenden Magazine,

    "Inventory_Base" fĂŒr eigentlich alle Inventar-GegenstĂ€nde, "HouseNoDestruct" fĂŒr statische Objekte wie GebĂ€ude,

    BĂ€ume oder Fahrzeugwracks. "SurvivorBase" fĂŒr den Charakter, "DZ_LightAI" fĂŒr alles KI gesteuerte wie Tiere

    oder Infizierte, "CarScript" fĂŒr Landfahrzeuge bzw. Autos und "BoatScript" fĂŒr Wasserfahrzeuge wie Boote.

    Existiert oder wird eine neue Grundklasse eingefĂŒgt, wie z.B. seit der 1.26 die Boote,

    dann wird es also auch hier wieder eine neue Zeile geben, in der die neue Klasse vertreten ist.


    "act":

    Dabei handelt es sich um Funktion oder den Typ, welchen die Grundklasse einnimmt.

    Es gibt die Möglichkeiten "none" fĂŒr keine, "car" fĂŒr Fortbewegungsmittel

    und "character" fĂŒr Lebewesen, also Spieler, Tiere oder Charaktere.

    Wird hier nichts Genaues definiert, gilt fĂŒr die Klasse "none" und zĂ€hlt im Grunde als Objekt.


    "reportMemoryLOD":

    Wie wo was genau, bin ich etwas ĂŒberfragt, aber es hat scheinbar etwas mit den LOD's

    und den Modellen zu tun 😅.



    Kommen wir nun zum etwas interessanteren Teil, den "defaults".

    Diese legt nochmal ein paar, nennen wir es "Grundregeln" fĂŒr die Ökonomie des Servers fest

    und besitzt zusÀtzlich nochmal ein paar separate Einstellungen.


    Wichtig!!! Hier gibt es wieder ein paar Zeilen, die in den Standardeinstellungen nicht vorhanden sind,

    um diese kĂŒmmern wir uns allerdings auch erst etwas spĂ€ter und widmen uns erst mal denen,

    die auch Vanilla schon vorhanden sind.


    "dyn_radius" = ZonengrĂ¶ĂŸe dynamischer Zonen von Infizierten in "m"


    Hier kann, wie es oben schon ausgesagt wird, die GrĂ¶ĂŸe der Zonen festgelegt werden, in denen nachher unsere dynamischen Zombies umherwandern können.


    "dyn_smin" = minimale Anzahl dynamischer Zonen von Infizierten (statische ZĂ€hlung)

    "dyn_smax" = maximale Anzahl dynamischer Zonen von Infizierten (statische ZĂ€hlung)

    "dyn_dmin" = minimale Anzahl dynamischer Zonen von Infizierten (dynamische ZĂ€hlung)

    "dyn_dmax" = maximale Anzahl dynamischer Zonen von Infizierten (dynamische ZĂ€hlung)


    Hier kann die minimale und die maximale Anzahl der dynamischen Zonen angegeben werden.

    Diese werden mehr oder weniger, wie alles andere vom Server gezÀhlt.

    Je nachdem wie sich das Ganze auf dem Server und der Verteilung von den Infizierten verhÀlt,

    wie viele Spieler an verschiedenen Orten unterwegs sind, kann es sein,

    dass am Ende ggf. zu viele Infizierte umherirren, da dynamische Spawns immer dann eintreten,

    wenn sich ihnen ein Spieler nÀhrt. Da es vorkommt, dass hier nicht nur eine Zone im Umfeld ist,

    kann der Server diese so ausbalancieren, dass es am Ende nicht zu viele werden

    und die Performance am Ende darunter leidet.

    Da diese Werte aber wahrscheinlich bei den meisten Servern von Haus aus bei "0" liegt,

    somit kein fester Wert angegeben und die Server soweit recht passabel laufen,

    wĂŒrde ich eher abraten, hier an den werten herumzuspielen.



    Die folgenden Einstellungen haben eher etwas mit dem Protokollieren der Central Economy zu tun

    und können maximal aktiviert (true) oder deaktiviert (false) werden.


    "log_ce_loop" = Protokollierung von CE-Schleifen (bezieht sich wahrscheinlich allgemeine Verhalten der Central Economy)

    "log_ce_dynamicevent" = Protokollierung von dynamischen Events

    "log_ce_vehicle" = Protokollierung von Fahrzeug spawns

    "log_ce_lootspawn" = Protokollierung von Loot und seinem Spawn verhalten

    "log_ce_lootcleanup" = Protokollierung von Loot Despawns

    "log_ce_lootrespawn" = Protokollierung von Respawns

    "log_ce_statistics" = Protokollierung von statistischen Daten

    "log_ce_zombie" = Protokollierung von Infizierten

    "log_storageinfo" = Storage Infos ĂŒber die Konsole

    "log_hivewarning" = Hive Warnungen ĂŒber die Konsole

    "log_missionfilewarning" = Warnmeldungen ĂŒber Missions Dateien

    "save_events_startup" = Speichern von Event Daten bei Serverstart

    "save_types_startup" = Speichern von Objekt Daten bei Serverstart



    Jetzt kommen wir zu den EintrÀgen, die scheinbar nicht in den Vanilla Dateien enthalten sind

    oder eventuell auch nicht mehr benötigt werden. Was aber in den meisten FÀllen der Fall ist,

    ist die Tatsache, dass bei nicht eintragen dieser Zeilen entweder die Grundwerte zÀhlen

    oder die Einstellung automatisch auf "false" gestellt und somit deaktiviert wÀre.


    "log_ce_animal" = Protokollierung von Tieren


    "world_segments" = Anzahl der Segmente, in die die Map geteilt werden soll


    Hier muss man sich das ganze als eine Art Raster vorstellen, in welches die Karte aufgeteilt wird.

    Standard wĂ€ren es "12", womit man also sagen könnte, die Karte wird wie ein Kuchen in mehrere StĂŒcke aufgeteilt

    und jedes StĂŒck hat mehr oder weniger seine eigenen Speicherdaten.

    Dies ist also im Prinzip dafĂŒr da, damit der Server nicht jedes Mal eine riesige Datei,

    sondern mehrere kleinere Dateien zum Laden hat, da jede Datei als Backup dient.


    "backup_period" = Zeit zwischen Server Backups in "min"


    Hier wird in Minuten angegeben, wie viel Zeit zwischen den Backups vergehen soll.

    Im Normalfall sollte der Server jede Stunde ein Backup anlegen.

    Der minimale Wert ist hierbei "15" Minuten und der maximale und auch Standard Wert sind "60".


    "backup_count" = Anzahl der Ordner fĂŒr Server Backups


    Hier kann mit einem Wert festgelegt werden, wie viele Ordner dem Server zur VerfĂŒgung stehen sollen,

    um Backups anzulegen. Nehmen wir den Standardwert "12", legt unser Server 12 Backups an.

    Ein Backup fĂŒr jede Stunde bedeutet wir hĂ€tten z.B. von 1 Uhr bis 12 Uhr fĂŒr jede Stunde

    einen Speicherstand fĂŒr unseren Server. Das nĂ€chste Backup, welches also 13 Uhr angelegt wird,

    Überschreibt das erste und somit das Backup von 1 Uhr, usw....


    "backup_startup" = Backups nach Server Start


    Hiermit können wir dem Server ein Backup gleich nach dem Start bzw. dem ersten Respawn anlegen lassen.



    Dies war es fĂŒr den Ersten Teil. Jetzt kommen wir zum etwas interessanteren Part dieser Datei,

    denn wir können hier eigene Dateien und Pfade anlegen.

    Diese beschrÀnken sich zwar ein wenig, können aber vor allem bei Mods hilfreich sein,

    bei denen z.B. etwas in die Types.xml eingetragen werden mĂŒsste.

    Somit haben wir die Möglichkeit nicht laufend etwas in die Original Types.xml einzutragen

    sondern legen einfach eine eigene an, benennen den Pfad und mĂŒssen nach einem Update,

    welches die Originale ĂŒberschreibt, nicht laufend alles neu eintragen.


    Aber kommen wir erst mal zum Kern der Sache, denn wir können nur fĂŒr bestimmte Dateien einen Eintrag hinterlegen.

    Um dies ĂŒberhaupt möglich zu machen, mĂŒssen wir die cfgeconomycore.xml ein wenig erweitern.

    Dies machen wir relativ einfach, in dem wir am Ende einfach einen Zusatz anhÀngen,

    was am Ende und im Ganzen wie folgt aussehen sollte oder kann.



    Hier gilt es jetzt natĂŒrlich ein paar kleine Dinge zu beachten.

    Zu aller erst einmal mĂŒssen wir wissen, fĂŒr welche Dateien das ganze ĂŒberhaupt möglich ist,

    denn da haben wir folgende EintrÀge, die anstelle von "Datei Art" einzutragen sind:


    "types" fĂŒr eine "types.xml"

    "cfgspawnabletypes" fĂŒr eine "cfgspawnabletypes.xml"

    "globals" fĂŒr eine "globals.xml"

    "economy" fĂŒr eine "economy.xml"

    "events" fĂŒr eine "events.xml"

    "messages" fĂŒr eine "messages.xml"


    Dies kann z.B. im Falle einer von uns angelegten types.xml wie Folgt aussehen.

    (Ab jetzt nehme ich gekĂŒrzte Fassungen)


    Code
        </defaults>
    <ce folder="Ordner Name">
        <file name="Name neuer Types.xml" type="types" />
    </ce>
</economycore>


    Nun haben wir noch zu ĂŒberlegen, wie wir unser Dateichaos ggf. auf dem Server fĂŒr uns ansprechend anpassen können,

    um am Ende auch zu wissen, wo wir welche Datei abgelegt haben. Denn genau da ergeben sich uns die ersten Möglichkeiten.

    Wir können uns dafĂŒr entscheiden einen Ordner anzulegen, in den wir all unsere Dateien ablegen

    und diesem einen Namen geben. Die nÀchste Möglichkeit wÀre, einen schon bestehenden Ordner zu verwenden,

    welche sich in unserem Fall auf "db" und "env" beschrÀnken.

    Oder wir legen fĂŒr jede Datei oder Dateigruppe einen eigenen Ordner an.


    FĂŒr unser Beispiel nehmen wir einfach eine Waffen Mod, fĂŒr die wir 2 Dateien haben,

    eine types.xml und eine cfgspawnabletypes.xml, da diese wohl auch am meisten vertreten sind.

    Nun können wir uns zusĂ€tzlich noch fĂŒr einen neuen Namen entscheiden und mĂŒssen unsere nicht zwingend nur types.xml nennen.

    Wir benennen fĂŒr dieses Beispiel die Dateien einfach in Waffen_types.xml und Waffen_spawnabletypes.xml um.

    (Ich empfehle immer das types oder spawnabletypes irgendwie im Namen stehenzulassen, da sich die Dateien damit einfacher auseinander halten lassen)


    Nun haben wir unsere Dateien und entscheiden uns fĂŒr einen neuen Ordner, in dem wir beide Dateien ablegen.

    Diesen nennen wir einfach "Custom" und tragen den Namen natĂŒrlich unter "Ordner Name" ein.

    Am Ende sollte alles wie folgt aussehen.


    Code
        </defaults>
    <ce folder="Custom">
        <file name="Waffen_types.xml" type="types" />
        <file name="Waffen_spawnabletypes.xml" type="cfgspawnabletypes" />
    </ce>
</economycore>


    Nehmen wir an wir haben mehrere Mods, fĂŒr welche wir unterschiedliche Ordner anlegen wollen,

    mĂŒssen wir das Ganze ein wenig anpassen. DafĂŒr nenne ich unseren "Custom" Ordner in "Weapons" um,

    damit es fĂŒr unser Bsp. einfacher zum ErklĂ€ren wird 😅.

    Unsere neue Mod beinhaltet jetzt einfach neue Fahrzeuge,

    weshalb wir das Ganze am Ende folgendermaßen aussehen lassen können.


    Code
        </defaults>
    <ce folder="Weapons">
        <file name="Waffen_types.xml" type="types" />
        <file name="Waffen_spawnabletypes.xml" type="cfgspawnabletypes" />
    </ce>
    <ce folder="Vehicle">
        <file name="Auto_types.xml" type="types" />
        <file name="Auto_spawnabletypes.xml" type="cfgspawnabletypes" />
    </ce>    
</economycore>


    Wir mĂŒssen also das ganze wie man sehen kann, ein wenig trennen,

    damit das System weiß, welche Datei wo zu finden ist.


    Wollen wir alles in den schon vorhandenen "db" Ordner legen, sollte es also wie folgt aussehen,

    und hoffe, ich habe alle Möglichkeiten somit abgedeckt.


    Code
        </defaults>
    <ce folder="db">
        <file name="Waffen_types.xml" type="types" />
        <file name="Waffen_spawnabletypes.xml" type="cfgspawnabletypes" />
        <file name="Auto_types.xml" type="types" />
        <file name="Auto_spawnabletypes.xml" type="cfgspawnabletypes" />
    </ce>    
</economycore>


    So, das sollte es glaube ich hierfĂŒr aber auch gewesen sein.

    Ich hoffe, es ist nicht zu verwirrend und einigermaßen verstĂ€ndlich 😅.

    Damit sollten wir dann aber mit diesem Thema durch sein

    und können uns dem nÀchsten Thema widmen.

    Thema:



    cfgignorelist.xml


    Hier kommen wir mal zum, meiner Meinung nach, einfachsten und schnellste Thema.

    Zumindest davon ausgehend, dass tatsĂ€chlich und ĂŒberhaupt etwas in dieser Datei enthalten ist đŸ˜…đŸ€Ł.


    Kern dieser Datei ist eigentlich nur folgender Inhalt:



    Dabei handelt es sich im Grunde auch nur um eine Auflistung von Objekten,

    die vom Spiel oder Server nicht geladen und ignoriert werden sollen.

    Dabei ist es egal, ob diese Objekte irgendwo hinterlegt sind,

    sei es beim Start Gear, einfaches Objekt oder sonstiges.


    Die Liste kann ganz einfach weitergefĂŒhrt werden, wobei nur wichtig ist, dass nicht die Bezeichnung, sondern der Name des Objektes,

    welcher in der Config hinterlegt ist, einzutragen ist. Also nicht "BaseballschlÀger" sondern "BaseballBat".

    Ansonsten gilt einfach nur eine neue Zeile anlegen, Namen eintragen und fertig 😅.

    Simpel und einfach.


    Bsp.:

    .

    .

    .

    <type name="Wreck_Mi8"></type>

    <type name="BaseballBat"></type>

    </ignore>


    Schon gÀbe es keinen BaseballschlÀger mehr zu finden.


    Und das war es tatsÀchlich auch schon,

    Sag ja, ist nicht viel đŸ€Ł.


    Damit ab zum nĂ€chsten Part 😁


    Thema:



    cfglimitsdefinition.xml


    Kommen wir nun zu einem sehr wichtigen Aspekt, wenn es um die Loot Verteilung auf dem Server geht.

    Ich persönlich finde diesen abschnitt, sehr interessant,

    wenn er mit der types.xml und der mapgroupproto.xml kombiniert wird.

    Es kann zwar etwas kompliziert wirken und werden, aber gerade, wenn es darum geht,

    Server ein klein wenig einzigartig werden zu lassen, ist hier ein guter Anfang 😊.


    Aber wofĂŒr sind diese Datei denn eigentlich gedacht?

    Denn das ist relativ einfach zu beantworten, da es sich hierbei um eine Art "Loot Tag" Verzeichnis handelt.

    Hier legen wir die grundlegenden Klassifizierungen der einzelnen Loot Punkte fest.

    Ähnlich einem Supermarkt, in dem wir den Bereich "GemĂŒse" festlegen,

    damit Kunden, die unseren Supermarkt betreten, wissen, wo sie eben das "GemĂŒse" finden.

    Nur das hier eben dem Server gesagt wird, welche Bereiche es ĂŒberhaupt gibt,

    damit er am Ende weiß, was er wo ablegen bzw. spawnen darf.


    Aber erst mal wieder die Grunddatei, wie sie meist auf den Servern zu finden ist.


    Wie man sehen kann, ist alles in unterschiedliche Bereiche aufgeteilt

    und wir gehen dementsprechend erst einmal die einzelnen Bereiche durch,

    Bevor wir tiefer Graben 😅.


    Zu aller erst haben wir die "categories", welche genutzt wird,

    um Objekten spÀter eine Art Rolle zuzuweisen.

    Am Supermarkt Beispiel wÀren dies also die Oberkategorien unserer Ware.

    Hier haben wir einmal alle Vanilla "categories",

    denen ich auch ein paar Beispiele anhÀnge.


    name="tools" = Werkzeuge und VerbrauchsgegenstÀnde

    wie Hammer, Wecker, Angelhaken, Bandagen oder Messer

    name="containers" = Container wie Zelte, RucksÀcke und Kisten

    name="clothes" = Kleidung im allgemeinen

    name="lootdispatch" = Bezieht sich nur auf große Fahrzeugteile

    wie TĂŒren und Reifen

    name="food" = Lebensmittel im allgemeinen

    name="weapons" = Fernwaffen und zugehörige AusrĂŒstung

    wie Magazine, AufsÀtze und Munition

    name="books" = BĂŒcher (Momentan nicht vorhanden)

    name="explosives" = Sprengstoff wie Granaten oder Minen



    Als NĂ€chstes haben wir die "tags", welche festlegen,

    an welcher Stelle sie in unserem Supermarkt liegen können

    oder wir sie haben möchten.

    Also ob es z.B. große oder eher kleine Objekte sind

    oder diese eher an einem bestimmten Platz zu finden sind.


    name="floor" = Fußboden und große Objekte

    wie Fahrzeuge, FĂ€sser, Kisten oder auch Schuhe (Wer mag die auch auf nem Tisch đŸ˜…đŸ€Ł)

    name="shelves" = Regale, Tische und eher kleinere Objekte

    wie Streichhölzer, Taschenlampen oder einzelne Munition bis hin zu z.B. MĂŒtzen

    name="ground" = Boden (wird momentan nicht genutzt)



    Im etwas grĂ¶ĂŸeren abschnitt haben wir die "usageflags",

    welche uns an unserem Supermarkt Beispiel unsere Abteilungen darstellen.

    Nur sind es eben nicht Hygiene, Artikel oder die KĂŒhlabteilung,

    sondern Bereiche, die eine Art sozialen Aspekt abdecken

    und dafĂŒr sorgen, dass beispielsweise Polizeiuniformen

    nicht in SchulgebÀuden, sondern eben in den Polizeiwachen spawnen.

    Die nachfolgenden Bereiche werde ich jetzt nicht mit Beispielen

    abdecken, da es eher um die logische Assoziation geht,

    wie die oben beschriebene Polizeiuniform.


    name="Military" = MilitÀr

    name="Police" = Polizei

    name="Medic" = Medizin

    name="Firefighter" = Feuerwehr

    name="Industrial" = Industriell

    name="Farm" = Landwirtschaft

    name="Coast" = KĂŒste

    name="Town" = Stadt

    name="Village" = Dörfer und KleinstÀdte

    name="Hunting" = Jagd

    name="Office" = BĂŒro

    name="School" = Schule

    name="Prison" = GefÀngnis

    name="Lunapark" = Freizeitpark

    name="SeasonalEvent" = Saison bedingte Events

    name="ContaminatedArea" = Kontaminierte Zonen

    name="Historical" = Orte mit historischem Hintergrund



    Als Letztes hÀtten wir jetzt noch die "valueflags",

    welche die Zonen der Karte bzw. eine Art Schwierigkeitsstufe darstellen.

    Auch hier kann man wieder unseren Supermarkt als Beispiel nehmen

    und das ganze als eine Art Preisklasse sehen.

    Somit hÀtten wir die "Billigprodukte" bis hin zu den teuren "Markenprodukten"

    und sogar die "Wochenendangebote" đŸ€Ł.


    name="Tier1" = Zone / Stufe 1

    name="Tier2" = Zone / Stufe 2

    name="Tier3" = Zone / Stufe 3

    name="Tier4" = Zone / Stufe 4

    name="Unique" = Einzigartige oder besondere Zonen / Orte



    Diese ganzen Definitionen sind spÀter wichtig, um dem Spiel zu sagen oder zu zeigen,

    woran es sich fĂŒr die einzelnen Objekte orientieren kann.

    Es dient aber nicht nur dem Spiel, sondern eben auch dem ganzen Spielfluss.

    Damit wir als Spieler ein wenig wissen, wonach wir suchen mĂŒssen, oder besser gesagt,

    wo wir suchen mĂŒssen.

    Denn logischerweise wissen wir dadurch, dass eben militÀrischer Loot auch in militÀrischen

    GebĂ€uden oder Ă€hnlichem suchen mĂŒssen.

    Selbes trifft eben auch auf Zivilkleidung zu, die wir eben nicht in MilitÀrgebÀuden finden,

    sondern eben in StĂ€dten und Dörfern. DafĂŒr eben "Military", "Town" oder "Village".


    Nun, da wir unseren Supermarkt aber eingerichtet haben... đŸ˜œđŸ€ŁđŸ˜…

    nein Spaß, ich hoffe nur das bis hier hin so weit alles VerstĂ€ndlich war,

    denn jetzt kommen wir zu dem interessanten Teil,

    da es sich im Grunde nur um die Vanilla und Entwickler Einstellungen handelt.

    Wir können das ganze beliebig anpassen und erweitern, sollten aber bedenken,

    dass es nicht nur hier, sondern auch in anderen Dateien angepasst werden muss.

    Darunter zÀhlen die types.xml und die mapgroupproto.xml.


    Im Grunde ist es fĂŒr diesen Bereich oder diese Datei relativ simpel.

    Man sollte sich vorerst natĂŒrlich darĂŒber Gedanken zu machen, wie wir unseren neuen Eintrag nennen wollen.

    Es sollte sich zum einen von den anderen abheben und fĂŒr uns auch nachvollziehbar sein,

    um diesen spÀter auch wiederzuerkennen.

    Es empfiehlt sich also immer ein Textdokument oder Àhnliches, bei dem ihr euch Notizen machen könnt.


    Ich nehme fĂŒr dieses Bsp. die neue Kategorie "Supermarket" und möchte damit erreichen,

    dass Lebensmittel nur noch in den SupermÀrkten von Chernarus auftauchen.

    DafĂŒr tragen wir nun einfach unsere neue Kategorie in die "usageflags" ein,

    was im gesamten am Ende so aussehen sollte.


    GlĂŒckwunsch,

    wir haben einen neuen sozialen Bereich geschaffen đŸ€Ł.

    Mehr ist es erst mal nicht, denn hier kommt es natĂŒrlich darauf an,

    wie ausgeprÀgt man das ganze gestalten möchte. Vorweg sei aber auch gesagt,

    dass es zu Komplikationen kommen kann, wenn zu viele EintrÀge vorgenommen werden.

    Dadurch kann es passieren, dass auf Dauer das ganze System darunter leidet,

    der Server zu viel beachten und berechnen muss

    und am Ende wieder die Performance darunter leidet.

    Um in der Reihenfolge zu bleiben, machen wir fĂŒr den nĂ€chsten Abschnitt

    am Ende der types.xml weiter 😊.


    Damit sollte es aber fĂŒr dieses Thema erst einmal gewesen sein

    und hoffe wie immer das man sich beim nĂ€chsten Thema wieder sieht 😊.

    Thema:



    cfglimitsdefinitionuser.xml


    Kommen wir hier zu einem wahrscheinlich auch relativ kurzen Thema.

    Bevor wir aber wieder weiter darauf eingehen, erst mal wieder die Grunddatei und schon mal vorweg,

    ich habe es bisher noch nicht getestet. Das bedeutet, dass es in erster Linie um die Theorie geht.

    Wenn ich tatsĂ€chlich einen Test durchfĂŒhre, werde ich das ganze natĂŒrlich nochmal nachtragen 😊.


    Aber fangen wir an.



    Kommen wir als nĂ€chstes erst einmal zu einem sehr wichtigen Punkt, der fĂŒr die Types.xml, die Events.xml oder jede andere Datei wichtig ist.

    Die Anzahl der Zeilen in den Dateien belĂ€uft sich auf ein Maximum von rund 50000 oder 5 MB. Dies hatte wohl vorsorglich dazu gefĂŒhrt,

    dass man sich Mittel und Wege einfallen lassen musste, um Platz in Dateien zu sparen.

    Somit ist diese Datei, noch einmal in etwa dieselbe, wie die cfglimitsdefinition.xml.

    Der Unterschied besteht darin, dass die in der cfglimitsdefinition.xml definierten "name" oder Wert als Grundlage dienen

    und hier mehr oder weniger in Gruppen eingeteilt werden.


    Als Bsp. nehmen wir einfach "Town" und "Village".

    Diese sind in der cfglimitsdefinition.xml einzeln aufgefĂŒhrt und werden spĂ€ter auch in dertypes.xml fĂŒr ein Objekt definiert,

    damit dieses eben in diesen definierten Regionen oder Loot Punkten spawnt.

    Damit eben dieser Platz gespart wird, da es im Regelfall jede Definition

    eine eigene Zeile hat, hat man diese kombiniert und wir haben "TownVillage".


    FĂŒr Diejenigen, die sich fragen, warum man dies denn ĂŒberhaupt macht, muss man Verstehen,

    dass bei der Spielentwicklung jeder MB zÀhlt. Damit entweder Platz auf DatentrÀgern (jeglicher Form)

    gespart wird, oder um Downloads so klein wie möglich zu halten.

    An sich klingt es nach nicht viel, da es genau genommen ja auch nur 2 Wörter und somit 2 Zeilen sind.

    Es kommt aber in solchen FĂ€llen auf die Masse an, denn berĂŒcksichtigt man das 2 Zeilen

    unter 1000 Objekten steht, sind es eben 500 Zeilen, die man sich sparen könnte.

    So kann man sich in etwa hochrechnen, wie viel es am Ende doch ausmachen kann.


    Kommen wir nun aber noch schnell zurĂŒck zum Thema, denn im Grunde werden hier nur die einzelnen

    Werte hier nur noch einmal ein wenig zusammen gelegt.

    Somit haben wir wie oben schon beschrieben die "usageflags" fĂŒr die "usage" (Verwendung) der Umgebungstypen.



    Definiert wird hier eben nur, eine Art neue Oberklasse, die die Klassen der cfglimitsdefinition.xml beinhaltet.


    Selbiges gilt also auch fĂŒr die "Tier" Zonen 1 bis 4. Bei diesen wird es nur nicht als "usage" sondern als "value" (Wert) angegeben.



    Auch hier wird wie oben aus z.B. "Tier1" und "Tier2" eben "Tier12" gemacht.


    Somit könnte man also alle in der Types.xml enthaltenen Objekte diesen Werten anpassen.

    Um das ganze mal ein wenig herunterzubrechen, schmeiße ich mal ein paar Werte in den Raum

    um das Prinzip an der Vanilla Types der 1.26 zu zeigen.

    Diese besitzt insgesamt 23501 Zeilen ohne die entsprechende Anpassung.

    Mit den oben angegebenen Anpassungen, hÀtte die Types nur noch 22745 Zeilen,

    insofern ich alles auf die schnelle erwischt habe 😅.


    Man kann dies natĂŒrlich noch nach Belieben erweitern und anpassen.

    Je nach Bedarf oder Belieben können wir z.B. noch "Military" und "Police" hinzufĂŒgen,

    was am Ende wie folgt, aussehen könnte.



    Jetzt hÀtten wir am Ende nur noch 22723 Zeilen und könnten dies nach Belieben fortsetzen.

    Ich hoffe, dies war soweit verstÀndlich und versteht das Prinzip dieses Systems.


    Damit sollte glaube ich, aber auch dieses Thema fertig und abgehakt sein 😁.


    Womit wir also zum NĂ€chsten ĂŒbergehen können 😊.

    Thema:



    types.xml


    Herzlich willkommen zu einem der wichtigsten Punkte unserer Reise,

    denn hier legen wir fest, welches Objekt wo spawnen darf.

    Und nicht nur das, wir legen hier ebenso die Anzahl fest, wie einzigartig es sein kann,

    indem wir z.B. festlegen, dass es ein Objekt nur bis zu einer bestimmten Anzahl auf der Karte existieren darf.

    Und auch sehr wichtig, da die Frage schon sehr oft gestellt wurde, die Lebensdauer der Objekte.

    Und damit sind nicht die Lebenspunkte gemeint 😅.


    Aber fangen wir mal wie immer mit der Grunddatei an, die ich hier natĂŒrlich nicht komplett eintragen werde.

    Es sprengt sonst einfach den Rahmen, wenn man hier die Komplette Types eintrĂ€gt đŸ€Ł.

    Ich werde mir einfach ein paar Objekte aussuchen, da es auch hier ein paar kleine Details zu Arten

    und Verwendungszwecken von Objekten gibt.

    Grundlegend sind sie natĂŒrlich alle gleich, aber am Ende hoffe ich, wird jeder den Unterschied verstehen

    und auch das, was ich damit genau meine.


    Als Beispiele nehme ich aber jeweils eines und gehe anschließen auch einzeln darauf ein.


    Erstmal ein normales Objekt, was auch gleich als Grundlage dient, da wie schon gesagt,

    im Kern alle gleich sind. Daher wird dies auch das Hauptbeispiel sein.



    Gefolgt von einem Herstellbaren Objekt und einem Basenbau Objekt.



    Als NĂ€chstes nehmen wir uns ein Fahrzeug und auch gleich ein Fahrzeugteil.



    Als NĂ€chstes kommen wir zu einem Infizierten Bzw. einem KI-Objekt, da Tiere dasselbe nur in lebend sind đŸ€Ł.


    Code
        <type name="ZmbF_ParamedicNormal_Blue">
        <nominal>0</nominal>
        <lifetime>1800</lifetime>
        <restock>0</restock>
        <min>1</min>
        <quantmin>-1</quantmin>
        <quantmax>-1</quantmax>
        <cost>100</cost>
        <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="0" deloot="0"/>
    </type>


    Jetzt haben wir noch ein Event, Bzw. dynamisches Objekt.



    In der Hoffnung, ich habe nichts vergessen, sollten dies so weit alle Objekttypen sein,

    womit wir auch gleich zu den Grundkenntnissen anhand des einfachen Objektes kommen.

    DafĂŒr mĂŒssen wir natĂŒrlich auch die einzelnen Zeilen verstehen und wissen,

    wofĂŒr diese eigentlich gedacht sind.

    Wer möchte, kann natĂŒrlich auch gerne nochmal im Post Beschreibung Types.xml nachlesen.

    Fangen wir aber an und fackeln nicht lange 😅.


    Als Erstes haben wir immer "<type ", was fĂŒr die AufzĂ€hlung der Objekte wichtig ist

    und damit das Spiel weiß, wann die Einstellungen fĂŒr ein Objekt anfangen und wo diese aufhören.

    Anschließend kommen die einzelnen Zeilen mit ihren entsprechenden Werten.


    name="BakedBeansCan" = Name des Objektes aus den "Config" Einstellungen


    Das bedeutet also, hier wird nicht eingetragen, wie das Objekt an sich heißt.

    Also nicht "Gebackene Bohnen in der Dose" sondern eben "BakedBeansCan",

    da dies der Name des Objektes ist und nicht wie es fĂŒr wen in der entsprechenden NationalitĂ€t heißt 😅.


    nominal>15</nominal = Maximale Anzahl des Objektes, wenn Platz vorhanden ist


    Hiermit wird also die maximale Anzahl und kein Durchschnittswert angegeben (in diesem Fall 15).

    Nach oben sind hier keine Grenzen gesetzt, zumindest nicht im eigentlichen sinne.

    Wichtig ist hier nĂ€mlich zum einen der Platz auf dem Server, da dieser versucht die gewĂŒnschte Menge

    spawnen zu lassen. Am Supermarkt Beispiel könnte man sagen, wir hĂ€tten ein Regal, in dem 15 Äpfel liegen.

    Nimmt ein Kunde einen dieser Äpfel mit, kommt ein Mitbarteiter und legt einen neuen hin,

    damit wieder 15 Äpfel verfĂŒgbar sind. Solange wir in das Regal natĂŒrlich auch nichts anderes hinein legen.

    Denn darauf kommt es natĂŒrlich auch noch an. Nehmen wir einen Apfel weg und legen dafĂŒr etwas anderes in das Regal,

    können wir natĂŒrlich keinen mehr hineinlegen.

    Liegt der Wert bei 0, wird auf normalem Wege das Objekt nicht gespawnt, wobei eben hier die Betonung auf "Normal" liegt.

    Denn alle in "nominal" eingetragenen Werte beziehen sich immer auf den Dynamischen Loot.

    Wer es also bemerkt hat, hat feststellen können, dass eben bei KI, Fahrzeugen oder anderen Objekten der Wert "0" eingetragen ist.

    Da der Server natĂŒrlich eine Types fĂŒr Objekte benötigt, muss es darin enthalten sein. Soll es aber nicht auf natĂŒrliche weise spawnen,

    wird eben der Wert auf "0" gesetzt um dies zu verhindern.

    Wichtig ist hierbei auch noch, dass andere Dateien unabhÀngig von der types.xml arbeiten. Selbst wenn wir unserer Dose den Wert "0" geben,

    sie aber in z.B. der cfgspawnabletypes.xml als Beute in einen Infizierten packen,

    wird der Infizierte diese auch haben. Somit kann man also z.B. bestimmten Loot tatsĂ€chlich nur als TrophĂ€e fĂŒr das Töten von Infizierten festlegen.


    lifetime>14400</lifetime = Maximale Lebenszeit eines Objektes auf dem Server in "s"


    Hier wird mit einem Wert die Lebensdauer in Sekunden festgelegt, wie lange ein Objekt maximal auf dem Server verweilen darf,

    bevor es despawnt wird.

    Dies bezieht sich aber hauptsÀchlich auf Objekte, mit denen interagiert wurde. Auch wenn sich hier wie bei vielen Dingen die Geister streiten.

    Wir haben gelernt, dass es Einstellungen gibt, die dem Server sagen, wann er Loot despawnen soll oder kann, was also an sich bedeutet,

    dass, wenn wir diese Dose sehen, aber nicht mitnehmen, sondern uns von dieser entfernen, bis sie nicht mehr in unserer Spieler Blase ist,

    oder wir uns sogar ausloggen, diese auch schon nach einer Stunde verschwunden sein kann.

    Hatten wir sie in der Hand, wĂŒrde sie fĂŒr 14400 s, also 4 Stunden auf dem Server liegen, wenn wir sie natĂŒrlich einfach nur auf den Boden legen.

    Ein Fass steht leider nach dem Spawnen nicht immer 45 Tage an derselben Stelle, da mĂŒsste ich leider ein Veto einlegen,

    da ich schon FĂ€sser oder allgemein Objekte hatte, die in der Theorie hĂ€tten, lĂ€nger an einem Ort stehen bleiben mĂŒssen,

    es aber nicht getan haben. Ist halt blöd, wenn man sich darauf verlÀsst, sich PlÀtze markiert, etwa 10 Tage spÀter diese dann abklappert

    aber nur noch rund die HĂ€lfte tatsĂ€chlich da ist. Und das bei einem Server fĂŒr nur eine Person đŸ€Ł.

    Es war niemand da, der hĂ€tte klauen können 😅.

    Der Server merkt letztendlich, ob sich in gewissen Gebieten Spieler bewegen und verteilt den Loot dementsprechend auch gern vor Ablauf der Lifetime neu.

    Im Grunde ist es nicht wirklich richtig, aber auch nicht wirklich verkehrt, da der Server ein gewisses Eigenleben besitzt 😂.

    Des Weiteren gilt hier natĂŒrlich auch, dass die Lifetime sich nur auf Objekte bezieht, die auf dem Boden liegen oder unter UmstĂ€nden auch mal in der Luft hĂ€ngen 😅.

    Also eben nicht fĂŒr Objekte im Charakterinventar oder in irgendeinem Inventar. Es zĂ€hlt eben immer das Objekt, welches Ihr auf den Boden legt.

    Legt ihr eine Hose in z.B. einen Schutzkoffer bleibt dieser natĂŒrlich fĂŒr 45 Tage liegen und beinhaltet auch die Hose die 45 Tage.

    Legt Ihr den Koffer in die Hose, ist beider nach 4 Stunden verschwunden, da die Lifetime der Hose zĂ€hlt đŸ€Ł.

    Ein ebenso wichtiger Aspekt ist der Ruhemodus eines Servers. Gerade bei Servern, die eventuell nur mal fĂŒr eine kleine Runde zu zweit oder alleine sind,

    kann es vorkommen, dass nach dem Ausloggen der Server in den Ruhemodus fÀllt und erst wieder richtig hoch fÀhrt, wenn sich jemand auf diesem einloggt.

    Das kann unter UmstĂ€nden dazu fĂŒhren, dass Objekte auch gern mal eine Woche an einem Platz liegen, obwohl sie hĂ€tten verschwinden mĂŒssen.

    Dies weiß ich tatsĂ€chlich aus eigener Erfahrung und fiel mir auf einem kleinen Test Server auf, als wir eine Maske aufgesammelt haben,

    und diese 5 Tage spÀter immer noch an derselben Stelle lag. In der Zwischenzeit war niemand auf dem Server und direkt ausgeschaltet

    oder herunter gefahren hat ihn auch niemand. Entweder war es ein dummer Zufall, oder wieder der Beweis fĂŒr das Eigenleben eines Servers 😅.


    restock>0</restock = Timer in "s" fĂŒr das AuffĂŒllen des Objektes


    Dies ist eigentlich relativ simpel erklÀrt, denn wie der Name schon sagt, ist es nur ein Timer der ablÀuft

    und dem Server erlaubt, das Objekt mit der "nominalen" Anzahl wieder zu fĂŒllen.

    Nehmen wir wieder unseren Supermarkt und Apfel als Beispiel, bedeutet es, dass unser Mitarbeiter z.B. bei einem Wert von "1800", 30 Min. Zeit hat,

    bis er einen neuen Apfel in das Regal legt. Dabei wird der Timer fĂŒr jedes und nicht fĂŒr alle Objekte festgelegt.

    Das bedeutet im Grunde nur, wenn wir alle 10 min einen Apfel nehmen, wĂŒrde unser Mitarbeiter nach dem 3 Apfel wieder einen neuen in das Regal legen dĂŒrfen,

    da fĂŒr den ersten die 30 min schon vorbei sind.

    Bei dem Wert "0" wird das Objekt eben sofort irgendwo nach gespawnt.


    min>12</min = Minimale Anzahl des Objektes


    Erst einmal vorweg, auch wenn es einen "min" Wert gibt, es gibt keinen "max" Wert, da "nominal" den maximalen Wert darstellt.

    Aber wie Minimal schon sagt, wird hier eben die minimale Anzahl eines Objektes festgelegt.

    Wird dieser Wert unterschritten, wird der Server versuchen diesen umgehen bis zu diesem Wert wieder aufzufĂŒllen.

    Wenn wir in unserem Markt also sagen, dass wir immer 10 Äpfel in unserem Regal liegen haben,

    wĂŒrde unser Mitarbeiter also umgehend lossprinten und einen Apfel holen, sobald nur noch 9 in unserem Regal liegen,

    sogar ungeachtet vom "restock" Wert.

    NatĂŒrlich ist oder wĂ€re es bei einem "restock" wert von 0 egal, da unser Apfel Regal in solch einer Situation immer wieder aufgefĂŒllt wird,

    sobald jemand einen nimmt. Allerdings darf man hier nicht vergessen, dass unser Mitarbeiter nicht die ganze Schicht ĂŒber an einem Regal steht.

    Zum anderen kann es natĂŒrlich auch passieren, dass je nach Loot und Spieler Bubble Objekte in hohen Mengen gleichzeitig aufgesammelt werden.


    quantmin>-1</quantmin = Minimale FĂŒllmenge Objekt

    quantmax>-1</quantmax = Maximale FĂŒllmenge Objekt


    Hierbei handelt es sich um den Inhalt, die Aufladung oder die Menge bei Objekten, die dies eben als Voraussetzung haben.

    Es ist nicht der Schaden an einem Objekt, sondern beispielsweise die FĂŒllmenge an Wasser,

    die eine Plastikflasche beim spawnen beinhalten kann.

    Der Wert, den wir eintragen können, wird in "%" angegeben, was also bei einer Flasche mit einem Liter Fassungsvermögen bedeuten kann:

    quantmin>25</quantmin = 250ml

    quantmax>100</quantmax = 1000ml bzw. 1l

    Selbes kann man beispielsweise auf einzeln spawnende Munition anwenden. Da diese meist in etwa 25 Patronen beinhalten,

    wĂŒrde es eben wie folgt aussehen:

    quantmin>10</quantmin = 3 Patronen (Es wird aufgerundet)

    quantmax>80</quantmax = 20 Patronen

    Und genau da sind wir eben wie schon angesprochen wieder bei der guten alten Mathematik, denn hier haben wir unter UmstĂ€nden ein kleines Problem 😅.

    Denn wer beispielsweise auf seinem Server die Stack-GrĂ¶ĂŸen erhöht, sollte auch hier die entsprechenden Anpassungen vornehmen.

    Beispielsweise hĂ€tten wir beim gleichen min. oder max. Wert und einer maximalen StapelgrĂ¶ĂŸe von z.B. 250 Patronen folgendes Problem:

    quantmin>10</quantmin = 25 Patronen

    quantmax>80</quantmax = 200 Patronen

    Die Stapel, die wir finden, wĂŒrden sich eben immer zwischen 25 und 200 Kugeln befinden,

    was in solch einem Falle sĂ€mtliche Munitionsboxen ĂŒberflĂŒssig machen wĂŒrde 😅.

    Wird der Wert mit "-1" angegeben, betrĂ€gt die FĂŒllmenge 0 und wird daher nur bei Objekten genutzt, welche eben keine haben,

    also Kleidung, Waffen, etc....


    cost>100</cost = PrioritÀt


    Hiermit können wir festlegen, wie hoch die PrioritĂ€t fĂŒr das spawnen eines Objektes sein soll,

    Also, ob es beispielsweise vor anderen Objekten spawnen soll.

    Hier kann man es auch wieder relativ gut und einfach mit dem Supermarkt erklÀren und z.B. sagen,

    unsere Äpfel hĂ€tten eine PrioritĂ€t von 100 und Birnen nur von 50.

    WĂŒrde ein Kunde jeweils von beiden ein paar mitnehmen,

    wĂŒrde unser Mitarbeiter eben vorrangig wieder unsere Äpfel auffĂŒllen.


    flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="0" deloot="0"/>


    Hier haben wir verschieden Möglichkeiten, unseren Objekten ein paar kleinere Eigenheiten zu verpassen.

    Diese werden entweder mit "1" aktiviert oder mit "0" aktiviert.

    Es handelt sich dabei hauptsĂ€chlich um das ZĂ€hlen von Objekten, also ob beim BerĂŒcksichtigen des nominal Wertes

    bestimmte Objekte z.B. im Inventar berĂŒcksichtigt werden sollen.

    Gehen wir aber alle wieder einzeln durch.


    count_in_cargo="0" = berĂŒcksichtigen von Objekten in Objekten


    Hier zÀhlen nur einfache Objekte oder Objekte die stÀndig in Bewegung sind und

    nicht grundlegend fĂŒr Basen oder zum Horten gedacht sind.

    Darunter zÀhlt Kleidung, RucksÀcke oder beispielsweise Fahrzeuge.

    Anhand von Einstellungen könnte man sagen, dass es alle Objekte betrifft,

    die keine Lebensdauer von 45 Tagen haben.

    Fahrzeuge sind leider etwas anderes, da diese grundlegend erst eine Lebensdauer haben,

    wenn ein Spieler damit interagiert hat.


    count_in_hoarder="0" = berĂŒcksichtigen von Objekten in Containern oder BehĂ€ltern


    Hierbei handelt es sich wiederum um eben die genannten Basen Objekte.

    Alles was fĂŒr einen lĂ€ngeren Zeitraum auf der Karte stehenbleibt und sich wieder

    auf die 45 Tage bezieht. Darunter zÀhlen FÀsser, Kisten oder Zelte.


    count_in_map="1" = berĂŒcksichtigen von Objekten auf der Karte


    Damit sagen wir, ob Objekte, die bereits auf der Karte existieren, mit berĂŒcksichtigt werden sollen.

    Dieser Einstellung sollte grundlegend auf "1" gelassen werden,

    da sonst der Server vom Objekt ĂŒberflutet wird 😅.

    Im Grunde wĂŒrden wir unserem Mitarbeiter eine Augenbinde umlegen und eine Kiste Äpfel hinstellen,

    die er blind reinfeuert đŸ€Ł.


    count_in_player="0" = berĂŒcksichtigen von Objekten im Spielerinventar


    Wie die anderen auch, wird hier nur festgelegt, ob Objekte, die der Charakter bei sich trÀgt mitgerechnet werden soll.

    Dabei werden nur Charaktere gezÀhlt, die sich auf der Map befinden.

    Sobald sich ein Charakter mit einem entsprechendem Objekt ausloggt,

    wird der Server das nach einem gewissen Zeitraum merken und diese Objekte auch wieder nach spawnen.

    Es wÀre ja sonst ein wenig irrational, wenn sich ein Spieler auf Servern einloggt, sÀmtliche Objekte einsammelt,

    diese anschließend auf einem anderen Server hortet, wĂ€hrend auf allen anderen nachher das Objekt nicht mehr spawnt 😅.

    Gleiches gilt aber auch wieder andersherum.

    Hat ein Spieler 1 oder mehrere von diesem Objekt bei sich und loggt sich auf einem anderen Server ein,

    wĂŒrde auch hier das spiel wieder zĂ€hlen und merken, dass zu viele oder die max. Anzahl dieses Objektes erreicht sind.

    Dementsprechend wĂŒrden nach dem de spawnen der Objekte diese nicht mehr nach spawnen,

    da der Charakter diese bei sich trÀgt.


    crafted="0" = Herstellbares Objekt


    Mit dieser Einstellung legen wir fest, ob ein Objekt herstellbar ist.

    Dabei sollte man 2 Dinge unterscheiden, bevor es zu MissverstÀndnissen kommt.

    Legen wir hier den Wert "1" fest, wĂŒrde das Objekt nicht spawnen, da wir festlegen, dass es eben ein Herstellungsobjekt ist.

    Haben wir hingegen ein Objekt, was wir zwar herstellen können, aber dennoch in der Welt zu finden sein soll,

    muss hier der Wert "0" angegeben werden.

    Nur weil ein Objekt eben herstellbar ist, mĂŒssen wir hier nicht zwingend den Wert mit "1" anpassen,

    da wir eben sonst dafĂŒr sorgen, dass es eben nicht mehr in der Welt zu finden ist.


    deloot="0" = "d" Dynamischer "e" Event Loot


    Hier können wir im Prinzip bestimmen, ob unser Objekt nur bei Events spawnen soll.

    Dazu zĂ€hlen z.B. Helikopter AbstĂŒrze, Polizei Events wie Straßensperren oder Konvois.

    Setzen wir unseren Wert hier auf "1", wird unser Objekt nur an solchen Events auftauchen

    und nicht wie normaler Loot irgendwo auf der Karte zu finden sein.



    Soweit so gut,

    Jetzt kommen wir noch zu unserem Supermarkt Prinzip, welches wir in der cfglimitsdefinition.xml (= Link: Thema: cfglimitsdefinition.xml) gelernt haben,

    da mit dem nÀchsten Abschnitt festgelegt werden kann, wo unser Objekt spawnen kann.


    DafĂŒr haben wir wieder die "category", den "tag", die "usage" und die "value".

    Da ich diese in der cfglimitsdefinition.xml (= Link: Thema: cfglimitsdefinition.xml) schon erklĂ€rt habe, werde ich hier jetzt nicht nochmal alle auflisten, wenn das OK ist 😅,

    sondern werde es nur an bisherigen Objekt, der "BakedBeansCan", noch einmal kurz und knapp erklÀren.

    Da haben wir nun folgende Einstellungen.


    category name="food"/>

    tag name="shelves"/>

    usage name="Town"/>

    usage name="Village"/>

    value name="Tier1"/>

    value name="Tier2"/>

    value name="Tier3"/>


    Es wurde also festgelegt, dass das Objekt an Orten spawnen darf, an denen Nahrung (food) erlaubt ist.

    Das Objekt soll wenn möglich nicht auf dem Boden, sondern in Regalen oder auf Tischen (shelves) spawnen

    und ist in Dörfern (Village) und in StÀdten (Town) der Schwierigkeitsstufen oder Zonen 1 bis 3 (Tier1 - Tier3) zu finden.


    Wer aber noch die ersten Zeilen dieses Posts im Kopf hat,

    wird sich abgesehen von den "BakedBeansCan" noch an die "BakedBeansCan_Opened" erinnern.

    Denn ab hier kommen wir zu den Abweichungen, Eigenheiten, Unterschieden und Besonderheiten spezieller Objekte.

    Da wir aber nun die Grundlagen kennen, können wir auch hier ein wenig tiefer tauchen

    und fangen auch gleich mit der "BakedBeansCan_Opened" an, da es sich hierbei um ein hergestelltes Objekt handelt.



    ZusÀtzlich hÀnge ich hier auch gleich noch einmal die Basenbau Objekte an,

    damit hier ggf. auch gleich noch einmal verglichen werden kann 😅.



    Was genau ist der Unterschied zu herkömmlichen Objekten?

    Bei Herstellbaren Objekten, wird zum einen kein "nominal" und auch kein "min" Wert benötigt,

    da das Objekt weder spawnt noch eine dementsprechende Spawn Anzahl braucht.

    Zum anderen sehen wir, die schon oben erwÀhnte Einstellung "crafted" mit dem Wert "1",

    was dem Server sagt, dass dieses Objekt eben ein Herstellungsobjekt ist und nicht gespawnt werden soll.

    Die "lifetime" der Objekte ist wie wir sehen unterschiedlich und sorgt trotz allem dafĂŒr,

    dass unser hergestelltes Objekt, nach dem wir es im Prinzip erschaffen haben,

    nach einer gewissen Zeit wieder verschwindet oder wie im Falle des "Watchtower",

    fĂŒr einen lĂ€ngeren Zeitraum auf dem Server verweilen kann.

    Da wir unser Objekt im Prinzip aber erschaffen und nicht spawnen lassen,

    benötigen wir weder einen "restock", einen "quantmin" oder "quantmax" Wert.

    Eben sowenig benötigen wir die "cost" Einstellung, noch die einzelnen Angeben,

    wo das Objekt auftauchen bzw. spawnen darf.

    Mit diesem Wissen, könnte unsere Type fĂŒr alle 3 Objekte auch folgendermaßen geschrieben werden,

    ohne, dass es das Spiel oder den Server stören sollte.


    Code
        <type name="BakedBeansCan_Opened">
        <lifetime>9000</lifetime>
        <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="1" deloot="0"/>
    </type>
    Code
        <type name="WatchtowerKit">
        <lifetime>14400</lifetime>
        <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="1" deloot="0"/>
    </type>
    <type name="Watchtower">
        <lifetime>3888000</lifetime>
        <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="1" deloot="0"/>
    </type>


    Wie auch schon im Thema cfglimitsdefinitionuser.xml angesprochen,

    haben die Dateien ein Limit von Zeilen und GrĂ¶ĂŸe, weshalb ich nicht ganz weiß,

    warum man diese Objekte nicht von Haus aus so schreibt, um eben Platz zu sparen.

    Aber das soll nicht unser Problem sein.

    Getestet habe ich das ganze auf einem Àlteren Server und der lief mit diesen AbÀnderungen ohne Probleme.

    Werder sind irgendwo WachtĂŒrme gespawnt, noch sind sie einfach verschwunden.

    Es lief so, wie es eben laufen sollte, wĂŒrde aber trotz des Wissens empfehlen,

    die Vanilla Einstellungen zu behalten. Wer natĂŒrlich möchte, kann es gern ausprobieren

    und wir gehen derweil zu den Fahrzeugen, da es auch hier ein paar Besonderheiten gibt.

    DafĂŒr natĂŒrlich noch einmal der Grundaufbau und danach ÂŽschauen wir uns das genauer an.



    Hier mĂŒssen wir das ganze aber ein wenig aufteilen und nehmen uns erst einmal das Fahrzeug vor.

    Da diese als Event funktionieren, haben wir hier schon einmal die Abweichung des "nominal" und "min" Wertes.

    Dieser wird hier mit "0" angegeben, da Fahrzeuge ihre Werte fĂŒr die Anzahl aus der Events.xml (= Link: Thema: events.xml) beziehen.

    Dadurch sind die hier eingetragenen Werte wieder ĂŒberflĂŒssig. Wir sind also wieder bei "Könnte man sich eigentlich sparen, aber naja".

    Als NĂ€chstes haben wir wieder die "lifetime", welche mit "3" angegeben ist.

    Nun ist es aber im Grunde so, dass Fahrzeuge eine Lebensdauer haben, die nicht an irgendwelchen Dateien gemessen wird,

    sondern haben in der Regel eine festgelegte Lebensdauer von "3888000" bis unendlich.

    Somit muss und brauch dieser Wert auch keinerlei Anpassungen, da es keinerlei VerĂ€nderungen mit sich bringen wĂŒrde.

    Anders wird es NUR, wenn wir mit Mods wie z.B. HĂ€ndlern arbeiten, da diese tatsĂ€chlich die Lebenszeit aus der Types.xml ĂŒbernehmen.

    Damit Fahrzeuge aber nicht an irgendwelchen WegesrÀndern versauern, hat auch hier zum einen unser Server sein Eigenleben

    und zum anderen haben wir noch die Events.xml (= Link: Thema: events.xml) zu der wir natĂŒrlich spĂ€ter kommen.

    Selbes gilt natĂŒrlich auch fĂŒr den "restock" Wert und die "cost", so wie fĂŒr "quantmin" und "quantmax".

    Wichtig ist allerdings die Einstellung "count_in_map", da hier gesagt wird, dass eben jenes Fahrzeug auf der Karte mit gezÀhlt werden soll,

    um nicht permanent neue Fahrzeuge spawnen zu lassen. Daher sollte dieser Wert auch immer auf "1" gestellt sein.


    Bei unserem Fahrzeugreifen (Hatchback_02_Wheel) handelt es sich zwar wiederum um ein normales Objekt,

    welches aber nicht auf herkömmliche Art spawnt.

    Dies nennt man in der Regel einen "proxy spawn" und bedeutet nichts anderes, als dass sie einen festgelegten Platz,

    so wie Ausrichtung haben, wie und wo sie an einem Objekt spawnen. Wie es eben im Spiel an den Autowracks der Fall ist.

    Die Motorhaube oder andere Teile, haben also eine ganz genaue Position, die sich eben auch nicht Àndert.

    Da sie aber dennoch als loot ZĂ€hlen, haben wir auch hier wieder unseren "nominal" und "min" Wert,

    so wie die ĂŒblichen Werte der "lifetime" oder dem "restock".

    Einzig Wichtige ist hier die "category", die bei diesen Objekten mit "lootdispatch" gekennzeichnet ist.

    Diese Kategorie wurde explizit dafĂŒr eingerichtet und sollte unter UmstĂ€nden nur dafĂŒr genutzt werden,

    da sie eben nur fĂŒr diese Art von spawns vorgesehen ist.

    Wie das ganze nachher funktioniert, klÀren wir aber spÀter in der mapgroupproto.xml genauer.


    Kommen wir zu KI Objekten.


    Code
        <type name="ZmbF_ParamedicNormal_Blue">
        <nominal>0</nominal>
        <lifetime>1800</lifetime>
        <restock>0</restock>
        <min>1</min>
        <quantmin>-1</quantmin>
        <quantmax>-1</quantmax>
        <cost>100</cost>
        <flags count_in_cargo="0" count_in_hoarder="0" count_in_map="1" count_in_player="0" crafted="0" deloot="0"/>
    </type>


    Auch hier gilt das Prinzip der Fahrzeuge, denn auch hier zÀhlen wieder die Werte aus der events.xml.

    Sie sind also dem Ganzen in etwa gleichzusetzen und da wir spÀter auch nochmal auf die einzelnen Aspekte eingehen,

    Springe ich abschließend noch zu den Event Objekten.



    Diese Objekte beziehen ihre Werte wie alles andere, was ĂŒber die events.xml lĂ€uft auch aus dieser Datei.

    Somit hÀtten wir dieses Thema im Groben sogar abgeschlossen.


    Jetzt haben wir nur noch das SahnehĂ€ubchen, denn jetzt könnten wir fĂŒr frischeren Wind auf unserem Server sorgen.

    Wie im Thema cfglimitsdefinition.xml (= Link: Thema: cfglimitsdefinition.xml) schon erwÀhnt,

    können wir hier alle Items anpassen, zum einen in Sachen Lebensdauer oder HÀufigkeit,

    zum anderen können wir sie aber auch neu zuordnen. Also zumindest wo sie spawnen sollen.

    Nehmen wir dafĂŒr aber wieder die "BakedBeansCan" und sagen wir einfach, wir können diese in jeder Zone finden.

    DafĂŒr mĂŒssen wir nicht extra den Eintrag "<value name="Tier4"/>" anhĂ€ngen, sondern entfernen einfach alle "Tier" EintrĂ€ge,

    was am Ende dazu fĂŒhrt, dass sie eben auf der ganzen Karte zu finden sind.

    Selbes können wir aber auch mit den "usage" anstellen und diese nach Belieben abÀndern, entfernen oder Erweitern.

    FĂŒr dieses Beispiel nehmen wir jetzt einfach die Polizei, womit wir zu folgendem Ergebnis kommen.



    Nun wĂŒrden unsere Bohnen in Polizeiwachen auf der ganzen Karte spawnen 😅.

    Das wÀre mir persönlich aber ein wenig fehl am Platz und möchte sie daher nur noch in SupermÀrkten finden.

    Wie schon in der cfglimitsdefinition.xml erwÀhnt,

    können wir dies anpassen und haben eine neue "usageflags" erstellt, welche wir "Supermarket" getauft haben.

    Hier auch nochmal als Erinnerung unsere cfglimitsdefinition.xml wie sie aussehen sollte.



    Nun können wir unseren Bohnen diesen Eintrag zuordnen, womit wir folgendes Ergebnis haben.



    Jetzt haben wir schon mal ein paar Anpassungen vorgenommen, welche wir allerdings noch in der mapgroupproto.xml anpassen mĂŒssen.

    Das wĂŒrde ich allerdings auch erst da weiterfĂŒhren und fĂŒr hier erst einmal behaupten, dass wir das Thema so weit abschließen können.


    Ich hoffe, ich habe alles soweit richtig und verstÀndlich erklÀrt, lasse mich gerne berichtigen, aber musste feststellen,

    dass es doch ein sehr trockenes und ausdauerndes Thema sein kann.

    Ich werde schauen, ob ich ĂŒber die Zeit, noch das ein oder andere anpassen

    und ggf. mit Bildern etwas besser darstellen kann 😅.

    Je nachdem wie weit ich es auch mit meinem Server gebastel schaffe,

    finden sich bestimmt auch da ein paar Anregungen, wie man seinen Server gestalten kann 😊.


    Bis dahin aber wieder ein danke fĂŒrs Zuhören, euer Interesse, Zeit und euer Durchhaltevermögen 😅😂.

    • Neu

    Huhu liebe Gemeinde 😁,


    zwar ein wenig her und wollt eigentlich auch schon etwas mehr fertig haben, aber leider kam da ein kleines Rendezvous mit einem Auto dazwischen und nebenbei noch der ĂŒbliche Feiertagswahnsinn đŸ€Ł.

    Da war doch auch hier und da die Muse nicht so ganz vorhanden. Ich werd aber im neuen Jahr wieder an allem weiterarbeiten und wĂŒnsche allen Lesern auf diesem Wege aber auf jeden Fall einen guten Rutsch, guten Loot und erfolgreiches Überleben im neuen Jahr 😁.

    • Neu

    Hey Kobold, vielen Dank fĂŒr deine Arbeit.

    Leider habe ich kaum bisher etwas gelesen, da alle Texte mit Schriftfarben formatiert wurden. Wenn du möchtest, dass mehr deine Texte lesen, bitte ich dich diese zu entfernen (auch weiß ist schlimm) und Standard zu lassen. Schriftfarben sind nur bei Überschriften zu verwenden.

    • Neu

    Erledigt und hoffe mal es ist jetzt besser und passt auch so 😁

    Zitat von Urs

    Hey Kobold, vielen Dank fĂŒr deine Arbeit.

    Leider habe ich kaum bisher etwas gelesen, da alle Texte mit Schriftfarben formatiert wurden. Wenn du möchtest, dass mehr deine Texte lesen, bitte ich dich diese zu entfernen (auch weiß ist schlimm) und Standard zu lassen. Schriftfarben sind nur bei Überschriften zu verwenden.