Beiträge von derKobold1987

  • Server Files: Erklärung und Bedeutung

    Thema:



    cfgeffectarea.json


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


    Heute im Programm, die toxischen Zonen.

    Also immer schön die Gasmasken aufsetzen, Schutzkleidung anlegen

    und gerne den POX-Pen bereithalten 🤣.


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

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

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

    ein Spieler hat sich in einem Gebiet ausgeloggt,

    an der eine toxische Zone auftauchen kann.


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

    sich nach ihrem Log-in in einer toxischen Zone wiederfinden

    und eines grauenhaften Todes sterben müssen,

    nur weil sie mal eben eine Pause einlegen mussten,

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


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

    hier wieder der alt bekannte Inhalt 😅.



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

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

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

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


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

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


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

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


    AbaN05A.jpeg



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

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

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

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

    Er sollte sich eben beim nächstgelegenen Punkt wiederfinden.

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

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

    Aber das wäre ja gemein 😉😅.



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

    weshalb wir jetzt zur zweiten Tagesordnung übergehen.

    Den erwähnten Statischen toxischen Zonen.



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

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

    musste ich hier nochmal alles ein wenig umarbeiten 👍😑.

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



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

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

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

    zu einer statischen Zone macht.



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

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

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

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

    und ein neues System (> 1.28) ein.


    Altes System (< 1.28).



    Neues System (> 1.28).



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

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

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

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

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



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


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

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

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

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

    dafür aber eben immer noch die dynamischen Zonen

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

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

    und wenn wir keine Statischen toxischen Zonen möchten,

    es folgendermaßen aussehen lassen können.


    Code
        "Areas": [
    ],


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

    Aber nun zu den Parametern.



    "AreaName": "" = Zonen Name


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



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


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

    das es sich eben um eine Statische toxische Zone handelt.



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


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


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

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

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

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

    und auch nicht wirklich was gefunden habe 😅.

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

    und dem Scripting gedacht.



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


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



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


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

    Dabei haben wir wieder folgende Koordinaten.


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

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

    "y" = Y Achse (Höhe zum Boden)


    Hier müssen wir wie gesagt ein wenig 3-Dimensional denken und uns Vorstellen, wir schauen von Oben auf die Karte.

    Jetzt haben wir die Koordinatenreihenfolge "Pos": [ x, y, z ]" und sehen beim Vergleich,

    dass die "y" Koordinate mit "0" angegeben ist.

    Das liegt daran, dass es eben nicht wie bei normalen Events die Höhe zum "0" Punkt bzw. zum Meeresspiegel ist,

    sondern die Höhe zum Boden, auf dem sich auch unser Charakter bewegt.

    Würden wir hier also beispielsweise den Wert "50" eintragen,

    würde unser Zonen-Event 50 m über unserem Charakter liegen 😅.



    "Radius": 100 = Zonen Radius in "m"


    Damit wird der Radius der Zone in Metern angegeben.



    "PosHeight": 22 = Zonen Höhe in "m" vom "0" Punkt


    Hiermit wird im Grunde zusätzlich noch einmal die Höhe der Zone in Metern angegeben.

    Sie wird hier vom "0" Punkt an gemessen, und geht damit in diesem Fall also vom Boden aus

    22 Meter in die Höhe.



    "NegHeight": 10 = Zonen Tiefe in "m" vom "0" Punkt


    Hier haben wir das Gegenstück zur "PosHeight", denn hier wird in Metern angegeben,

    wie weit die Zone vom Boden oder "0" Punkt in die Tiefe geht.

    Grund dafür ist eigentlich simpel, falls sich jemand fragt, was das für einen Zweck hat.

    Zum einen haben wir die Optik, denn je nach Grafik und Aufbau kann es doof aussehen,

    wenn da so ein Donut über dem Boden schwebt und zum anderen, stelle man sich vor,

    man hätte einen Hang, dann würde die Zone über ihm schweben

    und man könnte sich Verstecken und das ganze von unten betrachten ohne das etwas passiert 🤣😅.



    "InnerRingCount": 1 = Ringanzahl im inneren Bereich


    Damit wird die Anzahl an Ringen im inneren Bereich der Zone angegeben,

    auf dem wieder "Particle emitter" liegen können.



    "InnerPartDist": 50 = Entfernung zwischen zwei "Particle emitter" in "m" auf inneren Ringen


    Hier haben wir eine Entfernung in "m" auf gerader Linie zwischen den "emitter",

    welche sich auf einem inneren Ring befinden.



    "OuterRingToggle": 1 = Aktivieren oder Deaktivieren des Außenringes


    Hier kann mit "1" oder "true" ein Außenring aktiviert werden, welcher zusätzlich zu den inneren Ringen existiert.

    Mit "0" oder "false" kann dieser eben auch wieder deaktiviert werden.



    "OuterPartDist": 50 = Entfernung zwischen zwei "Particle emitter" in "m" auf dem äußeren Ring


    Hier haben wir wieder eine Entfernung in "m" auf gerader Linie zwischen den "emitter".

    Diesmal eben auf dem äußeren Ring.



    "OuterOffset": 0 = Entfernung des Außenrings zum Radius


    Dies ist wie eine Art Versatz des äußeren Ringes zum eigentlichen Radius.

    Dieser vergrößert die Zone mit einer Art Verdrängung, wie es bei einer Rauchwolke eben so ist.

    Sie wächst in gewisser Weise nach außen.



    "VerticalLayers": 0 = Anzahl vertikaler Schichten


    Hierbei können wir, zusätzlich zur Bodenebene, einen weiteren Layer hinzufügen.

    Im Prinzip hätte man dadurch eine Zone über einer Zone, wodurch diese höher wirken kann.



    "VerticalOffset": 0 = Schichten Versatz


    Hiermit legen wir einen Versatz oder Abstand zwischen den Ebenen oder Schichten fest.



    "ParticleName" = Name und Pfad der Partikel einer toxischen Zone


    Hier wird der Name und der Pfad zu den Partikeln angegeben.

    In diesem Fall haben wir "graphics/particles/" als Pfad

    und "contaminated_area_gas_bigass" als Datei für die Partikel.



    "PlayerData" ===========> Spieler spezifische Grunddaten


    "AroundPartName" = Name und Pfad von Partikeln um einen Spieler herum


    Hier haben wir, wie bei der "ParticleName", einen Pfad

    und den Zugehörigen "Partikel" Effekt um einen Spieler,

    wenn dieser eine Zone betritt.

    Wir haben "graphics/particles/" wieder als Pfad

    und "contaminated_area_gas_around" als Datei für unseren Effekt.



    "TinyPartName" = Name und Pfad von kleinen Partikeln um einen Spieler herum


    Hier haben wir zusätzlich noch einmal einen Pfad

    und den Zugehörigen "Partikel" Effekt von kleinen Partikeln,

    die um einen Spieler herum erscheinen, wenn dieser eine Zone betritt.

    Auch heir haben wir wieder "graphics/particles/" als Pfad

    und "contaminated_area_gas_around_tiny" als Datei für unseren Effekt.



    "PPERequesterType" = Typenbezeichnung des Post-Processing-Effekts


    Dabei handelt es sich um eine Bezeichnung des Types,

    welcher dafür verantwortlich ist, was wir als Spieler vor uns sehen,

    wenn wir uns in einer Zone bewegen.

    In diesem Fall ist es eben der Effekt "PPERequester_ContaminatedAreaTint".



    Kommen wir nun noch kurz zu ein paar eventuellen Fragen,

    wie "Was ist ein "Post-Processing-Effekt", "was ist ein Particle emitter",

    oder "Was ist ein Particle".

    Wir versuchen es so simpel wie Möglich, und ich hoffe einfach, dass es dadurch verständlich genug ist,

    um zu verstehen, was gemeint ist und was wir einstellen 😅.



    Was ist ein Particle:


    Am Einfachsten erklärt können es 2- oder 3-Dimensionale Objekte sein, welche z.B. Rauch oder Feuer simulieren können.

    Wir müssen hierbei nur zwischen dem Particle oder Partikel und dem Particle Effekt unterscheiden.

    Der Particle Effekt wäre eine Rauchsäule, wohingegen der Particle nur ein einzelnes Element dieser Säule ist.

    Rauch kann z.B. als ein 2-Dimensionales Bild dargestellt werden. Dieses lässt sich schieben, Drehen,

    verkleinern, bewegen oder die farblich anpassen. Dies geschieht wieder durch unseren Particle Effekt.

    Im Falle eines Bildes und damit auch gleich die Frage geklärt ist,

    sehen wir dieses immer nur aus der Front Perspektive.

    Es ist als würden wir um ein Blatt Papier herumlaufen,

    welches sich aber immer mit uns dreht.



    Was ist ein Particle emitter:


    Einfach gesagt, ist es der Punkt, an dem unser Particle Effekt startet.

    Von ihm ausgehend, werden z.B. Rauchwolken aufsteigen oder es wird ein Feuer dargestellt.

    In Kombination, können wir uns also vorstellen, dass ein Helicrash einen Particle emitter besitzt.

    Von diesem ausgehend, startet der Particle Effekt, welche z.B. die Richtung der Rauchwolke angibt,

    welcher Particle (z.B. welches Bild) dargestellt wird und wie er sich verhalten soll.

    Er wird z.B. vom emitter aus größer, dunkler und verschwindet beispielsweise anschließend.



    Was ist ein "Post-Processing-Effekt:


    Diesen Effekt kann man sich als eine Art Schablone vorstellen, welche zwischen unseren Bildschirm

    und unser Auge gesetzt wird. In diesem Fall und da es ja bekanntlich doof wäre,

    jedes mal eine neue Schablone auf unseren Monitor zu legen 🤣,

    passiert dies im Prinzip auf digitalem Wege.

    Es wird sozusagen eine Schablone zwischen dem Spiel

    und dem gelegt, was wir endgültig auf dem Monitor sehen.



    Jetzt gehen wir noch auf die Zonen direkt ein und wie sie funktionieren.

    Dafür hab ich da mal was vorbereitet 🤣.

    Nein, dank Bohemia, habe ich ein paar optische Aufklärungsbeispiele die ich ein wenig angepasst habe

    und hoffe, dass es damit auch gleich ein wenig verständlicher wird 😅.

    Hier aber auch der Link zur Bohemia Darstellung, in der auch nochmal

    die "cfgeffectarea.json" ein wenig erklärt wird.


    Bohemia Dayz Contaminated Areas Configuration



    Als Erstes nehmen wir eine Zone von der Seitenansicht,

    um die Optionen "Pos", "PosHeight", "NegHeight"

    und ggf. "Radius" besser aufzuzeigen.


    NaC2KtA.png




    Als Nächstes nehmen wir noch eine Zone in der Draufsicht, um damit nochmal die Option "Radius"

    und zusätzlich die Optionen "InnerRingCount", "InnerPartDist", "OuterPartDist" und "OuterOffset" darzustellen.


    OTpBTxP.png




    Die letzte Darstellung zeigt uns nochmal eine Draufsicht der Zone, wie sie am Ende aufgebaut wird.


    WImd7Ym.png



    Letzteres gilt aber hauptsächlich der Version 1.28, soll aber auch ein wenig aufzeigen,

    wie sich die Zone beispielsweise aufbaut oder wie sie kalkuliert wird.

    Hinzu kommen allerdings noch die Berechnungen einer Zone,

    auf welche wir jetzt zusätzlich auch noch ein wenig eingehen.

    Allerdings wird es ab hier auch ein klein wenig komplexer,

    weswegen ich das auch erst hier ans Ende stelle.


    Wem es also reicht, das ganze einfach mal gesehen zu haben, der kann den Teil gerne überspringen 😅🤣.



    Kommen wir nun aber zum praktischen Rechenteil.

    Damit wir Beispiele haben, werden wir uns einfach mal für alle Berechnungen

    ein paar Beispiele zusammenstellen.

    Ich trenne es hier aber wieder in die beiden Versionen vor und nach der 1.28.

    Das hat einfach den Grund, dass es in der neuen Variante wohl etwas,

    nennen wir es mal "Automatisierter" läuft.

    Innere Ringe oder der Gleichen, werden automatisch erzeugt, um die Zone auszufüllen.


    Wie wir im letzten Bild sehen, haben wir folgende Formeln, die aufzeigen, wie die Zone aufgebaut wird.


    R<Rp

    R<3 ∗ Rp

    R>3 ∗ Rp


    R = Radius + OuterOffset

    Rp = InnerPartDist / 2


    Die 3 steht meiner Meinung nach für die Formel und Funktion, die eingefügt wurde und davon ausgeht,

    dass es nur noch oder maximal 2 innere Ringe in einer Zone gibt und eben einen äußeren Ring (2 + 1 = 3).


    Nun legen wir hierfür mal 3 Beispiele fest.


    Nun müssen wir für uns für die Berechnung die Werte anschauen, die dafür auch von Bedeutung sind.

    Diese minimieren sich auf "Radius", "OuterOffset" und "InnerPartDist".

    Somit bleiben nur noch diese 3 Werte für diese Berechnung übrig, welche wir uns nun

    für jedes Beispiel herauspicken und somit folgende Zeilen haben.


    Für Zone-A:


    Radius = 30

    OuterOffset = 15

    InnerPartDist = 100


    Für Zone-B:


    Radius = 75

    OuterOffset = 20

    InnerPartDist = 100


    Für Zone-C:


    Radius = 100

    OuterOffset = 60

    InnerPartDist = 100



    Nun rufen müssen wir uns wieder unsere Werte für die Formeln ins Gedächtnis rufen,

    welche wir für die Berechnung benötigen.


    R = Radius + OuterOffset

    Rp = InnerPartDist / 2



    Somit haben wir nun folgende Werte.


    Für Zone-A:


    R = Radius + OuterOffset = 45

    Rp = InnerPartDist / 2 = 50


    Für Zone-B:


    R = Radius + OuterOffset = 95

    Rp = InnerPartDist / 2 = 50


    Für Zone-C:


    R = Radius + OuterOffset = 160

    Rp = InnerPartDist / 2 = 50



    Jetzt kommen die Formeln wieder ins Spiel, in welcher wir unsere Werte einsetzen können.

    Und damit man nicht nochmal Scrollen muss, hier auch gleich noch einmal die Formel,

    in der wir die Werte entsprechend eintragen können.


    R<Rp

    R<3∗Rp

    R>3∗Rp



    Für die Berechnung haben wir anschließend folgende Werte und

    anschließend nochmal die endgültige Darstellung.


    Für Zone-A:


    45<50

    45<3 ∗ 50 = 150

    45>3 ∗ 50 = 150


    Endgültige Darstellung


    45<50

    45<150

    45>150


    Für Zone-B:


    95<50

    95<3 ∗ 50 = 150

    95>3 ∗ 50 = 150


    Endgültige Darstellung


    95<50

    95<150

    95>150


    Für Zone-C:


    160<50

    160<3 ∗ 50 = 150

    160>3 ∗ 50 = 150


    Endgültige Darstellung


    160<50

    160<150

    160>150



    Das sieht wahrscheinlich auf den ersten Blick schlimmer aus als es eigentlich ist,

    denn im Grunde können wir nun ein wenig abgleichen und schauen,

    welche aussagen zutreffend sind.


    Für Zone-A:


    45<50 ✓

    45<150 ✓

    45>150 ×


    Für Zone-B:


    95<50 ×

    95<150 ✓

    95>150 ×


    Für Zone-C:


    160<50 ×

    160<150 ×

    160>150 ✓



    Schauen wir uns nun unsere Ergebnisse an, sollten wir diese mit dem Bild zu diesen Berechnungen vergleichen

    und feststellen, dass Zone-B wie oben im Bild den Aufbau einer Zone mit nur einem Ring hätte.

    Zone-C hingegen ist so groß, dass sie zusätzlich einen Ring, bzw. "emitter" benötigt, um diese zu füllen.

    Zone-A hat nun aber ein kleines Problem, da 2 Angaben zutreffen.

    Hier würde aber nur die erste tatsächlich zutreffen, also 45<50, was daran liegt,

    das einer unserer Partikel Effekte von alleine größer ist, als die Zone selbst.

    Somit ist die Zone also mit nur einem abgedeckt und muss nicht unnötig Ringe darin aufbauen,

    um diese zu füllen.



    Dies sollte es grundlegend für die neue Variante gewesen sein.

    Da das System aber abwärtskompatibel ist, müssen wir nun aber leider

    auch noch zusätzlich darauf eingehen, wie es mit dem Berechnen der "emitter" aussieht,

    da man in diesem Fall selber ein wenig schauen muss, wie sich das ganze ein wenig aufbaut.

    Natürlich kann man dieses Prinzip auf beide Varianten anwenden,

    allerdings müsste man in der neuen Variante auch wissen,

    wie viele Ringe man am Ende tatsächlich hat 😅.



    Aber hier mal die grundlegende Formel, die auch auf der Bohemia Webseite zu finden ist

    und wieder 3 Beispiele, mit denen wir auf die schnelle arbeiten.


    3 Beispiele.



    Und hier die Formel.


    2 PI / ACOS(1 - (x^2 / 2 ∗ y^2))


    Als Anmerkung:

    "x^2" bedeutet hoch 2, was also "x²" bedeutet und wer es noch kennt, mit "x ∗ x" gerechnet wird 😅.

    Ich werde daher in meinen Beispielen "²" verwenden, sieht halt auch schöner aus 🤣.

    Mal so zum Vergleich "2 PI / ACOS(1 - (x² / 2 ∗ y²))" 😅🤣.



    Nun müssen wir erst einmal wissen, was "x" und "y" darstellt.


    x = Platz zwischen den "emitter" des zu berechnenden Ringes = "InnerPartDist" oder "OuterPartDist"

    y = Radius des zu berechnenden Ringes



    Nun haben wir das Problem, dass wir wissen müssen, wie wir unsere Zone aufbauen wollen,

    da dies ja hier nicht automatisch passiert.

    Dafür müssen wir uns die Zeilen "InnerRingCount" und "OuterRingToggle" anschauen.


    Haben wir "OuterRingToggle" mit dem Wert "1" angegeben, besitzt unsere Zone schon mal einen Ring,

    da wir damit, wie oben beschrieben, den äußeren Ring erlauben.


    Wird "InnerRingCount" zusätzlich mit "1" angegeben, hätte unsere Zone also 2 Ringe,

    einmal einen Außenring und einen inneren Ring.

    Geben wir bei "InnerRingCount" 2 an, hätten wir dementsprechend 3 Ringe.



    Nun wissen wir schon mal, wie wir das zu berücksichtigen haben, müssen aber herausfinden,

    wie groß unsere jeweiligen Ringe sind, da mit "Radius" nur die Größe des äußeren Ringes angegeben wird.

    Da sollte man aber nicht zu viel Angst haben, denn das ist tatsächlich simpel,

    da wir nur unseren "Radius" durch unsere Anzahl der Ringe teilen müssen 😅🤣.

    Unsere Formel hierfür sollte also lauten:


    Radius / (InnerRingCount + 1)


    Nehmen wir dafür das Beispiel "Radius" = 150 und "InnerRingCount" = 2,

    sollte unsere Formel also wie folgt aussehen.


    150 / 3 = 50


    Dies wiederum bedeutet für uns, dass der innerste Ring einen "Radius" von 50,

    der mittlere Ring einen "Radius" von 100 und der äußerste wieder unseren "Radius" von 150 hat.


    Als Gegenbeispiel nehmen wir nun mal noch schnell "Radius" = 150 und "InnerRingCount" = 1,

    was für uns also heißt


    150 / 2 = 75


    Somit hat also unser innerer Ring einen "Radius" von 75 und unser äußerer wieder den Wert 150.


    Wichtig ist natürlich zu beachten, dass wenn "OuterRingToggle" mit "0" angegeben ist

    und "InnerRingCount" mit beispielsweise "2", wir in diesem Falle nur 2 und nicht 3 Ringe haben.

    In diesem Fall würden wir zwar immer noch mit 3 Ringen rechnen,

    müssen dies aber bei der Berechnung der "emitter" berücksichtigen.



    Aber weiter im Text und weiter mit dem Kopfzerbrechen 🤣, denn nun kommen wir wieder zu unserer Formel,

    mit der wir die "emitter" berechnen.

    Wir erinnern uns nochmal an die Formel "2 PI / ACOS(1 - (x² / 2 ∗ y²))"

    und schauen uns zur not die Bohemia Version mit dem Rechenweg für "x" = 20 und "y" = 105 an.


    2 PI / ACOS(1 - (20² / 2 ∗ 105²)) = 2 PI / ACOS(1 - (400 / 2 ∗ 11025)) = 2 PI / ACOS(1 - (400 / 22050)) = 2 PI / ACOS(1 - 0,01814059) = 2 PI / ACOS(0,98185941) = 2 PI / 0,190765318 = 32,93672756


    Das ganze können wir aber etwas aufhübschen, was meiner Meinung nach

    auch gleich etwas verständlicher aussieht.


    2 PI / ACOS(1 - (20² / 2 ∗ 105²))

    = 2 PI / ACOS(1 - (400 / 2 ∗ 11025))

    = 2 PI / ACOS(1 - (400 / 22050))

    = 2 PI / ACOS(1 - 0,01814059)

    = 2 PI / ACOS(0,98185941)

    = 2 PI / 0,190765318

    = 32,93672756



    Nun aber endlich zu dem worauf alle gewartet haben und wir alle gespannt sind,

    wie berechnen wir nun diese blöden "emitter" 🤣.

    Nein, Spaß.

    Ich würde glaube ich auch lieber ein Eis essen, aber Respekt an alle, die es bis hier hingeschafft

    und durchgehalten haben 😅.



    Jetzt aber wirklich 😅.

    Nehmen wir wieder unsere 3 Beispiele von oben, haben wir folgende und für uns wichtigen Werte nochmal in Kurzform

    und zusätzlich die Anzahl und Größe der Ringe, die wir berechnen konnten.


    Für Zone-A:


    Radius = 60

    InnerRingCount = 1

    InnerPartDist = 20

    OuterRingToggle = 1

    OuterPartDist = 30


    Anzahl Ringe = 2


    Radius Ring 1 = 30

    Radius Ring 2 = 60


    Für Zone-B:


    Radius = 100

    InnerRingCount = 1

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 50


    Anzahl Ringe = 2


    Radius Ring 1 = 50

    Radius Ring 2 = 100


    Für Zone-C:


    Radius = 150

    InnerRingCount = 2

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 40


    Anzahl Ringe = 3


    Radius Ring 1 = 50

    Radius Ring 2 = 100

    Radius Ring 3 = 150



    Nun können wir das ganze Wissen anwenden und unsere "emitter" auf den Ringen berechnen,

    so wie unsere Gesamtanzahl an "emitter" für unsere Zone.


    Dafür fangen wir wieder mit Zone-A an, bei welcher wir nun die Berechnung für jeden der beiden Ringe vornehmen müssen.

    Also haben wir eine Berechnung für Ring 1 und eine für Ring 2.

    Wichtig zu beachten ist hier aber, welcher Ring mit welchem "...PartDist" berechnet wird.

    In unserem Bsp. ist Ring 1 der innere Ring und wird in diesem Fall mit dem Wert der "InnerPartDist" berechnet.

    Ring 2 ist der äußere Ring und wird daher mit dem Wert der "OuterPartDist" berechnet.

    Die Gleichungen dafür sehen also in Kurzer und Rechenweg Variante folgendermaßen aus.


    Zone-A Ring 1 = 2 PI / ACOS(1 - (20² / 2 ∗ 30²))


    2 PI / ACOS(1 - (20² / 2 ∗ 30²))

    = 2 PI / ACOS(1 - (400 / 2 ∗ 900))

    = 2 PI / ACOS(1 - (400 / 1800))

    = 2 PI / ACOS(1 - 0,22222222)

    = 2 PI / ACOS(0,77777778)

    = 2 PI / 0,67967382

    = 9,24441272


    Zone-A Ring 2 = 2 PI / ACOS(1 - (30² / 2 ∗ 60²))


    2 PI / ACOS(1 - (30² / 2 ∗ 60²))

    = 2 PI / ACOS(1 - (900 / 2 ∗ 3600))

    = 2 PI / ACOS(1 - (900 / 7200))

    = 2 PI / ACOS(1 - 0,125)

    = 2 PI / ACOS(0,875)

    = 2 PI / 0,50536051

    = 12,43307536


    Nach dieser Rechnung und wenn wir alles richtig gerechnet haben,

    haben wir die Werte 9,24441272 für den inneren

    und 12,43307536 für den äußeren Ring.

    Für unsere Anzahl benötigen wir allerdings nur die Zahl vor dem Komma.

    Somit haben wir also nur noch die Werte 9 und 12, welche wir zusammenrechnen können.


    9 + 12 = 21 + 1 = 22


    Unsere Zone hat also 22 "emitter" und lässt nun noch die Frage offen, warum wir nochmal + 1 rechnen?

    Das ist wieder relativ simpel, denn es gibt immer einen Mittelpunkt, welcher eben einen "emitter" besitzt.

    Diesen müssen wir einfach immer hinzurechnen, auch wenn dieser glaube den Kohl nicht Fett macht 🤣.

    Seid der 1.28 ist das Maximum an "emitter" auf 1000 pro Zone limitiert,

    um die Serverperformance aufrechtzuerhalten.



    Um eventuell die Frage zu klären, wie man "ACOS" anwendet, hier mal noch schnell ein visuelles Bsp.,

    des Windows Taschenrechners. In meinem Fall ist es gerade Windows 11,

    sollte aber unter Windows 10 nicht anders sein 😅.


    Als Erstes müssen wir unseren Taschenrechner öffnen und ihn von "Standard" auf "Wissenschaftlich" umstellen.


    4ye1Rab.png


    rMUC8hj.png


    Anschließend stellen wir ihn, wenn es nicht schon eingestellt ist, von "DEG" auf "RAD".


    nAZt6w1.png


    Jetzt geben wir unseren Wert ein. In diesem Bsp. ist es "0,5", gehen auf "Trigonometrie",

    anschließend auf "2ⁿᵈ" und sehen unser "cos⁻¹", welches wir jetzt nur noch ausführen

    um unser Ergebnis zu erhalten.


    b3a7Iot.png


    9V855Q0.png


    8ffuOhx.png


    rk94ueK.png



    Und schon hätten wir auch den Ausflug zum Taschenrechner überstanden und kommen langsam zum Abschluss 😅.

    Dafür machen wir jetzt nur noch unsere letzten Hausaufgaben und rechnen unsere Letzten beiden Zonen aus.

    Um das Scrollen noch einmal zu ersparen, hier noch einmal unsere Werte.


    Für Zone-B:


    Radius = 100

    InnerRingCount = 1

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 50


    Anzahl Ringe = 2


    Radius Ring 1 = 50

    Radius Ring 2 = 100


    Für Zone-C:


    Radius = 150

    InnerRingCount = 2

    InnerPartDist = 50

    OuterRingToggle = 1

    OuterPartDist = 40


    Anzahl Ringe = 3


    Radius Ring 1 = 50

    Radius Ring 2 = 100

    Radius Ring 3 = 150


    Nun noch schnell zu unseren Rechenaufgaben und wir sollten mit diesem Thema endlich durch sein 😅.



    Zone-B Ring 1 = 2 PI / ACOS(1 - (50² / 2 ∗ 50²))


    2 PI / ACOS(1 - (50² / 2 ∗ 50²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 2500))

    = 2 PI / ACOS(1 - (2500 / 5000))

    = 2 PI / ACOS(1 - 0,5)

    = 2 PI / ACOS(0,5)

    = 2 PI / 1,04719755

    = 6,00000001


    Zone-B Ring 2 = 2 PI / ACOS(1 - (50² / 2 ∗ 100²))


    2 PI / ACOS(1 - (50² / 2 ∗ 100²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 10000))

    = 2 PI / ACOS(1 - (2500 / 20000))

    = 2 PI / ACOS(1 - 0,125)

    = 2 PI / ACOS(0,875)

    = 2 PI / 0,50536051

    = 12,43307536


    Somit ergibt sich also nach unserem oben erwähnten Bsp. die Werte für Ring 1 mit "6" und Ring 2 mit "12".

    Was uns am Ende mit unserem Mittelpunkt auf 19 "emitter" kommen lässt.



    Jetzt noch unser letztes Beispiel und die letzte Zone für heute.


    Zone-C Ring 1 = 2 PI / ACOS(1 - (50² / 2 ∗ 50²))


    2 PI / ACOS(1 - (50² / 2 ∗ 50²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 2500))

    = 2 PI / ACOS(1 - (2500 / 5000))

    = 2 PI / ACOS(1 - 0,5)

    = 2 PI / ACOS(0,5)

    = 2 PI / 1,04719755

    = 6,00000001


    Zone-C Ring 2 = 2 PI / ACOS(1 - (50² / 2 ∗ 100²))


    2 PI / ACOS(1 - (50² / 2 ∗ 100²))

    = 2 PI / ACOS(1 - (2500 / 2 ∗ 10000))

    = 2 PI / ACOS(1 - (2500 / 20000))

    = 2 PI / ACOS(1 - 0,125)

    = 2 PI / ACOS(0,875)

    = 2 PI / 0,50536051

    = 12,43307536


    Zone-C Ring 3 = 2 PI / ACOS(1 - (40² / 2 ∗ 150²))


    2 PI / ACOS(1 - (40² / 2 ∗ 150²))

    = 2 PI / ACOS(1 - (1600 / 2 ∗ 22500))

    = 2 PI / ACOS(1 - (1600 / 45000))

    = 2 PI / ACOS(1 - 0,03555556)

    = 2 PI / ACOS(0,96444444)

    = 2 PI / 0,2674632

    = 23,49177497


    Und auch hier gilt wieder das Zusammenrechnen unserer "emitter" auf jedem Ring und das Einbeziehen unseres Mittelpunktes.

    Folgend haben wir also diesmal nicht 2, sondern 3 Ringe, was also folgendes bedeutet.


    6 + 12 + 23 = 41 + 1 = 42


    Und siehe da, wir haben eine Gesamtanzahl von 42 "emitter" in unserer Zone und endlich auch das Ende erreicht 😅🤣.


    Wichtig wäre eventuell noch zu erwähnen, das nicht aufrundet wird, selbst wenn nach dem Komma eine 9 steht.

    Haben wir also zum Beispiel einen Wert oder ein Ergebnis von "2,9", bleibt es bei der "2".

    Ebenso wichtig ist es auch noch, unsere "VerticalLayers" Einstellung zu berücksichtigen.

    Haben wir hier nur einen Layer, also den Wert "0" haben wir nur unsere 42 "emitter".

    Geben wir allerdings einen Wert mit "1" an, haben wir natürlich die doppelte Anzahl,

    da unsere Zone 2 Schichten übereinander hat und somit auf 84 kommt.

    Das ganze geht natürlich immer so weiter und wir hätten bei einem "VerticalLayers" Wert von "2"

    eben die 3-fache Anzahl an "emitter"



    So, das sollte es glaube ich gewesen sein, ist ja nun doch ne ganze Menge zusammen gekommen.

    War zwar anfangs etwas anders gedacht, aber ist man einmal dabei,

    verliert man auch schnell mal die Größe eines solchen Textes 😅.


    Wie gesagt hat es etwas länger gedauert, da ich mehrmals neu angefangen habe,

    aber ich hoffe, es sei mir verziehen und genauso hoffe ich das es ausführlich genug ist,

    um das ganze zu verstehen.

    Sollten dennoch Rechenfehler oder Fragen auftreten oder auffallen,

    dann natürlich wie immer gern Bescheid geben 😊.



    Ich für meinen Teil hoffe, es war interessant genug,

    bedanke mich wie immer für die Geduld,

    Durchhaltevermögen und Zeit 👍.


    Und natürlich freue ich mich schon, wenn wir uns beim nächsten Thema wieder sehen 😁.

  • Permanente Rote Zonen

    Huhu 👋,


    Um die Zonen zu entfernen, müsstest du sie tatsächlich entfernen 😅.


    Leg dir am besten eine Sicherungskopie der originalen Datei "cfgeffectarea.json" an.


    Die in deinem Verzeichnis solltest du folgendermaßen anpassen und sollte so auch funktionieren.

    "SafePositions" solltest du nicht löschen, die sind halt noch für die dynamischen Zonen 😅.

    Und nimm ggf. nicht meine eingetragenen "SafePositions", das ist nur ein Bsp, da ich nicht weiß, ob es noch aktuell ist.



    Und gerne nochmal eine Rückmeldung, obs geklappt hat 😉😁.

  • Bauenplus

    Und danke für den Hinweis, dass etwas Neues hinzukam, ich hatte noch nicht die Möglichkeit zu schauen,

    aber werde die Einstellung ""disableColdAreaBuildingCheck": false," mal noch hinzufügen, sobald ich kann 👍😁

  • Server Files: Erklärung und Bedeutung

    Thema:



    cfgeventgroups.xml


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


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

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

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

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

    welche kostbare Beute hervorbringen können.

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

    dieselben Polizeigebäude oder Militärbaracken abzuklappern.


    Aber machen wir nochmal einen kleinen Ausflug in die Vergangenheit

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


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


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

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

    so wie der Name der Event Gruppe.



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

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

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


    Event Gruppe "Train_Abandoned_Kamy":



    Event Gruppe "Train_Abandoned_Svetlo":



    Event Gruppe "Train_Accident_Dobroe":



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

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

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

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

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

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


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

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


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


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

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


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


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

    sollte uns noch ein kleiner Unterschied auffallen.


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


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


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

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

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

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

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

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

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

    welche alle in der gewählten Gruppe nach spawnt.

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

    quasi am gesetzten Spawn Punkt ausgerichtet.

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

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



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

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


    group name="Train_Abandoned_Kamy" = Name der Event Gruppe


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

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


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


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

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


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


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

    ob unser Objekt "Dynamischen Event Loot" enthalten darf.

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

    bei welchem Objekt es sich um solchen Loot handelt

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

    ob dieses spawnen darf.


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

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


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

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

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

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

    beziehen sich hier auf die "mapgroupproto.xml".


    spawnsecondary="false"


    Hierbei hab ich leider nichts Genaues oder Handfestes.

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

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

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

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

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

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

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

    die das spawnen von Infizierten deaktiviert.

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

    bei Event Gruppen ist es aber leider etwas anders.

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

    sondern auf jedes in der Gruppe hinterlegte Objekt.

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

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



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

    die wir schon aus der "cfgeventspawns.xml" kennen

    und halbwegs am Anfang schon ein wenig behandelt haben.


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

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

    "a" = Rotation des Objektes / Events

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


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

    sollte uns noch Folgendes auffallen.


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


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

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

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

    eben von diesem Mittelpunkt aus an ihre Position gebracht werden.



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

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

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

  • Feedback - Chernarus Survival Server

    Huhu 👋


    Ich würde einfach mal meinen Senf dazu geben wollen, auch wenn ich selbst nicht auf den Servern unterwegs bin 😅.

    Aber hier gehts ja glaube auch eher um konstruktive Ideen.


    Die Grundidee finde ich an sich sehr gut und lässt meiner Meinung nach auch viel Frei- und Spielraum für Kompromisse.

    Wie genau das mit den Map links technisch funktioniert und was genau alles wie möglich ist, weiß ich leider nicht.

    Genauso wenig weiß ich nicht, inwieweit es mit den Servern bzw. der Server Anzahl bei GDZ ausschaut.


    Aber diese Idee lässt sich ja eben je nach Möglichkeit ausbauen.


    Möglichkeiten wären z.B. je nach Verlinkung, eben die Karten Deer und Cherno als Maps beizubehalten,

    diese zu verlinken das man zwischen beiden auch reisen kann, aber eben eine dritte Karte für eben dieses Endgame

    oder diesen Anreiz zur Erkundung anzuregen.

    So hätten beide Parteien immer noch ihre Map und dennoch hätte man den Grundgedanken dieser Idee erfüllt.

    Als zusätzliche Möglichkeit wäre hier noch die Frage der Umsetzung und ob man ggf. diese zusätzliche Karte geheim halten könnte.

    Damit gäbe es eben zusätzlich noch eine Art Überraschungsmoment, da man nicht genau weiß, wohin die Reise hingeht.

    Klar würde es am Ende die Runde machen, sobald man sehen würde, wo es hingeht oder eben der erste Spieler seinen Fuß auf diese Karte setzt.

    Wie gesagt steht da die Frage der Möglichkeiten im Raum, ob man Namen oder Infos zu dieser Karte verbergen kann

    und damit meine ich auch die Map Infos hier auf GDZ 😉.


    Wie gesagt, und auch erwähnt wurde, sind es alles nur Ideen und ich finde den Grundgedanken ziemlich Cool 😁👍

  • Server Files: Erklärung und Bedeutung

    Thema:



    territories.xml


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

    Und hier die Themen 🤣.

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


    Dabei handelt es sich im Grunde nur um eine Art Koordinatenverzeichnis

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


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

    und somit sein eigenes Verzeichnis hat.

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

    bevor wir hier richtig loslegen.



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

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

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


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

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

    aber keinen Eintrag in unserer Liste.

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

    und übriggebliebene Datei handelt.

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


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

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


    bear_territories.xml = Bären Spawn Punkte 🐻


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


    cattle_territories.xml = Rinder Spawn Punkte 🐮


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


    fox_territories.xml = Fuchs Spawn Punkte 🦊


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


    hare_territories.xml = Hasen Spawn Punkte 🐰


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


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


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


    pig_territories.xml = Hausschwein Spawn Punkte 🐷


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


    red_deer_territories.xml = Rothirsch Spawn Punkte 🦌


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


    roe_deer_territories.xml = Hirsch Spawn Punkte 🦌


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


    sheep_goat_territories.xml = Ziegen & Schaf Spawn Punkte 🐑🐐


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


    wild_boar_territories.xml = Wildschwein Spawn Punkte 🐗


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


    wolf_territories.xml = Wolf Spawn Punkte 🐺



    zombie_territories.xml = Zombie Spawn Punkte 🧟



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

    sondern eventuell nur etwas anders nennen.

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


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


    Hiermit wird die Farbe der Territorien festgelegt und ist eigentlich eher

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

    Um es ein optisch auch mal ein wenig darzustellen,

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


    wf6Xqn9.jpeg

    Quelle: Reddit (Stand: 2019)


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

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


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

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

    in der "events.xml" festgelegt haben.

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

    sollten wir hier also wieder ein klein wenig berechnen,

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


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

    aber hätten eine maximale Anzahl von 50 festgelegt.

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

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


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

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



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

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


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

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

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

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

    und eben berechnet wird.



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

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

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


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

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



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


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


    Hier können wir unseren Zonen einen Namen geben.

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


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

    welche grundlegend nur einen Spawn Punkt festlegen.

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

    dass ich hier nur einen Auszug eingefügt haben

    und das Original mit deutlich mehr Positionen ausfällt.

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

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

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

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

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


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

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

    Diese haben unter anderem aber zusätzlich verschiedene Bezeichnungen.


    "Graze" = Grasen

    "Rest" = Ausruhen

    "Water" = Trinken

    "HuntingGround" = Jagdgebiet


    Es handelt sich zwar um ein Koordinatenverzeichnis,

    aber diese Bezeichnungen haben einen kleinen Hintergrund.

    Auch wenn die KI anderweitig in ihrem Verhalten festgelegt wird,

    wird damit das Verhalten an den jeweiligen Spawn Punkten bestimmt.

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

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

    eher langsamer unterwegs ist oder sich eben ausruht.


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

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

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

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

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

    auf diese Gebiete aufgeteilt.

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

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



    Als letzte Kategorie haben wir nun noch unsere Infizierten,

    welche wieder eine andere Art von Verhalten haben.

    Natürlich haben wir wieder unsere bekannten Werte,

    aber es läuft eben ein wenig anders.


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

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

    um eben die Server Performance zu gewährleisten.

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

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

    haben wir hier also auch dementsprechend hohe Werte,

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


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

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


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



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

    die in dieser Gruppe enthalten und spawnen können.


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

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

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

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



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

    ich habe nichts Vergessen 😅.


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

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

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

    wenn auch beim nächsten Thema

    wieder eingeschaltet wird 😁😜🤣.

  • Server Files: Erklärung und Bedeutung

    Thema:



    cfgenvironment.xml


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


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

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


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

    und wir anschließend wieder alles einzeln durchgehen.



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

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



    Als Erstes haben wir folgenden Abschnitt.



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

    welcher für unsere Gebiete verantwortlich sind.

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

    welcher ich schon im ersten Beitrag erwähnt habe.

    Wer sich also erinnern kann, wird folgende Zeile wiedererkennen.


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


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

    weshalb unsere Ordnerstruktur also folgende ist.


    "Basisverzeichnis\mpmissions\dayzOffline.chernarusplus\env"


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

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

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

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

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


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

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

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

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

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


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

    oder einem neuen Verzeichnis abzulegen.


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

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



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



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

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

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

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


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

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

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


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

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

    und werden nicht permanent an irgendwelchen stellen nach gespawnt.

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


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

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

    wenn wir uns eben einem Spawn Punkt nähren.


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


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


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


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


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


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


    Welcher eben den Namen unseres Gebietes angibt.


    behavior="DZWolfGroupBeh =====> Tierverhalten


    Womit wir das Verhalten der Tiere festlegen können.


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


    Welche auf die im ersten Abschnitt festgelegte Datei verweist.


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

    womit wir nun auch gleich zum Huhn übergehen.



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

    weshalb ich diese jetzt nicht noch einmal aufliste,

    sondern gleich zu den nachfolgenden Einstellungen komme.

    Dabei haben wir einmal folgendes.


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


    Hier haben wir nun folgende 2 Zeilen


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


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

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


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


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

    und eben ihre Spawn Wahrscheinlichkeit.


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

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

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

    der ebenfalls mit einer Wahrscheinlichkeit festgelegt wurde.


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


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


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


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


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

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


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

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

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


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

    und eben ihre entsprechende Spawn Wahrscheinlichkeit.


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

    und wieder eine entsprechende Wahrscheinlichkeit.

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

    "Animal_GallusGallusDomesticusF_Spotted" und "Animal_GallusGallusDomesticusF_White" als Hühner

    und wir haben die angegebenen Wahrscheinlichkeiten.


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

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

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

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

    welcher auch nur 1 Mal vorhanden sein darf.

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

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

    Darunter "Animal_GallusGallusDomesticusF_Brown" z.B. nur einmal,

    "Animal_GallusGallusDomesticusF_Spotted" bis zu 10 Mal

    und "Animal_GallusGallusDomesticusF_White" bis zu 20 Mal.


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

    welcher meine Theorie ein wenig unterstützt.


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


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


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

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

    Hoffe nur, das kann man auch soweit nachvollziehen 😅.


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

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


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


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

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


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

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

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

    oder noch zu weit entfernt sind.


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

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


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


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

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

    auf diese Zeilen nicht nochmal so genau einzugehen.

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

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


    Einzige Änderung ist hier also folgendes.


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


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


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

    nachdem diese von allen Spielern verlassen wurde.

    Verlassen wir also alle einen bestimmten Bereich,

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

    an dieser Position auftauchen kann.



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

    Zumindest hoffe ich das ich nichts vergessen habe 😅🤞.



    Damit kommen wir zum letzten Teil, den Infizierten.



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

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


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


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

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

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

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


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

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

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

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

    auf den eigentlichen Wert gebracht werden.


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


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

    oder die Versuche für eventuelle Horden.

    Wie gesagt, es sind nur Theorien 😅.



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

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

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



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

    Geduld und Eure Zeit 😁😅.

  • Leidiges Thema Fahrzeug-despawn (gelöst)

    👋 Huhu und ja, das ist wie in einem Spukschloss 😅🤣.


    Aber erstmal zum Thema Trader oder Admin Tool, denn diese lassen Fahrzeuge nicht auf herkömmliche Art und Weise auf die Map bringen, weshalb ihre eigentliche Lebensdauer nicht greift.

    Nun zum Thema Fahrzeuge und ihre Lebensdauer, denn die ist irgendwie so eine Sache für sich selbst, da ihre Lebensdauer nach dem normalen Spawnen festgelegt wird.

    Was den despawn angeht, könnte es an der Bereinigung der Karte liegen, also wann der Server halt etwas verschwinden lässt. Ist natürlich nur ne Theorie 😅.


    Ob Fahrzeuge von einer Flagge geschützt werden weiß ich nicht genau, da hab ich leider noch nie so richtig drauf geachtet 🤔. Aber es könnte daran liegen, wie die Vanilla oder die Mod-Fahrzeuge geschrieben sind. Ist aber auch nur eine Theorie 🤣.


    Wenn jemand noch ein paar Ideen hat, dann natürlich immer her damit 😁.

  • Ständiger wipe bei Server Restart (gelöst)

    Freut auch mich zu hören, dass alles wieder so weit funktioniert 👍.


    Wäre aber auch das Letzte, womit ich gerechnet hätte, dass ein Mod tatsächlich dafür verantwortlich ist.

    Aber DayZ hat eben Features, die sonst kaum ein Spiel bietet 🤣.


    Weiterhin auf jeden Fall viel Spaß und guten Loot.

    Vor allem welcher, der dieses Mal auch liegen bleibt 😅.

  • Ständiger wipe bei Server Restart (gelöst)

    🤔 Fehlerquellen kann es mehrere geben, wie schaut denn deine "economy" genau aus?

    Andere Sache wäre die Frage, wie schaut es mit der "types" aus? Die Eventuell Mal auf Fehler überprüfen, nicht das sich irgendwo etwas eingeschlichen hat was der Grund sein könnte 😅.


    Ggf. noch die Frage welche Datei angepasst wurden. Also die richtige mpmission meine ich 😅.

  • dayz error NULL pointer to instance Class: 'EntityAI' Entity id:2975830 Function: 'EEInit' Stack trace: scripts/3_Game/entities\entityai.c:900

    huhu👋,


    Schon irgendeine Lösung gefunden?

    Ich hätte maximal nach google suche den Vorschlag gefunden, mal den "storage" Ordner in der "mpmissions" zu löschen.


    Der Beitrag auf Steam "Local DayZ server using 100% ram - Solution" ist zwar etwas älter, aber vllt. hilft es ja.


    Ansonsten gibt es noch einen älteren Beitrag auf GDZ "Spielabsturz bei der Militärbasis!" in dem als Lösungsvorschlag das Überprüfen der Dateien oder Mods vorgeschlagen wird.


    Wären mal schnell 2 Vorschläge, die ich schnell gefunden habe 😅

  • Server Files: Erklärung und Bedeutung

    Hallo zusammen und willkommen liebe Gemeinde,

    auch heute haben wir uns hier wieder zusammengefunden,

    um den Server Files zu Huldigen

    und sein täglich Opfer darzubringen 🤣😂😅.



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

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

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

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


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

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

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


    Fangen wir aber auch gleich ohne weitere Umschweife an 😁.


    Als Erstes haben wir hier die cfgenvironment.xml,

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


    Als Nächstes folgt die territories.xml,

    mit Koordinaten für Tier und Zombie Gebiete.


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

    welche einzelne vordefinierte Event Gruppen beinhaltet.


    Gefolgt von einer ähnlichen Datei namens cfgeffectarea.json,

    als Konfigurationsdatei für Statische toxische Zonen.


    Die Datei cfgundergroundtriggers.json,

    für Konfigurationen von Lichtverhältnissen.


    Anschließend haben wir die mapgroupdirt.xml,

    mit Positionen für Kartengruppen.


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

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


    Anschließend haben wir die mapgrouppos.xml,

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


    Gefolgt von der mapclusterproto.xml,

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


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

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


    Die cfgweather.xml,

    welches als unser Wetterkontrollzentrum darstellt.


    Anschließend noch die cfgplayerspawnpoints.xml

    mit Spawn Punkten für Spieler.


    Und als Letztes noch die messages.xml,

    für Server Nachrichten.



    In der Hoffnung ich habe jetzt nichts vergessen,

    widmen wir uns wieder nach und nach den einzelnen Themen,

    hoffe natürlich auch auf weiteres Interesse

    und bedanke mich auch schon mal im Vorfeld

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