Beiträge von derKobold1987

  • Experimentel 1.29 - "Can't compile "Game" script module!" (AdminTools, CF, DF) Experimentel

    Als kurzes Update, der Editor Loader ist scheinbar auch betroffen.
    Zumindest bekomme ich auch da eine Fehlermeldung.

    Fehler / Crash:

    Can't compile "Game" script module!
    DayZEditorLoader/scripts/3_Game/dayzeditorloader\dayzgame.c(1): Unknown type 'EditorDeletedObjectData'


    Ob es jetzt damit zusammenhängt, dass Dabs Framework nicht mehr funktioniert, weiß ich leider nicht genau 😅.

  • Experimentel 1.29 - "Can't compile "Game" script module!" (AdminTools, CF, DF) Experimentel

    Huhu zusammen 👋,

    Da es jetzt auch mich erwischt hat, dachte ich mir mal ich mache mal nen kleinen Info- und Diskussions-Post.
    Ich bekomme seit dem letzten 1.29 Experimentel Patch eine Fehlermeldung, sobald ich diesen Versuch den Server zu starten.
    Vor einer Woche hat noch alles funktioniert und geändert hab ich seit dem auch nichts am Server.

    Fehler / Crash:

    Can't compile "Game" script module!
    VPPAdminTools/3_Game/vppadmintools\utils\sha256.c(150): Overloaded function 'ToHex' not compatible


    Leider scheint es aber momentan viele neue Probleme zu geben, welche grundlegende und Admin spezifische Mods betreffen.
    So sind also Mods wie VPPAdminTools, LBmaster AdminTools, CF (Community Framework) oder Dabs Framework davon betroffen
    was dazu führt, dass viele ihre Mods ggf. nicht auf ihren experimentellen Servern testen können.

    Das Problem ist schon bekannt und sorgt auch bei anderen Serverbetreibern und Moddern für Frustration.
    Hier mal ein Link zu einem schon bestehenden Ticket: "1.29 Exp broke Mod loadorder",
    welchen ich von Moe bekommen habe.
    Hauptproblem hierbei ist, dass Modder ggf. ihre Mods nicht vorher auf den experimentellen Versionen testen können,
    wenn sie auf diese Mods und Hilfen / Admin Tools angewiesen sind.
    Im schlimmsten Fall zieht sich das Problem wieder mit in die Stabel Version und ich glaube, wir wissen alle, was das "DeerIsle Fiasko von 24" angerichtet hat 🤣.

    Für alle, die also ebenfalls Probleme haben und die, die eventuell Lösungen anbieten können, gerne schreiben, denn zu dieser Teeparty sind alle eingeladen 😅.

  • DayZ DLC: Badlands

    Ich finde das Video bzw. der Trailer hat einen leicht sarkastischen Unterton 🤣.

    Das Rumgebastel und funktioniert trotzdem nicht, hat ein wenig die aussage:
    "So lange wurde daran herumgeschraubt und trotzdem hat es nicht funktioniert"

    Das Einblenden und Zeigen eines anderen Bikes und damit wegfahren wirkt ein wenig wie:
    "Jetzt haben wir ein wenig die Engine überarbeitet, angepasst und geändert, und mit einem Mal gehts ja doch😅"

    Zumal das alte Bike eine Jawa Enduro 380 CZ war und die neue eigentlich dieselbe ist, nur in einer richtigen Cross-Variante
    und das komplett neue eine Jawa 50 / 21

    C3ojjjP.jpeg

    aTZkLJW.jpeg

    cwbmp9p.jpeg

  • DayZ DLC: Badlands

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Ich dachte ich bin Mal so frei, denn wenn's tatsächlich so ist und stimmt dann 😍😍😍

  • Editor-Workshop gewünscht?

    Huhu 👋,

    wenn ich da mal eine Idee in den Raum werfen darf, kann ich je nach Art wie man einen Workshop machen will
    und abgesehen von Discord noch Parsec empfehlen.

    Es ist zwar für jeden ein Account vonnöten, aber wer es nicht kennt, es ist quasi eine Fernsteuerungssoftware.
    Allerdings sind die Latenzen sehr gering und läuft eigentlich auch sehr flüssig bei 60 fps.

    Vorteil ist hier eben, dass man eine komplette Session mit mehreren Teilnehmern gleichzeitig starten kann,
    wobei alle auf einen Desktop oder Spiel zu und eingreifen können.
    Der Host kann ganz einfach die Steuerung aller Teilnehmer einzeln aktivieren oder deaktivieren,
    Tastatur, Maus und sogar Controller Support.

    Idee wäre also, dass alle Teilnehmer für den Anfang nicht jeder auf seinem Rechner den Editor offen hat,
    sondern nur einer, der als Lehrmeister und Host dient.
    Man hätte ein Übungsprojekt, an dem sich alle mehr oder weniger gleichzeitig
    und auch nur über einen Bildschirm beteiligen könnten.
    Der Host kann also Dinge vorgeben und zeigen, ohne, dass jeder im Discord einen separaten Bildschirm teilen muss.
    Wie bei einer Fahrschule kann er die Kontrolle jederzeit entweder wieder übernehmen oder an jemand anderen übergeben.
    Einziges Manko, wäre dasselbe wie im DC, 720p bei der kostenlosen Nutzung.

    Ist wie gesagt nur eine Idee 😅

    Aber da ich es ggf. selber nutze, um auf die schnelle Fernwartungen durchzuführen oder auch mal keine Ahnung,
    mal hier was schreiben, an einem Model was anpassen, in irgend nem Spiel was helfen oder zeigen, kann ich es nur empfehlen.

    Und wer richtig nostalgisch werden will..... damit lassen sich wunderbar Couch-Coop oder PS1 und 2 Spiele online zocken 😉

  • Map wechsel

    👋 Huhu, wenn sich das noch nicht erledigt hat, wäre meine Frage dazu erst einmal folgende.

    Inwieweit ist Map wechsel gemeint? Mir wäre es neu, dass es von Chernarus, eine eigenständige Winter Map gibt.
    Lasse mich aber gerne Berichtigen, Korrigieren und eines besseren Belehren 😅😊.

    Wenn es rein um eine Mod geht, die Chernarus in ein prächtiges Wintermärchen verwandelt,
    ist das keine Eigenständige Map, sondern nur eine Mod, die jederzeit rein und herausgenommen werden kann oder sollte.
    Beispiel wäre halt die Mod Winter Chernarus V2.

    Der Fortschritt und an sich alles würde so bleiben wie es ist und würde nichts an den gespeicherten daten der Charaktere,
    Fahrzuge oder Basen ändern.

  • Server Files: Erklärung und Bedeutung

    Thema:


    mapgroupdirt.xml

    Wieder mal ein herzliches Willkommen zum heutigen Beitrag und Thema.

    Wir widmen uns hier der "mapgroupdirt.xml" und fangen auch gleich mit der Vanilla Datei an 🤣😅.

    Code
    <map>
