Beiträge von derKobold1987

  • Server Files: Erklärung und Bedeutung

    Thema:



    types.xml


    Herzlich willkommen zu einem der wichtigsten Punkte unserer Reise,

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

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

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

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

    Und damit sind nicht die Lebenspunkte gemeint 😅.


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

    Es sprengt sonst einfach den Rahmen, wenn man hier die Komplette Types einträgt 🤣.

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

    und Verwendungszwecken von Objekten gibt.

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

    und auch das, was ich damit genau meine.


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


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

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



    Gefolgt von einem Herstellbaren Objekt und einem Basenbau Objekt.



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



    Als Nächstes kommen wir zu einem Infizierten Bzw. einem KI-Objekt, da Tiere dasselbe nur in lebend sind 🤣.


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


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



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

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

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

    wofür diese eigentlich gedacht sind.

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

    Fangen wir aber an und fackeln nicht lange 😅.


    Als Erstes haben wir immer "<type ", was für die Aufzählung der Objekte wichtig ist

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

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


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


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

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

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


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


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

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

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

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

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

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

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

    können wir natürlich keinen mehr hineinlegen.

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

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

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

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

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

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

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

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


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


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

    bevor es despawnt wird.

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

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

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

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

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

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

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

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

    aber nur noch rund die Hälfte tatsächlich da ist. Und das bei einem Server für nur eine Person 🤣.

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

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

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

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

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

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

    Legt Ihr den Koffer in die Hose, ist beider nach 4 Stunden verschwunden, da die Lifetime der Hose zählt 🤣.

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

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

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

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

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

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


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


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

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

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

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

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

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

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


    min>12</min = Minimale Anzahl des Objektes


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

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

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

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

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

    sogar ungeachtet vom "restock" Wert.

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

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

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


    quantmin>-1</quantmin = Minimale Füllmenge Objekt

    quantmax>-1</quantmax = Maximale Füllmenge Objekt


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

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

    die eine Plastikflasche beim spawnen beinhalten kann.

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

    quantmin>25</quantmin = 250ml

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

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

    würde es eben wie folgt aussehen:

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

    quantmax>80</quantmax = 20 Patronen

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

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

    Beispielsweise hätten wir beim gleichen min. oder max. Wert und einer maximalen Stapelgröße von z.B. 250 Patronen folgendes Problem:

    quantmin>10</quantmin = 25 Patronen

    quantmax>80</quantmax = 200 Patronen

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

    was in solch einem Falle sämtliche Munitionsboxen überflüssig machen würde 😅.

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

    also Kleidung, Waffen, etc....


    cost>100</cost = Priorität


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

    Also, ob es beispielsweise vor anderen Objekten spawnen soll.

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

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

    Würde ein Kunde jeweils von beiden ein paar mitnehmen,

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


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


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

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

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

    bestimmte Objekte z.B. im Inventar berücksichtigt werden sollen.

    Gehen wir aber alle wieder einzeln durch.


    count_in_cargo="0" = berücksichtigen von Objekten in Objekten


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

    nicht grundlegend für Basen oder zum Horten gedacht sind.

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

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

    die keine Lebensdauer von 45 Tagen haben.

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

    wenn ein Spieler damit interagiert hat.


    count_in_hoarder="0" = berücksichtigen von Objekten in Containern oder Behältern


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

    Alles was für einen längeren Zeitraum auf der Karte stehenbleibt und sich wieder

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


    count_in_map="1" = berücksichtigen von Objekten auf der Karte


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

    Dieser Einstellung sollte grundlegend auf "1" gelassen werden,

    da sonst der Server vom Objekt überflutet wird 😅.

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

    die er blind reinfeuert 🤣.


    count_in_player="0" = berücksichtigen von Objekten im Spielerinventar


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

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

    Sobald sich ein Charakter mit einem entsprechendem Objekt ausloggt,

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

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

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

    Gleiches gilt aber auch wieder andersherum.

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

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

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

    da der Charakter diese bei sich trägt.


    crafted="0" = Herstellbares Objekt


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

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

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

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

    muss hier der Wert "0" angegeben werden.

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

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


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


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

    Dazu zählen z.B. Helikopter Abstürze, Polizei Events wie Straßensperren oder Konvois.

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

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



    Soweit so gut,

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

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


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

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

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

    Da haben wir nun folgende Einstellungen.


    category name="food"/>

    tag name="shelves"/>

    usage name="Town"/>

    usage name="Village"/>

    value name="Tier1"/>

    value name="Tier2"/>

    value name="Tier3"/>


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

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

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


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

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

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

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

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



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

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



    Was genau ist der Unterschied zu herkömmlichen Objekten?

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

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

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

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

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

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

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

    für einen längeren Zeitraum auf dem Server verweilen kann.

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

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

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

    wo das Objekt auftauchen bzw. spawnen darf.

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

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


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


    Wie auch schon im Thema cfglimitsdefinitionuser.xml angesprochen,

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

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

    Aber das soll nicht unser Problem sein.

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

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

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

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

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

    Dafür natürlich noch einmal der Grundaufbau und danach ´schauen wir uns das genauer an.



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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

    welches aber nicht auf herkömmliche Art spawnt.

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

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

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

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

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

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

    Diese Kategorie wurde explizit dafür eingerichtet und sollte unter Umständen nur dafür genutzt werden,

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

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


    Kommen wir zu KI Objekten.


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


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

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

    Springe ich abschließend noch zu den Event Objekten.



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

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


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

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

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

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

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

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

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

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

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



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

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

    Wie schon in der cfglimitsdefinition.xml erwähnt,

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

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



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



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

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


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

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

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

    und ggf. mit Bildern etwas besser darstellen kann 😅.

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

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


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

  • Server Files: Erklärung und Bedeutung

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

  • Server Files: Erklärung und Bedeutung

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

  • Server Files: Erklärung und Bedeutung

    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 😁


  • Server Files: Erklärung und Bedeutung

    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.

  • Server Files: Erklärung und Bedeutung

    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.


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

  • Server Files: Erklärung und Bedeutung

    Auch hier wieder ein Herzliches Willkommen und treten sie näher 🤣.

    Natürlich freue ich mich auch wieder, dass ihr mein Programm bis hier her verfolgt habt

    und hoffe euch auch weiterhin Unterhalten zu können 😊.



    Ab hier und bis natürlich zum nächsten großen Abschnitt befassen wir uns mit der Economy,

    allem, was dem Spieler genug Nachschub bringt und wie sich Objekte und ihre Spawns verhalten.

    Denn wie auch ein echter Gamer nicht geboren, sondern gespawnt wird,

    werden Objekte nicht hergestellt, sondern ebenso gespawnt 🤣.


    Der war zwar etwas flach, aber kommen wir von Flach zu Trocken, denn viele Themen, Dateien und Einstellungen sind übergreifend

    und können am Ende so angepasst und erweitert werden, dass es eine unzählige Vielfalt an Servern geben könnte,

    wenn man sich tatsächlich die Zeit und die Mühe machen möchte.


    Da es sich meiner Meinung nach am besten anbietet von Grob nach Fein zu arbeiten,

    habe ich mir erlaubt, eine Reihenfolge festzulegen, die glaube ich am meisten Sinn ergibt.

    Und damit auch hier wieder jeder schon mal einen Überblick hat fangen wir wieder

    mit einer Art Inhaltsangabe an.


    Als Erstes haben wir die economy.xml,

    die eine Art zentrales Befehlszentrum für de gesamte Economy fungiert.


    Danach haben wir die globals.xml,

    die, wie der Name schon sagt, für globale Einstellungen da ist.


    Als Nächstes haben wir die cfgeconomycore.xml,

    für die Kerneinstellungen der Economy und die Dateien.


    Gefolgt von der cfgignorelist.xml,

    als "Limitierungsliste" für Objekte.


    Danach kommen wir zur cfglimitsdefinition.xml,

    als eine Art Orientierungs- und Kategorien Verzeichnis.


    Als Nächstes die cfglimitsdefinitionuser.xml,

    die ebenso als eine Art Kategorien Verzeichnis dient.


    Gefolgt von der types.xml,

    als Loot Einstellung für sämtliche Objekte.


    Die events.xml,

    für dynamische Events.


    Der cfgeventspawns.xml,

    als Koordinatenverzeichnis der einzelnen Events.


    Dann haben wir noch die cfgspawnabletypes.xml,

    als Gruppenverzeichnis für das spawnen an Objekten.


    Und als Letztes noch die cfgrandompresets.xml,

    für das Erstellen einzelner Objektgruppen zu spawnen in Objekten / Containern.



    Das sollten dann so weit alle wichtigen Dateien sein.

    Damit wir auch hier nicht weiter und lange verweilen müssen,

    fangen wir auch gleich mit dem ersten Thema an 😁.

  • Server Files: Erklärung und Bedeutung

    Thema:


    cfggameplay.json Extras:


    objectSpawnersArr


    Damit machen wir einen kleinen Ausflug zu weiteren Möglichkeiten,

    mit denen man die schon vorhandenen DayZ Maps ein wenig bearbeiten und seinen Vorstellungen erweitern kann, ohne Mods zu benutzen.

    Bewusst nenne ich es erweitern, da schon bestehende Objekte nicht einfach gelöscht werden können.

    Zumindest nicht ohne Mods 😅.


    Wichtig!!! Bei diesem Thema ist zu beachten, dass durch neue Objekte und Strukturen, der Server mehr Leistung benötigt.

    Dies kann zu erhöhten Ladezeiten führen, da jedes Objekt Spawnen muss. Hinzu kommen eventuelle Bugs und Glitches,

    so wie im schlimmsten Fall der Serverabsturz. Daher ist das ändern, hinzufügen und nutzen dieser Einstellung immer mit einem

    Risiko verbunden und jedem sich selbst überlassen.



    Zu aller erst müssen wir aber das ganze aktivieren.

    Und da fängt es natürlich erst mal wieder damit an, dass wir in der serverDZ.cfg

    die Zeile "enableCfgGameplayFile = 1;" eintragen müssen, um überhaupt die cfggameplay.json zu aktivieren.

    Anschließend müssen wir, insofern nicht vorhanden, die Zeile "objectSpawnersArr": []," unter "WorldsData"

    In der cfggameplay.json eintragen.


    Dies sollte dann so aussehen:



    Jetzt haben wir 2 Möglichkeiten,

    in beiden fällen brauchen wir natürlich erst mal eine neue .json, die im Anschluss unsere Objekte oder Strukturen beinhalten.

    Diese nenne ich für in dem Fall einfach:


    Haus.json


    (Für die, die nicht wissen, wie man schnell eine.json erstellt, einfach eine neue Textdatei erstellen

    und .txt durch .json ersetzen.)


    diese kann natürlich am Ende so benannt werden, wie man es möchte.

    Wichtig ist nur, dass man am Ende weiß, welche Datei was beinhaltet, da man sich nicht nur auf eine beschränken muss.


    Jetzt kommen wir zur Möglichkeit 1:


    Dafür müssen wir unsere "Haus.json" lediglich in den "Missions" Ordner Einfügen / Kopieren.


    In diesem Fall ist es natürlich wieder unser Bekannter Pfad:


    Basisverzeichnis\mpmissions\dayzOffline.chernarusplus


    Anschließend müssen wir in unsere "objectSpawnersArr" noch unsere .json hinterlegen.


    Dies sollte am ende wie folgt aussehen:



    Kommen wir zur Möglichkeit 2:


    Hier sind Eigentlich alle Schritte gleich, nur das wir unsere "Haus.json" nicht einfach in den "Missions" Ordner werfen,

    sondern einen neuen Ordner anlegen. Dies kann für eine bessere Übersicht sorgen, ist aber jedem selbst überlassen.

    In diesem Beispiel nenne ich den Ordner einfach "Buildings" und unsere Ordnerstruktur sollte dann wie folgt aussehen.


    Basisverzeichnis\mpmissions\dayzOffline.chernarusplus\Buildings


    Da wir jetzt aber einen neuen Ordner erstellt haben, mit dem das Spiel so nichts anfangen kann und diesen auch nicht nutzen wird,

    müssen wir das ganze natürlich wieder in der "objectSpawnersArr" anpassen, was dann wie folgt aussehen sollte:


    Haben wir mehrere Dateien, müssen wir natürlich in beiden Fällen jeweils das ganze mit einem "," trennen.

    Ich nehme dafür jetzt einfach "Baum.json", was am Ende wie Folgt aussehen sollte:

    Oder mit einem neu erstellten Ordner:


    Und nur der Vollständigkeit halber das ganze auch nochmal, wenn z.B. mehrere neue Ordner erstellt wurden:



    Als kleine Ergänzung und je nachdem wie man es für sich verwalten möchte, ist es meiner Meinung nach am besten,

    die Ordnerstruktur so einzurichten, dass jeder Ordner "custom..." benannt wird für das "..." wäre mein Vorschlag,

    immer die jeweilige Zuordnung zu nehmen, da es hierfür noch andere Dateien gibt, die man selbst anlegen kann.

    Dazu kommen wir aber zum gegebenen Zeitpunkt noch genauer, aber damit man schon mal ein wenig nachvollziehen kann,

    was gemeint ist, kann man z.B. die Ordner "customtypes", "customspawnabletypes" oder für eben die Map Bearbeitung

    den Ordner "customobjects" als kleine Orientierung nutzen. So weiß man am Ende am besten, was in welchem Ordner

    vorhanden sein sollte und kommt meiner Meinung nach weniger durcheinander.



    Kommen wir nun aber zu dem Teil, was in unserer "Haus.json" stehen bzw. enthalten sein muss.


    Ich erstelle einfach ein Beispiel, bei dem es sich nicht um exakte Koordinaten oder Namen handelt.

    Es dient nur als kleines Beispiel und zur Anschauung 😅.


    Nehmen wir das Ganze ein wenig auseinander, haben wir folgende Zeilen im Allgemeinen:



    "name": "Apfel", ============> Objektname


    Hier muss der Klassenname des gewünschten Objektes eingetragen werden.


    "pos": [ ============> Objektposition mit Koordinaten


    5520.00, = X Achsen Koordinate

    2023.80, = Y Achsen Koordinate

    10.65 = Höhe des Objektes vom 0 Punkt der Karte

    ],


    Damit wird die Position auf der Karte angegeben. Dafür können unterschiedliche Wege genutzt werden.

    Entweder man orientiert sich einfach an einer Karte und nutzt die Koordinaten, wobei dort keine Höhe angegeben wird.

    Dies ist dann leider eher ein Experimentieren.

    Ein anderer Weg ist der Offline Mode, bei dem man sich Offline über die Karte bewegen kann

    und dort auch Objekte platzieren und bearbeiten kann.

    Des Weiteren gäbe es noch die Möglichkeit über die Mod "VPP-Admin Tools" oder "DayZ Editor".


    "ypr": [ ============> Objekt Positionsanpassung

    0.0, = Drehung um die eigene Achse in °

    0.0, = Neigung nach links oder rechts in °

    0.0 = Kippen nach vorn oder hinten in °

    ],


    Hier kann, wie auch schon oben mit den aufgeführten Möglichkeiten, das Objektes an seiner Position ausgerichtet werden.

    Es kann gedreht oder in eine Richtung rotiert werden, je nachdem, wie man es braucht oder möchte.


    "scale": 1, =========> Objekt Skalierung


    Dies kann zur Größenskalierung eingetragen werden, wenn man es möchte. Die Zeile kann auch einfach gelöscht oder weggelassen werden,

    wenn man diese eben nicht benötigt und man das Objekt in seiner ursprünglichen Größe belassen will.

    Ansonsten wäre der Wert "1" die Originalgröße und wäre somit als 100 % zu betrachten.

    Bei dem Wert "2" wären es also 200 % und somit die doppelte Größe.

    Je nachdem sind Werte wieder mit "1.1" für z.B. 110 % oder "1.01" für z.B. 101 % zu verwenden.


    "enableCEPersistency": true ============> Objekt Persistenz


    Bei dieser Einstellung, wird dem Objekt, wenn es eine Lebenszeit besitzt, diese so lange entzogen, bis ein Spieler damit interagiert.

    Um das ganze etwas einfacher darzustellen, nehmen wir wieder einen Apfel und ein Haus als Beispiel.

    Bei dem Haus handelt es sich um ein statisches Objekt. Dieses besitzt keine Lebensdauer, was es irgendwann wieder verschwinden lässt.

    Bei einem Apfel hingegen ist dies eben anders.

    Normalerweise wird ein Apfel z.B. an einem Apfelbaum gespawnt, verbleibt dort eine gewisse Zeit und gammelt eventuell vor sich hin

    und despawnt dann einfach wieder, das kann ein wenig variieren, aber für dieses Beispiel nehmen wir jetzt mal 2 Stunden.

    Würde also kein Spieler mit einem normal gespawnten Apfel Interagieren, würde dieser nach 2 Stunden wieder despawnen.

    Nimmt ein Spieler ihn mit, greift die in der Types.xml hinterlegten Lebensdauer und er bleibt z.B. für sagen wir mal 4 Stunden liegen.

    Hingegen würde der mit der "objectSpawnersArr" gespawnte Apfel nicht nach 2 Stunden verschwinden, sondern so lange liegen bleiben,

    bis ein Spieler mit diesem interagiert. Erst nach dem ein Spieler mit diesem interagiert hat, würde er wie ein normaler Apfel,

    nach 4 Stunden verschwinden.

    Ich habe das jetzt leider nicht so ausführlich getestet, aber würde meinen, dass wenn ein Spieler den Apfel einsammelt,

    wird das Spiel merken, dass das Objekt fehlt und beim nächsten Serverneustart einen neuen Apfel an der Position spawnen.


    Ich hoffe, ich habe nichts Vergessen und würde sagen, dass auch dieses Thema damit erledigt ist und hoffe es ist weitestgehend verständlich 😅.

  • Server Files: Erklärung und Bedeutung

    Willkommen im nächsten Abschnitt 👋

    Und freut mich das ihr bis hier durchgehalten

    oder das ganze bis hier hin weiter verfolgt habt 😊.


    Ab hier beginnen wir mit den Setting-Extras:



    In den nächsten Abschnitten geht es hauptsächlich um zusätzliche oder um die Berechnungen vorheriger Einstellungen.



    Zur besseren Übersicht mache ich hier noch einmal ein kleineres Inhaltsverzeichnis für die Themen, mit denen wir uns beschäftigen werden.


    Als Erstes die Serverzeit Berechnung,

    bei der wir uns mit allen Einstellungen und Verhaltensweisen, die sich mit der Zeit und auch mit ihrer Auswirkung befassen.


    Die Schock-Berechnung,

    für die Berechnung und Einstellungen von Schäden, die den Charakter z.B. ohnmächtig werden lassen.


    Die Ausdauer Berechnung,

    für die Berechnung und Anpassung der Einstellungen, die sich mit dem Durchhaltevermögen des Charakters befassen.


    Des Weiteren haben wir noch die cfggameplay.json Extras,


    mit der objectSpawnersArr,

    für das Platzieren und Spawnen von z.B. neuen Gebäuden.


    Und den spawnGearPresetFiles,

    mit Einstellung und dem Anpassen von Startausrüstungen.


    Als Letztes haben wir noch das Thema server_manager,

    der sich mit einer anderen Art der Mod Installation befasst.



    Bei den Berechnungen lässt sich leider schon erahnen, dass in diesen Abschnitten sehr viel Mathematik vorkommt.

    Und ja, jetzt verstehe ich auch meinen Mathematik-Lehrer, der gemeint hat,

    "Es wird die Zeit kommen, wo du es brauchen wirst" 😅.

    🤔 Er hatte bedauerlicherweise recht 🤣.


    Aber nichtsdestotrotz, fangen wir an und stürzen uns ins Getümmel 😁😜.


  • Server Files: Erklärung und Bedeutung

    Thema:


    init.c



    Placeholder ☕🍪




    Da ich die Themen, die sich mit Servereinstellungen befassen, gerne etwas zusammen haben möchte, bevor ich zu anderen Sachen wie den Types übergehe,

    hoffe, ich mal das ist Ok, wenn ich das ganze mal kurz so abkürze und Nachtragen.

    Je nachdem, wie ich die Themen fertig habe.


    Ich würde dementsprechend versuchen dem Wunsch der Types und Events nachzukommen und werde diese nebenbei mit bearbeiten.

    Da ich eh etwas Simultan an mehreren gleichzeitig arbeite, sollte das hoffentlich gehen 😅.


    Ich bitte daher um ein klein wenig Nachsicht und Verständnis 😅

  • NylonSheath

    Huhu,


    ich glaube, ich muss dich da halbwegs enttäuschen.

    Ich selber habe jetzt leider auch nix auf die schnelle finden können, um das Ding einzufärben.

    Ich habe zwar Mods gesehen, in denen es eine grüne oder schwarze Variante gibt, aber habe beim Nachschauen festgestellt,

    das die Modelle selbst neu bearbeitet wurden und dazu das Originalmodell verwendet wurde.

    Oder sie sind einfach gut genug, um eine 1 zu 1 Kopie nachzubauen 🤣.

    Aber insofern sich sonst niemand findet, muss ich dich wohl wie gesagt enttäuschen 😫

  • Server Files: Erklärung und Bedeutung

    Das kann ich gerne machen, ich arbeite gerade an 3 kleineren Themen und schau Mal ob ich schaffe die beiden gleich mit an zu hängen 😁 und ich schau auch gleich ob ich noch eine Thema dazu packe um das ganze ein wenig ab zu runden, da ein thema für die "Typen.xml" noch etwas interessant sein könnte😉

    Aber danke für das Feedback und da weiß ich doch schonmal worauf ich mich als nächstes stürze 😅😂

  • Server Files: Erklärung und Bedeutung

    Thema:


    cfggameplay.json


    Was ist die cfggameplay.json?


    Im Prinzip ist sie eine erweiterte, Benutzerfreundlicherer oder einfachere Form der serverDZ.cfg .

    Sie beschäftigt sich hauptsächlich damit, wie der Server, das Spiel, der Spieler und die Umwelt sich in bestimmten Sachen verhalten soll.

    Dafür gibt es zum einen verschiedene Bereiche, die sich mit Einstellungen bezüglich bestimmter gebiete wie Ausdauer, Basenbau oder der Temperatur befassen.


    Wichtig!: Diese Datei ist meist schon auf dem Server Vorhanden, um diese aber tatsächlich nutzen zu können,

    muss in der serverDZ.cfg eine neue Zeile erstellt oder wenn vorhanden die Zeile "enableCfgGameplayFile = 1;"

    erstellt oder geändert werden.

    Ebenso Wichtig ist, das Zeilen die in der cfggameplay.json geändert oder angepasst werden,

    in der serverDZ.cfg nicht eingetragen werden sollten und wenn doch, sollten sie nicht mit Unterschiedlichen Werten aufgeführt sein.


    Nehmen wir aber erst mal wieder den Grundaufbau und nehmen ihn danach Stück für Stück alles auseinander.


    Jetzt die einzelnen Bereiche und da fängt das ganze schon mal mit einem kleinen wichtigen Detail an.


    "version": 122, = Versionsnummer


    Dabei handelt es sich nicht direkt um die Version dieser Datei, sondern lediglich darum bei welchem Patch das letzte mal etwas geändert wurde.

    Vorherige Versionen waren die 120 zum Patch 1.20 und die 121 zum Patch 1.21. Würde sich also zum Patch 1.26 in dieser Datei etwas ändern, wird daraus nicht die 123,

    sonder gleich die 126, da dann die letzte Änderung zum Patch 1.26 stattfand.

    Da auch nach Patch 1.26 immer noch die 122 vorhanden ist, wissen wir also, das hier nichts geändert wurde.



    Im nächsten Abschnitt geht es eher um Globale Generelle kleinere Einstellungen. Und ja, einige Einstellungen oder bestimmte Zeilen werden dem ein

    oder anderen Bekannt vorkommen, denn ein paar davon sind in einer abgeänderten Form schon im Thema serverDZ.cfg so wie im serverDZ.cfg Extras Thema vertreten 😉.


    "GeneralData": = Eine einfache Einteilung für die Generellen Einstellungen


    "disableBaseDamage": false, ===========> Basebuildingschaden Einstellung


    Hier kann der Schaden an Basenbau Objekten aktiviert (= false) oder deaktiviert (= true) werden.

    Es bezieht sich aber nur auf Objekte wie dem Wachturm, Zäunen und den Fahnenmast so wie Zukünftigen Strukturen.


    WICHTIG!!! Bei solchen Einstellungen, die mit true oder false eingestellt werden, immer aufpassen und lesen.

    In diesem Falle könnte man sich das ganze als Bsp. vorstellen als würde sich das Spiel hinsetzen

    und dem Admin eine Frage stellen. "disableBaseDamage" übersetzt in "Basenbau Schaden deaktiviert?".

    Und aus diesem Grund als Antwort richtig oder Falsch.

    Ich hoffe das als Beispiel ist für alle Zukünftigen abfragen und Einstellungen soweit selbsterklärend

    und ausreichend😅.


    "disableContainerDamage": false, =======> Containerschaden Einstellung


    In diesem Fall das selbe wie die Vorherige Einstellung, nur bezieht sie sich auf Objekte wie Zelte oder Fässer.

    Objekte, in denen man eben viel verstauen kann oder die als "Container" deklariert sind.


    "disableRespawnDialog": false, ========> Respawn Dialog Einstellung


    Hier kann man den Dialog aus und einstellen, der den Spieler nach dem der Respawn Auswahl entscheiden lässt, ob er mit einem Zufälligem

    oder einem Personalisiertem Charakter respawnen kann. Wenn "true" eingetragen ist, wird sozusagen immer ein zufälliger Charakter gewählt.


    "disableRespawnInUnconsciousness": false ========> Respawn Dialog Einstellung im Zustand Bewusstlos


    Bei dieser Einstellung wird die Respawn Einstellung für den Bewusstlosen Zustand Deaktiviert oder Aktiviert.

    Somit sollte im Regelfall nur noch der Respawn nach dem tot des Charakters möglich sein.



    In diesem Abschnitt geht es mehr um Spieler bezogene Einstellungen, wie die schon erwähnte Ausdauer zum Beispiel.


    "PlayerData": = Eine einfache Einteilung für die Kategorie Spieler


    "disablePersonalLight": false, ========> Charakter Leuchten


    Mit dieser Einstellung kann man das Licht, welches der Spieler bzw. der Charakter ausstrahlt ein und ausstellen.

    Dadurch wird es dem Spieler erschwert Objekte oder Wände etc. zu sehen, die sich direkt vor ihm befinden und auf dem Server tiefste Nacht ist.


    !!! "spawnGearPresetFiles": [], !!!


    Wichtig!: Diese Zeile ist in den Original Dateien nicht vertreten. Aber ich dachte mir, ich nehme diese der Vollständigkeit halber mit in diese Erklärung hinein.

    Auch um zu zeigen, das es kleinere dinge gibt, die das Spiel nicht gleich verrät 😁 und was abseits der Standardeinstellungen noch so möglich ist.

    Dafür würde ich aber das Thema cfggameplay.json Extras spawnGearPresetFiles separat anlegen und mich dort nur damit befasse.



    "StaminaData": = Eine einfache Einteilung für die Kategorie Ausdauer


    Da ich beim Schreiben gemerkt habe das es etwas viel wurde, werde ich ein Extra Thema für die Stamina/Ausdauer Berechnung.

    Von daher schneiden wir das Thema hier nur kurz ein wenig an 😅.


    "sprintStaminaModifierErc": 1.0, ==============> Modifikator für den normalen Sprint im stehen

    "sprintStaminaModifierCro": 1.0, ==============> Modifikator für das Sprinten Bzw. das schnellere kriechen in der Hocke

    "staminaWeightLimitThreshold": 6000.0, ========> maximal Gewicht in g bis zu welchem der Spieler keine Ausdauer verliert

    "staminaMax": 100.0, ==========================> maximale Ausdauer die ein Spieler ab Spielbeginn hat

    "staminaKgToStaminaPercentPenalty": 1.75, =====> Wert für die Berechnung des Ausdauer Verlustes pro kg

    "staminaMinCap": 5.0, =========================> minimale Ausdauer, die ein Spieler behält

    "sprintSwimmingStaminaModifier": 1.0, =========> Modifikator für das schnelle Schwimmen

    "sprintLadderStaminaModifier": 1.0, ===========> Modifikator für das schnelle Leitern klettern

    "meleeStaminaModifier": 1.0, ==================> Modifikator für Nahkampf Angriffe

    "obstacleTraversalStaminaModifier": 1.0, ======> Modifikator für das überqueren von Hindernissen

    "holdBreathStaminaModifier": 1.0 ==============> Modifikator für das Luftanhalten



    "ShockHandlingData": = Einteilung für die Kategorie Schock Schaden und Zustände


    Hierbei Handelt es sich um eine kleine Einstellungsmöglichkeiten, die sich mit Schock Zuständen oder Werten befassen.

    Das es Zwar im Gegensatz zur Ausdauer keine weiteren festen Werte gibt, aber man auch hier und da schauen kann,

    ob man auf seinem Server ein klein wenig herumschrauben und einstellen kann, werde ich auch hier ein kleines Extra Thema anlegen.

    Also schaut einfach unter dem Thema Schockberechnung.

    Es lassen sich auch hier einfach wieder ein paar kleinere Berechnungen besser an einem Einzelbeispiel darstellen und erklären 😅.


    "shockRefillSpeedConscious": 5.0, =============> Wert für die Schock Wiederherstellung während der Charakter bei Bewusstsein ist

    "shockRefillSpeedUnconscious": 1.0, ===========> Wert für die Schock Wiederherstellung während der Charakter Bewusstlos ist

    "allowRefillSpeedModifier": true ==============> Einstellung zum Aktivieren oder deaktivieren der Schockwiederherstellungsmodifikatoren



    "MovementData": = Einteilung für die Kategorie der Charakterbewegung und Trägheit


    Hier kann eingestellt werden wie sich die Bewegungsgeschwindigkeit des Charakters verhalten soll. Hier kann auch wieder viel Probiert und Experimentiert werden,

    um die perfekte Balance für seinen Individuellen Server zu erreichen.

    Da hier in % gerechnet wird sollte berücksichtigt werden, dass 1.0 = 1 Sekunde ist.

    Daher schreibe ich die Tatsächliche Zeit hinter die einzelnen Werte, in der Hoffnung das alles so stimmt und passt.


    "timeToStrafeJog": 0.1, = 6 ms


    Verzögerung, mit der der Charakter vom Joggen in die Schießanimation wechselt beziehungsweise übergeht.


    "rotationSpeedJog": 0.3, = 18 ms


    Verzögerung, mit der der Charakter sich während des Joggen`s dreht.


    "timeToSprint": 0.45, = 27 ms


    Verzögerung, mit der der Charakter in den Sprint übergeht.


    "timeToStrafeSprint": 0.3, = 18 ms


    Verzögerung, mit der der Charakter vom Sprinten in die Schießanimation wechselt beziehungsweise übergeht.


    "rotationSpeedSprint": 0.15, = 9 ms


    Verzögerung, mit der der Charakter sich während des Sprinten`s dreht.


    "allowStaminaAffectInertia": true


    Hiermit wird einfach nur erlaubt, ob Ausdauer die Trägheit des Charakters beeinflussen darf oder nicht. In wie weit sich dies auswirkt,

    hab ich leider noch nicht herausfinden können, kann es mir aber nur so vorstellen, das z.B. mit mehr Ausdauer, die Geschwindigkeit der Jeweiligen

    Aktion schneller wird.



    "DrowningData": = Einteilung für die Kategorie des Ertrinkens


    Hierbei Handelt es sich um ein paar einfache Schadenswerte, die der Charakter erhält, wenn er unter Wasser ist bzw. am Ertrinken.

    Man hat meist nur noch Sekunden und kann z.B. eintreten wenn man doch mal unter die Map verschwindet 😅.


    "staminaDepletionSpeed": 10.0, ================> Ausdauer schaden in Sekunden

    "healthDepletionSpeed": 10.0, =================> Schaden in Sekunden an den Lebenspunkten

    "shockDepletionSpeed": 10.0 ===================> Schockschaden in Sekunden


    Davon ausgehend das die Standard Werte nur 100 betragen, bedeutet es eigentlich das man z.B. innerhalb von 10 sec.

    nach dem man mit einem Auto unter Wasser geraten ist ertrunken und somit Tot ist.



    "WorldsData": = Einteilungen für die Umgebung und das Klima


    Hier wird sich hauptsächlich mit Einstellungen befasst, die sich mit der Welt und ihren Interaktionsmöglichkeiten auseinander setzen.


    "lightingConfig": 0, =============> Einstellungsmöglichkeit der Lichtverhältnisse bei Nacht


    Eine Einstellungsmöglichkeit der Lichtverhältnisse in der Nacht. Es gibt 3 Einstellungsmöglichkeiten,


    "0" = eine relativ helle Nacht


    "1" = eine dunkle Nacht und


    "2" = eine Einstellung die meiner Meinung nach die hellste ist, aber die Ergebnisse könnten abweichen.


    Als Bsp. mal ein paar Bilder Bilder mit den Unterschiedlichen Einstellungen


    VJsk20T.png

    So sah es bei mir mit dem Wert "0" aus.


    RSlqZQI.png

    Mit dem Wert "1" sah es dann so aus (Es hat angefangen mit Regnen 😅)


    LXCDpSH.png

    Bei dem Wert "2" sah es dann bei mir so aus.


    !!! "objectSpawnersArr": [], !!!


    Wichtig!: Diese Zeile ist in den Original Dateien zwar vertreten, aber ich werde auch hier der Vollständigkeit halber

    und der besseren Darstellung noch das Thema cfggameplay.json Extras: objectSpawnersArr erstellen.


    "environmentMinTemps": [-3, -2, 0, 4, 9, 14, 18, 17, 13, 11, 9, 0],

    "environmentMaxTemps": [3, 5, 7, 14, 19, 24, 26, 25, 18, 14, 10, 5],


    Hier nehme ich einfach mal gleich beide Zeilen, da sie eh zusammengehören und die Temperaturen für oben min und unten max darstellen.

    Aufgeteilt ist dies in 12 Monate, angefangen mit Januar links, bis Dezember rechts. Hier kann man also ein wenig Spielen, sollte es aber nicht übertreiben.

    Als Beispiel nehmen wir einfach mal die min Temperatur von -3 und max von 3 im Januar. Es bedeutet nur das sich der Server danach richtet,

    nicht, das der wert Tatsächlich auch erreicht wird. der Tiefpunkt ist Beispielsweise eher Nachts und die max Temperatur eher Tagsüber.

    Dazu kommen natürlich noch die Faktoren von Wind und Wetter.


    "wetnessWeightModifiers": [1.0, 1.0, 1.33, 1.66, 2.0]


    Dies ist ein Modifikator für das Gewicht von Objekten anhand der Feuchtigkeitsstufe.

    Von Links nach Rechts ausgehend ist der Wert 1.0 wieder in % angegeben oder zu berechnen.

    Daher nehme ich einfach mal eine Daunenjacke als Bsp.:


    Trocken =====> 1.0 = 100% = 2 Kg (Das ist also Ihr Standartgewicht)

    Feucht ======> 1.0 = 100% = 2 Kg

    Nass ========> 1.33 = 133% = 2,66 Kg

    Durchnässt ==> 1.66 = 166% = 3,32 Kg

    Klitschnass => 2.0 = 200% = 4 Kg


    Ich hoffe das man so einen kleinen Überblick hat, wie das Gewicht am ende berechnet wird.



    "BaseBuildingData": = Einteilungen für das Basenbau verhalten


    Hier geht es hauptsächlich um das verhalten beim Platzieren von Basenbau Objekten und Containern wie z.B. Fässern in der Welt

    und das daraus resultierende Basebuilding. Dabei gibt es ein paar sachen, mit denen man es den Spielern einfachere

    oder schwerer machen kann.



    "HologramData": = Einteilungen für Hologramme


    "disableIsCollidingBBoxCheck": false, =============> Einstellung für die Platzierung, wenn das Hologramm mit Objekten in der Welt kollidiert


    Bei dieser Einstellung wird mit "false" dem Spiel und dem Spieler die Platzierung von Objekten verboten, wenn das Hologram auf z.B. einen Baum trifft.

    Mit "true" wird dieses erlaubt und ermöglicht im Grunde auch eine Platzierung, wenn ein Baum oder eine Wand das Objekt zur Hälfte verdecken würde.


    "disableIsCollidingPlayerCheck": false, ==========> Einstellung für die Platzierung, wenn das Hologramm mit dem Spieler kollidiert


    Hierbei wird mit "false" dem Spiel und dem Spieler die Platzierung von Objekten verboten, wenn das Hologram auf einen Spieler trifft bzw. er im weg steht.

    Mit "true" wird dieses erlaubt und ermöglicht eine Platzierung, auch wenn ein Spieler versehentlich mal durch das Hologram läuft.


    "disableIsClippingRoofCheck": false, ==============> Einstellung für die Höhen Überprüfung bei der Platzierung


    Mit "false" wir dem Spiel die Überprüfung der Höhe eines Objektes erlaubt und somit geschaut wird, das z.B. bei einem Zelt ein Teil des Daches nicht

    in der Decke verschwindet. Bei "true" könnte man also ein Zelt selbst dann Platzieren, wenn es für einen Raum zu hoch wäre.


    "disableIsBaseViableCheck": false, ===============> Einstellung für die Platzierung auf dynamischen Objekten


    Im Prinzip und einfach ausgedrückt wird mit "false" das Platzieren auf nicht Statischen Objekten wie z.B. Fahrzeugen

    oder Events (Heli Crashes, Konvois) verboten.

    Als Gegenstück wird mit "true" dies wiederum erlaubt.


    "disableIsCollidingGPlotCheck": false, ===========> Einstellung für die Platzierung von Feldern


    Hierbei wird das platzieren eines Feldes mit "false" auf nicht kompatiblen Untergründen wie Beton verboten.

    Mit "true" hingegen ist es demnach erlaubt und man kann überall Felder anlegen.


    "disableIsCollidingAngleCheck": false, ===========> Einstellung für die Überprüfung des Winkels bei der Platzierung


    Bei dieser Einstellung wird mit "false" der Winkel und das Gefälle des Untergrunds Geprüft auf dem gebaut werden soll.

    Mit "true" wird diese Überprüfung deaktiviert und es ist eher möglich auf nicht geraden Oberflächen wie z.B. Dächern zu bauen

    oder Fässer zu platzieren. Zu beachten ist hierbei natürlich ob sich Objekte am Untergrund Orientieren. Was bei Aktivierung

    zwar bis zu einer bestimmten Steigung noch möglich ist und auch noch human aussieht, kann bei der Deaktivierung zu ein paar Problemen führen.


    "disableIsPlacementPermittedCheck": false, =======> Einstellung für Zulässige Platzierungen


    Mit dieser Einstellung wird mit "false" das bauen auf nicht zulässigen Oberflächen und Strukturen verboten.

    Womit bei "true" z.B. das bauen auf Strukturen wie dem Zaun oder dem Turm erlaubt wird.


    "disableHeightPlacementCheck": false, ============> Einstellung für das Platzieren mit begrenzter Höhe


    Hierbei wird mit "false" das bauen nur bis zu einer bestimmten Höhe erlaubt. Wo die maximal Höhe liegt weiß ich nicht,

    aber vlt. lässt sich das ja noch heraus finden 😉.

    Mit "true" lässt sich also die maximale Bauhöhe entfernen.


    "disableIsUnderwaterCheck": false, ===============> Einstellung für das Platzieren unter Wasser


    Wie die Einstellung schon sagt, ist mit "false" das Platzieren unter Wasser nicht möglich.

    Mit "true" hingegen würden sich Fässer unter Wasser verstecken lassen oder sogar Türme in Seen platzieren lassen.


    "disableIsInTerrainCheck": false, ================> Einstellung für die Überprüfung von Terrain


    Hiermit lässt sich mit "falls" die Überprüfung zum Abschließen an einem Gelände Aktiveren.

    Deaktiviert mit "true" lässt uns sozusagen einen Turm auch an einem Hang platzieren,

    selbst wenn ein Stamm oder eine Wand nicht mehr den Boden berühren würden sondern eben in der Luft hängen.


    "disallowedTypesInUnderground": ["FenceKit","TerritoryFlagKit","WatchtowerKit"] => Verweigerung für Objekte im Untergrund


    Bei dieser Einstellung wird das Platzieren von Objekten um Untergrund, also in Bunkern verboten.

    Dabei wird auf die Types zurückgegriffen bzw. auf die Klasse (Class) von Objekten.

    Da hier auf eine Klassenvererbung zurückgegriffen wird, muss man sich das ganze vereinfacht ausgedrückt so vorstellen.

    Nehmen wir das Fass als kleines Beispiel.

    Dieses hat in seinen Objekt Einstellungen eine Basis Klasse = Barrel_ColorBase.

    Diese beinhaltet alle Einstellungen und Überträgt diese auf alle Nachfolgenden Objekte.

    In diesem Fall also auf die Einzelnen Farbigen Fässer. Somit ist also zu Berücksichtigen, das hier nicht nur Barrel_Yellow,

    sondern eben Barrel_ColorBase einzutragen ist, da man sonnst nur ein Gelbes Fass nicht im Untergrund Platzieren darf.

    Ich hoffe das das so Verständlich genug ist... Besser ist es mir auf Anhieb nicht eingefallen 😅.



    "ConstructionData": = Einteilungen für Konstruktionen


    "disablePerformRoofCheck": false, =================> Einstellung für die Überprüfung von Höhen Kollisionen


    Hierbei geht es um die Überprüfung beim Konstruieren bzw. Bauen.

    Dabei wird mit "false" Verhindert, das ein Turm z.B. in einer Scheune komplett gebaut werden kann.

    Die letzte Ebene wäre in sofern nicht mehr möglich, wenn diese die Höhe des Raumes überschreitet.

    Mit "true" hingegen wäre dies möglich und man könnte einen Turm einfach durch die Decke weiter bauen.


    "disableIsCollidingCheck": false, =================> Einstellung für die Überprüfung von Kollisionen


    Hierbei wird mit "false" Verhindert, das man beim kollidieren mit anderen Objekten in der Welt weiterbauen könnte.

    Mit "true" wird genau dieses deaktiviert und z.B. der bau eines Zaunes nicht verhindert,

    selbst wenn man ein Fass in den weg stellen würde.


    "disableDistanceCheck": false =====================> Einstellung für die Überprüfung der Entfernung zu Spielern


    Mit dieser Einstellung lässt sich mit "false" die Überprüfung der Entfernung Aktivieren.

    Mit "true" lässt diese sich also auch wieder Deaktivieren und ermöglicht das bauen selbst dann,

    wenn die Distanz zu einem zu gering wäre und dieser ggf. beim Bau eines Turms zu nahe steht,

    egal ob in der Höhe oder z.B. der selben Ebene.



    "UIData": = Einteilungen für das User Interface


    "use3DMap": false, = Map Einstellung


    Mit dieser Einstellung lässt sich zwischen den 2 möglichen In-Game Karten wählen.

    Bei "false" wird die 2D Map genutzt, welche eine Art Fenster öffnet, auf dem wir uns mit der Maus bewegen können.


    Hierzu ein Bild zum besseren Verständnis

    AyTVV5G.png


    Ist diese Einstellung auf "true" gestellt, wird dem Spieler die Ansicht nur so gewährt,

    wie der Charakter diese in der Hand hält.


    Auch hier für noch ein Bild wie es anschließend In-Game aussieht.

    20LIrAG.jpeg


    Wichtig!!! Beim nutzen der 3D Karte wirkt es deutlich Immersiver und hat den Vorteil, das man immer noch sehen kann was um den Charakter herum passiert.



    "HitIndicationData": = Treffer Einstellungen


    Wichtig!!! Bei dieser Kategorie bin ich mir unsicher, ob diese Tatsächlich noch vorhanden und Wirksam ist.

    Trotz testen, einstellen und anpassen aller möglichen Einstellungen, sowohl hier als auch in den anderen Configs,

    wurden mir keine unten aufgeführten anzeigen und Markierungen angezeigt.

    Da diese Einstellung schon mit der 1.15 erschien und wir mittlerweile Vanilla schon ein Treffer feedback haben,

    glaube ich, das es im folgenden eher um eine Erklärung der Vollständigkeit halber handelt und diese Einstellungen zu Testzwecken

    und einem Prototypen der heutigen Blutflecken am Bildschirmrand 😅.

    Aber natürlich kann man mich auch an dieser Stelle gerne wieder berichtigen und mir ggf. sagen was man einstellen muss

    um den doppelt gemoppelten feedback Tracker zu Aktivieren 🤣. Bei mir hat es ztumindest nicht Funktioniert.


    "hitDirectionOverrideEnabled": false, ============> Einstellung für die Überschreibung Treffer Richtung


    Mit dieser Einstellung wird Grundlegen alles was in der "HitIndicationData" steht mit "true" Aktiviert und mit "false" Deaktiviert.

    Bzw. wird bei "false" jeder Wert als "0" angesehen.


    "hitDirectionBehaviour": 1, ======================> Einstellungen für das Treffer Richtungsverhalten


    Hierbei lassen sich 3 Einstellungen vornehmen, und zwar die Werte "0", "1" und "2".


    "0" = Deaktiviert

    Hiermit haben wir also nur die Vanilla Einstellung und sehen ob wir getroffen wurden und in etwa aus welcher Richtung.


    "1" = Statisch

    Hierbei wird dem Spieler Zusätzlich mit einer Richtungsmarkierung auf dem Monitor gezeigt, von wo aus er getroffen wurde.

    Diese bleibt z.B. bei einem Treffer von Links auch dann am linken Bildschirmrand, selbst wenn wir und um 180° drehen.


    "2" = Dynamisch (Diese Einstellung war als Experimentell zu betrachten und würde es warscheinlich noch, wenn es gehen würde 🤣)

    Im Gegensatz zur Dynamischen anzeige wird hier wie im Beispiel oben bei einem Treffer von links die Markierung die Position

    des Treffers beibehalten und sich nicht mit dem Charakter bewegen.


    "hitDirectionStyle": 0, ==========================> Einstellungen für das aussehen der Richtungsmarkierung


    Auch hier gibt es wieder die 3 Einstellungsmöglichkeiten "0", "1" und "2".

    Dabei wird hier nur festgelegt, welches Set von Bildern für diese Darstellung genutzt werden soll.


    0 = Blutflecken


    1 = eine Spitze


    2 = ein Pfeil


    "hitDirectionIndicatorColorStr": "0xffbb0a1e", ===> Einstellungen für die Farbe der Richtungsmarkierung


    Hier kann die Farbe Richtungsmarkierung Eingestellt werden.

    Hierbei ist zu beachten, das die Farben im ARGB-Format und Hexadezimal angegeben werden.

    Ich mache gerne ein extra Thema dafür, da das hier den Rahmen sprängen würde 😅.


    "hitDirectionMaxDuration": 2.0, ==================> Einstellungen für die Dauer der Richtungsmarkierung


    Damit kann die max. Dauer einer Markierung festgelegt werden, dabei ist aber ein wenig zu berücksichtigen,

    das es zum einen auf die schwere des Treffers ankommt.

    Daher würde ich hier maximal das bekannte Experimentieren vorschlagen, oder den Standartwert einfach lassen wie er ist.


    "hitDirectionBreakPointRelative": 0.2, ===========> Einstellungen für die Ausblendung der Richtungsmarkierung


    Hier Empfehle ich auch wieder das Experimentieren für das persönliche Ergebnis.

    Grundlegend wird hier aber angegeben, wie lange es dauert bis die Markierung Ausgeblendet wird.

    Zu Beachten ist maximal, das hier die Dauer angegeben wird und nicht nach wie vielen Sekunden.


    "hitDirectionScatter": 10.0, =====================> Einstellungen für die Präzision der Richtungsmarkierung


    Mit dieser Einstellung lässt sich die Genauigkeit der Richtung des Treffer feedback's einstellen.

    Der Wert der hier angegeben wird, wird in Grad, bzw. im Winkel zum 0 Punkt in beide Richtungen angegeben

    und wird zufällig im angegebenen Bereich angezeigt.

    Wäre hier der Wert "0.0" angegeben, wäre es also die exakte Richtung eines Treffers.

    Bei "5.0" wäre es ein Bereich von 10°, bei "10.0" Sind es also 20°.

    Würde man hier also lustigerweise "180.0" eintragen, hätte man eine Markierung Irgendwo auf dem Bildschirm,

    selbst wenn man genau von Vorne Getroffen wurde 😅.

    Totale Verwirrung also 🤣.


    "hitIndicationPostProcessEnabled": true ==========> Einstellungen für die Nachbearbeitung


    Hier kann man eine Art Nachbearbeitung mit "true" aktivieren, die als eine Art Roter Blitz dargestellt wird.

    Mit "false" wird das Ganze natürlich wieder Deaktiviert.



    "MapData": = Einteilungen für die Karten Nutzung


    "ignoreMapOwnership": false, ==========> Einstellungen für öffnen und anzeigen der Karte


    Hierbei kann mit "true" zum Aktivieren und "false" wieder zum Deaktivieren, die Nutzung der In-Game Karte über die Taste "M" eingestellt werden.


    Wichtig!!! Bei dieser Einstellung ist wahrscheinlich gut zu wissen, das bei der Nutzung der In-Game Map nur 3 Möglichkeiten zur Verfügung stehen,

    "use3DMap" ist hierbei mit zu Berücksichtigen.


    1. Man nutzt nur die 3D Karte des Charakters, wenn dieser sie in der Hand hält und die Entsprechende Aktion ausführt.


    2. Nur die 2D Karte wird genutzt und angezeigt, sobald der Charakter die Karte öffnet.


    3. Die 2D Map kann mit "M" immer geöffnet werden. Eine Einstellung, das man die Karte mit "M" öffnen kann,

    nur wenn der Charakter die Karte im Inventar hat ist leider nicht möglich.

    Wäre aber wahrscheinlich mal ne Anfrage bei Bohemia wert 🤣😅.


    Und da ich es beim letzten mal vergessen und Übersehen habe, noch mal ein kleiner Nachtrag.

    Denn es gibt einen kleinen Unterschied bei der Darstellung der 2D Karte.

    Zum einen das schon oben gezeigte Bild, welches das Layout zeigt, wenn unser Charakter die Karte in der Hand hält.

    Dabei ist egal, ob wir sie mit "M" öffnen, oder über die Aktion des Charakters.

    Haben wir die Karte nicht in der Hand sondern nur im Inventar oder Überhaupt nicht und öffnen diese mit "M", haben wir folgendes Layout:

    mApCwPF.png

    (Kommt dem Original am nächsten, selbsterstellter Screenshot wird nachgetragen 😅, Quelle ist aber so lange ein Screenshot von iZurvive )


    Wichtig!!! Wenn "use3DMap" Aktiv ist, kann auch mit "M" keine Karte geöffnet werden, selbst wenn "ignoreMapOwnership" Aktiv ist.


    "ignoreNavItemsOwnership": false, ==========> Einstellungen für Kompass / GPS Nutzung


    Mit "true" wird hier für die Nutzung der Zusätzlichen Anzeigen (Position / Koordinaten) bei der 2D Map die Notwendigkeit

    von einem Kompass oder GPS Gerätes Deaktiviert.

    Mit "false" müssen also der Kompass oder das GPS Gerät für die Infos im Inventar Vorhanden sein.


    Wichtig!!! Diese Info Anzeigen sind nur mit der 2D Karte Kompatibel. Wird die Karte vom Charakter nur in der Hand gehalten (3D Map),

    sind diese also nicht Vorhanden.


    "displayPlayerPosition": false, ==========> Einstellungen für Spielerposition


    Bei dieser Einstellung wird mit "true" einfach gesagt, das der Charakter mit einem roten Marker auf der In-Game Map (2D) angezeigt wird.

    Mit "false" wird es eben wieder Deaktiviert.


    "displayNavInfo": true ==========> Einstellungen für Kompass / GPS UI


    Hiermit lässt sich das UI von Kompass und GPS Komplett deaktivieren, egal ob sich die beiden Objekte im Inventar befinden.

    Mit "true" wird es angezeigt, mit "false" dementsprechend Ausgeblendet.



    Das sollte alles im großen und ganzen hoffentlich auch für diese Thema gewesen sein.

    Ich hoffe wie immer, das es für alle soweit Verständlich war und bin wie immer für Feedback, Verbesserungen, Berichtigungen und Ergänzungen immer offen 😁.


    Aber dennoch wünsche ich auch weiterhin allen die sich bis hierhin Durchgebissen haben viel Erfolg und hoffe das es eine kleine Hilfe ist.