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 😊.

    2 Mal editiert, zuletzt von derKobold1987 (30. Dezember 2024 um 15:16)

    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.

    4 Mal editiert, zuletzt von derKobold1987 (30. Dezember 2024 um 15:16)

    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.

    3 Mal editiert, zuletzt von derKobold1987 (8. Mai 2025 um 20:32)

    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 😁

    2 Mal editiert, zuletzt von derKobold1987 (30. Dezember 2024 um 15:15)

    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 😊.

    3 Mal editiert, zuletzt von derKobold1987 (16. Januar 2025 um 20:10)

    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 😊.

    2 Mal editiert, zuletzt von derKobold1987 (30. Dezember 2024 um 15:15)

    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 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 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 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 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 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 😅😂.

    3 Mal editiert, zuletzt von derKobold1987 (8. Mai 2025 um 21:11)

    Thema:


    events.xml

    Hier beschäftigen wir uns nun mit den Events und fangen wie immer zu den grundlegenden Sachen,

    dem Aufbau der Events.

    Dabei haben wir wieder ein paar unterschiedliche Arten, die allerdings im Kern alle gleich sind.

    Ich liste sie also einfach auf und gehen im Anschluss einfach alle möglichen Einstellungen durch.

    Wir haben also als Erstes die "Ambient" Events.

    Im Prinzip gleich haben wir aber als Nächstes die "Animals".

    Anschließend haben wir die "Infected".

    Hier haben wir zwei statische Objekte.

    Als Nächstes haben wir eine statische Objektgruppe.

    Obst, Gemüse und andere kleine Naturobjekte, die in der Wildnis vorkommen.

    Und als Letztes haben wir noch die Fahrzeuge.


    Soweit so gut haben wir also alle Arten von momentan enthaltenen Events.

    Unterschieden tun sie sich insofern, dass sie beispielsweise auf unterschiedliche Dateien zugreifen,

    Welche z.B. die Orte bestimmen, an denen das Event stattfinden kann.

    Darauf gehen wir aber später ein, jetzt erst einmal die einzelnen Parameter und Einstellungen.

    Da an sich alle Einstellungen gleich sind und sich nur Werte oder ähnliches ändern,

    werde ich aus allen möglichen Event Beispielen Zeilen auswählen, um diese so ausführlich wie möglich zu erklären.


    name="VehicleOffroad02" = Name des Events

    Hier wird als der Name des Events festgelegt. Dieser bezieht sich allerdings nicht auf Objekte aus der "types.xml".

    Es ist nur der Name des Events und in diesem Falle ist es eine Zusammensetzung zwischen der Art, also dem "Vehicle"

    und dem Fahrzeug "Offroad_02".

    "Trajectory", "Static" oder "Infected" dienen zum Auseinanderhalten und besseren Übersicht.

    Inwieweit es einen Unterschied macht, ob wir beispielsweise nur "Mustang" und nicht "VehicleMustang" nehmen,

    kann ich leider auch nicht zu 100 % sagen, würde aber meinen, dass es egal wäre 🤔.

    Wichtig ist nur, dass unser Event Name beim Eintragen in anderen Dateien derselbe ist.


    nominal>50</nominal = maximale Anzahl gleichzeitiger Events

    min>25</min = minimale Grenze gleichzeitiger Objekte aus einem Event

    max>100</max = maximale Grenze gleichzeitiger Objekte aus einem Event

    Hier wird es jetzt ein wenig schwieriger und muss leider auch schon ein paar Einstellungen vorgreifen 😅.

    Dafür nehme ich also auch die "children" Werte mit ins Boot und versuche es ein wenig aufzuschlüsseln.

    Dazu kommt, dass dies nur ein wenig als Beispiel gilt, da diese Rechnung nicht auf alles zutrifft

    und von zusätzlichen Faktoren wie dem "limit" abhängig ist. Es ist also nur ein Beispiel,

    welches man ein wenig nutzen kann, um an diese ganze Sache heranzugehen 😊.

    children = Enthaltene Objekte in einem Event

    <child lootmax="5" lootmin="0" max="0" min="40" type="ZmbF_PoliceWomanNormal"/>

    <child lootmax="5" lootmin="0" max="0" min="40" type="ZmbM_PolicemanFat"/>

    <child lootmax="5" lootmin="0" max="20" min="0" type="ZmbM_PolicemanSpecForce"/>

    <child lootmax="5" lootmin="0" max="20" min="0" type="ZmbM_PolicemanSpecForce_Heavy"/>

    Aufgeteilt noch einmal in

    lootmax="5" = maximale Anzahl an Loot um das Event Objekt

    lootmin="0" = minimale Anzahl an Loot um das Event Objekt

    max="0" = maximale Anzahl von Event Objekten

    min="40" = minimale Anzahl von Event Objekten

    type="ZmbF_PoliceWomanNormal" = Objektname, wie auch in der types.xml enthalten

    Nun zur Aufschlüsselung des Ganzen, denn hier müssen wir tatsächlich ein wenig von unten anfangen.

    In unserem Bsp. werden die Objekte "ZmbF_PoliceWomanNormal", "ZmbM_PolicemanFat", "ZmbM_PolicemanSpecForce"

    und "ZmbM_PolicemanSpecForce_Heavy" angegeben und jeweils mit einem "min" und "max" Wert versehen.

    Bei einem Event müssen oder können wir diese Werte zusammenrechnen,

    um am Ende mit den "min" und "max" Werten des gesamten Events arbeiten zu können.

    Ich hoffe nur, ich bekomme es auch gut genug erklärt 😅🤣.

    Wir haben also erst mal folgende Werte, die unter "children" festgelegt wurden:

    max = 0 + 0 + 20 + 20 = 40

    min = 40 + 40 + 0 + 0 = 80

    Also haben wir pauschal erst mal einen "max" Wert von 40 und einen "min" Wert von 80.

    Wer in Mathematik aufgepasst hat, wird allerdings merken, dass diese Rechnung in dieser Form nicht ganz stimmen kann,

    da wir ja minimal nicht mehr haben können, als maximal 🤔.

    Das wäre ja als würde in einem Kochbuch stehen wir sollen mindestens einen Liter Wasser hinzu kippen

    aber nicht mehr als einen halben Liter 😅.

    Das liegt einfach daran, dass bei einem "max" Wert von "0" die Zahl "Unendlich" gilt.

    Es wurde also lediglich festgelegt, dass "ZmbM_PolicemanSpecForce" höchstens 20-mal vertreten sein darf,

    ebenso wie "ZmbM_PolicemanSpecForce_Heavy" nur 20-mal auftauchen darf.

    "ZmbF_PoliceWomanNormal" und "ZmbM_PolicemanFat" haben dafür kein Limit.

    Selbes gilt natürlich beim "min" Wert zu berücksichtigen, denn der eingetragene Wert entspricht tatsächlich "0"

    und somit können zwischen "0" und "20" Infizierte vom Typ "ZmbM_PolicemanSpecForce_Heavy" auftauchen.

    Dies bedeutet also, dass mindestens 80 Infizierte Polizisten umherstreifen können, aber es nach oben kein Limit gibt.

    und genau da kommt, der kniff mit den "nominal", "min" und "max" Werten ins Spiel.

    Der Nominal wert wurde mit "50" festgelegt, und lässt 50 Events gleichzeitig auf der Karte stattfinden,

    Auf all diese Events werden im Prinzip je nach Event unsere Polizisten aufgeteilt,

    wobei hier nun die Werte "min>25</min" und "max>100</max" zum Einsatz kommen.

    Der "max" Wert sorgt dafür, dass nicht unendlich, sondern eben nur 100 Polizisten die Gegenden unsicher machen

    und der "min" Wert dafür, dass bei weniger als 25 Polizisten diese priorisiert nach gespawnt werden.

    Es ist also wichtig hier die richtige Balance zu finden und das ganze abzuwiegen, da es sonst passieren kann,

    dass bei zu hohen oder niedrigen Werten zu wenig von anderen Objekten vorkommen kann.

    Würden wir z.B. nicht "max>100</max", sondern nur "max>80</max", könnte es passieren,

    dass eben "ZmbM_PolicemanSpecForce" oder "ZmbM_PolicemanSpecForce_Heavy" nicht mehr oder kaum spawnen,

    da die beiden anderen mit ihren jeweils "min= "40"" schon die maximale Anzahl von "80" erreichen.

    Dies kann auf alle Events zutreffen, von daher sollte man sich da wirklich die Zeit nahmen

    und ggf. schauen, testen und probieren bis das gewünschte Ergebnis erreicht ist 👍😊.

    "lootmin" und "lootmax" definieren einfach eine minimale und maximale Anzahl an Loot, die aus dem Event Objekt hervorgehen können.

    Dies kann bei statischen Objekten um das entsprechende Objekt herum sein, aber auch am Objekt selbst.

    Z.B. würden bei einem Zug die Objekte nicht nur um den Zug, sondern auch auf den Ladeflächen liegen.

    Unser Server sucht sich gegebene Spawnpunkte und lässt an diesen eben Loot spawnen, was also bei unseren Infizierten bedeutet,

    dass auch sie in einem gewissen Radius Loot auftauchen lassen. Das erklärt dem ein oder anderen auch, wie es eben sein kann,

    dass medizinisches Equipment nicht nur in einem Krankenhaus, sondern auch in Objekten um das Gebäude auftauchen.

    Ich hoffe, jetzt nur es ist nicht zu kompliziert oder zu viel 😅🤔😲,

    aber leider ist dies Thema sehr komplex und hat auch noch zusätzliche Faktoren.

    Es soll in erster Linie eine grobe Richtlinie sein, an der man sich ggf. ein wenig orientieren kann.

    Die übrigen Einstellungen sollten wieder etwas einfacher sein 😅.


    lifetime>300</lifetime = Lebensdauer in "s" eines Events

    Dieser Wert legt fest, wie lange ein Event in der Welt ohne Interaktion verbleibt und wieder nach gespawnt wird.

    Je nach Event Art haben dies allerdings noch einmal eine separate Lebensdauer, was also bedeutet,

    dass die hier angegebene Lebensdauer nicht immer zu 100 % zutreffend ist,

    wie es beispielsweise bei Fahrzeugen der Fall sein kann.


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

    Wie auch in den types.xml, wird hier nach Ablauf eines Timers das Event oder die Objekte wieder aufgefüllt.

    Es werden hier aber nicht alle Events mit einem Mal neu aufgefüllt, sondern Objekt für Objekt.

    Je nach Event gibt es zwar noch Unterscheide, aber nehmen wir mal die "Bretterstapel" als Beispiel.

    Stehen 2 Stapel relativ nah beisammen und wir bauen nur einen ab,

    richtet sich der "restock" Timer einmal nach dem abgebauten und nach Ablauf der Lebensdauer nach dem anderen.

    Es ist und kommt eben auch immer auf Aktivität auf dem Server an.


    saferadius>500</saferadius = Sicherheitsradius in "m" um einen Spawnpunkt

    Hierbei wird festgelegt, wie weit z.B. ein Spieler von einem Spawnpunkt entfernt sein muss,

    damit dieses stattfinden oder erscheinen kann. Würden wir den Wert "0" nehmen, könnte es unter Umständen passieren,

    dass ein Bretterstapel genau an der Stelle spawnt, an der unser Charakter sich befindet.

    Das macht dann dolle AUA bei unserem Charakter, könnt zu Problemen führen oder dessen Tot herbeirufen 😅.


    distanceradius>500</distanceradius = Spawnradius in "m" in dem Objekte Spawnen können

    Auch hier wird wieder in Metern eine Art Umkreis festgelegt, in dem eben unsere Events stattfinden können.

    Dabei ist auch wieder die Art des Events wichtig, da es Events mit einer festen Position gibt,

    aber eben auch Events, die sich eben in diesem Radius bewegen und stattfinden können.

    Hierbei zählt unter anderem z.B. die Entfernung zu Objekten oder Spielern, welche mit einberechnet werden.


    cleanupradius>200</cleanupradius = Despawnradius in "m" in dem Objekte verschwinden können

    Hier wird in Metern die Entfernung festgelegt, wie weit ein Spieler vom Event oder dessen Objekten entfernt sein muss,

    damit diese auch wieder verschwinden. Dies ist eben wie schon der "saferadius" dafür da,

    dass Objekte nicht unmittelbar vor unserer Nase verschwinden.


    secondary>InfectedArmy</secondary = Zusätzliche Spawns bei einem Event

    Damit lassen sich beispielsweise zusätzlich Infizierte zum Event hinzufügen.

    Also eine Art Event in einem Event, wenn man es so möchte 🤔.

    Ich möchte mich zwar nicht zu weit aus dem Fenster lehnen, aber hierbei sollte es mit Infizierten,

    aber auch mit Tieren funktionieren. Wichtig ist, dass es hierbei nicht um ein Objekt,

    sondern auch wieder um eine Eventgruppe handelt wie z.B. "InfectedPolice" oder "AnimalCow".


    flags deletable="0" init_random="0" remove_damaged="1" = Zusätzliche Objekt Regeln

    Hier können mit dem Wert "0" (Deaktiviert) und "1" (Aktiviert) kleiner Einstellungen vorgenommen werden,

    wie sich das Event eben bei folgenden Sachen verhalten soll.

    deletable="0" = löschbare Objekte

    Legt im Grunde fest, ob Objekte, die mit dem Event spawnen auch wieder mit dem Event verschwinden.

    Im Falle unserer Infizierten bleiben sie z.B. liegen, wohingegen sie bei einem Helicrash verschwinden, wenn der Heli verschwindet.

    init_random="0" = Zufalls Loot Platzierung

    Hier kann im Prinzip entschieden werden, ob Loot entweder mit "1" Zufällig platziert werden soll und ob der Loot selbst Zufällig ist.

    Meine Hand will ich dafür nicht ins Feuer schmeißen, da ich tatsächlich mit in dynamischen kontaminierten Zonen

    noch nicht wirklich unterwegs war. Diese sind allerdings auch die einzigen Events, die diesen Wert mit "1" angegeben haben.

    remove_damaged="1" = Loot despawn wenn Beschädigt

    Hierbei wird wieder mit "0" oder "1" festgelegt, ob beschädigte Objekte oder Loot despawnen soll.


    position>fixed</position = Art der Event Position

    Hier haben wir eine Einstellung, die mehr oder weniger festlegt, ob das Event mit "fixed" und somit eine feste Position in der Welt hat.

    Dabei wird also keine Rücksicht auf Spielerbewegungen genommen, sondern Spawnt eben einfach auf einem festgelegten Punkt.

    Mit "player" können wir festlegen, ob das Event eben stattfindet, wenn der Server Bewegungen von Spielern in der Nähe registriert,

    wie es z.B. bei Äpfeln der Fall ist.

    Als dritte Möglichkeit gibt es noch "uniform" bei welcher ich mir nicht ganz sicher bin.

    Da das Event der Weihnachtsbäume allerdings jeweils mit 13 festgelegt ist und es auch 13 Spawnpunkte hat,

    ist es für mich am naheliegendsten, dass diese Variante genutzt wird, wenn eben Spawnpunkt Anzahl und Event Anzahl gleich sind.

    Aber auch hier wäre meine Angabe ohne Gewähr und ist leider nur eine Spekulation, da ich momentan keinen ausführlichen Test habe 😅.


    limit>mixed</limit = Art der Limitierung

    Damit lassen sich die Anzahl, Häufigkeit oder Limitation noch einmal etwas einstellen und ausrichten.

    Es wird auch hier noch einmal unterteilt in "custom", "mixed", "child" oder "parent".

    Mit "custom" wird festgelegt, dass diese Events ihre Werte aus Externen Dateien wie z.B. den "territories.xml" beziehen.

    "mixed" führt zu einer Kombination aus den angegebenen "children" Werten aus der "events.xml"

    und eventuell zugehörigen Werten, wie beispielsweise im Falle von "TrajectoryApple", welche in der "mapclusterproto.xml"

    Zusätzliche Werte definiert haben oder dem "StaticHeliCrash", welcher zusätzliche Werte in der "cfgeventspawns.xml" hat.

    Mit "child" wird festgelegt, dass die Limitierung sich nur auf die "children" Werte bezieht

    und damit alles bis zum "nominal" Wert auffüllt.

    "parent" bezieht wahrscheinlich seine Werte nur aus der zugehörigen Datei.

    Dies ist momentan nur bei der "StaticContaminatedArea" der Fall, welche ihre Werte demnach wahrscheinlich die Werte

    aus der "cfgeventspawns.xml" bezieht.


    active>1</active = Event Aktivierung / Deaktivierung

    Damit wird ganz einfach und simpel das Event mit "1" in den Aktiven und mit "0" in den inaktiven Zustand versetzt.

    Somit können auf einfache Art und Weise unerwünschte Events abgeschaltet werden, ohne dass man an Werten herumschrauben muss.


    So, ich hoffe, ich habe nichts Vergessen und ja, auch dieses Thema ist und kann sehr komplex sein.

    Über die letzten Jahre hat sich auch hier sehr viel verändert und weiterentwickelt,

    weshalb ich auch sehr auf die Zukunft gespannt bin, und was sich noch alles verändern wird 😊.

    Aber dennoch sollte es auch hiermit erst mal für dieses Thema reichen

    und bedanke mich fürs Lesen und eure Aufmerksamkeit 😁.

    4 Mal editiert, zuletzt von derKobold1987 (8. Mai 2025 um 21:15)

    Thema:


    cfgeventspawns.xml

    Bei diesem Thema handelt es sich im Grunde um eine Ansammlung von Koordinaten für Events.

    Da dies relativ simpel und an sich auch fast immer gleich ist,

    sollten wir uns hier hoffentlich nicht allzu lange aufhalten müssen 🤣.

    Wie immer schauen wir uns aber schnell wieder ein paar Grundkonstrukte an.

    Als Erstes können wir nun klären, was die einzelnen Werte für eine Bedeutung haben.

    Denn diese haben immer dieselbe Bedeutung und macht uns das Leben am Ende etwas einfacher,

    da es sich im Grunde nur wiederholt 😅.

    Wir haben also folgende Werte:

    name = Name des Events

    Dabei handelt es sich um die in der "events.xml" festgelegten Event Bezeichnung,

    nicht um den Namen eines Objektes.

    "x" = X Achse (Horizontal von links nach rechts)

    "z" = Z Achse (Vertikal von Unten nach Oben)

    "a" = Rotation des Objektes / Events

    "y" = Y Achse (Höhe zum 0. Punkt und der Wasseroberfläche)

    Dies sind die grundlegenden Werte, mit denen bei Events gearbeitet wird und wie wir wissen,

    arbeiten wir mit einem Objekt oder Event in einem 3 dimensionalem Raum

    und haben dementsprechend diese Koordinaten und Ausrichtungen.

    Fangen wir mit dem Fahrzeug an, bei dem hauptsächlich die "x" und "z" Achse genutzt wird,

    um eine Position zum spawnen auf der Karte genutzt wird.

    Mit "a" legen wir nur noch eine Rotation des Objektes um die eigene Achse im Uhrzeigersinn fest.

    Wenn "a" nicht vorhanden sein sollte, gibt es eigentlich 2 mögliche Szenarien.

    Entweder das Spiel sucht sich eine geeignete Rotation, je nachdem wie es passt,

    oder sie wird einfach mit "0" angegeben, was zu einer immer gleichen Ausrichtung führt.

    Mit "-1" wird wahrscheinlich die Rotation deaktiviert.

    Da dies nur bei den Helis der Fall ist, bin ich mir leider nicht ganz sicher

    ob "0" und "-1" am Ende nicht sogar den selben Effekt haben.

    An unserem Beispiel, dem "VehicleOffroad02" haben wir also folgendes,

    x="801.261841" = 801.261841m auf der x-Achse

    z="1919.863403" = 1919.863403m auf der y-Achse

    a="6.049285" = eine Rotation von 6.049285° um die eigene Achse und im Uhrzeigersinn

    Ich hoffe, dass dies soweit Verständlich genug ist, um es nicht an jedem Beispiel zu wiederholen 🤣😅.


    Da das Grundwissen damit erklärt sein sollten, hake ich auch gleich die erste Eventart ab

    und komme zur nächsten Besonderheit und nächsten Art, dem statischen Event.

    Somit haben wir also unter dem Event "StaticHeliCrash" nun noch die Zeile:

    Code
            <zone smin="1" smax="3" dmin="3" dmax="5" r="45" />

    In der "events.xml"haben wir gesehen, dass das Event zusätzlich Infizierte hervorbringen soll.

    Dies ist mit dieser Zeile festgelegt und bildet mit "smin" und "smax" die Werte,

    mit denen immer Infizierte hervorgebracht werden sollen.

    smin="1" = Statische minimale Anzahl an Infizierten

    smax="3" = Statische maximale Anzahl an Infizierten

    Es sollten also immer 1 bis 3 Infizierten vorhanden sein.

    Zusätzlich kommen nun noch dynamische Infizierten hinzu, welche mit "dmin" und "dmax" festgelegt werden.

    dmin="3" = Dynamische minimale Anzahl an Infizierten

    dmax="5" = Dynamische maximale Anzahl an Infizierten

    Somit kommen zu den Statischen Infizierten noch Dynamische hinzu,

    was eben einen Spielraum von minimal 4 bis maximal 8 Infizierten ergibt.

    Diese können in einem Radius von 45 m um das Event auftauchen und Nerven 😅.

    Damit wissen wir jetzt auch, was "r" bedeutet.

    r="45" = Radius in m um das Event

    Damit hätten wir auch diese Besonderheit geklärt, denn der Rest ist wie vorher,

    nur eine Ansammlung der einzelnen Koordinaten bestehend aus "x" "z" und "a"


    Als Letztes haben wir nun noch das Beispiel "StaticTrain", welcher zusätzlich zu den üblichen Werten

    den Wert "y" für die Höhe des Events beinhaltet. Da ich diesen schon erläutert habe,

    komme ich gleich zur Besonderheit.

    group="Train_Abandoned_Kamy" = Eventgruppe

    Dies ist eine für jede Koordinate festgelegte Gruppe von Objekten,

    welche in der "cfgeventgroups.xml" vordefiniert ist.

    Der Rest ist auch hier wieder derselbe.

    Zusätzliche Infizierte, Koordinaten und Ausrichtung.


    Am Ende haben wir nur noch

    Welche eine Auflistung von nicht vorhandenen Events

    und wahrscheinlich einer Weiterleitung beinhalten.

    Da bin ich mir aber auch nicht ganz sicher

    und empfehle diese nicht unbedingt zu löschen 😅.


    Das war es dann tatsächlich schon mit diesem Ausflug und hoffe er war informativ genug,

    auch wenn ich dieses Mal versucht habe das Ganze etwas kürzer zu gestalten 😅.

    Wie immer danke fürs Lesen und euer Interesse 😁👍.

    4 Mal editiert, zuletzt von derKobold1987 (21. Mai 2025 um 19:33)

    Thema:


    cfgspawnabletypes.xml

    Hier wird es jetzt mal wieder ein wenig knifflig und muss wohl oder übel darauf hinweisen,

    dass dieser Abschnitt Hand in Hand mit dem Thema "types.xml" und dem Thema "cfgrandompresets.xml" geht.

    Da ich allerdings schon ein paar mal damit konfrontiert wurde,

    muss ich zu aller erst einmal eine sehr wichtige Frage beantworten.

    Was ist die "cfgspawnabletypes.xml" überhaupt? Was macht sie und vor allem, was macht sie nicht!

    Sie ist in erster Linie nur eine Erweiterung der "types.xml" und ist nicht dafür verantwortlich,

    dass Objekte überhaupt spawnen. Jedes Objekt, welches wir hier in irgendeiner Form eintragen,

    muss auch vorher in der "types.xml" definiert sein.

    Ich habe Gespräche gehabt, in denen man davon ausgegangen ist oder angenommen wird,

    hier würde man festlegen, mit welcher Chance ein Objekt überhaupt spawnt.

    Die wildesten Theorien, welche ich jetzt auch nicht alle aufzählen will 🤣😅.

    Um Gotteswillen, das ist alles halb so wild und für jeden, der hiermit etwas Neues lernen kann

    und das ganze drumherum verstehen lernt, bin ich froh.

    Denn es soll ein wenig die Sicht ändern und schließlich aufzeigen, was denn möglich ist

    oder eben wofür manche Sachen tatsächlich gut sind.

    Damit komme ich nun auch zum Punkt, was diese Datei überhaupt ist,

    denn hier legen wir fest, welches Objekt in oder an einem anderen Objekt spawnt.

    Also ob beispielsweise unsere Fahrzeuge schon reifen haben, unsere Pistole ein Magazin

    oder ob und was ein Infizierter bei sich trägt.

    Aber fangen wir mal an und kommen wieder zu ein paar kurzen Beispielen

    um die Möglichkeiten aufzuzeigen.

    Jetzt gehen wir aber ein wenig anders an die Sache heran, denn an sich muss man hier nur zwischen Inventar, also dem "cargo"

    und einem Slot Anhang, dem sogenannten "attachments" Unterscheiden.

    Der "cargo" ist also Beispielsweise das, was in einem Rucksack abgelegt wird und "attachments" eben an den Slots,

    wo unser Knicklicht oder Funkgerät Platz finden kann.

    Viel mehr müssen wir hier grundlegend nicht Unterscheiden, Fangen aber mal ganz oben an, bevor wir dann Speziell werden.


    name="Barrel_Blue" = Objekt Name / Bezeichnung

    Hier haben wir wie immer den Namen des Objektes, so wie er auch schon in der "types.xml" steht und auch hier gilt wieder,

    nicht "Fass" sondern eben "Barrel_Blue", da es sich explizit um das blaue Fass handelt.

    Es reicht auch nicht, wenn wir eine Oberklasse nehmen, wir müssen jedes Objekt einzeln auflisten.

    Wer da schon ein wenig mehr Ahnung hat, kennt es, für andere als kleiner Ausflug in die Beschaffenheit und Aufbau wie es hinter den Kulissen ausschaut.

    Grob gesagt wird in der Programmierung für Objekte eine Oberklasse angelegt, welche z.B. "Barrel_ColorBase" heißt.

    Dies wird eben auch in Mods genutzt, ist aber eben nur eine übergeordnete Klasse, die quasi alle möglichen Parameter enthält (In Game Bezeichnung, Beschreibung, Gewicht, etc....).

    Anschließend werden eben auf dieser Klasse Objekte aufgebaut, in der man z.B. nur noch die Farben / Texturen ändert.

    Somit haben wir also unser "Barrel_Blue" oder auch ein "Barrel_Red" und immer so weiter.

    Im Spiel heißen sie aber eben zum einen alle "Fass" und zum anderen würde es nichts bringen, weil eben das "Barrel_ColorBase" nicht in der Welt spawnt.

    Die hier eingetragenen Sachen würden auch nicht auf alle "Barrels" übergehen, sondern beziehen sich wie gesagt immer nur auf explizit dieses eine Objekt.

    Ich hoffe das dies soweit Verständlich ist, ich wollte nicht zu weit abschweifen 😅.

    Damit aber weiter im Text 🤣.


    hoarder /> = Containern Inventar

    Wie schon in der "types.xml" erwähnt gibt es Objekte, die eben länger auf der Karte verweilen.

    Diese Objekte haben eben keinen einfachen "cargo", sondern bezeichnen diesen eben als "hoarder".

    Damit gearbeitet habe ich leider noch nicht, kann aber an dieser Stelle sagen,

    dass es im Grunde dasselbe wie der "cargo" wäre.

    Ob es etwas bringt hier etwas einzutragen, müsste ich mal in Ruhe testen 😅.

    Leider funktioniert bei Objekten dieser Art keine Anpassung wie bei den üblichen Objekten,

    weshalb ich an dieser Stelle erst mal sagen würde, man sollte es so belassen wie es ist 😅🤣.


    damage min="0.0" max="0.35" /> = Beschädigung in "%"

    Damit lassen sich, auch wenn es eine globale Einstellung gibt, nochmal der Grad der Beschädigung einstellen.

    Dies liegt wahrscheinlich daran, dass Objekte, die als Attachment an einem Objekt spawnen,

    keine Beschädigung haben, sondern immer den makellosen Zustand haben oder hätten.

    Es ist nur eine Vermutung, kann ich mir aber auch nicht anders erklären.

    Die Beschädigung wird hier in "%", mit "min" und "max angegeben", wobei wir berücksichtigen müssen,

    dass "min" nicht der minimale Schadenszustand ist, sondern eben die minimale Beschädigung.

    "min="0.0" wären also in Lebenspunkten gerechnet 100 % leben, was bedeutet,

    dass "max="0.35"" nur noch 65 % Lebenspunkte bedeutet.

    Das Objekt wäre ja sonst schon ruiniert, wenn es anders wäre 🤣.


    Kommen wir nun zum "cargo", denn da haben wir folgende Möglichkeiten.

    Wir können entweder eine zufällige Objektauswahl oder ein Objekt direkt im Inventar spawnen lassen, welches wir festlegen können.

    cargo preset="mixArmy" /> = Zufälliges Objekt aus einer angelegten Auswahl

    Hier müssen wir erst mal wissen, woher die zufällige Objektauswahl stammt, denn diese wird in der "cfgrandompresets.xml" festgelegt.

    Wenn man hier also etwas genauer nachschauen möchte und damit ich hier nicht den Rahmen spränge,

    Würde ich auf das Thema: "cfgrandompresets.xml" verweisen und hier mit den für diesen Teil wichtigen Sachen weiter machen 😊.

    Also zurück zum "preset", denn es handelt sich wie schon gesagt um ein zufälliges Objekt aus einer definierten Auswahl.

    Damit wird aber auch nur ein einziges zufälliges Objekt bestimmt, keine 3, 4 oder 10, sondern nur eines.

    Daher ist in folgendem Bsp. zu sehen, dass diese Zeile ganze 3-mal eingefügt ist.

    Code
        <type name="AssaultBag_Ttsko">
        <cargo preset="mixArmy" />
        <cargo preset="mixArmy" />
        <cargo preset="mixArmy" />
    </type>

    Somit wird je Zeile ein Objekt gewählt, womit man also auf bis zu 3 Objekte kommt.

    Da in der Definition der "mixArmy" allerdings auch alles mit einer Wahrscheinlichkeit versehen ist,

    ist hier nicht garantiert, dass auch immer 3 Objekte vorhanden sind.

    Es bedeutet nur, dass es bis zu 3 Objekte sein können, genauso gut aber auch überhaupt keines.

    Für solch eine Einstellungen ist an sich kein Limit gesetzt, und kann natürlich angepasst werden, wie es einem beliebt.

    Es gilt aber auch hier wieder das Limit der Dateigröße und Zeilenanzahl.

    Zusätzlich muss man auch bedenken, dass Inventare nicht unendlich Platz bieten.

    Es sollte also überlegt sein, wie viele Objekte gespawnt werden sollen.

    Des Weiteren ist ein wenig zu berücksichtigen und auch ein wichtiger Punkt, was die "types.xml" angeht.

    Diese muss man hier ein wenig außer Acht lassen, nicht zu 100 %, aber um es an einem Beispiel zu erklären,

    nehmen wir uns mal unsere alt bekannten "BakedBeansCan", welche in der "types.xml" mit einem "nominal" Wert von "15" versehen sind.

    Der in der "types.xml" hinterlegte "nominal" Wert lässt je nach Platz 15 Dosen auf der Karte erscheinen.

    Dabei kann das Spiel eine Sache aber nicht zu 100 % berücksichtigen, und das ist der Faktor "Spieler".

    Da das Spiel nicht alle Infizierten einfach spawnen lässt, sondern diese teilweise erst dann spawnen,

    sobald sich ein Spieler in einem bestimmten Bereich befindet, lassen sich diese eben schlecht einkalkulieren.

    Nehmen wir also an es liegen 15 Dosen auf der Karte, müsste in der Theorie also eine Dose verschwinden,

    damit eine Dose in einem Infizierten gefunden werden kann.

    Würden allerdings 15 Spieler neben einer solchen Dose stehen, würde diese ja nicht einfach verschwinden.

    Das würde wiederum bedeuten, dass in einem Infizierten ja auch keine Dose auftauchen könnte.

    Genau an diesem Punkt kommt auch unsere Einstellung aus der "types.xml" ins Spiel.

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

    Die Einstellung "count_in_cargo="0"" sorgt in diesem Moment dafür, dass eben das Inventar eines Infizierten nicht berücksichtigt wird.

    Dadurch können eben 15 Dosen auf der Karte existieren und trotzdem auch zusätzlich in einem Infizierten oder anderen Container hervorgebracht werden.

    Den "nominal" Wert in unserer "types.xml" nach oben zu treiben, hat hier also keinerlei Auswirkung.

    Es würde lediglich dazu führen, dass eben mehr Dosen in der Welt spawnen, aber nicht in unseren Infizierten.


    Als Nächstes haben wir die Möglichkeit, ein explizit ausgewähltes Item unter denselben Bedingungen in einem Infizierten

    oder Container auftauchen zu lassen.

    Dafür haben wir hier aber 2 notwendige Zeilen.

    cargo chance="0.6"> = Wahrscheinlichkeit in "%"

    item name="BandageDressing" /> = Ausgewähltes Objekt

    Hier wird zum einen in "%" die Wahrscheinlichkeit angegeben, mit der das Objekt in einem Inventar eines Objektes auftauchen kann.

    Die "0.6" sind dabei "60 %", was also bedeutet, dass "0.01" nur "1 %" wäre und "1.0" dementsprechend "100 %".

    Das "item name=" kann mit jedem gewünschten Item gefüllt werden, welcher eben wie immer auch in der "types.xml" hinterlegt ist.

    Nun gibt es hier noch eine weitere Möglichkeit, die wir nutzen können.

    Dafür hier das Beispiel des "CanvasBag_Medical", bei dem wir für jedes Objekt eine Zeile haben.

    Jetzt wird es ein wenig heikel, da ich mir etwas unsicher bin, wie am Ende der Server tatsächlich reagiert.

    Es gibt entweder die Möglichkeit, dass es keinerlei Auswirkung hat

    oder die Möglichkeit und hierbei beschränke ich mich erst mal auf eine Zeile,

    wäre die Wahrscheinlichkeit noch ein wenig zu verringern.

    Dabei können wir dies wie folgt aussehen lassen.

    Ich bin mir wie gesagt etwas unsicher, was die Berechnung in dieser Situation angeht.

    Daher ist es ein wenig schwierig, da tatsächlich auch das ganze richtig zu erklären.

    Wie gesagt, kann es sein, dass eben diese zusätzliche Chance keine Auswirkungen hat.

    Das glaube ich allerdings nicht, da es beim Nachfolgenden Bsp.

    und einer erhöhten Objektauswahl eben wieder eine Bedeutung hat.

    Als Nächstes ist die Frage, ob der Server nur einen Unterschied zwischen der Höhe der Chance macht,

    oder ob er mit einer gesamten Wahrscheinlichkeit von "100 %" arbeitet.

    Aus anderen "cfgspawnabletypes.xml" Dateien mit Vanilla Einstellungen, werden nie die "100 %" überschritten.

    Sie werden entweder mit "1.0" also "100 %" bei einem einzelnen Objekt oder auch mal nur mit "0.14" (14 %) angegeben.

    Auch bei mehreren Objekten, worauf ich gleich näher eingehe, werden entweder beide mit "0.5" angegeben

    oder eines mit "0.25" und das andere mit "0.75".

    Ggf. sind bei 2 Objekten auch mal beide nur mit "0.2" angegeben, aber es wird in keinem Fall die Gesamthöhe von "1.0" überschritten.

    Ich habe daher für mich daraus abgeleitet und gehe auch nach dem Prinzip diese nicht zu überschreiten

    und würde daher auch jedem raten, dieser Regel nachzugehen.

    Somit ist man, glaube ich, auf der richtigen Seite 😅👍.

    Aber kommen wir nun zurück zum Thema, um das ganze auch an Beispielen zu erklären.

    Wie oben schon erwähnt haben wir für die "BandageDressing" eine Wahrscheinlichkeit von "60 %", dass diese im "CanvasBag_Medical" auftauchen.

    Zusätzlich haben wir nochmal eine "50 %" Wahrscheinlichkeit, dass diese auch wirklich vorhanden sind.

    Das bedeutet, dass wir nun am Ende nur noch eine endgültige Wahrscheinlichkeit von "30 %" haben,

    dass unsere "BandageDressing" tatsächlich auftauchen.

    Alles andere würde für mich auch keinen Sinn ergeben und bedeutet halt letztendlich das wir zu "70 %" nichts haben

    oder zu "30 %" eben die "BandageDressing".


    Das ganze lässt sich jetzt auch auf eine Objektauswahl erhöhen, womit wir die Möglichkeit haben,

    z.B. 0 bis 4 Objekte auftauchen zu lassen, was am Ende wie folgt aussehen kann.

    Code
        <type name="CanvasBag_Medical">
        <cargo chance="0.6">
            <item name="BandageDressing" chance="0.25" />
            <item name="IodineTincture" chance="0.25" />
            <item name="TetracyclineAntibiotics" chance="0.25" />
            <item name="VitaminBottle" chance="0.25" />
        </cargo>
    </type>

    Wie oben auch schon erwähnt richte ich mich nach der "100 %" Regel, und habe für dieses Bsp. jeweils die Chance auf "0.25" angepasst.

    Am Ende haben wir also für jedes Objekt wieder eine endgültige Wahrscheinlichkeit von "15 %" auf jedes Objekt.

    Das ganze können wir halt anpassen, aber sollten eben unsere "100 %" dabei wieder nicht außer Acht lassen.

    Aussehen könnte das ganze dann am Ende folgendermaßen.

    Code
        <type name="CanvasBag_Medical">
        <cargo chance="0.6">
            <item name="BandageDressing" chance="0.35" />
            <item name="IodineTincture" chance="0.15" />
            <item name="TetracyclineAntibiotics" chance="0.25" />
            <item name="VitaminBottle" chance="0.25" />
        </cargo>
    </type>

    Jetzt wäre logischerweise die Wahrscheinlichkeit für die "BandageDressing" am höchsten

    und die Wahrscheinlichkeit für "IodineTincture" am niedrigsten.

    Als Rechenbeispiel für die endgültige Wahrscheinlichkeit können wir das ganze jetzt halt noch einmal durchrechnen,

    um das ganze endgültig aufzuschlüsseln und hoffe, dass man es einigermaßen versteht 😅.

    chance="0.6" = "60 %" = Wahrscheinlichkeit auf eines der Objekte

    "BandageDressing" chance="0.35" = "35 %" von "60 %" = "21 %" endgültigen Wahrscheinlichkeit

    "IodineTincture" chance="0.15" = "15 %" von "60 %" = "9 %" endgültigen Wahrscheinlichkeit

    "TetracyclineAntibiotics" chance="0.25" = "25 %" von "60 %" = "15 %" endgültigen Wahrscheinlichkeit

    "VitaminBottle" chance="0.25" = "25 %" von "60 %" = "15 %" endgültigen Wahrscheinlichkeit

    21 + 9 + 15 + 15 = 60

    So sehen wir also, wie die "60 %" unter den Objekten am Ende aufgeteilt werden

    und hoffe, man kann es so ein klein wenig nachvollziehen, auch wenn es sehr verwirrend ausschaut 😅😲.


    Aber kommen wir nun zur Möglichkeit, bei der wir das ganze mit mehreren Objekten machen können.

    Jetzt wurde also die Möglichkeit festgelegt, wieder 4 Objekte auftauchen lassen zu können,

    nur das es jetzt auch 4-mal dieselben Objekte sein könnte 😅.

    Wie man sehen kann, wurde wieder jeweils die Chance mit "25 %" angegeben, da wir wie erwähnt 4 Objekte haben

    und auf diese eben die 100 % aufteilen.

    Das Prinzip bleibt dasselbe wie oben beschrieben, nur dass es eben auf jeden "cargo" Eintrag einzeln angewendet wird.


    Am Rande aber noch die Info, dass wir eben um Platz und Arbeit zu sparen genau für solche Sachen die cfgrandompresets.xml haben.

    Ich hoffe aber soweit war dies erst mal verständlich und ausführlich genug, damit wir jetzt zur letzten Variante übergehen können,

    den "attachments".

    Dabei wird wie oben schon erwähnt, die Möglichkeit gesetzt, ein Objekt an einem bestimmten Slot eines Objektes auftauchen zu lassen.

    Auch hier haben wir 2 Möglichkeiten, zum einen können wir wieder mit einem Preset arbeiten,

    was eigentlich auch nicht anders funktioniert als auch schon oben beschrieben.

    In der cfgrandompresets.xml legen wir eine Auswahl an Objekten fest, auf die in diesem Fall wieder zurückgegriffen wird.

    Die Zeilen mit dem "cargo" Ignorieren wir jetzt einfach mal, das hatten wir ja schon 🤣.

    Code
        <type name="ZmbF_Clerk_Normal_Blue">
        <cargo preset="foodCity" />
        <cargo preset="toolsCity" />
        <cargo preset="toolsCity" />
        <attachments preset="glassesCity" />
        <attachments preset="hatsCity" />
    </type>

    Die zweite Möglichkeit sind eben wieder explizit ausgewählte Objekte, welche auch wie bei der "cargo" Variante

    mit einer Wahrscheinlichkeit in "%" angegeben werden.

    Code
        <type name="PersonalRadio">
        <attachments chance="0.30">
            <item name="Battery9V" chance="1.00" />
        </attachments>
    </type>

    Bei diesem Bsp. haben wir das "PersonalRadio", also das Funkgerät, welches zu "30 %" eine Batterie enthalten kann.

    Wie man auch sehen kann, wurde hier wieder mit einer zusätzlichen Wahrscheinlichkeit für dieses Objekt eine Chance von "100 %" angelegt,

    Womit wir wieder beim obigen Thema währen.

    Ich hoffe aber ich muss das jetzt nicht nochmal groß aufgreifen, sondern wissen,

    dass wir hier einfach eine definitive Chance von "30 %" auf unser Objekt haben 😅.


    Dieses Prinzip lässt sich auch wieder auf mehrere Objekte erweitern, wie es z.B. bei den "preset" der Fall wäre.

    Als Beispiel nehmen wir hierfür die "VSS".

    Code
        <type name="VSS">
        <attachments chance="1.0">
            <item name="PSO11Optic" chance="1.00" />
        </attachments>
        <attachments chance="0.35">
            <item name="Mag_VSS_10Rnd" chance="0.50" />
            <item name="Mag_VAL_20Rnd" chance="0.35" />
            <item name="Mag_Vikhr_30Rnd" chance="0.15" />
        </attachments>
    </type>

    Jede "attachments" Eintrag zählt hier auch nur für einen Slot, welcher mit einem in dieser Auswahl hinterlegten Objekte spawnen kann.

    Es ist hier nur wichtig zu beachten, dass wir unser Objekt, welches wir somit bestücken wollen kennen,

    da es nur für einen Slot auch nur eine "attachments" Auswahl gibt.

    Das Spiel sucht sich die passenden Ausrüstungsslots selber, darum müssen wir uns nicht kümmern.

    Wichtig ist nur, dass wir nicht wie im nachfolgenden Bsp. mehrere Objekte, die an den gleichen Slot gehören oder sollen, einzeln eintragen.

    Es könnte zwar passieren, dass eines der Objekte am richtigen Slot abgehangen wird, ist aber nicht Sinn und Zweck der Sache 😅.


    Sooooo mit o, das sollte es glaube ich im Großen und Ganzen gewesen sein glaube ich.

    Falls mir doch nochmal was auffallen sollte, würde ich das natürlich nochmal nachtragen,

    aber ich glaube, das sollte auch erst mal genug für dieses Thema sein.

    Wie erwähnt gehen wir im Nachfolgenden Thema cfgrandompresets.xml näher auf die "preset" Möglichkeiten ein

    Und würde mich somit bei diesem Thema Verabschieden, Freue mich wie immer über eure Geduld,

    eure Zeit und Interesse, bis zum Nächsten Thema 😁.

    3 Mal editiert, zuletzt von derKobold1987 (8. Mai 2025 um 21:17)

    Thema:


    cfgrandompresets.xml

    Auch hier wieder ein Herzliches willkommen beim nächsten Thema 😁.

    Es wird auch hier wieder ein wenig trocken, wie es eigentlich bei fast allen Dateien ist,

    weshalb ich mich auch zuerst ein wenig entschuldigen muss 😅.

    Fangen wir aber erst mal damit an, wofür die cfgrandompresets.xml gedacht ist.

    Würde man es vereinfacht ausdrücken, wäre es die Beschreibung auf der Rückseite einer Mystery-Box oder auf einem Booster-Pack von Sammelkarten,

    mit den möglichen Inhalten 🤣.

    Also eine Auflistung für mögliche Objekte, die in Objekten auftauchen können

    und in der cfgspawnabletypes.xml festgelegt werden.

    Fangen wir wie immer mit den Grundbeispielen an.

    Wie man hoffentlich sehen kann, haben wir hier in erster Linie nur 2 wichtige Grundklassen, zwischen denen wir unterscheiden müssen.

    Zum einen haben wir wieder die "cargo" und unsere "attachments", welche eben wie schon in der cfgspawnabletypes.xml erwähnt,

    für Inventar und Slots stehen.

    Ebenso haben wir auch wieder eine Grundwahrscheinlichkeit, mit der festgelegt werden kann, wie hoch diese eben überhaupt sein soll,

    dass ein Objekt hervorgebracht wird.

    Diese wird eben je nach Art, die wir haben möchten entweder mit "cargo chance="0.1" name=" für Inventar-Objekte angegeben

    oder mit "attachments chance="0.30" name=" für Slot Objekte.

    Es gilt natürlich wieder "0.1" = "10 %" 😉.

    Bei Inventaren gilt natürlich auch hier wieder die Größe zu beachten, da es nichts bringt ein Fass in einem Rucksack zu packen 🤣.

    Auch hier ist natürlich wichtig zu erwähnen, dass es nur eine Auswahl an Objekten ist, von denen am Ende auch nur eines ausgewählt wird.

    Das Ganze wird auch hier wieder mit einer Wahrscheinlichkeit in "%" angegeben, wobei sich hier wieder die Geister streiten könnten,

    was die Berechnung angeht 😅.


    Kommen wir aber nun ein wenig zur Berechnung.

    Ich für meinen Teil halte mich hier wieder an die "100 %" Regel, welche ich auch schon in der cfgspawnabletypes.xml erwähnt habe.

    Aufgrund der einzelnen Vanilla Einstellungen, bin ich mir nicht ganz sicher, ob diese Berechnung hier im selben Maße stattfindet.

    Dies liegt daran, dass es "presets" gibt, die eben die "100 %" Übersteigen.

    Es kann sich dabei um Schreibfehler handeln, Absicht, da eben hier anders gerechnet wird oder weiß der Geier.

    Von daher würde ich es hier mit beiden Varianten versuchen zu erklären, wovon man sich die Variante

    die man für sich eben als logischer oder ansprechender empfindet, auswählen kann.


    Fangen wir am besten mit der Variante an, bei der die "100 %" Regel nicht zutreffen würde.

    Dabei würde man ganz einfach die Chance jedes Objektes seinen Wünschen anpassen und ggf. neue Objekte an das Ende eines "presets" stellen,

    Ich hoffe, es versteht sich von selbst, dass es vor "</cargo>" gestellt wird 😅.

    Wir können einfach eine beliebige Wahrscheinlichkeit einfügen, die wieder mit einem Wert zwischen "0.01" für 1 % und "1.00" für 100 % angegeben wird.

    Der Unterschied zur "100 %" Regel wäre hierbei, dass nur die Chance jedes Items einzeln berücksichtigt wird und je nach Objekt

    die Chance höher oder niedriger wäre.

    Warum das Ganze für mich allerdings etwas unlogisch klingt, wäre ein Vergleich zu D&D, P&P oder ähnlichen Spielen,

    bei denen die Chance ausgewürfelt wird.

    Machen wir es mal an einem Praktischen Bsp. und stellen uns vor, das jeder Prozent, also alle "1 %" ein würfel gewürfelt werden muss,

    der uns die Zahl 6 anzeigen muss. Am Ende ist natürlich das Objekt der Gewinner, welches am häufigsten die 6 gewürfelt hat.

    Jetzt nehmen wir erst mal das Bsp. "mixArmy" und kürzen es ein wenig.

    Code
            <cargo chance="0.1" name="mixArmy">
                <item name="SodaCan_Cola" chance="0.05" />
                <item name="TunaCan" chance="0.1" />
        </cargo>

    Unser Bsp. hätte jetzt 2 Objekte, welche zur Auswahl stehen, einmal mit dem Wert "0.05", also 5 %

    und einmal den Wert "0.1" und somit 10 %.

    Das würde also bedeuten, dass "SodaCan_Cola" jetzt 5-mal würfeln darf und "TunaCan" 10-mal.

    Jetzt wäre also die Frage, welches Objekt die bessere Chance hätte eine oder mehrmals eine 6 zu würfeln.

    Ich hoffe, man sieht ein wenig worauf ich hinaus möchte und nehme jetzt mal die komplette "mixArmy".

    Wenn wir hier durchrechnen oder zählen, haben wir 3 mal 20 Würfelversuche,

    3 mal 10 Versuche und 10 mal 5 Versuche.

    Lässt man sich das mal durch den Kopf gehen, oder probiert es selber mal aus,

    dann versteht man glaube ich, was ich meine, denn mit jedem Objekt was wir hinzufügen würden,

    eventuell mit einem Wert von "0.2", würde es die Chance für andere Objekte

    mit niedrigerem Wert so massiv verschlechtern, dass diese irgendwann kaum

    oder gar nicht mehr hervorgebracht werden.

    Ich kann mich um Gotteswillen auch Irren, und wer möchte, kann mich gerne immer berichtigen.

    Aber kommen wir deshalb gleich zu der "100 %" Regel Variante um eben den Unterschied zu erklären.


    Das Prinzip bleibt natürlich jetzt dasselbe, "1 %" = ein Würfel.

    Schauen wir uns wieder die "mixArmy" an und rechnen uns das ganze mal zusammen, hätten wir Folgendes.

    (3 x 20) + (3 x 10) + (10 x 5) = 140

    Gehen wir nun davon aus, dass wir uns nach den 100 % richten müssten wir also alles so anpassen,

    dass wir eben auf unsere 100 kommen, aber in etwa dieselben Chancen haben.

    Klar, das Ergebnis wäre in etwa dasselbe, aber es ist meiner Ansicht nach einfach nur fairer verteilt.

    Am Ende haben wir nach der neuen Berechnung nun wieder unsere "100 %" verteilt und habe es folgendermaßen angepasst.

    (3 x 10) + (3 x 8 ) + (6 x 5) + (4 x 4) = 100

    Ich hoffe das man dies so ein wenig verstehen kann, auch wenn es kein Würfelspiel ist 😅🤣.

    Aber so ließ es sich, glaube ich, gerade am einfachsten erklären bzw. vergleichen.

    Um Gotteswillen soll jetzt natürlich niemand los dackeln und alles in der cfgrandompresets.xml anpassen.

    Das ist ja auch nicht Sinn und Zweck der Sache, es soll nur aufzeigen wie es berechnet oder

    dargestellt werden kann, um zu zeigen, was eventuell passiert, wenn wir permanent Objekte anhängen.

    Weder ist das eine noch glaube ich ist das andere Falsch und wer es genau erklären kann, darf dies natürlich machen.

    Wichtig ist am Ende, egal wie der Server oder das Spiel das ganze berechnet oder auswürfelt,

    dass Spieler dafür belohnt werden, wenn sie z.B. einen Infizierten meucheln.

    Es sollte einfach eine faire Chance bestehen, dass Objekte tatsächlich gefunden werden,

    egal wie hoch oder niedrig wir Objekte somit in ihrer Wahrscheinlichkeit einstellen.


    Aber jetzt nochmal kurz zum Kern der Sache 😅.


    Wie wir nun wissen, haben wir zum einen die Wahrscheinlichkeit, dass überhaupt ein Objekt vorhanden ist

    und zum anderen die Wahrscheinlichkeit für jedes einzelne Objekt.

    Wir wissen, dass nur eines aus dieser Auswahl genommen wird,

    da die Anzahl der Objekte über die cfgspawnabletypes.xml geregelt wird.

    Mit "cargo" können wir Objekte in ein Inventar legen lassen, wobei hier wie gesagt die Inventar- und Objektgröße zu berücksichtigen ist.

    Bei "attachments" hingegen sind eben wieder unsere Slots und Objekte zu berücksichtigen.

    Wir sollten kein Objekt nehmen und in eine Auswahl einfügen, die anschließend nicht an den gewünschten Slot passen.

    Das Objekt würde halt nicht auftauchen, weshalb also eine Dose Cola an einem Slot für Brillen keinen Sinn ergibt 🤣.


    Wir können somit neue "presets" erstellen und z.B. eines erstellen, welches jede Art von Nahrung beinhaltet.

    Als Bsp. nennen wir es jetzt einfach "foodAll" und nehmen einfach alles an essen oder Trinken in dieses Preset.

    Am Ende passen wir noch unsere Werte an und können dies, auch wenn ich hier jetzt nicht alles herausgesucht habe 😅,

    in die cfgrandompresets.xml aufnehmen.

    Anschließend können wir uns in der cfgspawnabletypes.xml noch z.B. einen oder mehrere Infizierte aussuchen,

    die diese Auswahl enthalten sollen, (Es geht natürlich alles, was ein Inventar hat, sei es Auto oder Rucksack)

    was in der cfgspawnabletypes.xml also so aussehen kann.

    Code
        <type name="ZmbF_Clerk_Normal_Blue">
        <cargo preset="foodCity" />
        <cargo preset="foodAll" />
        <cargo preset="toolsCity" />
        <cargo preset="toolsCity" />        
        <attachments preset="glassesCity" />
        <attachments preset="hatsCity" />
    </type>

    Dasselbe Prinzip gilt natürlich für die "attachments", was ich jetzt aber nicht weiter ausschweifen werden 😅.


    Ich hoffe aber, dass das Prinzip verstanden wurde und bedanke mich natürlich wie immer für Zeit,

    Geduld und euer Interesse.

    Hoffe, es war nicht allzu kompliziert und wünsch jedem Spaß beim Aus- und Herumprobieren 😁.

    Wir sehen oder lesen uns beim nächsten Thema 😉

    3 Mal editiert, zuletzt von derKobold1987 (24. März 2025 um 20:25)

    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 😁.

    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.

    K1Hzda5.png

    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.

    Hallo zusammen und willkommen liebe Gemeinde,

    auch heute haben wir uns hier wieder zusammengefunden,

    um den Server Files zu Huldigen

    und sein täglich Opfer darzubringen 🤣😂😅.


    Nein, Spaß bei Seite, wir kommen ab hier zum nächsten großen Abschnitt,

    den ich auch hier nochmal wie gewohnt mit einer Art Inhaltsverzeichnis versehe.

    Befassen werden wir uns ab hier mit dem Environment und der Umgebung,

    allem was sich rund um den Spieler, auf der Karte oder sonst wo herumtreibt oder abspielt.

    Machen wir uns aber wieder den Spaß und teilen unser Verzeichnis ein und legen die einzelnen Dateien fest.

    Da ich mir wieder grob eine Reihenfolge festgelegt habe, kann man sich also entweder gemütlich

    von nach hinten durcharbeiten oder hier einfach wieder das passende oder gewünschte Thema herauspicken.

    Fangen wir aber auch gleich ohne weitere Umschweife an 😁.

    Als Erstes haben wir hier die cfgenvironment.xml,

    die als eine Art Grundpfeiler und Grundkonfiguration für Tiere dient.

    Als Nächstes folgt die territories.xml,

    mit Koordinaten für Tier und Zombie Gebiete.

    Die nächste wäre die cfgeventgroups.xml,

    welche einzelne vordefinierte Event Gruppen beinhaltet.

    Gefolgt von einer ähnlichen Datei namens cfgeffectarea.json,

    als Konfigurationsdatei für Statische toxische Zonen.

    Die Datei cfgundergroundtriggers.json,

    für Konfigurationen von Lichtverhältnissen.

    Anschließend haben wir die mapgroupdirt.xml,

    mit Positionen für Kartengruppen.

    Die nächste wäre die mapgroupproto.xml,

    mit Positionen für Loot spawn Punkten in, an und um Objekte.

    Anschließend haben wir die mapgrouppos.xml,

    welche Koordinaten für alle Kartenobjekte enthält, die Loot hervorbringen können.

    Gefolgt von der mapclusterproto.xml,

    mit Positionen für Loot spawn Punkten in der Natur und Naturobjekten.

    Als Nächstes hätten wir noch die mapgroupcluster.xml,

    mit Koordinaten von Naturobjekten, die Loot hervorbringen können.

    Die cfgweather.xml,

    welches als unser Wetterkontrollzentrum darstellt.

    Anschließend noch die cfgplayerspawnpoints.xml

    mit Spawn Punkten für Spieler.

    Und als Letztes noch die messages.xml,

    für Server Nachrichten.


    In der Hoffnung ich habe jetzt nichts vergessen,

    widmen wir uns wieder nach und nach den einzelnen Themen,

    hoffe natürlich auch auf weiteres Interesse

    und bedanke mich auch schon mal im Vorfeld

    für euer Interesse und Durchhaltevermögen 😅🤣.

    4 Mal editiert, zuletzt von derKobold1987 (3. Juli 2025 um 19:53)

    Thema:


    cfgenvironment.xml

    Dann legen wir mal los und wünsche hiermit allen Interessierten und Lese lustigen ein herzliches Willkommen 😁.

    Hier haben befassen wir uns ein Wenig mit den Grundeinstellungen für KI gesteuerte Objekte, wenn man es so möchte.

    Also unsere netten Infizierten und alles was an Tieren die Umgebung unsicher macht.

    Hierfür haben wir wieder unsere Grunddatei, welche ich dieses Mal auch im Kompletten nehme

    und wir anschließend wieder alles einzeln durchgehen.

    Nun haben wir wieder mehrere einzelne Abschnitte, wenn man es so möchte,

    die wir bearbeiten können oder müssen, aber am Ende auch wieder alle miteinander spielen.


    Als Erstes haben wir folgenden Abschnitt.

    Dabei handelt es sich im Prinzip um eine Liste und den Verweis der einzelnen Dateien,

    welcher für unsere Gebiete verantwortlich sind.

    Hier müssen wir uns in erster Linie wieder unseren Server Aufbau bzw. unsere Ordnerstruktur ins Gedächtnis rufen,

    welcher ich schon im ersten Beitrag erwähnt habe.

    Wer sich also erinnern kann, wird folgende Zeile wiedererkennen.

    Bsp.: "Basisverzeichnis\mpmissions\dayzOffline.chernarusplus\db"

    Hier ist allerdings nicht der Ordner "db", sondern der erwähnte "env" Ordner wichtig,

    weshalb unsere Ordnerstruktur also folgende ist.

    "Basisverzeichnis\mpmissions\dayzOffline.chernarusplus\env"

    Da sich das Spiel immer auf das Verzeichnis unserer genutzten Karte bezieht, müssen wir hier nicht unseren kompletten Pfad angeben.

    In der Theorie kann auch ein neuer Ordner erstellt werden, um z.B. neue oder eigene Gebiete zu erstellen.

    Es ist nur wichtig, dass dieser als neuer "path=" angegeben wird.

    Aber erst mal schnell zurück zum Original, denn jeder Pfad führt zu einer Datei, welche Spawn Punkte unserer KI Objekte enthält.

    Konkret auf diese Dateien, gehen wir im Thema: "territories.xml" ein, Erwähnen schadet ja aber nicht 😅.

    Jede dieser Dateien hat also seinen Zweck und kann gern für neue Projekte als Vorbild genutzt werden.

    Wichtig ist dabei natürlich, dass alles an Pfaden und Namen übereinstimmt.

    Dafür erschaffen wir zur besseren Anschauung ein einfaches Bsp. und stellen uns vor, wir hätten "Igel".

    Ob Englisch, Deutsch oder eine Abkürzung spielt erst mal keine Rolle.

    Von daher heißen sie jetzt auch für dieses Beispiel einfach "Igel" 🤣.

    Als Datei würden wir diese also "igel_territories.xml" nennen und hätten jetzt die Möglichkeit diese in das Vanilla

    oder einem neuen Verzeichnis abzulegen.

    Bei der Vanilla Variante würde sich nichts ändern, sondern müsste lediglich ein neuer Eintrag angelegt werden

    und entsprechend angepasst werden, was am Ende einfach folgendermaßen aussehen kann.

    Würden wir ein neues Verzeichnis anlegen, welches wir jetzt einfach mal "new" nennen, würde es wiederum folgendermaßen aussehen.

    Egal für welchen Weg wir uns entscheiden, ist nun eine weitere Entscheidung wichtig, und zwar die Art und Weise.

    Vanilla und Spieltechnisch wird in 2 oder 3 Unterschieden, wenn es darum geht, wie die KI auf die Karte gebracht werden.

    Um das etwas besser zu erklären, nehmen wir einfach die Beispiele Huhn (Ambient), Wolf (Herd) und Infizierte.

    Zusätzlich klären wir natürlich auch gleich den Unterschied zwischen "Herd" und "Ambient", um diesen Aspekt mit abzudecken.

    Der Wolf ist im Prinzip immer vorhanden. Er hat Spawn Punkte, welche einfach immer zufällig belegt werden.

    Wir als Spieler laufen eben einfach in ein Gebiet, in dem sie sich gerade befinden und haben einfach den Salat 😅.

    Aber sie sind eben einfach da, was, wie wir jetzt wissen, für alle Tiere zutrifft, die mit "type="Herd" angegeben sind.

    Das Huhn hingegen, welche uns als Spieler eben auch als Nahrungsquelle dienen soll, wird eben zufällig hervorgebracht,

    wenn wir uns einem Spawn Punkt nähren. Sie sind oder werden also nur durch uns als Spieler hervorgebracht

    und werden nicht permanent an irgendwelchen stellen nach gespawnt.

    Wie also bei "Herd" gilt hier das Prinzip, dass es auf alle Tiere zutrifft, welche mit "type="Ambient" angegeben werden.

    Infizierte sind da nochmal ein Ding für sich, da diese im Grunde beide Wege kombinieren.

    Es gibt welche, die immer vorhanden sind und zusätzliche Infizierte, die wir als Spieler hervorbringen,

    wenn wir uns eben einem Spawn Punkt nähren.

    Da wir dies nun wissen, können wir nun zum nächsten Abschnitt übergehen und schauen uns diesen auch gleich am Beispiel Wolf an.

    Code
            <territory type="Herd" name="Wolf" behavior="DZWolfGroupBeh">
            <file usable="wolf_territories" />
        </territory>

    Wir haben hier also 4 Einträge, welche für diese Art von Tier-Spawns wichtig sind.

    territory type="Herd" =====> Gebietstyp

    Dieser gibt eben unsere oben beschriebenen Typen "Herd" oder "Ambient" an.

    name="Wolf" =====> Gebietsname

    Welcher eben den Namen unseres Gebietes angibt.

    behavior="DZWolfGroupBeh =====> Tierverhalten

    Womit wir das Verhalten der Tiere festlegen können.

    file usable="wolf_territories" =====> Verwendete Datei

    Welche auf die im ersten Abschnitt festgelegte Datei verweist.

    Mehr benötigen wir im Prinzip für ein mit "Herd" hervorgebrachtes Tier nicht,

    womit wir nun auch gleich zum Huhn übergehen.

    Hier haben wir wieder unsere Grundangaben Gebietstyp bis zur verwendeten Datei,

    weshalb ich diese jetzt nicht noch einmal aufliste,

    sondern gleich zu den nachfolgenden Einstellungen komme.

    Dabei haben wir einmal folgendes.

    Code
                <agent type="Male" chance="1">
                <spawn configName="Animal_GallusGallusDomesticus" chance="1" />
            </agent>

    Hier haben wir nun folgende 2 Zeilen

    agent type="Male" chance="1" =====> Geschlecht und Spawn Wahrscheinlichkeit

    Hierbei wird festgelegt zu welchem Geschlecht das nachfolgende Tier gehört

    und je nach Anzahl, wie viele dieser Tiere erscheinen können.

    spawn configName="Animal_GallusGallusDomesticus" chance="1" =====> Tierdefinition und Spawn Wahrscheinlichkeit

    Damit werden die in der "types.xml" festgelegten Tiere definiert, welche eben hierfür zutreffend sind

    und eben ihre Spawn Wahrscheinlichkeit.

    In diesem Fall haben wir also "Male" für Männlich mit seiner Wahrscheinlichkeit,

    dass eben eines dieser hier aufgelisteten Tiere tatsächlich erscheint.

    Danach haben wir als männliche Vertreter "Animal_GallusGallusDomesticus" als Hahn,

    der ebenfalls mit einer Wahrscheinlichkeit festgelegt wurde.

    Selbes Spiel noch einmal allerdings mit neuen Werten, haben wir natürlich noch die Variante in der weiblichen Form.

    Code
                <agent type="Female" chance="3">
                <spawn configName="Animal_GallusGallusDomesticusF_Brown" chance="1" />
                <spawn configName="Animal_GallusGallusDomesticusF_Spotted" chance="10" />
                <spawn configName="Animal_GallusGallusDomesticusF_White" chance="20" />
            </agent>

    Auch hier gelten die erwähnten Regeln, Werte und Definitionen.

    agent type="Female" chance="3" =====> Geschlecht und Spawn Wahrscheinlichkeit

    Hier wird wieder, zu welchem Geschlecht das nachfolgende Tier gehört

    und je nach Anzahl der Tiere, wie viele dieser Tiere erscheinen können.

    spawn configName="Animal_GallusGallusDomesticusF_Brown" chance="1" \

    spawn configName="Animal_GallusGallusDomesticusF_Spotted" chance="10" =====> Tierdefinition und Spawn Wahrscheinlichkeit

    spawn configName="Animal_GallusGallusDomesticusF_White" chance="20" /

    Wie auch beim männlichen Vertreter wird hier das in der "types.xml" festgelegte Tiere definiert,

    und eben ihre entsprechende Spawn Wahrscheinlichkeit.

    Wir haben hier also wieder unser Geschlecht, welches mit "Female" für Weiblich angegeben ist

    und wieder eine entsprechende Wahrscheinlichkeit.

    Zusätzlich haben wir die Definitionen für die weiblichen Vertreter "Animal_GallusGallusDomesticusF_Brown",

    "Animal_GallusGallusDomesticusF_Spotted" und "Animal_GallusGallusDomesticusF_White" als Hühner

    und wir haben die angegebenen Wahrscheinlichkeiten.

    Da es auch für mich etwas verwirrend ist, würde ich für folgendes nicht meine Hand ins Feuer legen

    und das ganze auch nur als eine Theorie abstempeln, was die Wahrscheinlichkeiten angeht.

    Aufgrund dessen, wie hier die Werte angegeben sind, würde ich es eher als eine Art Häufigkeit definieren.

    Im Falle von "Male" würde es also anhand der Werte bedeuten, dass es einen Hahn als Vertreter gibt,

    welcher auch nur 1 Mal vorhanden sein darf.

    Gäbe es 2 männliche Vertreter, dürfte also nur einer dieser Hähne spawnen,

    weshalb im Falle von "Female" 3 Vertreter angegeben sind, und somit alle vorhanden sein können.

    Darunter "Animal_GallusGallusDomesticusF_Brown" z.B. nur einmal,

    "Animal_GallusGallusDomesticusF_Spotted" bis zu 10 Mal

    und "Animal_GallusGallusDomesticusF_White" bis zu 20 Mal.

    Um das ganze meiner Logik nach auch damit weiter zu erklären, müssen wir nun zu dem Teil kommen,

    welcher meine Theorie ein wenig unterstützt.

    Code
                <item name="globalCountMax" val="50" />
            <item name="zoneCountMin" val="1" />
            <item name="zoneCountMax" val="1" />
            <item name="playerSpawnRadiusNear" val="25" />
            <item name="playerSpawnRadiusFar" val="75" />

    item name="globalCountMax" val="50" =====> Maximale Anzahl an Objekten in der Welt

    Hier wird die maximale Anzahl unserer gesamten Hühner festgelegt, welche auf der Karte vorhanden sein können,

    was also für mich die oben genannten Werte und logische Erklärung wäre.

    Hoffe nur, das kann man auch soweit nachvollziehen 😅.

    name="zoneCountMin" val="1" =====> Minimale Objektanzahl in einer Zone

    name="zoneCountMax" val="1" =====> Maximale Objektanzahl in einer Zone

    Diese beiden Zeilen geben an, wie viele Hühner minimal und maximal pro Zone bzw. Event vorhanden sein dürfen.

    name="playerSpawnRadiusNear" =====> kürzeste Spawn Entfernung zum Spieler in "m"

    name="playerSpawnRadiusFar" =====> weiteste Spawn Entfernung zum Spieler in "m"

    Hier bin ich mir wieder unsicher, würde aber meinen, dass es eben die Spawn Entfernung zu einem Spieler

    sein könnte, welche eben eine Art Radius festlegt, ob und wann eines der Hühner auftauchen kann.

    Somit kann festgelegt werden, ob wir uns zu nah an einem solchen Spawn Punkt aufhalten

    oder noch zu weit entfernt sind.

    Das war es glaube ich auch im Großen und Ganzen was das Huhn angeht,

    weshalb wir jetzt gleich zur nächsten "Ambient" Typ übergehen.

    Code
            <territory type="Ambient" name="AmbientHare" behavior="DZAmbientLifeGroupBeh">
            <file usable="hare_territories" />
            <agent type="Male" chance="1">
                <spawn configName="Animal_LepusEuropaeus" chance="1" />
            </agent>
            <agent type="Female" chance="1">
                <spawn configName="Animal_LepusEuropaeus" chance="1" />
            </agent>
            <item name="zoneTouchDisableEditPeriodSec" val="300" />
        </territory>

    In diesem Bsp. sollten wir wieder ein paar bekannte Zeilen wiedererkennen,

    welche sich eben auch fast immer wieder wiederholen, weshalb ich mir erlaube

    auf diese Zeilen nicht nochmal so genau einzugehen.

    Als Kurzfassung daher haben wir wieder unseren "type="Ambient", "name" und "DZAmbientLifeGroupBeh".

    Unseren Dateiverweis und Hinterlegung der Männlichen und weiblichen Vertreter.

    Einzige Änderung ist hier also folgendes.

    Code
                <item name="zoneTouchDisableEditPeriodSec" val="300" />

    name="zoneTouchDisableEditPeriodSec" val="300" =====> Zonen Abklingzeit in "sec"

    Hiermit wird in Sekunden festgelegt, wann eine Zone wieder ein Tier hervorbringen kann,

    nachdem diese von allen Spielern verlassen wurde.

    Verlassen wir also alle einen bestimmten Bereich,

    dauert es 300 Sekunden bis ein Tier, in diesem Fall ein Hase,

    an dieser Position auftauchen kann.


    Damit hätten wir auch alles was man zum Thema "Ambient" Spawn sagen kann.

    Zumindest hoffe ich das ich nichts vergessen habe 😅🤞.


    Damit kommen wir zum letzten Teil, den Infizierten.

    Hier könnt man sich eigentlich sogar relativ kurzfassen und könnte das Prinzip vom "Herd" Typ wiederholen.

    Es sind tatsächlich wieder voranging, die ersten beiden Zeilen wichtig.

    Code
            <territory type="Herd" name="ZombieTest" behavior="DZdomesticGroupBeh">
            <file usable="zombie_territories" />

    Wir haben unseren "type", unseren "name", den "behavior" und unsere verwiesene Datei.

    Das ist, wenn man es so möchte, sogar das einzige, was man benötigt.

    Ich habe es getestet und alles ist auch so, wie wir es eben kennen.

    Infizierte kommen und gehen, und verhalten sich, wie sie eben sollen.

    Von daher bin ich mir bei dem Letzten abschnitt nicht sicher, was dieser Tatsächlich bewirken soll 😅.

    Da auch die Werte für die Anzahl der Infizierten in anderen Dateien definiert werden,

    weiß ich nicht, ob diese hier mit "0" angegebenen Werte für "countMin" und "countMax"

    für irgendeinen Grund wert stehen sollen, welche durch andere Dateien

    auf den eigentlichen Wert gebracht werden.

    Wenn es also Jemand genau erklären kann, dann bitte auch ich da gerne um die Hilfe zur Lösung des Rätsels 🤣.

    Alles Weitere sind daher nur Theorien, welche entweder noch Relikte aus älteren Tagen darstellt,

    oder die Versuche für eventuelle Horden.

    Wie gesagt, es sind nur Theorien 😅.


    Das war es dann aber tatsächlich auch und weise nochmal auf das hiermit verbundene Thema "events.xml" hin,

    in welchem die hier hinterlegten Tiere oder Infizierten als Event festgelegt werden

    und auf das Thema "territories.xml", in welchem die Spawn Punkte und jeweiligen Areale festgelegt werden.


    Damit endet auch dieses Thema und hoffe wie immer es war verständlich, bedanke mich für Interesse,

    Geduld und Eure Zeit 😁😅.

    Einmal editiert, zuletzt von derKobold1987 (8. Mai 2025 um 21:19)

    Thema:


    territories.xml

    Auch hier wieder ein herzliches Willkommen, zur heutigen Ausgabe der Serverfiles.

    Und hier die Themen 🤣.

    Nein Spaß, aber trotzdem willkommen beim Thema der "territories.xml".

    Dabei handelt es sich im Grunde nur um eine Art Koordinatenverzeichnis

    für die einzelnen KI-Objekte wie Tiere und Infizierte.

    Zu aller erst einmal aber müssen wir wissen, dass jedes Tier eben seine eigene Datei

    und somit sein eigenes Verzeichnis hat.

    Wir müssen uns also an folgendes aus der "cfgenvironment.xml" erinnern

    bevor wir hier richtig loslegen.

    Wenn wir also ein wenig nachzählen, gibt es 13 Dateien, die es hier anzuschauen gibt,

    welche wir aber, um das ganze abzukürzen, wieder ein wenig auf die oben erwähnten Arten herunterbrechen 😅.

    Dafür komme ich aber noch einmal zu einer Erwähnung aus meinem ersten Beitrag

    denn wenn wir noch etwas genauer hinschauen und unsere Dateien vergleichen,

    werden wir feststellen, dass es eine Datei namens "domestic_animals_territories.xml" gibt,

    aber keinen Eintrag in unserer Liste.

    Dies liegt wahrscheinlich daran, dass, wie in vielen Fällen, es sich um eine Veraltete

    und übriggebliebene Datei handelt.

    Daher ignorieren wir diese einfach mal und kommen zu den wichtigen und genutzten Dateien.

    Dafür nehmen wir uns einfach aus jeder Datei mal auf die schnelle eine der sogenannten "territories" heraus.

    (Ich gehe hier nach Datei und alphabetischer Reihenfolge vor und passe den Inhalt ggf. ein wenig an)

    bear_territories.xml = Bären Spawn Punkte 🐻

    Code
        <territory color="4294923520">
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="1920" z="13115" r="100"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="2085" z="13415" r="200"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="2465" z="14005" r="150"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="2485" z="14580" r="150"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="2780" z="14350" r="150"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="3260" z="14625" r="150"/>
    </territory>

    cattle_territories.xml = Rinder Spawn Punkte 🐮

    Code
        <territory color="864420070">
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="5300.23" z="10531.7" r="90"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="5593.11" z="10450.3" r="195"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="5926.86" z="10824.9" r="150"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="6082.11" z="10669.7" r="82.5"/>
        <zone name="Water" smin="0" smax="0" dmin="0" dmax="0" x="6182.73" z="10538.1" r="90"/>
    </territory>

    fox_territories.xml = Fuchs Spawn Punkte 🦊

    Code
        <territory color="4294945280">
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="322.5" z="2426.25" r="50"/>
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="247.5" z="2681.25" r="50"/>
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="1593.75" z="2355" r="50"/>
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="1612.5" z="2812.5" r="50"/>
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="2111.25" z="3123.75" r="50"/>
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="2280" z="2921.25" r="50"/>
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="2201.25" z="2621.25" r="50"/>
        <zone name="Zone_fox" smin="0" smax="0" dmin="0" dmax="2" x="1890" z="3303.75" r="50"/>
    </territory>

    hare_territories.xml = Hasen Spawn Punkte 🐰

    Code
        <territory color="4289352960">
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="1661.25" z="2288.75" r="50"/>
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="1305" z="2425" r="50"/>
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="1217.5" z="2442.5" r="50"/>
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="315" z="2530" r="50"/>
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="1570" z="3370" r="50"/>
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="1627.5" z="3267.5" r="50"/>
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="1637.5" z="3132.5" r="50"/>
        <zone name="Zone_Hare" smin="0" smax="0" dmin="0" dmax="2" x="1865" z="3305" r="50"/>
    </territory>

    hen_territories.xml = Hähne & Hühner Spawn Punkte 🐔

    Code
        <territory color="3556750600">
        <zone name="Zone_hen" smin="0" smax="0" dmin="0" dmax="2" x="4560" z="4590" r="112.5"/>
        <zone name="Zone_hen" smin="0" smax="0" dmin="0" dmax="2" x="4350" z="4680" r="112.5"/>
        <zone name="Zone_hen" smin="0" smax="0" dmin="0" dmax="2" x="3345" z="4927.5" r="105"/>
    </territory>

    pig_territories.xml = Hausschwein Spawn Punkte 🐷

    Code
        <territory color="872381884">
        <zone name="Water" smin="0" smax="0" dmin="0" dmax="0" x="7715.33" z="4921.17" r="50"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="7489" z="4745.67" r="60"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="7617.83" z="5101.67" r="60"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="7483" z="5017.17" r="50"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="7634.5" z="5182.5" r="60"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="7719.67" z="5044.5" r="50"/>
    </territory>

    red_deer_territories.xml = Rothirsch Spawn Punkte 🦌

    Code
        <territory color="856817408">
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="1034.5" z="11280" r="67.5"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="900.501" z="10756" r="100"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="541.001" z="10806.5" r="67.5"/>
        <zone name="Water" smin="0" smax="0" dmin="0" dmax="0" x="1665.5" z="10723.5" r="75"/>
        <zone name="Water" smin="0" smax="0" dmin="0" dmax="0" x="1793.88" z="11295.5" r="100"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="1052.5" z="10886.5" r="100"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="1572" z="10896" r="100"/>
    </territory>

    roe_deer_territories.xml = Hirsch Spawn Punkte 🦌

    Code
        <territory color="1090576876">
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="6581.67" z="4664.17" r="120"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="5822.14" z="4350" r="100"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="6390" z="4622.86" r="60"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="6210.71" z="4231.07" r="60"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="6553.86" z="4407.61" r="55"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="6150" z="4146.43" r="80"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="6239.29" z="4390.71" r="67.5"/>
        <zone name="Water" smin="0" smax="0" dmin="0" dmax="0" x="6791.25" z="4535.63" r="80"/>
    </territory>

    sheep_goat_territories.xml = Ziegen & Schaf Spawn Punkte 🐑🐐

    Code
        <territory color="872412928">
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="4592.14" z="11616.4" r="100"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="5108.57" z="11554.3" r="100"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="4737.86" z="11837.1" r="150"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="5117.14" z="11892.9" r="100"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="4662.86" z="11305.7" r="100"/>
    </territory>

    wild_boar_territories.xml = Wildschwein Spawn Punkte 🐗

    Code
        <territory color="2841534046">
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="9058.75" z="13568.8" r="60"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="9247.5" z="13934.4" r="80"/>
        <zone name="Graze" smin="0" smax="0" dmin="0" dmax="0" x="9436.25" z="13328.8" r="60"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="9830" z="13506.9" r="80"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="8838.75" z="13825" r="70"/>
        <zone name="Rest" smin="0" smax="0" dmin="0" dmax="0" x="8635" z="14320" r="60"/>
        <zone name="Water" smin="0" smax="0" dmin="0" dmax="0" x="9164.38" z="13298.1" r="67.5"/>
    </territory>

    wolf_territories.xml = Wolf Spawn Punkte 🐺

    zombie_territories.xml = Zombie Spawn Punkte 🧟

    Jetzt haben wir je nach Datei ein paar Sachen, die sich nicht grundlegend ändern

    sondern eventuell nur etwas anders nennen.

    Daher fassen wir das ganze ein wenig zusammen, um das ganze abzukürzen.

    territory color="" =====> Territorien Farbe

    Hiermit wird die Farbe der Territorien festgelegt und ist eigentlich eher

    für die Bearbeitung der "areaflags.map" und dem CE Editor wichtig.

    Um es ein optisch auch mal ein wenig darzustellen,

    ein Bild wie es in etwa gemeint ist, auch wenn dies ein wenig älter ist 😅.

    wf6Xqn9.jpeg

    Quelle: Reddit (Stand: 2019)

    smin="0" =====> Statische minimale Anzahl

    smax="0" =====> Statische maximale Anzahl

    Hier können wir mit einem Wert eine minimale und maximale Anzahl an Objekten festlegen.

    Dabei müssen wir beachten, mit welchen Werten wir z.B. unsere Tiere

    in der "events.xml" festgelegt haben.

    Da bei einem statischen Wert ab "smin="1" immer ein Objekt vorhanden ist,

    sollten wir hier also wieder ein klein wenig berechnen,

    wie viele Objekte haben wir festgelegt und wie viele Spawn Punkte haben wir.

    Hätten wir 250 Spawn Punkte für einen Polizeizombie

    aber hätten eine maximale Anzahl von 50 festgelegt.

    Würden hier jeden Spawn Punkt mit "smin="1" angeben,

    könnte es sein, das wir nur einen Infizierten an 50 Punkten hätten.

    Hinzu kommt natürlich wieder, das die Spawn Punkte immer mit Objekten befüllt werden,

    egal ob ein Spieler in der Nähe ist oder nicht.


    dmin="0" =====> Dynamische minimale Anzahl

    dmax="0" =====> Dynamische maximale Anzahl

    Hier gilt in etwa dasselbe Grundprinzip wie bei den statischen Objekten,

    nur das diese eher darauf ausgelegt sind, das wir als Spieler diese auslösen.

    Damit wird unter anderem dem Server die Last genommen, permanent KI zu berechnen,

    da diese nicht in Massen auf dem Server in allen Ecken umherwandert

    und eben berechnet wird.


    x="" =====> X Achse (Horizontal von links nach rechts)

    z="" =====> Z Achse (Vertikal von Unten nach Oben)

    r="" =====> Spawn Radius

    Wie auch schon in den "cfgeventspawns.xml" haben wir hier also unsere Koordinaten

    und einen Spawn Radius in dem unsere Objekte gespawnt werden können.


    Kommen wir nun noch zum letzten Punkt, denn dieser wird ein wenig schwieriger.

    zone name="" =====> Zonenname

    Hier können wir unseren Zonen einen Namen geben.

    Dabei gibt es hier allerdings ein paar Kleinigkeiten, die man eventuell beachten muss.

    Als Erstes haben wir "Zone_fox", "Zone_Hare" und "Zone_hen",

    welche grundlegend nur einen Spawn Punkt festlegen.

    Schauen wir uns die Dateien mal an, wird man sehen,

    dass ich hier nur einen Auszug eingefügt haben

    und das Original mit deutlich mehr Positionen ausfällt.

    Was aber im Vergleich zu z.B. den Bären oder Wölfen auffällt,

    ist hier die auf und Einteilung, da es sich nur um eine Auflistung der Punkte handelt.

    In diesen Fällen können wir uns wieder an unsere Unterschiede aus der "cfgenvironment.xml" erinnern,

    in der wir gelernt haben, dass "Ambient" durch uns Spieler ausgelöst wird.

    Damit ist hier also jeder Spawn Punkt ein potenzielles vorkommen dieser Objekte.

    Als Gegensatz dazu, haben wir noch unsere "Herd" Tiere,

    bei denen wir beim Hinschauen viele kleinere "territory" Gruppen finden.

    Diese haben unter anderem aber zusätzlich verschiedene Bezeichnungen.

    "Graze" = Grasen

    "Rest" = Ausruhen

    "Water" = Trinken

    "HuntingGround" = Jagdgebiet

    Es handelt sich zwar um ein Koordinatenverzeichnis,

    aber diese Bezeichnungen haben einen kleinen Hintergrund.

    Auch wenn die KI anderweitig in ihrem Verhalten festgelegt wird,

    wird damit das Verhalten an den jeweiligen Spawn Punkten bestimmt.

    Ein Wolf an einem "HuntingGround" Spawn Punkt rennt z.B. eher durch die Gegend

    auf der Suche nach Beute (Spielern 🤣) wohingegen er bei "Rest" Spawn Punkten

    eher langsamer unterwegs ist oder sich eben ausruht.

    Die erwähnten Gruppen dienen als Revier und lassen die KI der Tiere in diesem herum streunern.

    Im Bsp. der Wölfe bilden die Koordinaten also nicht nur die Spawn Punkte

    sondern stellen gleichzeitig ein Gebiet oder Revier dar, in dem sie sich bewegen.

    Je nach Server Neustart werden hier also nicht direkt die Spawn Punkte befüllt,

    sondern eben gleichzeitig je nach Anzahl und Einstellung die Rudel und Gruppen

    auf diese Gebiete aufgeteilt.

    Es ist also nicht jeder Spawn Punkt und auch nicht jedes Gebiet mit Wölfen ausgestattet,

    was also für alle Tiere zutrifft, die eben in diesen Dateien diese Art von Gruppen haben.


    Als letzte Kategorie haben wir nun noch unsere Infizierten,

    welche wieder eine andere Art von Verhalten haben.

    Natürlich haben wir wieder unsere bekannten Werte,

    aber es läuft eben ein wenig anders.

    Zu aller erst müssen wir wissen, dass es hier wieder funktioniert, wie bei den "Ambient" Spawns,

    was also bedeutet, dass diese wieder von uns Spielern ausgelöst werden,

    um eben die Server Performance zu gewährleisten.

    In ein Paar Fällen, gibt es hier allerdings auch Infizierte, welche immer vorhanden sind.

    Aufgrund der Masse an Infizierten, die wir auf einem Server haben können,

    haben wir hier also auch dementsprechend hohe Werte,

    die gerne mal von "dmin="15" bis "dmax="20" reichen.

    Wichtig ist hier nun noch die Bezeichnung "name=", welche sich im Gegensatz zu z.B. "Zone_fox",

    auf die in der "events.xml" definierten Event Gruppen bezieht und ihren darin definierten Inhalt.

    Als Bsp. nehmen wir hier auf die schnelle einen Auszug aus der "events.xml"

    Wie wir hier sehen haben wir das definierte Event und die Infizierten,

    die in dieser Gruppe enthalten und spawnen können.

    Somit ergibt sich also, das in jedem "territory", in welchem "InfectedArmyHard" enthalten ist,

    die in der "events.xml" festgelegten Infizierten auftauchen können.

    Wir legen also einen Spawn Punkt für eine ganze Gruppe von Infizierten fest,

    welcher wieder zufällig mit den festgelegten Werten bestückt wird.


    Im Großen und Ganzen, war es das glaube ich sogar schon und hoffe,

    ich habe nichts Vergessen 😅.

    Damit kommen wir nun zu den Sportmeldungen und dem Wetter 🤣.

    Nein, ich bedanke mich wie immer für Geduld, Zeit und Interesse,

    hoffe, es war soweit verständlich und freue mich,

    wenn auch beim nächsten Thema

    wieder eingeschaltet wird 😁😜🤣.

    Thema:


    cfgeventgroups.xml

    Und auch hier wieder ein Hallo zusammen und willkommen beim nächsten Thema 😁.

    Auf dem heutigen Lehrplan stehen Event Gruppen, welche wir nutzen können

    um Situationen oder Ereignisse auf die Karte zu bringen, die nicht permanent auf der Karte herumstehen.

    Sie können unseren Server und der Karte ein wenig Leben und den Spielern Überraschungen bieten

    und lassen die Welt im ganzen etwas Lebendiger wirken und gleichzeitig können wir damit Loot Punkte erschaffen,

    welche kostbare Beute hervorbringen können.

    Dadurch können Spieler in Bewegung gehalten werden, um nicht Trost und Motivation immer wieder

    dieselben Polizeigebäude oder Militärbaracken abzuklappern.

    Aber machen wir nochmal einen kleinen Ausflug in die Vergangenheit

    und werfen einen Blick auf die "cfgeventspawns.xml", um uns an eine kleine Sache zu erinnern.

    Code
        <event name="StaticTrain">
        <zone smin="0" smax="0" dmin="1" dmax="2" r="20" />
        <pos x="11254.230" z="3290.319" a="0" y="6.65" group="Train_Abandoned_Kamy"/>
        <pos x="13377.262" z="13919.888" a="0" y="17.247" group="Train_Abandoned_Svetlo"/>
        <pos x="12851.586" z="8577.874" a="0" y="6.567" group="Train_Accident_Nizhnoye"/>
        <pos x="13363.302" z="5439.232" a="0" y="8.0" group="Train_Accident_Solnichniy2"/>
        <pos x="1443.256" z="6622.697" a="0" y="176.220" group="Train_Mil_Metalurg"/>
    </event>

    Wenn wir uns daran erinnern, wissen wir hoffentlich wieder, dass es sich hier um die Koordinaten

    und die damit verbundene Position auf der Karte handelt, an der das Event stattfindet,

    so wie der Name der Event Gruppe.


    Wir möchten uns jetzt also der damit verbundenen Event Gruppe widmen

    und nehmen uns daraus auch gleich die Beispiele "Train_Abandoned_Kamy" und "Train_Abandoned_Svetlo".

    Zusätzlich nehmen wir uns aber für die Vollständigkeit eine andere Gruppe namens "Train_Accident_Dobroe".

    Event Gruppe "Train_Abandoned_Kamy":

    Event Gruppe "Train_Abandoned_Svetlo":

    Event Gruppe "Train_Accident_Dobroe":

    Wie wir wieder sehen ist im Grunde fast alles bis auf eine Ausnahme gleich aufgebaut,

    was auch nur den Grund hat, dass es sich hierbei wieder um eine Art Koordinaten Verzeichnis handelt,

    bei welchem jede einzelne Position, jedes einzelnen Objektes, welches wiederum zu diesem Event gehört

    hinterlegt wurde und nur mit ein paar Zusätzen versehen wurde.

    Anders als bei normalen Events, sind die hier hinterlegten Koordinaten allerdings keine Karten Koordinaten.

    Sie markieren nicht die Position auf der Karte, sondern sind eine relative Koordinate zum eigentlichen Event Objekt.

    Aber fangen wir erst einmal wieder langsam an und schauen uns die einzelnen Sachen an.

    Dazu müsste uns zu aller erst folgende Zeile auffallen.

    Code
        <!--pos x="11254.230" z="3290.319" a="0" y="6.513" group="Train_Abandoned_Kamy"/-->

    Wenn wir uns diese etwas genauer anschauen, sollte uns im Original auffallen, das diese ausgegraut ist.

    Was zum einen als Lesezeichen dient und zum anderen fast exakt aussieht, wie eine Zeile aus der "cfgeventspawns.xml".

    Code
        <pos x="11254.230" z="3290.319" a="0" y="6.65" group="Train_Abandoned_Kamy"/>

    Wenn wir mal zum Spaß beide Zeilen miteinander vergleichen und ein wenig anpassen,

    sollte uns noch ein kleiner Unterschied auffallen.

    Code
        <pos x="11254.230" z="3290.319" a="0" y="6.513" group="Train_Abandoned_Kamy"/>
    <pos x="11254.230" z="3290.319" a="0" y="6.65" group="Train_Abandoned_Kamy"/>

    Wie man sehen kann, ist der einzige Unterschied hier die "y=" Koordinate, welche die Höhe angibt.

    Wie kann man sich diesen Unterschied jetzt erklären? Und wie kann ich das am einfachsten erklären 😅.

    Man könnte sagen, dass diese Zeile als eine Art imaginärer Ankerpunkt dient,

    welcher eventuell bei der Erstellung des Events mit einem Objekt versehen wurde.

    Da es je nach Objekt zu kleineren unterschieden kommen kann, was die Platzierung

    und das spawnen angeht, muss eben geschaut werden, das eben diese auch richtig Positioniert werden.

    Im Regelfall wie Beispielsweise bei einem Hubschrauberabsturz das Objekt schon beim Event selbst vorhanden ist,

    muss man sich hier eben vorstellen, das hier Praktisch ein nicht vorhandenes Objekt gespawnt wird,

    welche alle in der gewählten Gruppe nach spawnt.

    Die nach gespawnten und zugehörigen Objekte werden anschließend beim Erscheinen,

    quasi am gesetzten Spawn Punkt ausgerichtet.

    Also hat das Objekt nicht die Koordinate der Karte, sondern ist eben als Bsp. 10 m

    vom gesetzten Spawn Punkt entfernt und ist von mir aus auch noch 2 m darüber 😅🤣.


    Da wir aber somit das Grundprinzip haben, wissen wir jetzt wie die Objekte auf die Karte gebracht werden.

    Somit können wir uns also den übrigen Zeilen und Werten zuwenden.

    group name="Train_Abandoned_Kamy" = Name der Event Gruppe

    Hier wird wie auch bei unserem "Ankerpunkt" erwähnt, der Name der Event Gruppe hinterlegt,

    welchen wir in der "cfgeventspawns.xml" angegeben haben.

    child type="StaticObj_Wreck_Train_742_Red_DE" = Name des zu spawnenden Objektes

    Hiermit werden die Objekte, welche wir in diese Gruppe spawnen lassen wollen, festgelegt.

    Dabei handelt es sich wiederum um Objekte, welche auch in der "types.xml" hinterlegt sein müssen.

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

    Wie schon in der "types.xml" erwähnt, können wir hier bestimmen,

    ob unser Objekt "Dynamischen Event Loot" enthalten darf.

    Wir halten also hier nochmal fest, dass wir in der "types.xml" festlegen,

    bei welchem Objekt es sich um solchen Loot handelt

    und in der "cfgeventgroups.xml" legen wir damit fest,

    ob dieses spawnen darf.

    lootmax="3" = maximale Anzahl an Loot um das Event Objekt

    lootmin="1" = minimale Anzahl an Loot um das Event Objekt

    Hier gilt wieder das Prinzip der "events.xml" womit wir also festlegen können,

    wie viele Objekte um oder an unserem Event Objekt spawnen sollen oder dürfen.

    Wichtig ist hier zu wissen, wonach sich das ganze hier richtet,

    denn es zählt jedes Event Objekt für sich und die jeweiligen Loot Positionen,

    beziehen sich hier auf die "mapgroupproto.xml".

    spawnsecondary="false"

    Hierbei hab ich leider nichts Genaues oder Handfestes.

    Gehe ich hier vom Logischen aus, hätten wir folgende Situation und Erklärung.

    Aufgrund dessen, dass alle hinterlegten Objekte mit diesem Eintrag keine Loot Positionen

    in der "mapgroupproto.xml" haben, wäre es also überflüssig, Zeilen dafür zu hinterlegen.

    Da in der "cfgeventgroups.xml" allerdings hinterlegt ist, das ein Event Infizierte hervorbringen kann

    und auch in der "events.xml" beispielsweise beim "StaticHeliCrash" eine Zeile mit "secondary" hinterlegt ist,

    jeder, der ein Event schon einmal gesehen hat weiß, das es mehr als nur einen Infizierten gibt,

    gehe ich zu 99 % davon aus das es sich hierbei um eine Einstellung handelt,

    die das spawnen von Infizierten deaktiviert.

    War ein langer Satz 😅, aber im Grunde wird zwar beim Event festgelegt, das es Infizierte hervorbringen kann,

    bei Event Gruppen ist es aber leider etwas anders.

    Dabei bezieht sich die Anzahl der möglichen Infizierten nicht auf das Event,

    sondern auf jedes in der Gruppe hinterlegte Objekt.

    Haben wir also eine Eventgruppe in der wir 2 Infizierte für das Event festlegen,

    bedeutet es, das wir bei einer Gruppe mit 4 Objekten 8 Infizierte haben können.


    Soweit so gut, nun haben wir nur noch unsere netten Koordinaten,

    die wir schon aus der "cfgeventspawns.xml" kennen

    und halbwegs am Anfang schon ein wenig behandelt haben.

    "x" = X Achse (Horizontal von Links nach Rechts)

    "z" = Z Achse (Vertikal von Unten nach Oben)

    "a" = Rotation des Objektes / Events

    "y" = Y Achse (Höhe zum 0 Punkt)

    Hier kommt aber noch einmal die relative Koordinate ins Spiel, denn wenn wir uns ein Bsp. nochmal anschauen,

    sollte uns noch Folgendes auffallen.

    Code
        <!--pos x="11254.230" z="3290.319" a="0" y="6.513" group="Train_Abandoned_Kamy"/--
    <group name="Train_Abandoned_Kamy">
        <child type="StaticObj_Wreck_Train_742_Red_DE" deloot="0" lootmax="3" lootmin="1" x="0" z="0" a="232.116" y="1.9"/>
        <child type="Land_Train_Wagon_Box_DE" deloot="0" lootmax="3" lootmin="2" x="10.519" z="7.484" a="56.981" y="1.359"/>

    In 99 % der Fälle ist das erste Objekt der Mittelpunkt und hat "x="0" z="0" als Koordinate.

    Alle nachträglichen Objekte richten sich also wie schon erwähnt am Mittelpunkt des Events aus.

    Somit weiß man und erklärt sich hoffe ich, das die nachfolgenden Objekte

    eben von diesem Mittelpunkt aus an ihre Position gebracht werden.


    Dies sollte für heute reichen und sollte eigentlich auch weitestgehend alles sein.

    Ich hoffe, ich hab nichts Vergessen und bedanke mich wie immer für eure Aufmerksamkeit

    und wir sehen uns damit also im nächsten Thema 😁👍.

    Thema:


    cfgeffectarea.json

    Wie immer ein herzliches Willkommen beim heutigen Teil der Sendung 😁🤣.

    Heute im Programm, die toxischen Zonen.

    Also immer schön die Gasmasken aufsetzen, Schutzkleidung anlegen

    und gerne den POX-Pen bereithalten 🤣.

    Aber legen wir mal los, denn diese Datei beinhaltet 2 wichtige Dinge.

    Zum einen befasst und enthält sie statische Positionen für toxische Zonen

    und zum anderen Koordinaten für sichere Log-in Positionen, für den Fall,

    ein Spieler hat sich in einem Gebiet ausgeloggt,

    an der eine toxische Zone auftauchen kann.

    Damit sichergestellt werden kann, dass Spieler, die keine Ausrüstung haben,

    sich nach ihrem Log-in in einer toxischen Zone wiederfinden

    und eines grauenhaften Todes sterben müssen,

    nur weil sie mal eben eine Pause einlegen mussten,

    werden sie für diese Fälle außerhalb einer Zone gespawnt.

    Damit wir diesen Teil, da er relativ simpel ist, auch gleich abhaken können,

    hier wieder der alt bekannte Inhalt 😅.

    Wie der Name "SafePositions" schon vermuten lässt, handelt es sich hier um die besagten sicheren Spawn Punkte.

    Diese sind, wie man sehen kann, ganz simpel aufgelistet und beinhalten nichts anderes als 2 Koordinaten,

    welche die "x" und "y" Koordinaten sind.

    (Wir müssen hier leider 2-Dimensional denken, deswegen ist es dieses mal nicht die "z" Koordinate 😅).

    "x" = X Achse (Horizontal von links nach rechts)

    "y" = Y Achse (Vertikal von Unten nach Oben)

    Wenn man sich die Karte mal ein wenig genauer anschaut, sehen wir wie weit ein solcher Spawn Punkt entfernt ist

    und nicht grundsätzlich jede Zone einen solchen Punkt braucht.

    AbaN05A.jpeg


    Dies sollte in der Regel daran liegen, dass in diesen Fällen der nächstgelegene Punkt ausgewählt wird,

    was also bedeutet, dass ein Spieler, der sich in Tisy ausgeloggt hat und sich einloggt,

    während eine toxische Zone in Tisy ist, sich in Berenzino wiederfindet,

    würde man sich eben auf nur diesen beschränken 🤣.

    Er sollte sich eben beim nächstgelegenen Punkt wiederfinden.

    Man könnte also in der Theorie ein wenig gemein sein und bis auf einen Punkt alle entfernen,

    so würden sich alle Spieler nach solch einem Szenario an einem Punkt wiederfinden 🤣😅.

    Aber das wäre ja gemein 😉😅.


    Nein Spaß, das sollte es aber mit dieser Abteilung gewesen sein,

    weshalb wir jetzt zur zweiten Tagesordnung übergehen.

    Den erwähnten Statischen toxischen Zonen.


    Da mir mitten im Bearbeiten und Vorschreiben dieses Beitrags noch die 1.28

    eine Ohrfeige verpassen musste und unbedingt ein paar Dinge ändern musste,

    musste ich hier nochmal alles ein wenig umarbeiten 👍😑.

    Dadurch hat es leider etwas länger gedauert, aber ich hoffe mir sei Verziehen 🤣.


    Als Erstes sollte man mal am Rande erwähnen, dass diese Zonen nicht wirklich statisch sind.

    Sie werden nach jedem Server Neustart hervorgebracht und bleiben oder sollten,

    bis zum nächsten Neustart an ihrer Position stehen, was sie eben in diesem Fall

    zu einer statischen Zone macht.


    Aber weiter im Text und hier ist es wichtig zu wissen, dass es 2 Möglichkeiten gibt.

    Im Prinzip sind sie natürlich irgendwie gleich und erfüllen beide denselben Zweck.

    Allerdings gibt es jetzt eine Kurze und eine ausführliche Möglichkeit, wenn man es so möchte.

    Dafür nehmen wir folgende Beispiele und teilen sie eben mal schnell in ein Altes (< 1.28)

    und ein neues System (> 1.28) ein.

    Altes System (< 1.28).

    Neues System (> 1.28).

    Jetzt haben wir aber wieder einige Parameter und Werte, die wichtig für diese Datei sind

    und wie wir sehen, sind einige Parameter jeweils in beiden Versionen vertreten.

    Da ich zum einen nicht alles neu und auch nicht alles doppeltgemoppelt aufschreiben will,

    auch wenn ich diesen Beitrag schon 5 mal neu geschrieben habe 😅,

    nehmen wir also alle Parameter nach einander durch und gehen dann wieder genauer auf das Thema ein.


    "Areas" ===========> Zonen Einteilung in dieser Datei

    Hiermit werden zu aller erst die Zonen von unseren oben genannten "SafePositions" getrennt.

    Dies ist für diese Datei wichtig, da alles in diesem eingeklammerten Bereich auch nur

    für unsere statischen Zonen wichtig ist und nichts mit den "SafePositions" zu tun hat.

    Man könnte also den Bereich leer lassen und hätte am Ende keine statischen Zonen,

    dafür aber eben immer noch die dynamischen Zonen

    mit den zugehörigen Sicheren Spawn Punkte für Spieler.

    Somit können wir uns also Merken, das es mit "[" anfängt, mit "]," aufhört

    und wenn wir keine Statischen toxischen Zonen möchten,

    es folgendermaßen aussehen lassen können.

    Code
        "Areas": [
    ],

    Damit hätten wir eben keine statischen Zonen mehr auf unserer Karte.

    Aber nun zu den Parametern.


    "AreaName": "" = Zonen Name

    Hier haben wir wieder die Bezeichnung und den Namen, der sich eben dieses mal auf unsere Zone bezieht.


    "Type": "ContaminatedArea_Static" = Typ und Klassifizierung der Zone

    Hier wird eben der Typ und in dem Fall "ContaminatedArea_Static" angegeben, damit der Server weiß,

    das es sich eben um eine Statische toxische Zone handelt.


    "TriggerType": "ContaminatedTrigger" = Auslöser Typ für das Event

    Damit wird die Art bestimmt, wie diese Zone ausgelöst werden soll.

    Die bisherigen Einstellungen würde ich empfehlenswerter weise lassen wie sie sind

    und nicht ändern, wenn man nicht weiß, was man alles ändern kann.

    Da muss ich mich grundsätzlich erst einmal mit einbeziehen,

    da ich auch nicht weiß, was es alles an Möglichkeiten gibt

    und auch nicht wirklich was gefunden habe 😅.

    Tendenziell ist es aber, glaube ich bis hier auch alles eher der Programmierung

    und dem Scripting gedacht.


    "Data" ===========> Grunddaten für die toxische Zone

    Wie es der Name schon sagt, kommen hier nun alle für die Zone wichtigen Daten rein 🤣.


    "Pos": [ 13684, 0, 11073 ] = Position der Zone mit Koordinaten

    Hier wird die Position der Zone auf der Karte wieder in der 3-Dimension festgelegt.

    Dabei haben wir wieder folgende Koordinaten.

    "x" = X Achse (Horizontal von links nach rechts)

    "z" = Z Achse (Vertikal von Unten nach Oben)

    "y" = Y Achse (Höhe zum Boden)

    Hier müssen wir wie gesagt ein wenig 3-Dimensional denken und uns Vorstellen, wir schauen von Oben auf die Karte.

    Jetzt haben wir die Koordinatenreihenfolge "Pos": [ x, y, z ]" und sehen beim Vergleich,

    dass die "y" Koordinate mit "0" angegeben ist.

    Das liegt daran, dass es eben nicht wie bei normalen Events die Höhe zum "0" Punkt bzw. zum Meeresspiegel ist,

    sondern die Höhe zum Boden, auf dem sich auch unser Charakter bewegt.

    Würden wir hier also beispielsweise den Wert "50" eintragen,

    würde unser Zonen-Event 50 m über unserem Charakter liegen 😅.


    "Radius": 100 = Zonen Radius in "m"

    Damit wird der Radius der Zone in Metern angegeben.


    "PosHeight": 22 = Zonen Höhe in "m" vom "0" Punkt

    Hiermit wird im Grunde zusätzlich noch einmal die Höhe der Zone in Metern angegeben.

    Sie wird hier vom "0" Punkt an gemessen, und geht damit in diesem Fall also vom Boden aus

    22 Meter in die Höhe.


    "NegHeight": 10 = Zonen Tiefe in "m" vom "0" Punkt

    Hier haben wir das Gegenstück zur "PosHeight", denn hier wird in Metern angegeben,

    wie weit die Zone vom Boden oder "0" Punkt in die Tiefe geht.

    Grund dafür ist eigentlich simpel, falls sich jemand fragt, was das für einen Zweck hat.

    Zum einen haben wir die Optik, denn je nach Grafik und Aufbau kann es doof aussehen,

    wenn da so ein Donut über dem Boden schwebt und zum anderen, stelle man sich vor,

    man hätte einen Hang, dann würde die Zone über ihm schweben

    und man könnte sich Verstecken und das ganze von unten betrachten ohne das etwas passiert 🤣😅.


    "InnerRingCount": 1 = Ringanzahl im inneren Bereich

    Damit wird die Anzahl an Ringen im inneren Bereich der Zone angegeben,

    auf dem wieder "Particle emitter" liegen können.


    "InnerPartDist": 50 = Entfernung zwischen zwei "Particle emitter" in "m" auf inneren Ringen

    Hier haben wir eine Entfernung in "m" auf gerader Linie zwischen den "emitter",

    welche sich auf einem inneren Ring befinden.


    "OuterRingToggle": 1 = Aktivieren oder Deaktivieren des Außenringes

    Hier kann mit "1" oder "true" ein Außenring aktiviert werden, welcher zusätzlich zu den inneren Ringen existiert.

    Mit "0" oder "false" kann dieser eben auch wieder deaktiviert werden.


    "OuterPartDist": 50 = Entfernung zwischen zwei "Particle emitter" in "m" auf dem äußeren Ring

    Hier haben wir wieder eine Entfernung in "m" auf gerader Linie zwischen den "emitter".

    Diesmal eben auf dem äußeren Ring.


    "OuterOffset": 0 = Entfernung des Außenrings zum Radius

    Dies ist wie eine Art Versatz des äußeren Ringes zum eigentlichen Radius.

    Dieser vergrößert die Zone mit einer Art Verdrängung, wie es bei einer Rauchwolke eben so ist.

    Sie wächst in gewisser Weise nach außen.


    "VerticalLayers": 0 = Anzahl vertikaler Schichten

    Hierbei können wir, zusätzlich zur Bodenebene, einen weiteren Layer hinzufügen.

    Im Prinzip hätte man dadurch eine Zone über einer Zone, wodurch diese höher wirken kann.


    "VerticalOffset": 0 = Schichten Versatz

    Hiermit legen wir einen Versatz oder Abstand zwischen den Ebenen oder Schichten fest.


    "ParticleName" = Name und Pfad der Partikel einer toxischen Zone

    Hier wird der Name und der Pfad zu den Partikeln angegeben.

    In diesem Fall haben wir "graphics/particles/" als Pfad

    und "contaminated_area_gas_bigass" als Datei für die Partikel.


    "PlayerData" ===========> Spieler spezifische Grunddaten

    "AroundPartName" = Name und Pfad von Partikeln um einen Spieler herum

    Hier haben wir, wie bei der "ParticleName", einen Pfad

    und den Zugehörigen "Partikel" Effekt um einen Spieler,

    wenn dieser eine Zone betritt.

    Wir haben "graphics/particles/" wieder als Pfad

    und "contaminated_area_gas_around" als Datei für unseren Effekt.


    "TinyPartName" = Name und Pfad von kleinen Partikeln um einen Spieler herum

    Hier haben wir zusätzlich noch einmal einen Pfad

    und den Zugehörigen "Partikel" Effekt von kleinen Partikeln,

    die um einen Spieler herum erscheinen, wenn dieser eine Zone betritt.

    Auch heir haben wir wieder "graphics/particles/" als Pfad

    und "contaminated_area_gas_around_tiny" als Datei für unseren Effekt.


    "PPERequesterType" = Typenbezeichnung des Post-Processing-Effekts

    Dabei handelt es sich um eine Bezeichnung des Types,

    welcher dafür verantwortlich ist, was wir als Spieler vor uns sehen,

    wenn wir uns in einer Zone bewegen.

    In diesem Fall ist es eben der Effekt "PPERequester_ContaminatedAreaTint".


    Kommen wir nun noch kurz zu ein paar eventuellen Fragen,

    wie "Was ist ein "Post-Processing-Effekt", "was ist ein Particle emitter",

    oder "Was ist ein Particle".

    Wir versuchen es so simpel wie Möglich, und ich hoffe einfach, dass es dadurch verständlich genug ist,

    um zu verstehen, was gemeint ist und was wir einstellen 😅.


    Was ist ein Particle:

    Am Einfachsten erklärt können es 2- oder 3-Dimensionale Objekte sein, welche z.B. Rauch oder Feuer simulieren können.

    Wir müssen hierbei nur zwischen dem Particle oder Partikel und dem Particle Effekt unterscheiden.

    Der Particle Effekt wäre eine Rauchsäule, wohingegen der Particle nur ein einzelnes Element dieser Säule ist.

    Rauch kann z.B. als ein 2-Dimensionales Bild dargestellt werden. Dieses lässt sich schieben, Drehen,

    verkleinern, bewegen oder die farblich anpassen. Dies geschieht wieder durch unseren Particle Effekt.

    Im Falle eines Bildes und damit auch gleich die Frage geklärt ist,

    sehen wir dieses immer nur aus der Front Perspektive.

    Es ist als würden wir um ein Blatt Papier herumlaufen,

    welches sich aber immer mit uns dreht.


    Was ist ein Particle emitter:

    Einfach gesagt, ist es der Punkt, an dem unser Particle Effekt startet.

    Von ihm ausgehend, werden z.B. Rauchwolken aufsteigen oder es wird ein Feuer dargestellt.

    In Kombination, können wir uns also vorstellen, dass ein Helicrash einen Particle emitter besitzt.

    Von diesem ausgehend, startet der Particle Effekt, welche z.B. die Richtung der Rauchwolke angibt,

    welcher Particle (z.B. welches Bild) dargestellt wird und wie er sich verhalten soll.

    Er wird z.B. vom emitter aus größer, dunkler und verschwindet beispielsweise anschließend.


    Was ist ein "Post-Processing-Effekt:

    Diesen Effekt kann man sich als eine Art Schablone vorstellen, welche zwischen unseren Bildschirm

    und unser Auge gesetzt wird. In diesem Fall und da es ja bekanntlich doof wäre,

    jedes mal eine neue Schablone auf unseren Monitor zu legen 🤣,

    passiert dies im Prinzip auf digitalem Wege.

    Es wird sozusagen eine Schablone zwischen dem Spiel

    und dem gelegt, was wir endgültig auf dem Monitor sehen.


    Jetzt gehen wir noch auf die Zonen direkt ein und wie sie funktionieren.

    Dafür hab ich da mal was vorbereitet 🤣.

    Nein, dank Bohemia, habe ich ein paar optische Aufklärungsbeispiele die ich ein wenig angepasst habe

    und hoffe, dass es damit auch gleich ein wenig verständlicher wird 😅.

    Hier aber auch der Link zur Bohemia Darstellung, in der auch nochmal

    die "cfgeffectarea.json" ein wenig erklärt wird.

    Bohemia Dayz Contaminated Areas Configuration


    Als Erstes nehmen wir eine Zone von der Seitenansicht,

    um die Optionen "Pos", "PosHeight", "NegHeight"

    und ggf. "Radius" besser aufzuzeigen.

    NaC2KtA.png


    Als Nächstes nehmen wir noch eine Zone in der Draufsicht, um damit nochmal die Option "Radius"

    und zusätzlich die Optionen "InnerRingCount", "InnerPartDist", "OuterPartDist" und "OuterOffset" darzustellen.

    OTpBTxP.png


    Die letzte Darstellung zeigt uns nochmal eine Draufsicht der Zone, wie sie am Ende aufgebaut wird.

    WImd7Ym.png


    Letzteres gilt aber hauptsächlich der Version 1.28, soll aber auch ein wenig aufzeigen,

    wie sich die Zone beispielsweise aufbaut oder wie sie kalkuliert wird.

    Hinzu kommen allerdings noch die Berechnungen einer Zone,

    auf welche wir jetzt zusätzlich auch noch ein wenig eingehen.

    Allerdings wird es ab hier auch ein klein wenig komplexer,

    weswegen ich das auch erst hier ans Ende stelle.

    Wem es also reicht, das ganze einfach mal gesehen zu haben, der kann den Teil gerne überspringen 😅🤣.


    Kommen wir nun aber zum praktischen Rechenteil.

    Damit wir Beispiele haben, werden wir uns einfach mal für alle Berechnungen

    ein paar Beispiele zusammenstellen.

    Ich trenne es hier aber wieder in die beiden Versionen vor und nach der 1.28.

    Das hat einfach den Grund, dass es in der neuen Variante wohl etwas,

    nennen wir es mal "Automatisierter" läuft.

    Innere Ringe oder der Gleichen, werden automatisch erzeugt, um die Zone auszufüllen.

    Wie wir im letzten Bild sehen, haben wir folgende Formeln, die aufzeigen, wie die Zone aufgebaut wird.

    R<Rp

    R<3 ∗ Rp

    R>3 ∗ Rp

    R = Radius + OuterOffset

    Rp = InnerPartDist / 2

    Die 3 steht meiner Meinung nach für die Formel und Funktion, die eingefügt wurde und davon ausgeht,

    dass es nur noch oder maximal 2 innere Ringe in einer Zone gibt und eben einen äußeren Ring (2 + 1 = 3).

    Nun legen wir hierfür mal 3 Beispiele fest.

    Nun müssen wir für uns für die Berechnung die Werte anschauen, die dafür auch von Bedeutung sind.

    Diese minimieren sich auf "Radius", "OuterOffset" und "InnerPartDist".

    Somit bleiben nur noch diese 3 Werte für diese Berechnung übrig, welche wir uns nun

    für jedes Beispiel herauspicken und somit folgende Zeilen haben.

    Für Zone-A:

    Radius = 30

    OuterOffset = 15

    InnerPartDist = 100

    Für Zone-B:

    Radius = 75

    OuterOffset = 20

    InnerPartDist = 100

    Für Zone-C:

    Radius = 100

    OuterOffset = 60

    InnerPartDist = 100


    Nun rufen müssen wir uns wieder unsere Werte für die Formeln ins Gedächtnis rufen,

    welche wir für die Berechnung benötigen.

    R = Radius + OuterOffset

    Rp = InnerPartDist / 2


    Somit haben wir nun folgende Werte.

    Für Zone-A:

    R = Radius + OuterOffset = 45

    Rp = InnerPartDist / 2 = 50

    Für Zone-B:

    R = Radius + OuterOffset = 95

    Rp = InnerPartDist / 2 = 50

    Für Zone-C:

    R = Radius + OuterOffset = 160

    Rp = InnerPartDist / 2 = 50


    Jetzt kommen die Formeln wieder ins Spiel, in welcher wir unsere Werte einsetzen können.

    Und damit man nicht nochmal Scrollen muss, hier auch gleich noch einmal die Formel,

    in der wir die Werte entsprechend eintragen können.

    R<Rp

    R<3∗Rp

    R>3∗Rp


    Für die Berechnung haben wir anschließend folgende Werte und

    anschließend nochmal die endgültige Darstellung.

    Für Zone-A:

    45<50

    45<3 ∗ 50 = 150

    45>3 ∗ 50 = 150

    Endgültige Darstellung

    45<50

    45<150

    45>150

    Für Zone-B:

    95<50

    95<3 ∗ 50 = 150

    95>3 ∗ 50 = 150

    Endgültige Darstellung

    95<50

    95<150

    95>150

    Für Zone-C:

    160<50

    160<3 ∗ 50 = 150

    160>3 ∗ 50 = 150

    Endgültige Darstellung

    160<50

    160<150

    160>150


    Das sieht wahrscheinlich auf den ersten Blick schlimmer aus als es eigentlich ist,

    denn im Grunde können wir nun ein wenig abgleichen und schauen,

    welche aussagen zutreffend sind.

    Für Zone-A:

    45<50 ✓

    45<150 ✓

    45>150 ×

    Für Zone-B:

    95<50 ×

    95<150 ✓

    95>150 ×

    Für Zone-C:

    160<50 ×

    160<150 ×

    160>150 ✓


    Schauen wir uns nun unsere Ergebnisse an, sollten wir diese mit dem Bild zu diesen Berechnungen vergleichen

    und feststellen, dass Zone-B wie oben im Bild den Aufbau einer Zone mit nur einem Ring hätte.

    Zone-C hingegen ist so groß, dass sie zusätzlich einen Ring, bzw. "emitter" benötigt, um diese zu füllen.

    Zone-A hat nun aber ein kleines Problem, da 2 Angaben zutreffen.

    Hier würde aber nur die erste tatsächlich zutreffen, also 45<50, was daran liegt,

    das einer unserer Partikel Effekte von alleine größer ist, als die Zone selbst.

    Somit ist die Zone also mit nur einem abgedeckt und muss nicht unnötig Ringe darin aufbauen,

    um diese zu füllen.


    Dies sollte es grundlegend für die neue Variante gewesen sein.

    Da das System aber abwärtskompatibel ist, müssen wir nun aber leider

    auch noch zusätzlich darauf eingehen, wie es mit dem Berechnen der "emitter" aussieht,

    da man in diesem Fall selber ein wenig schauen muss, wie sich das ganze ein wenig aufbaut.

    Natürlich kann man dieses Prinzip auf beide Varianten anwenden,

    allerdings müsste man in der neuen Variante auch wissen,

    wie viele Ringe man am Ende tatsächlich hat 😅.


    Aber hier mal die grundlegende Formel, die auch auf der Bohemia Webseite zu finden ist

    und wieder 3 Beispiele, mit denen wir auf die schnelle arbeiten.

    3 Beispiele.

    Und hier die Formel.

    2 PI / ACOS(1 - (x^2 / 2 ∗ y^2))

    Als Anmerkung:

    "x^2" bedeutet hoch 2, was also "x²" bedeutet und wer es noch kennt, mit "x ∗ x" gerechnet wird 😅.

    Ich werde daher in meinen Beispielen "²" verwenden, sieht halt auch schöner aus 🤣.

    Mal so zum Vergleich "2 PI / ACOS(1 - (x² / 2 ∗ y²))" 😅🤣.


    Nun müssen wir erst einmal wissen, was "x" und "y" darstellt.

    x = Platz zwischen den "emitter" des zu berechnenden Ringes = "InnerPartDist" oder "OuterPartDist"

    y = Radius des zu berechnenden Ringes


    Nun haben wir das Problem, dass wir wissen müssen, wie wir unsere Zone aufbauen wollen,

    da dies ja hier nicht automatisch passiert.

    Dafür müssen wir uns die Zeilen "InnerRingCount" und "OuterRingToggle" anschauen.

    Haben wir "OuterRingToggle" mit dem Wert "1" angegeben, besitzt unsere Zone schon mal einen Ring,

    da wir damit, wie oben beschrieben, den äußeren Ring erlauben.

    Wird "InnerRingCount" zusätzlich mit "1" angegeben, hätte unsere Zone also 2 Ringe,

    einmal einen Außenring und einen inneren Ring.

    Geben wir bei "InnerRingCount" 2 an, hätten wir dementsprechend 3 Ringe.


    Nun wissen wir schon mal, wie wir das zu berücksichtigen haben, müssen aber herausfinden,

    wie groß unsere jeweiligen Ringe sind, da mit "Radius" nur die Größe des äußeren Ringes angegeben wird.

    Da sollte man aber nicht zu viel Angst haben, denn das ist tatsächlich simpel,

    da wir nur unseren "Radius" durch unsere Anzahl der Ringe teilen müssen 😅🤣.

    Unsere Formel hierfür sollte also lauten:

    Radius / (InnerRingCount + 1)

    Nehmen wir dafür das Beispiel "Radius" = 150 und "InnerRingCount" = 2,

    sollte unsere Formel also wie folgt aussehen.

    150 / 3 = 50

    Dies wiederum bedeutet für uns, dass der innerste Ring einen "Radius" von 50,

    der mittlere Ring einen "Radius" von 100 und der äußerste wieder unseren "Radius" von 150 hat.

    Als Gegenbeispiel nehmen wir nun mal noch schnell "Radius" = 150 und "InnerRingCount" = 1,

    was für uns also heißt

    150 / 2 = 75

    Somit hat also unser innerer Ring einen "Radius" von 75 und unser äußerer wieder den Wert 150.

    Wichtig ist natürlich zu beachten, dass wenn "OuterRingToggle" mit "0" angegeben ist

    und "InnerRingCount" mit beispielsweise "2", wir in diesem Falle nur 2 und nicht 3 Ringe haben.

    In diesem Fall würden wir zwar immer noch mit 3 Ringen rechnen,

    müssen dies aber bei der Berechnung der "emitter" berücksichtigen.


    Aber weiter im Text und weiter mit dem Kopfzerbrechen 🤣, denn nun kommen wir wieder zu unserer Formel,

    mit der wir die "emitter" berechnen.

    Wir erinnern uns nochmal an die Formel "2 PI / ACOS(1 - (x² / 2 ∗ y²))"

    und schauen uns zur not die Bohemia Version mit dem Rechenweg für "x" = 20 und "y" = 105 an.

    2 PI / ACOS(1 - (20² / 2 ∗ 105²)) = 2 PI / ACOS(1 - (400 / 2 ∗ 11025)) = 2 PI / ACOS(1 - (400 / 22050)) = 2 PI / ACOS(1 - 0,01814059) = 2 PI / ACOS(0,98185941) = 2 PI / 0,190765318 = 32,93672756

    Das ganze können wir aber etwas aufhübschen, was meiner Meinung nach

    auch gleich etwas verständlicher aussieht.

    2 PI / ACOS(1 - (20² / 2 ∗ 105²))

    = 2 PI / ACOS(1 - (400 / 2 ∗ 11025))

    = 2 PI / ACOS(1 - (400 / 22050))

    = 2 PI / ACOS(1 - 0,01814059)

    = 2 PI / ACOS(0,98185941)

    = 2 PI / 0,190765318

    = 32,93672756


    Nun aber endlich zu dem worauf alle gewartet haben und wir alle gespannt sind,

    wie berechnen wir nun diese blöden "emitter" 🤣.

    Nein, Spaß.

    Ich würde glaube ich auch lieber ein Eis essen, aber Respekt an alle, die es bis hier hingeschafft

    und durchgehalten haben 😅.


    Jetzt aber wirklich 😅.

    Nehmen wir wieder unsere 3 Beispiele von oben, haben wir folgende und für uns wichtigen Werte nochmal in Kurzform

    und zusätzlich die Anzahl und Größe der Ringe, die wir berechnen konnten.

    Für Zone-A:

    Radius = 60

    InnerRingCount = 1

    InnerPartDist = 20

    OuterRingToggle = 1

    OuterPartDist = 30

    Anzahl Ringe = 2

    Radius Ring 1 = 30

    Radius Ring 2 = 60

    Für Zone-B:

    Radius = 100

    InnerRingCount = 1

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 50

    Anzahl Ringe = 2

    Radius Ring 1 = 50

    Radius Ring 2 = 100

    Für Zone-C:

    Radius = 150

    InnerRingCount = 2

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 40

    Anzahl Ringe = 3

    Radius Ring 1 = 50

    Radius Ring 2 = 100

    Radius Ring 3 = 150


    Nun können wir das ganze Wissen anwenden und unsere "emitter" auf den Ringen berechnen,

    so wie unsere Gesamtanzahl an "emitter" für unsere Zone.

    Dafür fangen wir wieder mit Zone-A an, bei welcher wir nun die Berechnung für jeden der beiden Ringe vornehmen müssen.

    Also haben wir eine Berechnung für Ring 1 und eine für Ring 2.

    Wichtig zu beachten ist hier aber, welcher Ring mit welchem "...PartDist" berechnet wird.

    In unserem Bsp. ist Ring 1 der innere Ring und wird in diesem Fall mit dem Wert der "InnerPartDist" berechnet.

    Ring 2 ist der äußere Ring und wird daher mit dem Wert der "OuterPartDist" berechnet.

    Die Gleichungen dafür sehen also in Kurzer und Rechenweg Variante folgendermaßen aus.

    Zone-A Ring 1 = 2 PI / ACOS(1 - (20² / 2 ∗ 30²))

    2 PI / ACOS(1 - (20² / 2 ∗ 30²))

    = 2 PI / ACOS(1 - (400 / 2 ∗ 900))

    = 2 PI / ACOS(1 - (400 / 1800))

    = 2 PI / ACOS(1 - 0,22222222)

    = 2 PI / ACOS(0,77777778)

    = 2 PI / 0,67967382

    = 9,24441272

    Zone-A Ring 2 = 2 PI / ACOS(1 - (30² / 2 ∗ 60²))

    2 PI / ACOS(1 - (30² / 2 ∗ 60²))

    = 2 PI / ACOS(1 - (900 / 2 ∗ 3600))

    = 2 PI / ACOS(1 - (900 / 7200))

    = 2 PI / ACOS(1 - 0,125)

    = 2 PI / ACOS(0,875)

    = 2 PI / 0,50536051

    = 12,43307536

    Nach dieser Rechnung und wenn wir alles richtig gerechnet haben,

    haben wir die Werte 9,24441272 für den inneren

    und 12,43307536 für den äußeren Ring.

    Für unsere Anzahl benötigen wir allerdings nur die Zahl vor dem Komma.

    Somit haben wir also nur noch die Werte 9 und 12, welche wir zusammenrechnen können.

    9 + 12 = 21 + 1 = 22

    Unsere Zone hat also 22 "emitter" und lässt nun noch die Frage offen, warum wir nochmal + 1 rechnen?

    Das ist wieder relativ simpel, denn es gibt immer einen Mittelpunkt, welcher eben einen "emitter" besitzt.

    Diesen müssen wir einfach immer hinzurechnen, auch wenn dieser glaube den Kohl nicht Fett macht 🤣.

    Seid der 1.28 ist das Maximum an "emitter" auf 1000 pro Zone limitiert,

    um die Serverperformance aufrechtzuerhalten.


    Um eventuell die Frage zu klären, wie man "ACOS" anwendet, hier mal noch schnell ein visuelles Bsp.,

    des Windows Taschenrechners. In meinem Fall ist es gerade Windows 11,

    sollte aber unter Windows 10 nicht anders sein 😅.

    Als Erstes müssen wir unseren Taschenrechner öffnen und ihn von "Standard" auf "Wissenschaftlich" umstellen.

    4ye1Rab.png

    rMUC8hj.png

    Anschließend stellen wir ihn, wenn es nicht schon eingestellt ist, von "DEG" auf "RAD".

    nAZt6w1.png

    Jetzt geben wir unseren Wert ein. In diesem Bsp. ist es "0,5", gehen auf "Trigonometrie",

    anschließend auf "2ⁿᵈ" und sehen unser "cos⁻¹", welches wir jetzt nur noch ausführen

    um unser Ergebnis zu erhalten.

    b3a7Iot.png

    9V855Q0.png

    8ffuOhx.png

    rk94ueK.png


    Und schon hätten wir auch den Ausflug zum Taschenrechner überstanden und kommen langsam zum Abschluss 😅.

    Dafür machen wir jetzt nur noch unsere letzten Hausaufgaben und rechnen unsere Letzten beiden Zonen aus.

    Um das Scrollen noch einmal zu ersparen, hier noch einmal unsere Werte.

    Für Zone-B:

    Radius = 100

    InnerRingCount = 1

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 50

    Anzahl Ringe = 2

    Radius Ring 1 = 50

    Radius Ring 2 = 100

    Für Zone-C:

    Radius = 150

    InnerRingCount = 2

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 40

    Anzahl Ringe = 3

    Radius Ring 1 = 50

    Radius Ring 2 = 100

    Radius Ring 3 = 150

    Nun noch schnell zu unseren Rechenaufgaben und wir sollten mit diesem Thema endlich durch sein 😅.


    Zone-B Ring 1 = 2 PI / ACOS(1 - (50² / 2 ∗ 50²))

    2 PI / ACOS(1 - (50² / 2 ∗ 50²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 2500))

    = 2 PI / ACOS(1 - (2500 / 5000))

    = 2 PI / ACOS(1 - 0,5)

    = 2 PI / ACOS(0,5)

    = 2 PI / 1,04719755

    = 6,00000001

    Zone-B Ring 2 = 2 PI / ACOS(1 - (50² / 2 ∗ 100²))

    2 PI / ACOS(1 - (50² / 2 ∗ 100²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 10000))

    = 2 PI / ACOS(1 - (2500 / 20000))

    = 2 PI / ACOS(1 - 0,125)

    = 2 PI / ACOS(0,875)

    = 2 PI / 0,50536051

    = 12,43307536

    Somit ergibt sich also nach unserem oben erwähnten Bsp. die Werte für Ring 1 mit "6" und Ring 2 mit "12".

    Was uns am Ende mit unserem Mittelpunkt auf 19 "emitter" kommen lässt.


    Jetzt noch unser letztes Beispiel und die letzte Zone für heute.

    Zone-C Ring 1 = 2 PI / ACOS(1 - (50² / 2 ∗ 50²))

    2 PI / ACOS(1 - (50² / 2 ∗ 50²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 2500))

    = 2 PI / ACOS(1 - (2500 / 5000))

    = 2 PI / ACOS(1 - 0,5)

    = 2 PI / ACOS(0,5)

    = 2 PI / 1,04719755

    = 6,00000001

    Zone-C Ring 2 = 2 PI / ACOS(1 - (50² / 2 ∗ 100²))

    2 PI / ACOS(1 - (50² / 2 ∗ 100²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 10000))

    = 2 PI / ACOS(1 - (2500 / 20000))

    = 2 PI / ACOS(1 - 0,125)

    = 2 PI / ACOS(0,875)

    = 2 PI / 0,50536051

    = 12,43307536

    Zone-C Ring 3 = 2 PI / ACOS(1 - (40² / 2 ∗ 150²))

    2 PI / ACOS(1 - (40² / 2 ∗ 150²))

    = 2 PI / ACOS(1 - (1600 / 2 ∗ 22500))

    = 2 PI / ACOS(1 - (1600 / 45000))

    = 2 PI / ACOS(1 - 0,03555556)

    = 2 PI / ACOS(0,96444444)

    = 2 PI / 0,2674632

    = 23,49177497

    Und auch hier gilt wieder das Zusammenrechnen unserer "emitter" auf jedem Ring und das Einbeziehen unseres Mittelpunktes.

    Folgend haben wir also diesmal nicht 2, sondern 3 Ringe, was also folgendes bedeutet.

    6 + 12 + 23 = 41 + 1 = 42

    Und siehe da, wir haben eine Gesamtanzahl von 42 "emitter" in unserer Zone und endlich auch das Ende erreicht 😅🤣.

    Wichtig wäre eventuell noch zu erwähnen, das nicht aufrundet wird, selbst wenn nach dem Komma eine 9 steht.

    Haben wir also zum Beispiel einen Wert oder ein Ergebnis von "2,9", bleibt es bei der "2".

    Ebenso wichtig ist es auch noch, unsere "VerticalLayers" Einstellung zu berücksichtigen.

    Haben wir hier nur einen Layer, also den Wert "0" haben wir nur unsere 42 "emitter".

    Geben wir allerdings einen Wert mit "1" an, haben wir natürlich die doppelte Anzahl,

    da unsere Zone 2 Schichten übereinander hat und somit auf 84 kommt.

    Das ganze geht natürlich immer so weiter und wir hätten bei einem "VerticalLayers" Wert von "2"

    eben die 3-fache Anzahl an "emitter"


    So, das sollte es glaube ich gewesen sein, ist ja nun doch ne ganze Menge zusammen gekommen.

    War zwar anfangs etwas anders gedacht, aber ist man einmal dabei,

    verliert man auch schnell mal die Größe eines solchen Textes 😅.

    Wie gesagt hat es etwas länger gedauert, da ich mehrmals neu angefangen habe,

    aber ich hoffe, es sei mir verziehen und genauso hoffe ich das es ausführlich genug ist,

    um das ganze zu verstehen.

    Sollten dennoch Rechenfehler oder Fragen auftreten oder auffallen,

    dann natürlich wie immer gern Bescheid geben 😊.


    Ich für meinen Teil hoffe, es war interessant genug,

    bedanke mich wie immer für die Geduld,

    Durchhaltevermögen und Zeit 👍.

    Und natürlich freue ich mich schon, wenn wir uns beim nächsten Thema wieder sehen 😁.