</map>

    So ja, was soll man dazu sagen, wie wir sehen, sehen wir nichts 🤣.

    Tatsächlich ist diese Datei leer und beinhaltet quasi nichts und Naja,

    ich hab jetzt nen Monat gesucht und versucht das ein oder andere zu finden,

    ein wenig selber versucht, aber was Sinnvolles oder etwas Funktionelles

    ist dabei nicht6 wirklich herumgekommen 😅.

    Bevor ich also noch ewig daran sitze und um auch endlich mal weiter zu kommen,

    bleibt bei diesem Thema erst einmal nur zu sagen, dass diese Datei Kartengruppen enthalten soll,

    die nicht an ein bestimmtes Karten Objekt gebunden sind.

    Wie weit dies nun genau zu verstehen ist, finde ich hoffentlich noch heraus,

    aber bis dahin müssen wir wohl erst mal damit leben 😅.

    Ich werde es natürlich nachtragen oder es findet sich jemand,

    der eine genaue Antwort und ein Beispiel geben kann 😁.

    Bis dahin aber wieder ein Dank für eure Aufmerksamkeit

    und eure Zeit, wir sehen uns dann einfach im nächsten Thema 😉.

  • Server Files: Erklärung und Bedeutung

    Thema:


    mapgroupcluster.xml

    Und natürlich auch hier wieder Willkommen beim heutigen Thema "mapgroupcluster" 😁,

    welche ähnlich wie die "mapgrouppos.xml" Koordinaten aller

    auf der Karte stehenden Cluster Objekten versehen ist.

    Bei den Clusterobjekten zählen jegliche Art von Bäumen oder Objekten,

    die eben nicht über die "mapgroupproto.xml" in Loot Gruppen,

    sondern in der "mapclusterproto.xml" erstellte Objekte.

    Da dies aber auch jede Menge Objekte sind und um Verwirrung aus dem Weg zu gehen,

    Schauen wir uns zu aller erst die letzte Zeile in dieser Datei an.

    Denn hier sieht man einen kleinen Trick, mit dem wir unser bekanntes Problem

    mit der Limitierung von Dateigröße und Zeilenanzahl umgehen können.

    Code
        <include file="mapgroupcluster01" />

    Dies steht am Ende, um auf eine nachträgliche Datei zu verweisen, in der die Liste fortgesetzt wird.

    Daher gibt es also nicht nur eine "mapgroupcluster.xml", sondern eben auch noch "mapgroupcluster01.xml",

    "mapgroupcluster02.xml", "mapgroupcluster03.xml" und "mapgroupcluster04.xml"

    Jede dieser Dateien beinhaltet also wieder dasselbe, weshalb wir uns auch hier wieder nur einer Zeile bedienen

    und uns ein Beispiel rau picken, welches uns bekannt vorkommen sollte.

    Code
        <group name="AppleTree1" pos="134.054962 428.124176 10424.508789" a="-58.978695" />

    Teilen wir diese jetzt wieder in ihre Bestandteile auf, haben wir folgende wichtige Werte.

    name="AppleTree1" = Cluster Name

    Hier haben wir den Cluster Namen, welcher in der "mapclusterproto.xml" hinterlegt ist.

    pos="134.054962 428.124176 10424.508789" = Position mit Koordinaten "x,y,z"

    Wie auch in der "mapgrouppos.xml" haben wir hier wieder die Position des Objektes in der Welt.

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

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

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

    a="-58.978695" = Ausrichtungswinkel

    Und auch hier haben wir wieder wie in der "mapgrouppos.xml" unseren "a" Wert,

    welcher auch hier wieder die Rotation des Objektes angibt.


    Warum haben wir hier keinen "rpy" Wert?

    Nun ja, das ist fast schon simpel, denn z.B. Bäume stehen in der Welt tendenziell immer senkrecht.

    Sie sind in der Regel nie gedreht oder gekippt, was also diese Werte überflüssig macht.

    Damit ist "a" hier also unser einziger und absoluter Rotationswert,

    der die Ausrichtung bestimmt.


    Das sollte es aber hier auch schon wieder gewesen sein.

    Platzieren wir mit einem Tool natürlich einen Baum, müssen wir mit den Formeln,

    die wir in der "mapgrouppos.xml" kennengelernt haben

    unseren "a" Wert ausrechnen, aber grundlegend gibt es hier nichts weiter.

    Daher würde ich mich an dieser Stelle verabschieden,

    euch für eure Zeit und eure Geduld danken und hoffe natürlich,

    dass wir uns auch im nächsten Thema wiedersehen 😁.

  • Server Files: Erklärung und Bedeutung

    Thema:


    mapgrouppos.xml

    Ein Herzliches Willkommen beim heutigen Thema und wie erwähnt,

    setzen wir hier die nächste wichtige Datei der "mapgroupproto.xml" fort.

    Hier wird sich mit der Position der einzelnen Objekte wie Häuser oder Fahrzeugwracks auseinandergesetzt.

    Da diese im Grunde eigentlich auch alle gleich sind, nehmen wir auch nur ein Beispiel

    und befassen uns mit den einzelnen Werten.

    Wir nehmen hierfür wieder ein Beispiel eines Gebäudes, welches uns bekannt vorkommen sollte 😁,

    nämlich dem "Land_Shed_M1".

    Ay5cKFh.png

    Quelle: dayz.fandom.com

    Code
       <group name="Land_Shed_M1" pos="201.383286 546.391113 11868.064453" rpy="-0.000000 0.000000 -69.709740" a="159.709732" />

    Teilen wir es wieder in seine Bestandteile, aufhaben wir viele Sachen, die uns schon sehr bekannt vorkommen sollten,

    aber auch einen kleinen Teil, der etwas komplizierter ist und auf den wir etwas näher eingehen werden.

    group name="Land_Shed_M1" = Gruppenname mit Namen des Objektes

    Name des Objektes bzw. der Gruppe, die wir in der "mapgroupproto.xml" angegeben haben.

    Es wird hier also angegeben, welche Spawn Gruppe an dieser Position steht und nicht das Objekt selbst.

    Es hat also auch keinerlei Auswirkung darauf, ob das Objekt an dieser Stelle steht

    und lässt sich damit auch nicht von der Karte löschen.

    Würden wir diesen Eintrag entfernen, würden wir damit lediglich erreichen,

    das an dieser Postion kein Loot mehr erscheint.

    pos="201.383286 546.391113 11868.064453" = Position mit Koordinaten "x,y,z"

    Hier haben wir wieder unsere bekannten Koordinaten, welche die Position der Spawn Gruppe auf der Karte angeben.

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

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

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

    rpy="-0.000000 0.000000 -69.709740" = Objekt Positionsanpassung mit "Roll,Pitch,Yaw" in °.

    Auch hier haben wir wieder bekannte Werte, bei denen es sich um die Ausrichtung der Gruppe handelt.

    r = "Roll" = Neigung nach links oder rechts in °

    p = "Pitch" = Kippen nach vorn oder hinten in °

    y = "Yaw" = Drehung um die eigene Achse in °

    a="159.709732" = Ausrichtungswinkel

    Hier wird es nun etwas kompliziert, denn wir haben Folgendes Problem.

    Unsere Werte "rpy" geben im Grunde die Ausrichtung einer Gruppe an, wobei mit "y" Bzw. "Yaw" die Drehung

    um seine eigene Achse angegeben wird. Es wird also an dieser Stelle eigentlich schon gesagt,

    in welche Richtung unsere Tür schaut.

    Allerdings kann es sein, dass je nach Objekt, Tool, Programm etc. dieser Winkel nicht stimmt.

    Dies kann daran liegen, dass ein Modell Beispielsweise ein anderes Vorne hat als unsere Spielwelt.

    Es ist wieder mehr so ein Programm und Visualisierungsproblem.

    Um das Ganze Visuell mal an einem Beispiel zu zeigen, schauen wir uns mal ein Beispiel

    mit einem Monopoly Spielbrett an.

    Dabei haben wir für uns Spieler das Spielbrett so vor uns liegen, dass wir das "Los" Feld immer lesen könnten.

    Es wäre also immer links von uns und der Pfeil würde ebenfalls von rechts nach Links zeigen.

    JJSfIA3.png


    Stellen wir uns nun aber vor, der Pfeil würde aus irgendwelchen Gründen und in Wirklichkeit

    immer nach Oben / Norden zeigen.

    Y5bdfAR.png


    Wir hätten also das Problem, dass wir als Spieler zwar unser "Los" lesen könnten und von links nach rechts laufen,

    unser Server, Spiel oder Programm sieht es mehr oder weniger anders, denn da zeigt der Pfeil ja nicht nach links

    sondern in Richtung Norden.

    Um dieses Problem zu richten, müsste man sich also etwas überlegen, womit beider Parteien,

    also wir als Spieler, als auch der Server klarkommen, da wir die Objekte anders sehen,

    als beispielsweise der Server.

    Und hier kommt der "a" Wert ins Spiel, da dieser den "y" Wert für das Spiel in den "a" Wert umwandelt.

    Dieser ist quasi um 90° gedreht und hat mehr oder weniger sogar seine eigenen Formeln, um diesen zu berechnen.

    Bzw. hat er eigentlich sogar 2 Formeln 😅.

    Zu aller erst verweise ich aber mal auf ein Video von "Scalespeeder" in dem das ganze auch nochmal ein wenig erklärt wird.

    DayZ YPR To A Converter For Mapgrouppos.xml : Spawning Loot In Custom Buildings Xbox PlayStation PC


    Auch von "Josie Garfunkle" gibt es hierzu ein Video mit einem Tool.

    DayZ XML Injector Bot | MapGroupPos Pull Tool


    Sollte aber erst mal reichen, denn es gibt mehrere Wege und mit Sicherheit auch unzählige Seiten und Möglichkeiten.

    Als Formeln selbst können wir aber folgendes nutzen.

    a = (360 - y) - 270, wenn der "y" Wert in einem positiven Bereich oder bis max -90° liegt.

    Also grob gesagt alles zwischen -90° bis 360°

    a = (-180 - y) - 90, wenn der "y" Wert in einem negativen Bereich über -90° liegt.


    Nehmen wir nun unser Beispiel "Land_Shed_M1" hätten wir einen "y" Wert von "-69,709740".

    Da der Wert die -90° nicht übersteigt, gilt hier also die Formel "a = (360 - y) - 270"

    Was also folgendermaßen aussieht.

    a = (360 - -69,709740) - 270

    a = 429,70974 - 270

    a = 159,70974

    Schauen wir uns nun den Wert aus unserem Beispiel und unserer Rechnung an,

    haben wir im Beispiel den Wert "159,709732" und in unserer Rechnung ein Ergebnis von "159,70974".

    Wir sehen also, wir kommen auf fast das exakt gleiche Ergebnis 👍, wobei der Originalwert

    aus mehreren Gründen von unserer Rechnung abweichen kann.

    So können wir aber ein wenig entgegen rechnen, um zu sehen, dass wenn wir in dieser Datei

    ein neues Objekt einfügen oder einfügen lassen,

    Wir auch den Richtigen "a" Wert haben.

    Zusätzlich und wie auch im Video von "Scalespeeder" lege ich hier mal einen Link zu einer Datei

    oder besser gesagt 2 Dateien, von Tabellen, in denen wir dafür eine automatische Berechnung haben.

    Diese wurde von "Scalespeeder" erstellt, um uns ein wenig das Rechnen leichter zu machen

    und um uns ein wenig die Zeit zu ersparen.

    DayZ y nach a Kalkulator für Mapgrouppos.xml


    Nehmen wir uns Spaßens halber jetzt mal noch 2 Beispiele.

    Ein Beispiel bei dem der Wert über -90° liegt und eines, wenn der "y" Wert "0" beträgt.

    Code
        <group name="Land_House_1W12" pos="266.296173 189.660706 6589.994141" rpy="-0.000000 0.000000 -161.286377" a="-108.713608" />

    Unser y Wert lautet hier "-161,286377" womit wir also die Formel "a = (-180 - y) - 90" anwenden müssen.

    a = (-180 - -161,286377) - 90

    a = -18,713623 - 90

    a = -108,713623

    Vergleichen wir hier wieder unsere Werte haben wir aus unserer Rechnung ein Ergebnis von "-108,713623"

    und im Original einen Wert von "-108,713608", was also auch hier wieder der Korrekte "a" Wert ist 👍.


    Als Nächstes haben wir noch unseren Wert "0" als Berechnung mit der Formel "a = (360 - y) - 270".

    Code
        <group name="Land_Container_1Aoh" pos="1153.822021 152.249237 6217.505371" rpy="-0.000000 0.000000 0.000000" a="90.000000" />

    a = (360 - 0) - 270

    a = 360 - 270

    a = 90

    Auch hier können wir unser Ergebnis und den Originalwert gegenüberstellen

    und sollten auch hier wieder sehen, dass in beiden Fällen

    das Ergebnis "90" beträgt 👍.


    Soweit so gut sollte es das für diesen Teil aber gewesen sein,

    denn mehr ist es hier auch nicht.

    Aufgrund von hier und da eventuell fehlenden Beispielen, werde ich, wenn es mir die Zeit erlaubt,

    am Ende des gesamten Beitrages noch Beispiele versuchen einzubauen und anzuwenden.

    In welcher Form und wie ich das ganze mache, muss ich natürlich selber noch schauen,

    aber das sollte machbar sein und das ganze mit einer Art praktischem Teil abrunden 😁.


    Damit würde ich mich aber auch in diesem Thema verabschieden, freue mich das ihr wieder dabei wart,

    Lust und Zeit mitgebracht habt und wir sehen uns im nächsten Thema 😊.

  • Server Files: Erklärung und Bedeutung

    Thema:


    mapclusterproto.xml

    👋 Hallo und natürlich auch hier wieder ein herzliches Willkommen beim heutigen Thema.

    Hier befassen wir uns mit dem Cluster, wie es auch schon der Name des Beitrags vermuten lässt 😉.

    Wie auch schon im Thema "mapgroupproto.xml" angesprochen, arbeitet dieser Teil mit der "mapgroupproto.xml" zusammen.

    Daher nehmen wir nochmal einen kleinen Auszug und schauen uns diesen Teil,

    der hierfür wichtig ist noch einmal an.

    Wir haben wieder "group" und "container" mit ihren Jeweiligem "lootmax" Wert

    und wie auch schon bei der mapgroupproto.xml erwähnt,

    gehen wir hier näher auf diesen Abschnitt ein,

    auch wenn es in erster Linie ein anderes Thema ist 😅.

    Daher schauen wir und nochmal grob diesen Abschnitt an und picken uns die wichtigsten Werte nochmal kurz raus.

    name="group" lootmax="6" = Gruppenname mit maximaler Gruppenbeute

    name="container" lootmax="4" = Containername mit maximaler Beutemenge

    name="clusterMatrix" = Bezeichnung für die Loot Verteilung

    de="TrajectoryApple" = Bezeichnung und Verweis für den Spawn bzw. die Flugbahn

    width="12" = Breite mit einem Wert in "m"

    height="12" = Höhe mit einem Wert in "m"


    Nun müssen wir ein wenig verstehen, wofür das Ganze ist und wie das Ganze hierfür funktioniert.

    Dafür müssen wir uns für unser Beispiel "TrajectoryApple", am besten vorstellen,

    wir wären auf einer Apfelplantage und schauen von oben darauf hinab.

    3F4XI7j.png


    Jeder Apfelbaum stellt quasi einen "container" dar, was also bedeutet,

    dass jeder Baum potenziell bis zu 4 Äpfel hervorbringen könnte,

    wenn wir uns hier erst einmal rein nach unseren angegebenen Grundwerten richten.

    Nun haben wir aber das erwähnte "Cluster" System (clusterMatrix), mit "width" und "height",

    was uns nun unsere Plantage in Kachel aufteilen lässt, welche eben alle eine Größe von "12" Metern haben.

    Behaupten wir jetzt einfach mal, dass ein Baum, wenn wir uns diesen mal kurz als einen Würfel vorstellen,

    4 Meter breit und Hoch ist, hätten wir also in einem unserer Kachel Platz für 9 Bäume.

    Optisch können wir uns dies folgendermaßen vorstellen.

    gauk9ji.png


    Nun haben wir 9 Bäume, welche in einem Cluster stehen und dementsprechend 9 Spawn Container.

    Jeder dieser Container / Bäumen könnte jetzt wie schon gesagt 4 Äpfel hervorbringen.

    Leider wäre das bisher ja leider utopisch, da wir ja potenziell 4 x 9

    und somit 36 Äpfel auf einer Fläche von 144,00 m² bzw. 12 m x 12 m hätten 😅.

    Aus diesem Grund kommt nun nochmal unsere Zeile "name="group" lootmax="6"" ins Spiel,

    welche das maximum auf ein solches Raster Bzw. auf ein Feld dieses Rasters

    auf 6 Äpfel begrenzt.


    So, Nun haben wir ein gewisses Grundwissen, mit dem wir uns jetzt dem eigentlichen Teil widmen können.

    Da sich auch hier das Ganze wieder in zwei Teilen abspielt, kümmern wir uns erst einmal um folgenden Abschnitt.

    Hierbei handelt es sich im Grunde um eine Art Sammlung, in welcher der Name des Clusters

    und dem dazugehörigen Model hinterlegt ist.

    Da wir uns bisher auf Äpfel eingespielt haben, bleiben wir auch bei diesen 😅.

    Code
                <export name="AppleTree1" shape="dz\plants\tree\t_malusDomestica_1s.p3d" />
            <export name="AppleTree2" shape="dz\plants\tree\t_malusDomestica_2s.p3d" />
            <export name="AppleTree3" shape="dz\plants\tree\t_malusDomestica_3s.p3d" />

    Das Ganze jetzt nochmal kurz aufgeteilt, haben wir Folgendes.

    <export name="AppleTree1" = Cluster Name

    shape="dz\plants\tree\t_malusDomestica_1s.p3d" = "shape" = Form, mit Dateipfad zum 3d Model

    Hier haben wir zuallererst unseren Cluster, welcher mit einem Namen versehen wurde

    und das dazugehörige Model mit dem Dateipfad.

    Dies ist in erster Linie wichtig, um dem Server zu sagen, welches Objekt zum Cluster gehört.

    Ähnlich der "mapgroupproto.xml", in welcher wir der Gruppe ein Objekt zuordnen.


    Wir haben nun also "AppleTree1", "AppleTree2" und "AppleTree3" mit dem jeweils zugeordneten Modell des Baumes,

    Und können damit auch zum nächsten Teil übergehen.

    Hier haben wir unsere Cluster mit folgenden Zeilen.

    cluster name="AppleTree1" lootmax="2" maxinstances="150" = Cluster Name mit maximaler Loot und Instanzen Anzahl

    Aufgeteilt haben wir in dieser Zeile folgende Werte und Bezeichnungen.

    cluster name="AppleTree1" = Cluster Name

    Hier haben wir wieder unsere oben erwähnte Cluster Bezeichnung,

    welche sich auf das oben erwähnte Objekt beziehen.

    lootmax="2" = maximale Loot Anzahl

    Hier wird die maximale Loot Anzahl festgelegt, welche sich auf dieses Objekt und diesen "Baum" bezieht.

    Damit sind es hier also nur noch 2 Äpfel auf einen Container.

    Wichtig ist hier, dass dies nur für das Objekt gilt, aber nicht für den Cluster.

    Dazu komme ich weiter unten noch einmal etwas genauer.

    maxinstances="150" = maximale Instanzen

    Dabei handelt es sich um eine Limitierung an maximalen Objekten für diesen Clusterund somit um die damit definierten Bäume.

    Da wir "AppleTree1", "AppleTree2" und "AppleTree3" jeweils mit einem Wert von "maxinstances="150"" haben,

    dürfte es also maximal 450 Äpfel gleichzeitig auf unserer Karte geben.


    de name="TrajectoryApple" = Bezeichnung der "Flugbahn"

    Hier haben wir wieder unsere Flugbahn Bezeichnung, welche wir auch aus der "mapgroupproto.xml" kennen dürften.


    container name="branch" lootmax="1" = Container Name mit Maximaler Loot Anzahl

    Ähnlich oder eigentlich auch genauso wie in der "mapgroupproto.xml", haben wir hier den Nahmen des Containers.

    In diesem Fall heißt er eben "branch" und bedeutet "Zweig" oder "Ast" und dient auch hier mehr der Orientierung.

    "lootmax="1"" bezieht sich hier auf die maximale Anzahl an Objekten pro Loot Spawn Punkt.

    Der Standardwert wird also auch hier wieder neu definiert und von "4" auf "1" gesetzt.


    point pos="-1.86 -2.40 0.12" range="0.55" height="1.63" flags="32" = Koordinaten des Spawn Punktes innerhalb des "containers" und "0" Punkt des Objektes

    point pos="0.51 -2.40 0.85" range="0.55" height="1.63" flags="32" = Koordinaten des Spawn Punktes innerhalb des "containers" und "0" Punkt des Objektes

    point pos="0.15 -2.40 -0.57" range="0.55" height="1.63" flags="32" = Koordinaten des Spawn Punktes innerhalb des "containers" und "0" Punkt des Objektes

    point pos="-1.09 -2.40 1.47" range="0.55" height="1.63" flags="32" = Koordinaten des Spawn Punktes innerhalb des "containers" und "0" Punkt des Objektes

    Hier haben wir wieder unsere Koordinaten, welche an sich exakt dasselbe Abbild aus der "mapgroupproto.xml" sind.

    Daher gehe ich hier nur nochmal grob darauf ein.

    point pos="0.0 0.0 0.0" = "x,y,z" Koordinaten des Spawn Punktes innerhalb des "containers" und "0" Punkt des Objektes

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

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

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

    der "0" Punkt des Objektes, ist dabei der Mittelpunkt des Objektes bzw. des Gebäudes oder in diesem Fall des Baumes.

    range="0.0" = max Reichweite / Radius des Spawn Punktes

    height="0.0" = max Höhe des Spawn Punktes

    flags="32" = Objektorientierung

    Auch hier wird damit wie eine Art Zylinder angegeben, in welchem unsere Äpfel spawnen dürfen

    und zusätzlich eine Orientierung festgelegt.


    Sooooo, ich hoffe das man es so weit durchschaut hat und das es einigermaßen verständlich genug war.

    Um aber jetzt noch unsere oben erwähnte Apfelutopie aufzuklären und wie das ganze nun am Ende funktioniert,

    verkrümeln wir uns noch einmal auf unsere Apfelplantage.

    Wie schon erwähnt, klären wir hier nun, wie diese ganzen Cluster, Baum und Container Sache nun zusammenhängt.

    Dafür müssen wir uns nur noch einmal an die "mapgroupproto.xml" Standardeinstellungen erinnern,

    denn da sind 3 Sachen wichtig.

    Als Erstes die Zeile "default name="group" lootmax="6"",

    denn diese Zeile legt den Maximalwert für einen Cluster fest.

    Anschließend die Zeile "default name="container" lootmax="4"",

    deren Standartwert wir noch einmal ändern.

    Und als letztes "default name="clusterMatrix" de="TrajectoryApple" width="12" height="12"",

    welche Cluster und Clustergröße festlegt.


    Jetzt müssen wir uns in der "mapclusterproto.xml" ebenfalls ein paar Werte anschauen.

    Da haben wir zum einen "cluster name="AppleTree1" lootmax="2" maxinstances="150"",

    welche unseren oben erwähnten Standardwert von "4" auf "2" setzt.

    Und die Zeile "container name="branch" lootmax="1"" welche festlegt,

    wie viele Objekte pro Spawn Punkt auftauchen dürfen.


    Wir haben damit also folgende festgelegte Werte.

    Cluster = max. 6

    Baum = max. 2

    Spawn Punkt = max. 1

    Damit haben wir nach unserem oben angefangenem Beispiel zwar 9 Bäume in einem Cluster,

    aber es dürfen nur maximal 6 Äpfel auftauchen und davon auch nur 2 gleichzeitig an einem Baum.

    Das können also 6 Bäume mit jeweils einem oder 3 Bäume mit jeweils 2 Äpfeln sein,

    1 Baum mit 2 und 4 Bäume mit einem Apfel, das ist am Ende zufällig,

    denn es können auch einfach mal überhaupt keine oder nur ein Apfel auftauchen.

    Völlig wild die ganze Sache 🤣.

    In unserem Beispiel haben wir 9 Cluster, was also heißt, auf alle 12 m haben wir die Möglichkeit

    6 Äpfel zu finden, was bei maximalem Loot Erfolg bedeuten würde,

    bei 9 Clustern mit a 6 Äpfeln, hätten wir am Ende 54 Äpfel 😱.

    Wilder wird es allerdings in einer Kombination mehrerer Bäume, da wir dabei unterscheiden müssen,

    dass unser Cluster für jeden "Trajectory" zählt.

    Es würde also 6 Äpfel und beispielsweise 6 Birnen auf ein 12 x 12 Cluster möglich sein,

    da in solch einem Moment der Maximalwert von 6 für jede Art von Bäumen für sich selber zählt.

    So hätte man beim gleichen Beispiel mit 9 Clustern, aber unterschiedlichen Bäumen,

    also 4 Apfel und 5 Birnen Bäumen, bei maximalem Loot Erfolg nicht nur 54 Äpfel,

    sondern auch noch 54 Birnen 🤯.

    Das Ganze ist jetzt natürlich nur mal eine übertriebene Darstellung 😅, aber so in etwa,

    kann man sich das grobe Prinzip vorstellen und ich hoffe, so kann man es ein wenig nachvollziehen

    und versteht es hoffentlich auch


    Wir hören aber an dieser Stelle auf, denn grundlegend war es das für diesen Teil.

    Jetzt ist noch die Frage zu klären, woher unser Server nun weiß,

    Wo denn jetzt genau all diese Objekte in der Welt stehen.

    Darum kümmern wir uns aber im Thema "mapgroupcluster.xml", weshalb ich mich an dieser Stelle wieder für eure Zeit

    und Aufmerksamkeit bedanke und wir uns hoffentlich im nächsten Beitrag wieder sehen 😊.

  • Server Files: Erklärung und Bedeutung

    Thema:


    mapgroupproto.xml

    Auch wenn wir uns wiederholen,

    ein herzliches Willkommen zum heutigen Punkt der Tagesordnung 😁.

    Hier haben wir es mit Gruppen für Spawn Punkte innerhalb eines Kartenobjektes zu tun.

    Kartenobjekte beziehen sich hierbei auf alles, was eben so auf der Karte herumsteht.

    Seien es Bäume, Autowracks oder Gebäude.

    Vorab ist es hier ein wenig schwierig das Ganze als ein alleiniges Thema zu behandeln,

    da es auch hier wieder ein großes und sehr komplexes Konstrukt aus verschiedenen Dateien ist.

    Daher verweise ich zu aller erst noch einmal auf die Themen "types.xml", "cfglimitsdefinition.xml"

    und "cfglimitsdefinitionuser.xml".

    "cfglimitsdefinition.xml" und "cfglimitsdefinitionuser.xml" sind hierbei eine Art Grundpfeiler,

    da in diesen Dateien schon grundlegende und hoffentlich noch bekannte "Attribute / Werte"

    wie beispielsweise "tools", "containers", "weapons", "Military", "Police" oder "School" hinterlegt sind,

    welche auch hier wieder zum Einsatz kommen.

    In der "types.xml" haben wir mit den selbigen Werte, die Zuordnung zu eben den in der "mapgroupproto.xml"

    Hinterlegten Kartenobjekten.


    Nun gibt es hier allerdings noch einmal 2 Grundtypen, welche wir auch gleich einmal aufteilen müssen.

    Daher fange ich auch gleich mal an und nehmen uns wieder die Grunddatei vor.

    In diesem Abschnitt verhält es sich ähnlich der "cfgenvironment.xml".

    Es handelt sich dabei um Früchte, Steine oder Pilze, welche in einer anderen Art und Weise

    und in der "mapclusterproto.xml" hinterlegt sind.

    Wichtig ist allerdings folgendes, denn das "<defaults>" ist hierbei nicht unbedingt Grundlos 😅.

    In den nachfolgenden Gruppen, auf welche wir eingehen, kommt es vor, dass gewisse Werte nicht angegeben werden,

    da sie diese eben von dieser Grundeinstellung beziehen.

    In den Grundeinstellungen haben wir nun aber erst mal folgende Zeilen und Werte.

    name="group" lootmax="6" = Gruppenname mit maximaler Gruppenbeute

    Hierbei handelt es sich, wie schon gesagt, um die Voreinstellung für alle nachfolgenden Gruppen.

    Es ist also eigentlich mehr eine Art Oberklasse, für die wir anschließend einfach

    unsere Gruppen erstellen und benennen.

    "lootmax" ist zusätzlich eine Einstellung mit einem Grundwert,

    welcher später für alle nachfolgenden Gruppen gilt,

    solange kein anderer Wert gewollt ist.

    name="container" lootmax="4" = Containername mit maximaler Beutemenge

    Hier haben wir eigentlich dasselbe Prinzip wie bei der "group",

    nur das es sich hierbei nochmal um eine weitere Unterkategorie handelt, wenn man es so möchte.

    Auch "lootmax" übernimmt hier wieder die Rolle des Grund- und Standardwertes,

    solange nichts anderes gewollt ist.

    name="keepInvalidPoints" enabled="yes" = Einstellung für ungültige / nicht zulässige Spawn Punkte

    Kann ich leider nicht wirklich sagen 😅.

    Man kann es zwar mit Englischkenntnissen übersetzen und sich auch gewissermaßen denken, was es bedeutet,

    allerdings kann ich nicht genau sagen, in welcher Form ungültigen Punkte gemeint sind.

    Würde ich nach dem Gehen, was mir Kopf und Bauchgefühl sagen, würde ich behaupten,

    das es sich hierbei um beispielsweise Blockierte Spawn Punkte handelt.

    Damit der Server eben keinen Loot an Punkten spawnen lässt,

    die ggf. durch ein Objekt blockiert werden, um zu verhindern,

    dass Objekte am Ende in einem Auto spawnen,

    wenn dieses unter einem Apfelbaum steht.

    Auf jeden Fall können wir hier das ganze mit "yes" aktivieren

    und mit "no" eben auch deaktivieren.

    Da Sicherheit vorgeht, ist mein Rat auch hier,

    alles lassen, wie es ist 😅.


    Nachfolgend haben wir jetzt folgendes.

    Code
    <default name="clusterMatrix" de="TrajectoryApple" width="12" height="12"/>

    Dies gilt als Cluster, für die oben erwähnten Früchte, Steine oder Pilze,

    welche über ein etwas anderes System laufen,

    wir aber dennoch ein wenig auseinander pflücken müssen.

    name="clusterMatrix" = Nennen wir es erst mal Bezeichnung 😅

    Dies ist eben die Bezeichnung, welche festlegt, wie das ganze mehr oder weniger funktioniert,

    da es hier über ein "Cluster" System geregelt wird.

    Einzeln zu erklären ist es etwas schwierig,

    weshalb ich darauf in der "mapclusterproto.xml" eingehe.

    de="TrajectoryApple" = Spawn Bezeichnung

    Dies ist mehr oder weniger die Spawn Bezeichnung, da es sich um eine Art Bahn handelt.

    Würde man es sich vorstellen, würde es im Entferntesten also bedeuten,

    dass hier die Flugbahn eines Apfels angedeutet wird.

    Gleichzeitig ist es auch hier wieder ein Verweis auf die Cluster,

    auf die wir in der "mapclusterproto.xml" eingehen.

    width="12" = Breite mit einem Wert in "m"

    height="12" = Höhe mit einem Wert in "m"

    Hier müssen wir uns wieder vorstellen, dass wir uns die Karte von oben anschauen,

    und wir einen Wert in Metern für eine Art Kachel festlegen.


    Alles in allem war es das mal grob überflogen, denn den übrigen Teil behandeln wir

    wie schon gesagt in der "mapclusterproto.xml", um dieses Thema in einem Rutsch durchzukauen 🤣.


    Aus diesem Grund machen wir nun mit dem eigentlich wichtigen Teil für diese Datei weiter,

    denn ab jetzt haben wir alle Einstellungen vor uns, die dafür zuständig sind,

    wo, wie viel und welche Objekte in unseren einzelnen Gebäuden spawnen.

    Dafür nehmen wir uns wieder ein paar Beispiele aus den Vanilla Dateien als Vorbild.

    Wir haben nun 5 Beispiele, welche wir uns einzeln anschauen, um einfach Schritt für Schritt

    auf Besonderheiten einzugehen, aber ggf. schon einfache Grundeinstellungen abgeklärt zu haben.

    So ist, es hoffe ich angenehmer und kein Wirrwarr Batzen auf einmal 😅.

    Damit haben wir nun als erstes folgendes Beispiel.

    Schauen wir uns die einzelnen Zeilen wieder an, haben wir folgende Werte, Attribute und Einstellungen,

    wobei Wichtig ist, das "group" immer für eine Gruppe Steht.


    name="Land_Shed_M1" lootmax="2" = Gruppenname mit maximaler Gruppenbeute

    Hier haben wir den uns schon aus den Standartwerten bekannten Gruppennamen,

    welcher hier mit einem Direkten Gruppennahmen versehen ist.

    Dabei bezieht sich "Land_Shed_M1" auf eben Jenes Statische Objekt,

    welches wir auf der Karte finden.

    Damit man auch weiß um welches Objekt es sich handelt,

    haben wir hier auch mal ein Bild.

    Ay5cKFh.png

    Quelle: dayz.fandom.com

    Hinzu kommt nun "lootmax" als zusätzliche Einstellung, damit hier die Grundeinstellung von "lootmax="6""

    auf "lootmax="2"" geändert wird.


    usage name="Industrial" = "usageflags" Zuordnung

    usage name="Farm" = "usageflags" Zuordnung

    Wer sich hier noch ein klein wenig an das Thema cfglimitsdefinition.xml und types.xml erinnern kann,

    weiß eventuell noch, was die "usageflags" bewirkt haben. Hier wird nun damit festgelegt wird,

    welchen Objekten es Erlaubt ist an diesen Positionen zu erscheinen.


    container name="lootFloor" lootmax="2" = Containername mit maximaler Beutemenge

    Nun haben wir zusätzlich zu unsere Gruppe noch den "Spawn Container",

    der hier einen Namen erhält.

    Wie auch schon in der Gruppe, haben wir auch hierfür zusätzlich "lootmax",

    um die Grundeinstellung ggf. noch einmal für diesen Container anzupassen,

    damit dieser eben nicht die Grundwerte übernimmt.


    category name="tools" = "category" Zuordnung

    category name="containers" = "category" Zuordnung

    tag name="ground" = "tag" Zuordnung

    tag name="floor" = "tag" Zuordnung

    Auch hier gilt das Prinzip der cfglimitsdefinition.xml und types.xml.

    Wie also auch bei den "usageflags" geklärt haben, legen wir hier die Erlaubnis fest,

    welche Objekte in diesem "container" Spawnen dürfen.


    point pos="0.504883 -1.174019 0.807373" range="0.587867" height="1.469666" flags="32" = Spawn Koordinate mit zusätzlichen Einstellungen

    point pos="0.852539 -1.174019 -0.850342" range="0.595474" height="1.488685" flags="32" = Spawn Koordinate mit zusätzlichen Einstellungen

    point pos="-0.238281 -1.174019 -0.895996" range="0.497570" height="1.243926" flags="32" = Spawn Koordinate mit zusätzlichen Einstellungen

    point pos="0.0 0.0 0.0" = "x,y,z" Koordinaten des Spawn Punktes innerhalb des "containers" und "0" Punkt des Objektes

    Hier haben wir wieder unsere bekannten Koordinaten , welche wieder die Position des Spawn Punktes angeben,

    an dem ein Objekt spawnen kann, wobei auch hier wieder gilt:

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

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

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

    der "0" Punkt des Objektes, ist dabei der Mittelpunkt des Objektes Bzw. des Gebäudes.

    range="0.0" = max Reichweite / Radius des Spawn Punktes

    Damit kann der Server ausloten, wo oder wie das Objekt spawnen kann.

    Es kann also mehr oder weniger damit die Position Variieren

    oder ein Objekt anhand seiner Größe dem Spawn Punkt angepasst

    und ausgerichtet werden.

    Zusätzlich soll dies auch dafür sorgen, dass nur Objekte mit der entsprechenden Größe

    an dieser Position spawnen.

    height="0.0" = max Höhe des Spawn Punktes

    Hier wird zusätzlich eine Maximalhöhe für den Spawn Punkt festgelegt,

    welcher wie auch die "range" für Ausrichtung / Positionierung sorgen soll

    und auch hier wieder verhindern soll das ein zu hohes Objekt

    an der Falschen Position auftaucht.

    "range" und "height" zusammen ergeben eine Art Zylinder,

    der eben Objekte spawnen lässt und dabei versucht,

    die Größe des Objektes dem Spawn Punkt anzupassen.

    Um sich das Ganze eventuell ein wenig Optisch vorstellen zu können,

    habe ich hier mal ein paar Bilder auf die schnelle rausgesucht.

    Mlxm5N0.jpeg

    Quelle: reddit.com

    yqOrXuV.jpeg

    Quelle: imgur.com

    Ich hoffe mal, man kann sich damit in etwa vorstellen, wie also am Ende ein solcher Punkt aussieht

    und wie es sich mit dem spawnen von Objekte und deren Größenordnung verhält.

    Zusätzlich können wir hier noch einmal unsere "tag" Einstellungen anschauen.

    Z.B. würde der "tag name="floor"" und "tag name="ground"" auf einen Spawn Punkt

    am Boden verweisen, da dieser mehr Platz hat.

    "tag name="shelves"" hingegen, würde wie man denke ich auch gut auf den Bildern sehen kann,

    auf Spawn Punkten angewendet werden, die sich auf kleineren Flächen befinden.

    Wie der jeweilige Name also ja auch schon vermuten lässt 😅.

    flags="32" = Objektorientierung

    Dies ist zusätzlich ein Wert, der genutzt werden kann und in diesem Fall dazu dient,

    Objekte auf dem Boden spawnen zu lassen. Damit ist nicht der Fußboden des Objektes gemeint

    sondern der Karten / Map Boden.

    Warum ist das notwendig?

    Nun ja, das ist eigentlich relativ simpel und hängt mit dem Objekt zusammen.

    Ein normales Haus hat, wie wir wissen, einen Boden oder eine Etage, eben eine Art festes Fundament,

    nach dem sich auch der Spawn Punkt richtet.

    Nehmen wir aber das Beispiel des "Land_Shed_M1", wissen wir, dass dieses kein eigenes Fundament hat.

    Wenn wir es betreten, sehen wir eben auf den Kartenboden.

    Zusätzlich kommt hier die Model Struktur ins Spiel und wie ein Model aufgebaut ist.

    Es gibt für die Spieler "Unsichtbare" Ebenen im Model, welche verhindern können,

    dass Objekte auf dem Boden spawnen, da das Objekt optisch eigentlich keinen hat.

    Auch kann es sein, dass ein Model / Objekt unterschiedlich auf der Karte steht.

    Mal einen kleinen Tick höher oder mal ein wenig niedriger.

    Da ggf. mal kein "Fundament" vorhanden ist oder auch verdeckt werden kann,

    muss und wird hiermit eben versucht Objekte auf dem Kartenboden erscheinen zu lassen.


    Jetzt haben wir schon mal einen ganzen Haufen an Informationen, die eigentlich auch als gute Grundlage dienen.

    Daher nehmen wir uns das nächste Beispiel, um uns zusätzliche oder weitere Parameter anzuschauen

    Was genau ist hier anders?

    Fangen wir auch hier am besten wieder von oben an, womit wir also unseren Gruppennamen "Land_Shed_Closed" haben.

    Also ein anderes Objekt, wobei hier auffallen sollte, dass wir keinen "lootmax" hinter unserer Gruppe haben.

    Als Nächstes sollten wir feststellen, dass es hier nicht mehr nur ein, sondern mehrere "container" vorhanden sind

    und nur einer dieser "container" wieder eine "lootmax" Einstellung besitzt.


    Was bedeutet das also für uns und für den Server?

    In unserem "Land_Shed_M1" Beispiel haben wir einen Wert von "lootmax="2"" auf unsere Gruppe

    und auch auf unseren "container".

    Damit wurde die Grundeinstellung und der Grundwert angepasst.

    Als Vergleich mal die Gegenüberstellung Alt und Neu.

    "name="group" lootmax="6"" wurde zu "name="group" lootmax="2""

    "name="container" lootmax="4"" wurde zu "name="container" lootmax="2""

    Damit wurde also in der Gruppe eine Maximale Loot Anzahl an Objekten von "6" auf "2"

    und auf unseren "Container" von "4" auf "2" geändert.

    Somit haben wir also maximal 2 Objekte.

    Im neuen Beispiel "Land_Shed_Closed" haben wir nun keinen neuen Wert, sondern den Grundwert "6",

    was also eine Maximale Loot Anzahl von 6 Objekten festlegt.

    Nun haben wir allerdings nicht einen, sondern 3 "container", wobei wir einen davon

    mit einem neuen Maximalwert von "3" haben.

    Bei 6 Objekten, dürfen pro "container" 4 Objekte spawnen und im neu festgelegten nur 3 Objekte.

    Mit dieser Verteilung hätten wir also eine Vielzahl von Möglichkeiten, die man natürlich wieder mathematisch versuchen kann aufzuschlüsseln 😅🤣.

    Gruppe = max 6 Objekte

    Container A = max 4 Objekte

    Container B = max 4 Objekte

    Container C = max 3 Objekte

    Verteilungen könnten also folgendermaßen aussehen, wenn denn tatsächlich mal 6 Objekte erscheinen 😅.

    Beispielverteilung A:

    Gruppe = 6 Objekte

    Container A = 1 Objekt

    Container B = 2 Objekte

    Container C = 3 Objekte

    Beispielverteilung B:

    Gruppe = 6 Objekte

    Container A = 1 Objekt

    Container B = 4 Objekte

    Container C = 1 Objekt

    Beispielverteilung C:

    Gruppe = 6 Objekte

    Container A = 3 Objekte

    Container B = 0 Objekte

    Container C = 3 Objekte

    Beispielverteilung D:

    Gruppe = 6 Objekte

    Container A = 4 Objekte

    Container B = 2 Objekte

    Container C = 0 Objekte


    Das ganze könnte man natürlich für jede Variante und unzählig weiter führen,

    aber ich hoffe mal, es reicht in etwa aus, um sich grob eine Vorstellung davon zu machen,

    was gemeint ist.


    Nun wäre noch die Einteilung der erlaubten Objekte zu betrachten und die einzelnen dafür angelegten "container".

    Hierfür haben wir zunächst die "usage", die festlegen, dass hier nur Objekte mit der Kennzeichnung

    "Industrial" und "Village" spawnen dürfen, wobei sich dies auf die gesamte Gruppe bezieht.

    Als Nächstes haben wir die einzelnen Container.

    Angefangen mit "lootFloor", was nicht automatisch bedeutet, dass es sich hier nur um große Objekte handelt.

    Es handelt sich lediglich um eine Bezeichnung und Kennzeichnung für den Überblick.

    Festgelegt wird es erst mit den "tag" Kennzeichnungen "ground" und "floor" wenn Objekte diese Kennzeichnung auch besitzen.

    "category" ist in diesem Falle also auch wieder eine Kennzeichnung, welche auch wieder nur Objekte erlaubt, die diese besitzen.

    Es kann also genauso gut sein, dass eine Flasche oder eine Nähset an einer solchen Stelle Spawnt, wenn sie diese Kennzeichnungen haben.

    Gleiches Prinzip gilt also auch für die restlichen "container", weshalb ich das ganze jetzt nicht noch einmal wiederhole 😅.

    Es handelt sich also um die Kennzeichnung der Objekte in jedem Container und um hierfür mal ein oder zwei Beispiele zu nennen,

    Haben wir hier mal ein paar Objekte, die an diesen Plätzen spawnen dürften.

    Wie man sehen kann, kommt es nicht darauf an, dass ein Objekt die exakten Werte und Kennzeichnungen hat,

    Es kommt auf die Kombination der Kennzeichnungen an.

    Ein Objekt mit "category name="weapons"" und "usage name="Hunting"" wird hier nicht auftauchen,

    da "usage name="Village"" nicht vertreten ist.


    Ich hoffe das es soweit verständlich war und man den Kern der Sache ein wenig nachvollziehen kann.

    Denn nun kommen wir zum nächsten Beispiel.

    Hier haben wir ein größeres Objekt mit jeder Menge Positionen namens "Land_HouseBlock_3F_Corner2"

    Wir haben wieder unsere üblichen Werte wie "category", "tag" und so weiter, welche wir ja nun kennen und wissen wie es gedacht ist.

    Wir kümmern uns hier nur noch einmal um die überschriebenen oder geänderten Grundwerte.

    Dafür nehmen wir nochmal das Beispiel der Verteilung.

    Gruppe = max 10 Objekte

    Container A = max 6 Objekte

    Container B = max 6 Objekte

    Container C = max 3 Objekte

    Wir sehen also einen neuen Wert von "10", womit wir folgende Verteilungen haben könnten, wenn tatsächlich 10 Objekte spawnen.

    Beispielverteilung A:

    Gruppe = 10 Objekte

    Container A = 6 Objekt

    Container B = 1 Objekte

    Container C = 3 Objekte

    Beispielverteilung B:

    Gruppe = 10 Objekte

    Container A = 3 Objekt

    Container B = 4 Objekte

    Container C = 3 Objekte

    Beispielverteilung C:

    Gruppe = 10 Objekte

    Container A = 4 Objekt

    Container B = 4 Objekte

    Container C = 2 Objekte

    Beispielverteilung D:

    Gruppe = 10 Objekte

    Container A = 4 Objekt

    Container B = 5 Objekte

    Container C = 1 Objekte

    Es werden also nie mehr als 10 Objekte in der Gruppe und nie mehr als die maximal Anzahl an Objekten,

    die pro Container zugelassen werden.


    Damit kommen wir aber auch gleich zum nächsten Beispiel.

    Da auch hier sich grundlegende Sachen wiederholen, kommen wir nur zum hier wichtigen Teil "dispatch".

    Es handelt sich hierbei um einen "proxy Spawn", welcher nur ein Objekt hervorbringen kann.

    Damit ist auch nicht nur ein beliebiges, sondern ein exaktes Objekt gemeint, welches dabei auch hinterlegt ist.

    In unserem Beispiel ist es "Land_Wreck_sed02_aban2_yellow_DE" und handelt sich um ein Fahrzeugwrack.

    Genauer gesagt den "Sarka 120" in Gelb, weshalb diese auch nur gelbe Fahrzeugteile hervorbringt.

    <proxy type="Sedan_02_Wheel" pos="-1.486 -0.296 0.805" rpy="0.0 0.0 0.0" />

    <proxy type="Sedan_02_Door_1_1_YellowRust" pos="-0.556 0.125 -0.860" rpy="0.0 190.0 0.0" />

    <proxy type="Sedan_02_Door_2_2_YellowRust" pos="0.156 0.168 1.150" rpy="-2.0 310.0 0.0" />

    <proxy type="Sedan_02_Hood_YellowRust" pos="-1.608 0.395 -0.174" rpy="0.0 180.0 90.0" />

    Grundlegend haben wir erst mal ein Objekt, welches wie wir es kennen, auch in den "types" zu finden ist.

    "Sedan_02_Wheel", "Sedan_02_Door_1_1_YellowRust", "Sedan_02_Door_2_2_YellowRust" und "Sedan_02_Hood_YellowRust".

    Jedes dieser Objekte hat nun einen eigenen Spawn Punkt, welcher wie üblichen mit "x,y,z" Koordinaten bestimmt wird.

    Zusätzlich haben wir aber nun "rpy", was wir eventuell aus dem Thema: "cfggameplay.json Extras: objectSpawnersArr"

    oder dem Thema: "cfgundergroundtriggers.json".

    Dabei handelt es sich nämlich um "Yaw", "Pitch" und "Roll", nur in einer anderen Reihenfolge 😅.

    r = Roll = Kippen nach vorn oder hinten in °

    p = Pitch = Neigung nach links oder rechts in °

    y = Yaw = Drehung um die eigene Achse in °

    Damit wird die genaue Ausrichtung des Objektes am Spawn Punkt festgelegt, damit ein Reifen beispielsweise

    nicht einfach auf dem Boden neben einem Auto liegt, sondern eben "Simuliert" wird,

    dass das Auto einen Reifen hat, den wir vom Auto entfernen.

    Gleiches gilt natürlich für Türen 🤣.


    Als letztes Beispiel und um die "dispatch" Werte zu vervollständigen, haben wir jetzt noch Folgendes.

    Dabei handelt es sich um "StaticObj_Train_Wagon_Flat_Industrial_Planks_DE", mit dem üblichen BlaBla.

    Konzentrieren wir uns auf "dispatch", werden wir hier den neuen Wert "dechance" sehen.

    Auch hier sollte uns das ganze ein wenig bekannt vorkommen, denn es handelt sich hierbei

    um die Wahrscheinlichkeit aus der cfgrandompresets.xml.

    Mit "dispatch dechance="1.0"" legen wir wieder die mögliche Wahrscheinlichkeit fest, dass das Objekt überhaupt erscheint.

    Bei mehreren Proxys würde es also hier wieder auf alle Proxys zutreffen.

    Anschließend haben wir am Ende des Proxys noch einmal einen "dechance" Wert,

    welcher sich wieder auf das Objekt selbst bezieht.

    In diesen Fällen sollte also zu 100 % ein "dispatch" also ein Proxy auftauchen

    und der Proxy "PileOfWoodenPlanks" zu 130 % 🤣.

    Ich weiß nicht, ob es ein Tippfehler ist und entweder 100 oder 30 % sein sollen.

    Da mehr als 100 % aber nicht möglich sind, denke ich mal, zählt es auch einfach nur als 100 %.


    Wer jetzt noch ein wenig aufgepasst hat, wird feststellen, dass wir einen "lootmax" von 15 haben,

    aber nur 11 Spawn Punkte.

    Es gibt auch anderer Gruppen mit weniger Punkten, aber ebenso einem "lootmax" von 15.

    In diesem speziellen Fall, liegt es daran, dass "StaticObj_Train_Wagon_Flat_Industrial_Planks_DE"

    zu einer Event Gruppe gehört, und somit im Thema: "cfgeventgroups.xml".

    In diesem haben wir gelernt, dass der Loot mit den Einstellungen des Events festgelegt wird.

    Nicht unbedingt was, sondern wie viel spawnen darf.

    Somit sind hier nur die Spawn Punkte und die Kennzeichnungen von Bedeutung

    und nicht die Anzahl der erlaubten Objekte.

    Wichtig ist aber, dass wir für alle gängigen statischen Objekte, die nicht zu einem Event gehören,

    nicht mehr erlaubten Loot haben, als Spawn Punkte tatsächlich vorhanden sind.

    Ein Objekt / Haus, mit nur 5 Spawn Punkten sollte also auch nie

    den "lootmax" Wert von 5 im zugehörigen Container überschreiten.


    Bevor wir uns aber für heute verabschieden, schauen wir nochmal

    auf die zugehörigen Dateien und Themen, damit wir einen Zusammenhang haben.

    Hier wissen wir ja nun, wie dafür gesorgt wird, wo Loot in Gebäuden auftaucht.

    Damit der Server weiß, wo allerdings ein Gebäude steht, in dem er Loot platzieren kann,

    müssen wir uns mit dem Schritt und Thema mapgrouppos.xml auseinandersetzen.

    Um ein wenig zu Verstehen und zu wissen wie die Äpfel vom Baum "fallen" 😅,

    schauen wir uns das Thema mapclusterproto.xml genauer an.

    Und um damit der Server natürlich auch da weiß, wo ein Baum steht,

    an dem er einen Apfel "fallen lassen" kann,

    schauen wir uns das Thema mapgroupcluster.xml an.


    Das sollte es aber gewesen sein und war, glaube ich, auch wieder genug für heute.

    Ich bedanke mich natürlich wie immer für eure Aufmerksamkeit und eure Zeit

    und freue mich, euch beim nächsten Thema wiederzusehen 😁😉.

  • Wie viel Suvival steckt noch in GDZ?

    🤣, Naja es sind oder waren ja auch nur kleine Anregungen.

    Jeder Server soll halt auf seine Art einzigartig sein, seinen eigenen Content bieten.

    Wie gesagt, haben wir es nur für einen kleineren Server getestet und ich habe zusätzlich die Möglichkeit entfernt Waffen zu Schultern.

    Hab Munitionspäckchen nur noch an speziellen Orten und Events auftauchen lassen, womit halt hauptsächlich nur noch einzelne Munition zu finden war

    und selbst die wurde minimiert 😁. Da bringt einem also auch die beste Waffe nix, wenn man entweder keinen Platz hat und wenn doch,

    kaum die passende Munition 😅.

    Ich gebe zu, es wurde mehr zu einem Stealth Game 🤣🤣🤣😅 aber Versuch macht ja auch bekanntlich klug 😁.

  • Wie viel Suvival steckt noch in GDZ?

    👋 Hallöle liebes GDZ Team, Community, Spieler, Leser, überlebende und einfach alle DayZ Spieler die hier fleißig mitlesen.

    Ich dachte mir, ich klinke mich mal ein wenig ein, denn der ein oder andere Beitrag

    lädt mich zum Nachdenken, grübeln und Antworten ein.

    In einem sind dich hoffentlich alle einig, denn ja, es ist tatsächlich schwer das richtige Mittelmaß,

    die richtige Balance, die richtigen Mechaniken oder Schwierigkeitsgrad zu finden.

    Was dem einen zu viel Realismus ist, ist dem anderen zu wenig. Was dem einen zu schwer ist oder fällt,

    ist wiederum anderen zu einfach oder schon reine Routine.

    Ich bin zugegebener maßen momentan kein Aktiver Spieler, weder öffentlich noch irgendwelchen Community Servern

    geschweige denn war ich überhaupt mal auf einem GDZ Server unterwegs 😅. "Hust... Ist mir tatsächlich peinlich.... Räusper".

    Ich bin leider auch weniger als ich es möchte im TS, da mit teilweise einfach die Zeit fehlt, der Kopf voll ist,

    ich selber auch Modde (wenn ich mal dazu komme) oder irgendwas dazwischen kommt.

    Selbst für so einen Text brauche ich 4 bis 5 Stunden 😅.

    Is ja auch egal, denn ich selber zähle mich auch zu denjenigen, die es nicht herausfordernd genug haben können.

    Mein Server, wenn ich es jemals schaffe 😅, soll, wenn möglich auch eine richtige Herausforderung sein,

    was mir aber auch immer wieder Fragen in den Kopf schmeißt und Sachen überdenken lässt.

    Da fängt es beim Realismus an und um mir mal ein konkretes Beispiel herauszupicken, wäre da das Benzin.

    Denn ja, Benzin ist nicht ewig haltbar, aber eben auch Kerosin nicht. Zwar länger, aber nicht ewig.

    Die Frage ist tendenziell immer, wann spielt DayZ und wann fand beispielsweise der Ausbruch stat.

    Gleiche Frage stellt sich da natürlich auch bei Lebensmitteln.

    Wenn wir also im Gegenzug mit Bio-Öl oder Bio-Diesel anfangen und in eine solche Richtung denken,

    muss man auch da den Realitätsaspekt bedenken, dass nicht jedes Auto mit Biokraftstoffen betankt werden kann.

    Man müsste also anfangen, ganze Motoren um oder neu bauen. Gehen wir also zu weit in Richtung Realität,

    nimmt es einem auf lange Sicht den Spielspaß, aber führt dennoch immer wieder zum gleichen Problem.

    Was ist zu viel..... etc.

    Daher ist dieses Thema, glaube ich aufgrund von Spaßfaktoren eine Sache, über die man hinwegsehen kann.

    Aber ich selber spiele auch mit dem Gedanken, Tankstellen nur noch begrenzten Vorrat zu geben.

    Mit freunden hatte ich bezüglich Realität auch schon die ein oder andere Auseinandersetzung, da man manche Sachen

    unrealistisch fand. Eine Sache war z.B. Hunger und Durst, genauso wie das Krank werden, da dies zu schnell geht

    oder man es einfach nicht loswurde. Kleidung, die ja so viele Taschen hat, aber nicht genug Platz,

    oder ganz einfach der Klassiker, warum kann ich kein Shirt unter einer Jacke tragen 🤣.

    Naja, da spalten sich also die Meinungen, denn in der Realität kann man ja schließlich in der Nase bohren.

    Trotzdem habe ich nicht die Möglichkeit im Spiel oder brauch sie einfach nicht.

    Kann ich mir denn in der Realität einfach eine Axt auf den Rücken schnallen oder eine Schaufel 🤔?

    Gleiche Person wollte aber immer die Ausdauer entfernt haben....

    Ja natürlich ist es realistisch, dass ich mit 50 kg Gepäck 30 km Sprinten kann 🤣.

    Ich schaue mir viele Streams und Videos, der verschiedensten Server an, und IntenZ, ist ziemlich nice,

    aber glaube eben für die Mehrheit einfach eine völlige Überforderung.

    Bi musste sich halt irgendwann entscheiden, in welche Richtung sich das Spiel entwickelt.

    Man musste, denke ich, das Spiel, um es für Einsteiger einfacher zu machen, hier und da an den Stellschrauben drehen,

    denn ohne wäre es mit großer Wahrscheinlichkeit nicht mehr so populär, wie es heute ist.

    Ich freue mich über jeden Spieler, der es probiert, egal ob Konsole oder PC, und die Spielerzahlen ein klein wenig steigen lässt.

    Nicht nur zeigt man damit, dass DayZ nicht tot ist, wie viele behaupten, sondern zeigt, dass ein klares Interesse da ist.

    Und je mehr Interesse, desto mehr Spieler, die wiederum neue Spieler anlocken, welche allerdings wieder Neulinge sind

    und vor denselben Problemen stehen. Denn dann kommt eben wieder die Frage auf, was ist zu schwer.....😅.

    Wir sehen, es ist und wird immer ein Teufelskreis bleiben, daher ist konstruktive Kritik und darüber sprechen, das wichtigste.

    Und auch da schließe ich mich den Meinungen an, dass die Community, soweit ich es bisher mitbekommen habe, großartig ist, egal in welcher hinsiecht.

    Ich finde daher Abstimmungen und Umfragen als eine sehr gute Alternative.

    Die Umsetzung der Wünsche ist noch einmal ein anderes Thema, aber dadurch lassen sich eventuell Verbesserungen,

    Wünsche oder Anpassungen in der Form vornehmen, wie es eventuell gewollt oder gewünscht wird.

    Ein Server für die Hardliner und einen für erfahrenere Spieler ist, daher denke ich auch schon ein guter Ansatz

    aber auch da wird es schwierig, denn ich denke mal, die Serverkapazitäten sind auch irgendwann erschöpft.

    So muss man eben auch wieder schauen, was ist sinnvoll und was nicht, wo müssen Abstriche gemacht werden.

    Von Season zu Season langsam vorarbeiten, schauen und beim nächsten Mal eben dasselbe Spiel nochmal.

    Was beispielsweise ein Punkt ist, ist die Vanilla Einstellung für Nahrung, denn auf Servern

    auf denen ich gespielt habe, gab es immer ein Problem, es gab zu viel. Das lag allerdings daran,

    dass Vanilla Einstellungen beibehalten und einfach neues Zeug hinzugefügt wurde.

    Somit war abgesehen vom eh schon relativ gut vorkommendem Loot, nur noch mehr vorhanden.

    Selbes galt für Waffen und Munition.

    Ressourcenknappheit sollte ein wichtiger Aspekt in DayZ sein,

    kommt aber eben aufgrund von Zugänglichkeit für neue Spieler gerne zu kurz.

    Daher sind das scheinbar Dinge, bei denen man sich eben auf Communitys verlässt,

    um genau solche Anpassungen vorzunehmen, damit es auch den ein oder anderen Hardliner reizt.

    Ich hatte Nahrung in Form von Dosen etc. zum Testen mal so eingerichtet,

    dass diese eben auf der Karte gezählt wird und somit irgendwann nur noch nach spawnte,

    wenn eben irgendwo eine Dose beispielsweise gegessen wurde.

    Es gab Events und Plätze, an denen eben häufiger oder ausschließlich Fertigfutter auftauchte.

    Das führte dazu, dass man nicht mehr nur irgendwie Häuser abklapperte oder Infizierte abmurkste,

    Sondern wie bei Helis spezielle Punkte aufsuchte, in der Hoffnung, es ist auch was vorhanden 😅.

    Zugegeben waren wir nur 5-6 Spieler, aber wenn man dahingehend die Loot Anzahl anpasst, wirkt das auch schon wunder.

    Selbes galt für Fahrzeugteile, denn auch diese wurden nur noch in oder an Fahrzeugen bzw. den Autowracks gefunden.

    Dies machte also das Suchen nach Fahrzeugteilen zum einen Interessanter, da jedes Wrack eine potenzielle Quelle war

    und hob zum anderen in diesem Punkt die Immersion nochmal ein wenig an.

    Ich persönlich mag es auch, wenn "Tiers" einfach mal entfernt werden, da somit jeder Bambi zur Gefahr wird,

    wenn er mit Glück schon in Anfangsgebieten eine M4 findet, oder was auch immer für eine Anpupstotumfallwaffe 🤣.

    Spezielle Waffen sollten natürlich auch nur an speziellen Orten zu finden sein, also Bunker etc.,

    Aber man spielt tendenziell anders, wenn man weiß das alles zur Gefahr werden kann, egal wo man sich befindet

    ob man Fresh Spawn, Bambi oder der härteste Hardliner persönlich ist.

    Wenn Infizierte dann noch die Chance haben Türen einzutreten, na dann Prost Mahlzeit 🤣😅.

    Unerfahrene Spieler könnten aber mit getrennten Servern auf einem Abgeschwächten oder Vanilla+ ähnlichen Server spielen und lernen,

    während sich die harten Veteranen auf einem, wie schon erwähnten, IntenZ Server durchschlagen.

    Ggf. auch auf der Deer Map 😉.

    Nur die Mischung und die Balance muss eben für alle stimmen, könnte aber eben nicht der einen Partei zu viele

    Survival Aspekte wegnehmen, während es der anderen zu viel sind und man kann den Charme für beide Serverparteien beibehalten.

    Bevor ich aber nur noch mehr schreibe und mich komplett verliere, höre ich erst mal auf, ist so schon viel zu viel 😅.

  • Server Files: Erklärung und Bedeutung

    Thema:


    cfgundergroundtriggers.json

    Wie immer ein Herzliches Willkommen beim heutigen Thema 😁.

    Hier befassen wir uns, wie das Thema ja schon vermuten lässt,

    mit der "cfgundergroundtriggers.json", welche im Grunde dafür verantwortlich ist,

    uns ein wenig an der Nase herumzuführen und uns glauben lässt,

    wir wären in einem Keller, Bergwerk oder eben einem Bunker.

    Eben allem, was sich ggf. unter der Erde befindet

    oder eben sonst keinerlei Licht von außen hereinkommt.

    Warum es uns an der Nase herumführt 🤔?

    Im Prinzip ist es ganz einfach, da im Spiel selber immer eine gewisse Art

    von Lichtquelle vorhanden ist, insofern z.B. die Sonne scheint oder es eben Tag ist.

    Dadurch ist es leider auch in Räumen, in denen keine Sonne hinkommen würde, hell.

    Hiermit lässt sich dieses System allerdings ein wenig umgehen.

    Wir können versuchen das ganze mal auf simple Art und Weise zu erklären,

    um das Prinzip eines Servers zu verstehen.

    Denn es ist nicht so, dass es irgendwo eine direkte Spielwelt gibt,

    auf der wir uns tatsächlich mit unserem Charakter bewegen

    und uns mit unseren Freunden treffen 🤣.

    Tatsächlich müssen wir uns damit abfinden, dass wir eigentlich alleine

    in Chernarus unterwegs sind und andere Spieler eigentlich eine Art Illusion darstellen.

    Jeder kann natürlich seine eigene Meinung haben, und es sich auf seine Art erklären,

    aber um meinen Gedanken ein wenig näherzubringen, stellen wir uns einfach folgende Situation vor.

    Wir wollen mit ein paar Freunden D&D spielen, welche aber leider nicht gleich um die Ecke wohnen.

    Man könnte auch Monopoly nehmen, falls nicht jeder weiß was D&D ist 🤣.

    Nun hat in unserer Situation jeder unserer Freunde ein Monopoly zuhause,

    was uns zu der Idee führt, dass wir uns in einem Discord oder Team Speak zusammenfinden.

    Gesagt, getan, baut jeder unserer Freunde sein Monopoly bei sich zuhause im Keller auf.

    Wir stellen allerdings nicht nur eine Figur, sondern auch die Figuren

    all unserer Freunde auf unser Spielbrett, und selbes machen natürlich unsere Freunde.

    Einen unserer Freunde ernennen wir zum Dungeon Master oder Spielleiter.

    Dieser hat nun leider die Aufgabe, all unsere Bewegungen und Aktionen zu notieren,

    was ihn also leider daran hindert tatsächlich selber zu Spielen 😫.

    Er erledigt also Papierkram und schreibt unsere Würfelzahlen auf,

    wann wir bei wem in welchem Hotel übernachtet haben,

    und wann wir über los oder ins Gefängnis mussten 😅.

    Wir spielen also jeder für sich auf einem eigenen Brett,

    bei uns zuhause, während eben einer unserer Freunde zuhause sitzt, unser Spiel Koordiniert

    und darauf achtet, das wir uns an die Regeln halten.

    Er kann uns mitteilen, welcher Spieler was gewürfelt hat,

    womit wir die Figuren unserer Freunde auch bei uns zuhause bewegen können,

    falls wir sie mal falsch gesetzt haben und irgendjemanden auffordern,

    und 4,5 Millionen zu zahlen, weil er angeblich auf unserer Schlossallee steht 🤣.

    Unser Spielleiter ist im Grunde unser Server.

    Er selber Spielt also selber nicht aktiv

    und hat kein direkt eigenes Spielbrett.

    Es ist Vielmehr in seinem Kopf und er tauscht mit uns

    die von ihm notierten Daten aller anderen Spieler aus,

    damit wir eben die Spielfiguren der anderen Spieler

    auf unserem Brett bewegen können.

    Auch wenn es eventuell ein doofer Vergleich ist, hoffe ich mal,

    man kann es ein wenig nachvollziehen und versteht wie ich das ganze meine.

    Denn nun können wir uns mal noch folgendes vorstellen.

    Unser Spielleiter kann wenn er es möchte auch gern mal die Spielregeln ändern.

    In unserem Fall und um einen Vergleich zur "cfgundergroundtriggers.json" zu ziehen,

    legt er nach jedem überqueren, des "LOS" Feldes fest, das der Spieler,

    der es überquert für 2 Züge das Licht im Keller ausmacht 😁.

    So ist es nur bei dem Spieler Dunkel, welcher "LOS" überquert,

    während es bei allen anderen Hell ist.

    SO, viel Text für wenig Datei 🤣😅.

    Aber wie gesagt, hoffe ich einfach, dass man das Prinzip somit wenigstens ein wenig verstehen kann

    und vor allem, was ich mit der aussage "alleine spielen" meine,

    auch wenn es ein merkwürdiges Beispiel ist 😅.


    Aber kommen wir nun zum eigentlich wichtigen Teil, nämlich unserer "cfgundergroundtriggers.json".

    Hier fangen wir wieder natürlich auch nochmal mit der Grunddatei an.

    Jetzt müssen wir uns das Ganze in 3 teilen vorstellen.

    Es gibt äußere so wie innere "Trigger" und zusätzliche "Krumen",

    die sich zwischen den Bereichen befinden.

    Man könnte sich die "Krumen" als eine Art Dimmschalter vorstellen,

    den wir nach jedem überqueren in der Helligkeit einstellen.


    Fangen wir aber erst mal wieder mit den Einstellungen an.

    "Position": [ 0, 0, 0] = Position des "Trigger" mit Koordinaten

    Hierbei handelt es sich wie bei allen anderen um Koordinaten,

    welche wieder einen Mittelpunkt darstellen.

    Dabei gilt hier wieder die Reihenfolge "[ x, z, y ]".

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

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

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


    "Orientation": [ 0, 0, 0 ] = Positionsanpassung / Orientierung / Ausrichtung

    Wie bei anderen Objekten wird oder können wir unseren "Trigger" oder "Bereich" anpassen.

    Dazu haben wir wieder die Möglichkeit es zu drehen, zu neigen oder zu kippen,

    was in diesem Fall die Reihenfolge "[ y, p, r ]" festlegt

    und wir ggf. auch noch aus der "cfggameplay.json Extras: objectSpawnersArr" kennen.

    y = Yaw = Drehung um die eigene Achse in °

    p = Pitch = Neigung nach links oder rechts in °

    r = Roll = Kippen nach vorn oder hinten in °


    "Size": [ 0, 0, 0 ] = "Trigger" oder "Bereich" Größe in Koordinaten

    Hier müssen wir wissen und beachten, dass es sich bei diesen "Bereichen" um ein Viereck in jeder Form handelt.

    Wir legen hier also eine Art Raum fest, in dem wir uns am Ende als Spieler befinden

    und uns eben die Dunkelheit vortäuscht, als würde man eine dicke Decke über einen Tisch legen

    unter dem wir uns befinden.

    Wie auch bei der "Position" gilt hier "[ x, z, y ]" als Ausrichtung und als Mittelpunkt.

    Das bedeutet also, dass bei einer Größe von z.B. 10 m Länge unser Raum vom Mittelpunkt aus

    5 m in die entsprechende Richtung gerückt wird.

    Ein wenig weiter unten kommen wir zu einer kleinen visuellen Erklärung 😁.


    "EyeAccommodation" = Dunkelheit als Wert in "%"

    Hiermit können wir die Dunkelheit bestimmen, bei der in "%" die Helligkeit bestimmt wird.

    Dabei gilt "1" als "100 %", "0" als eben "0 %" und beispielsweise "0.5" wären "50 %".


    "Breadcrumbs": [] = Krumen / Übergänge (Checkpoints) für Zwischenstufen

    Dabei handelt es sich um eine Art Checkpoints, die wir als Spieler ablaufen

    um am Ende den Tiefsten und dunkelsten Punkt dieses Raumes oder Bereiches zu erreichen.

    Die Krumen oder Checkpoints liegen hier immer in diesem angelegten Raum

    und sind kein eigener Raum. Auch hier kommen wir etwas weiter unten zu einer kurzen Erklärung 😉.


    "InterpolationSpeed" = Übergangsgeschwindigkeit als Wert in "sec"

    Hier können wir in mit einem Wert in Sekunden bestimmen, wie schnell ein Übergang zwischen "Triggern" vollzogen werden soll.

    Es wird also beispielsweise bei einem Wert von "5" ein Übergang von 5 Sekunden stattfinden,

    Was allerdings meist unnötig ist, da die Übergänge schon mit den "Breadcrumbs" festlegen.

    Ich bin mir zwar unsicher, bin aber der Meinung, dass bei einer Nichtangabe dieses Wertes immer der Wert "1" gilt.


    Nun kommen wir noch zu 2 Werten, welche nur in den "Breadcrumbs" verwendet werden.

    "UseRaycast" = "Raycasting" Verwendung

    Hierbei wird mit "1" / "true" oder mit "0" / "false" die Nutzung von "Raycasting" aktiviert.

    Ich bin leider immer noch kein Programmierer, was es mir also etwas schwerer macht,

    das ganze zu erklären 🤣😅.

    Daher würde ich jetzt mal auf die schnelle auf einen "Wikipedia" Eintrag verweisen,

    damit jeder, der daran Interesse hat, eventuell selber nochmal genauer nachlesen kann.

    Wikipedia: Raycasting


    "Radius" = Entfernung in "m" für Anpassung / Beeinflussung durch den Krumen

    Hiermit kann eine Entfernung in Metern angegeben werden, inwieweit der Krumen oder "Checkpoint"

    die angegebene Licht- oder Sichtanpassung beeinflussen kann.

    Dabei gilt der Wert "-1" als eine Einstellung, bei der ein Standardwert genutzt wird.

    Ich hab da leider auch noch keine genaue Erfahrung, was hier wie wo oder wann angepasst wird

    und empfehle daher entweder wie in der Vanilla Einstellung alles auf "-1" zu lassen

    oder ggf. einfach selber ausprobieren.

    Versuch macht eben klug 😉😁.


    Nun aber zum Allgemeinen, denn beim Aufbau eines "Unterirdischen" Bereiches,

    und nein er muss nicht zwingend unter der Erde sein 😅, ist es wichtig eine Art Startpunkt zu haben.

    Dieser sollte in der Regel schon vor dem Eintritt in beispielsweise einen Bunker vorhanden sein.

    In der Vanilla Livonia Variante haben wir dafür den folgenden ersten Trigger.

    Code
            {     
            "Position": [ 749.738708, 533.460144, 1228.527954],
            "Orientation": [ 0, 0, 0 ],
            "Size": [ 15, 5.6, 10.8 ],
            "EyeAccommodation": 1,
            "Breadcrumbs": [],
            "InterpolationSpeed": 1
        },

    Dieser hat die Koordinaten vor der Bunkertür und die entsprechende Größe,

    um zu verhindern, dass wir als Spieler an diesem Punkt vorbeilaufen können.

    Hier auch gleich ein Bildausschnitt mit der Position des "Triggers".

    7fxx2dK.png

    Zusätzlich haben wir die Einstellung "EyeAccommodation" mit dem Wert "1",

    was dafür sorgt, dass wir keinen Unterschied zur eigentlichen Tageszeit haben,

    da quasi die Einstellung für unseren "Lichtschalter" deaktiviert ist.

    Dies ist also unser Startpunkt für alle darauffolgenden "Trigger".


    Als Nächstes kommt nun der erste Raum und somit der "eigentlich" erste Bereich, der betreten wird.

    Code
            {     
            "Position": [ 735.0, 533.7, 1229.1 ],
            "Orientation": [ 0, 0, 0 ],
            "Size": [ 15, 5.6, 10.8 ],
            "EyeAccommodation": 0,
            "Breadcrumbs":
            [

    Abgesehen von Koordinaten und Größe, welche nun so angepasst sind, dass beide Bereiche aneinandergrenzen,

    haben wir hier wieder die Einstellung "EyeAccommodation", welche mit dem Wert "0" versehen ist.

    Dadurch ist dieser Bereich eigentlich in vollkommene Dunkelheit gehüllt, was bedeuten würde,

    wir würden innerhalb einer Sekunde in einem Raum in vollkommener Dunkelheit stehen.

    Hinzu kommt, dass wir ja nun wissen, dass bei uns, auf unserem Bildschirm,

    eigentlich die Sonne verschwindet, was also auch bedeutet,

    dass es auch draußen vollkommen dunkel wäre.

    Nun könnte man ja behaupten:

    "🤔 Es gibt doch die Einstellung "InterpolationSpeed" 🤓,

    womit ich diesen Übergang verzögern kann."

    So einfach ist das in der Praxis aber leider nicht 😅, denn das einzige was wir damit erreichen,

    wäre eine Verzögerung aber keine Beseitigung des Problems.

    Man würde also einen Raum betreten und während wir im Türrahmen stehen bleiben,

    macht einfach jemand langsam das Licht aus und gleichzeitig würde jemand die Sonne verschwinden lassen,

    während es bei unserem Kumpel, der genau hinter uns steht, noch Taghell ist 🤣.


    Daher kommen wir auch gleich zu den oben erwähnten Krumen / Breadcrumbs,

    welcher sich in unserem eigentlichen Bereich befindet.

    Dafür nehmen wir uns einfach auf die schnelle nochmal das komplette Beispiel.

    Auch hierfür und um den erwähnten Raum mit den enthaltenen Krumen darzustellen,

    Gibt es mal eine kleine Matheaufgabe. Aber dieses Mal ist sie relativ simpel 😅.

    Dafür nehmen wir als Erstes unsere Koordinate des Raumes "[ 735.0, 533.7, 1229.1 ]".

    Als Nächstes können wir jetzt das Wissen anwenden, welches wir über den Mittelpunkt

    und die "Size" haben, um eben die Größe des Raumes über Koordinaten bestimmen zu können.

    Dafür können wir die "Size" Werte "[ 15, 5.6, 10.8 ]" nehmen und diese erst einmal halbieren.

    Somit ergeben sich die Werte 7,5, 2,8 und 5,4. Jeweils vom Mittelpunkt aus in die entsprechende Richtung.

    ziu3bFH.png

    Jetzt können wir unsere Koordinaten des Raumes und seinem Mittelpunkt mit unseren Werten berechnen,

    in dem wir zum jeweiligen Wert + und - unserer halben "Size" Werte rechnen.

    Klingt schlimmer als es sich anhört 😅.

    Aber einfach gesagt rechnet man z.B. 735.0 + 7,5 und einmal 735.0 - 7,5 usw.

    Um das Ganze auch schnell hinter uns zu Bringen, machen wir also folgendes.

    Mittelpunkt = Position 735.0, 533.7, 1229.1

    735,0 - 7,5 = 727,5

    735,0 + 7,5 = 742,5

    533,7 - 2,8 = 530,9

    533,7 + 2,8 = 536,5

    1229,1 - 5,4 = 1223,7

    1229,1 + 5,4 = 1234,5

    (Zum Rechnen mit 'nem Taschenrechner am besten immer "." durch "," ersetzen, der kommt sonst damit nicht zurecht

    und ich werde, damit man nicht durcheinander kommt "." mit "," ersetzen. Es sieht halt auch besser aus 😅)

    Aber wozu das ganze nun gut ist, schauen wir uns mit den Positionen jedes Krumen / Breadcrumbs an.

    Es sollte sich jede Position immer zwischen den Werten befinden, die wir ausgerechnet haben.

    Als Beispiel nehmen wir uns einfach die ersten 3 Positionen, den Rest kann jeder für sich nachschauen.

    Damit lässt sich aber noch einmal überprüfen, dass sich unsere Krumen auch wirklich in dem Bereich befinden,

    für den wir die Krumen auch setzen.

    Schließlich können wir auch keinen Lichtschalter außerhalb unserer Wohnung anbringen,

    anschließend die Tür zu machen und versuchen ihn zu betätigen 🤣.

    So in Etwa sollte man sich dies eben auch mit den Krumen für einen Bereich vorstellen.

    Aber wie gesagt, hier nochmal zum Überprüfen.

    Ich setze jetzt nur schnell die Werte der einzelnen Positionen zwischen die berechneten Koordinaten

    und hoffe, man versteht somit einigermaßen was gemeint ist 😅.

    Krumen Nummer 1

    727,5

    741,294556

    742,5

    530,9

    531,522729

    536,5

    1223,7

    1227,548218

    1234,5

    Krumen Nummer 2

    727,5

    741,273071

    742,5

    530,9

    531,522729

    536,5

    1223,7

    1229,310547

    1234,5

    Krumen Nummer 3

    727,5

    739,904

    742,5

    530,9

    531,6

    536,5

    1223,7

    1230,51

    1234,5


    Nun noch zum letzten Teil, nämlich dem Aufbau eines "Untergrund" Areals.

    Dafür könnte man vorrangig erst mal ein paar Regeln und Grundlagen festhalten,

    die ein wenig Beachtung bekommen sollten.

    Darunter Zählen, dass wie schon erwähnt, immer ein Startpunkt außerhalb angelegt werden sollte oder muss.

    Diesen nennt man unter anderem auch "Outer Trigger" oder "Außen Trigger". Anschließend und der Vollständigkeit halber

    erwähnen wir am besten auch gleich, dass ein Areal mit Krumen ein "Transitional" / "Übergang" ist

    und alle nachfolgenden im inneren eben die "Inner Trigger" sind oder eben "Innere Trigger" 😅.

    Als Nächstes und auch da wie schon erwähnt, sollten Übergänge / Krumen innerhalb eines Trigger-Bereiches liegen.

    Wie auch schon erwähnt, sollte man einen Übergang nicht einfach nur über eine Übergangsgeschwindigkeit

    sondern mit den erwähnten Krumen erstellen.

    Als Nächstes sollten wir wissen, das wir keine doppelten Krumen und Übergänge anlegen müssen,

    da sie in beide Richtungen funktionieren.

    Die Krumen selber sollten am besten so Platziert werden, das es Optisch passt

    und wir z.B. nicht auf eine Wand zu laufen, es einfach dunkler wird,

    obwohl von hinten noch die Sonne scheint.

    Am besten also über enge Gassen und Ecken platzieren um schöne Übergänge zu schaffen

    und viel Experimentieren 😉.

    Ein Areal welches sich in einem simulierten Untergrund befindet und einen Ein- und einen Ausgang haben,

    sollten entsprechend mit Krumen versehen werden.

    🤔 mehr ist, es glaube ich auch nicht, abgesehen davon, dass man natürlich seine Konstruktion

    immer nochmal überprüfen und nach Fehlern Ausschau halten sollte.


    Jetzt kommen wir aber zu unserem kleinen Beispiel des Aufbaus.

    Dafür hab ich einen Tunnel mit einer Draufsicht in verschiedenen Abschnitten angelegt.

    Der Tunnel selbst, wie Areale und Übergänge angelegt werden können

    und sich unsere Dunkelheit verhalten kann.

    Es handelt sich nur um ein grobes Beispiel, aber hier wäre erst mal der Aufbau des Tunnels selbst.

    Er hat 2 Fahrtrichtungen, davon jede getrennt, aber durch einen Gang miteinander verbunden

    und an jedem Ein- und Ausgang gibt es einen Notausgang.

    Die Tunnel selber sind nicht von außen zugänglich

    genauso wenig wie 2 der Notausgänge.

    XYQVUf2.png

    Wir haben hier also einen Ein- und einen Ausgang so wie die Gestrichelte Linie,

    welche darstellen soll, wie wir durch diesen Tunnel gelangen können.


    Im nächsten Bild sehen wir, wie die Bereiche beispielsweise angeordnet werden können.

    Dabei sind zum einen die Werte und Angaben für die "EyeAccommodation" und die "Breadcrumbs" Markiert.

    Nicht Perfekt und auch der Außenbereich fehlen, aber ich hoffe da kann man drüber hinwegsehen,

    es soll ja nur eine grobe Darstellung sein 😅.

    NDS1gzS.png

    Die "Breadcrumbs" sind hierbei jeweils in den Gängen Bzw. den Türen, wenn man sich diese ein wenig hinzudenkt.

    Der "Trigger" oder Bereich soll hier ein wenig Kennzeichnen, das sich dieser Zwar über alle drei Räume erstreckt,

    dieser aber quasi in oder durch die einzelnen "Breadcrumbs" getrennt ist.


    Als Nächstes noch einmal das Gleiche, aber nur die "Trigger" ohne Tunnel.

    9CejPDs.png

    Soll nur noch einmal ein wenig die Einteilung darstellen 😅.


    Als Letztes haben wir nun noch unsere Tunnel, welche eben in Dunkelheit und ihre Übergänge eingeteilt sind.

    rXLaN66.png

    Hier geht es mehr oder weniger nur nochmal grob um die Veranschaulichung der Dunkelheit im Inneren

    und wie sich die Übergänge auf die Helligkeit in den Räumen auswirkt,

    trotz dessen, dass wir bei der Einstellung "EyeAccommodation" den Wert "0" gesetzt haben.


    So, aus die Maus, jetzt wird es Duster 🤣.

    Nein, es sollte es eigentlich auch mit diesem Thema gewesen sein.

    Ich hoffe wie immer ich habe nichts vergessen,

    bin für Änderungs- oder Verbesserungsvorschläge immer offen,

    Freue mich, euch beim nächsten Thema wieder an Bord zu haben,

    bedanke mich wieder für Zeit, Interesse, Geduld

    und eure Aufmerksamkeit 😅.

    Bis zum Nächsten Thema 😁👍

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