Server Files: Erklärung und Bedeutung

Hallo liebe Community, Modder, Spieler und einfache Leser 😁,

Ich bin mal so Frech und greife mal ein älteres aber bekanntes Thema auf und ich hoffe ich mach das hier alles nicht umsonst 😅.

Aber die Server Files sind ein Essenzieller Bestandteil eines jeden Servers und auch wenn schon viele viele wunderbare Beiträge dazu

verfasst wurden, dachte ich mir das ich versuche es so gut wie möglich in einem Post oder Beitrag mal zusammen zu bringen.

Da ich das Ganze Vorab schon schreibe, bevor ich es poste,

musste ich mir natürlich auch Gedanken machen, wie ich es am besten umsetze.

Das Thema ist aber am Ende wahrscheinlich sooooooo Umfangreich,

weshalb ich es einfach so versuchen, das ich jeden Nachtrag als ein Thema Nutze,

und versuche dieses damit abzuschließen. So ist am ende Jeder Beitrag ein Thema 😅.

Es soll wenn es klappt gleich alles als eine Art Inhaltsverzeichnis für Nachträgliche Posts dienen.

Ich versuche alles so zu Verlinken und anzupassen, das Ihr einfach die gewünschte und gesuchte Datei anklicken könnt

und zum dazugehörigen Post gelangen zu können oder zur entsprechenden Seiten.

Es wird auch mit Sicherheit nicht alles Chronologisch, sondern werde schauen wie ich es schaffe und es am besten nachvollziehbar ist.

Am Ende hoffe ich natürlich, das es für den ein oder anderen nützlich ist und auch noch das ein oder andere zu neuen Ideen beträgt.

Denn auch wenn es hier und da wie gesagt schon Themen gibt, hat sich im laufe der Zeit auch viel verändert und weiterentwickelt.

Dazu kommt natürlich das hier und da verstreut kleine Tricks und Tipps existieren,

die ich versuche mit eigener Erfahrung zu kombinieren,

es so einfach und Verständlich wie möglich versuche zu erklären und zu beschreiben.

Ich werde weitestgehend alles und jeden zu Verlinken und zu Markieren, einfach auch aus Prinzip und dem Respekt aller,

die schon vor mir angefangen haben anderen Moddern die Hilfe zukommen zu lassen.

Also schon mal vielen vielen dank an folgende User, Modder, Moderatoren, Admins und alle die mir dieses Projekt möglich machen, die ich bis jetzt Vergessen habe oder noch nachträglich eintrage😅

Urs , zm4ster, Herz-Aus-Gold, at3nd0, ErnaVII., Murphy  HalfMoon, DagiWeh, BrandyScotty, cj187, Juicy, HToneill

Es wären einfach zu viele Namen die ich unter jeden der Beiträge schreiben müsste, deshalb hoffe ich das es auch so Ok ist.

Für Verbesserungen, Berichtigungen und Ergänzungen bin ich natürlich offen, genauso wie für Feedback um das Thema für alle

so umfangreich, Verständlich und einfach wie möglich zu gestalten aber es gleichzeitig auch so Aktuell wie möglich zu halten.

Es soll sich an alle richten, egal ob Neuling oder alter Hase, ob Server Admin oder einfach nur Spieler.

Hauptsächlich beziehe ich mich mit allen Dateien auf Vanilla Chernarus und im Momentan beruht alles auf Build 1.26.

Ich werde aber schauen, das ich es immer dem aktuellen Build anpasse, insofern sich etwas Ändern oder hinzukommen sollte.

Aber fangen wir mal mit einer art Einführung an 😅.

- Wofür sind diese Files eigentlich zuständig und was ist eine Server-Economy:

Grundlegend ist erst mal zu Wissen und zu Verstehen, was ist die Server-Economy von DayZ eigentlich.

Sie bezeichnet das Verhalten von allem, was auf dem Server statt findet.

Wie, wo, wann oder wie viel der einzelnen Sachen Spawnt oder sich Bewegt.

Im Prinzip haucht sie dem Spiel überhaupt das leben ein.

Jede Datei hat ihre eigenen Zuständigkeitsbereiche und lässt sich Individuell anpassen und ändern

um den Server den eigenen oder den Wünschen der Community anzupassen.

Dies lässt sich auf verschiedene Wege und mit Verschiedenen Möglichkeiten bearbeiten.

Es gibt Unterschiedliche Programme oder Seiten im Internet, die einem das ganze möglich machen oder vereinfachen können.

Womit wir auch gleich zum nächsten Punkt Übergehen.

- Was benötigt man um mit und an den Dateien zu arbeiten:

Die wichtigsten Tools:

- DayZ Tool mit dem Economy Editor oder auch CE Editor genannt

(bekommt man automatisch mit dem kauf von DayZ)

- Visual Studio oder Notepad++ : zum bearbeiten der einzelnen Dateien

- Natürlich die Files selber (wo diese zu finden sind kommt im nächsten abschnitt)

Zusätzliche Tools und Seiten im Internet:

- xmlvalidation.com : Wie schon in einigen Posts beschrieben, lassen sich hier Dateien auf Fehler überprüfen.

- dayztools.de : Eine online Sammlung von Verschiedenen Tools

- DayZLootSpawnCalculator : Ein Online Kalkulator zum erstellen neuer Loot Proxys

- dayz.ginfo.gg : Einfach alle gängigen DayZ Maps mit Vanilla Loot Spots uvm.

- DayZ Loot Edit : Ein Tool um die Types etwas einfacher zu bearbeiten.

- dzconfig.com : Ein Online Editor für viele unterschiedliche Server Files. Es gibt einen Free und einen Premium Zugang

(Ich selber hab es erst vor Kurzem gefunden und bis jetzt selber noch nicht genutzt)

- filezilla oder WinSCP : Zum Dateien von eurem PC auf den Server hoch oder runter zu laden insofern es euer Server Host nicht von Haus aus hat.(Alternativ gibt es auch die Möglichkeit einfach den Browser zu Verwenden z.B.: DreamHost File Manager )

- Hier auch nochmal ein Nachtrag und einen großen 👍 nach oben für eine Zusammenstellung einiger sehr Arbeitserleichternden

und Großartigen Webtools im Beitrag DayZTools - Alle Tools auf einen Blick - Webtools für DayZ.

Das sollten aber erst mal genug Beispiele sein und damit kommen wir zum nächsten Punkt.

- Wo sind die Files überhaupt zu finden:

Die Files sind von der Ordnerstruktur unter "mpmissions" zu finden.

Je nach Server und Map ist es meist:

- "dayzOffline.chernarusplus" für Chernarus (Bsp.: "Basisverzeichnis\mpmissions\dayzOffline.chernarusplus)

- "dayzOffline.enoch" für Livonia (Bsp.: "Basisverzeichnis\mpmissions\dayzOffline.enoch)

- "dayzOffline.sakhal" für Sakhal (Bsp.: "Basisverzeichnis\mpmissions\dayzOffline.sakhal)

Hier sind nochmal die Unterordner "db" und "env" zu finden.

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

WICHTIG: Das "Basisverzeichnis" ist in diesem Falle euer Server, in dem sich auch die DayZServer-x64.exe und die serverDZ.cfg befinden

Hier auch noch ein Link zu zu den BohemiaInteractive Missions.

Dabei handelt es sich um die Verschiedensten Dateien, die auch an die Verschiedensten Events angepasst wurden.

github.com - BohemiaInteractive

Und schon kommen wir zum vorerst letzten Punkt.

- Welche Files gibt es und wofür sind diese zuständig:

Da ich im laufe der Zeit und beim Ausarbeiten überlegt habe, wie ich es am Besten mache,

habe ich mir das ganze in mehrere Themengebiete eingeteilt.

Die Ersten Themen befassen sich mit Allgemeinen Servereinstellungen.

Danach gehen wir über in ein paar Extra Einstellungen, welche ich in Setting Extras eingeteilt habe.

Anschließend gibt es den Bereich Economy, wo es Hauptsächlich um Objekte und deren Spawn Verhalten geht.

Als Abschluss haben wir noch den Bereich Environment, der sich nur noch mit der Map,deren Umgebung und Natur befasst.

Nachträgliche und Neue Themen werde ich nur noch unter dem Bereich Nachtrag einreihen

und hier auch im Anschluss verlinken.

Ich denke doch und hoffe mal das wird so gehen

aber machen erstmal weiter im Text 😅.

Aufgeteilt im jeweiligen Pfad, haben wir Folgende Dateien:

Das Basisverzeichnis:

Hauptsächlich ist hier nur die Datei serverDZ.cfg wichtig, mit der wir uns auch im verlinkten Thema befassen werden.

Wobei ich hier auch gleich noch ein kleines Extra Thema namens serverDZ.cfg Extras und das Thema dayzsettings.xml anhänge.

Diese beiden Theman sind nicht Ausschlaggebend Wichtig aber das ein oder andere kann man ja wenigstens mal gesehen oder gehört haben

und unter Umständen sind ja doch einige Sachen dabei, die man gebrauchen kann 😁.

Das Hauptverzeichnis:

Hier ist im Groben gesagt alles Vertreten, was für den Server und die Map wichtig ist. Z.B. Events, Server Einstellungen, Spawn-Punkte, etc.)

areaflags.map = Im Grunde ist dies eine Art Karte, die für die tier1 bis tier4 zuständig ist. (Ist nur mit dem CE Editor zu öffnen)

cfgeconomycore.xml = In dieser Datei werden Kerneinstellungen für die Loot Economy vorgenommen

cfgeffectarea.json = Dies ist eine Einstellungs- und Koordinaten Datei für Kontaminierte Zonen

cfgenvironment.xml = Eine Einstellungs- und Parameter Datei für die "env" Dateien

cfgeventgroups.xml = Hier werden Event-Gruppen von Objekten Definiert z.B. einem Entgleisten Zug oder Militär Convoy

cfgeventspawns.xml = In dieser Datei sind alle Koordinaten für Events wie Fahrzeuge, Bretterstapel oder die Event-Gruppen enthalten

cfggameplay.json = Das is eine Einstellungsdatei für das Spiel selber. Hier können Dinge wie schaden an Basen, Ausdauer oder Temperaturen angepasst, ein- oder ausgestellt werden

cfgignorelist.xml = Sozusagen eine Bannliste für Objekte. Alles in dieser Liste eingetragene wird im Grunde nicht gespawnt

cfglimitsdefinition.xml = Eine Art Kategorien und Tag Verzeichnis an dem sich der Server beim spawnen von Objekten Orientieren kann

cfglimitsdefinitionuser.xml = In etwa auch nochmal eine Art Verzeichnis für Kategorien

cfgplayerspawnpoints.xml = Hier sind Einstellungen und Koordinaten für Charaktere enthalten, die einem Server neu beitreten

cfgrandompresets.xml = In dieser Datei sind Objekt- oder Elementgruppen hinterlegt, die z.B. sagen mit welcher Wahrscheinlichkeit welcher Loot aus welcher Gruppe spawnen kann

cfgspawnabletypes.xml = Hier wird Objekten zugewiesen welche Objekt- oder Elementgruppen sie enthalten können und mit welcher Wahrscheinlichkeit diese enthalten sind

cfgundergroundtriggers.json = Eine Einstellungsdatei zum auslösen von Geräuschen und Licht in Bunkern (Momentan nur Livonia oder Mods)

cfgweather.xml = Eine Konfigurationsdatei für Wetter und Nebel

init.c = Eine Art Konfigurations- und Start Datei für den Server. Hier können z.B. Serverzeit oder Startequipment für Charaktere festgelegt werden

mapclusterproto.xml = Hier wird sozusagen für Objekte die eher in Massen auf der Map stehen hinterlegt wo und wie viel Loot an diesem spawnen kann z.B. Bäume, Büsche, Gleisen, etc.

mapgroupcluster.xml = Hier sind alle Koordinaten der von mapclusterproto definierten Objekten hinterlegt

mapgroupcluster01.xml = \

bis > Eine Weiterführung der mapgroupcluster Datei

mapgroupcluster04.xml = /

mapgroupdirt.xml = Momentan eine nicht benutzte Datei

mapgroupproto.xml = Hier wird für Objekte die auf der Map stehen hinterlegt, wo und wie viel Loot an und in diese spawnen kann aber ehr an Objekten wie z.B. Häusern oder Wracks

mapgrouppos.xml = Ähnlich der mapgroupcluster werden hier alle Koordinaten der von mapgroupproto definierten Objekte hinterlegt

Das Unterverzeichnis db:

Hier sind die Globalen Serverkonfiguration und die Kern Loot-Economy enthalten.

economy.xml = Hier kann man im Grunde die Economy des Servers einzeln Aktivieren oder Deaktivieren

events.xml = Ist für Dynamische Events und Ereignisse (Tiere, Zombies oder Statische Objekte z.B. Weihnachtsbäume)

globals.xml = Hier werden Globale Einstellungen wie z.B. die maximale Anzahl an Zombies oder Tieren definiert

messages.xml = Eine Datei für Globale Nachrichten und Infos, sowie Shutdown Einstellungen für den Server

types.xml = Eine Datei mit Loot Einstellungen für jedes einzelne Objekt, welches auf der Map als Loot Spawnen kann

Das Unterverzeichnis env:

Hier sind Koordinaten für Statische und Dynamische Spawns von Tieren und Zombies enthalten.

bear_territories.xml = Bären Spawn Punkte

cattle_territories.xml = Rinder Spawn Punkte

domestic_animals_territories.xml = Eine Veraltete Datei der Rinder Spawn Punkte die wohl nicht mehr genutzt wird

fox_territories.xml (= Link: Thema: territories.xml) = Fuchs Spawn Punkte

hare_territories.xml = Hasen Spawn Punkte

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

pig_territories.xml = Hausschwein Spawn Punkte

red_deer_territories.xml = Rothirsch Spawn Punkte

roe_deer_territories.xml = Hirsch Spawn Punkte

sheep_goat_territories.xml = Ziegen & Schaf Spawn Punkte

wild_boar_territories.xml = Wildschwein Spawn Punkte

wolf_territories.xml = Wolf Spawn Punkte

zombie_territories.xml = Zombie Spawn Punkte

Und um nocheinmal eine kleine Übersicht zu schaffen, Liste ich zum schluss nochmal alle Themengebiete auf,

wobei wir einfach mit den Servereinstellungen und seinen Anpassungen anfangen.

Danach geht es zu den Setting Extras,

wo wir uns mit ein paar Einstellungen noch einmal genauer befassen.

Anschließend haben wir die Economy,

die für den Nachschub von Objekten und deren Verhalten verantwortlich ist.

Als letztes haben wir noch Environment,

auf unserer Speisekarte, die sich hauptsächlich mit dem Leben,

der Ökonomie so wie der Umgebung befasst.

Als Nachtisch empfiehlt sich dann natürlich noch der Nachtrag,

bei der es eigentlich nur um alles geht, was ich eventuell vergessen habe,

mir erst später eingefallen ist, Dateien die sich Eventuell nicht auf Chernarus beziehen

oder erst später und neu hinzugefügt Bzw. Implementiert wurden.

Bis hierhin habt ihr es aber erst mal geschafft und bedanke mich zuallererst für eure Ausdauer und Zeit.

Ab jetzt wird es allerdings auch Komplizierter,da viele Dateien ineinander greifen können.

Es ist nicht immer zwingend Notwendig, aber dies kommt natürlich auch immer auf euren Geschmack und euren Server an.

Dies Sollte also als Einleitung und Verzeichnis hoffentlich erst mal ausreichen.

Ich hoffe das soweit auch alles verständlich ist und hilfreich ist.

Mit dem Nächsten Thema Startet auch der erste und Neue Beitrag,

also allen viel Spaß auch weiterhin beim Zocken, Modden und Zombies töten 😉😁.

Thema:

areaflags.map

Fangen wir als erstes gleich mal mit der areaflags.map an. Dies ist sozusagen auch gleich um zu zeigen, wie es am Ende in diesem Beitrag funktionieren und aussehen soll.

Der Economy Editor bzw. CE Editor wird hierfür zum Bearbeiten der einzelnen tiers benötigt.

Auf die tiers gehen wir aber in einem anderen Beitrag noch genauer ein.

Im Grunde und um es wahrscheinlich am einfachsten zu erklären sind die tiers aber eine Einteilung der Karte in verschiedene Zonen bzw. Schwierigkeitsstufen.

Diese sind meist auf verschiedenen Online Maps farblich dargestellt, wie sie es auch im CE Editor der Fall ist, hier mal ein kleines Beispiel:

Quelle: Reddit (Stand: 2020)

Hier auch gleich ein Beispiel, wie das Ganze im CE Editor aussieht:

Quelle: YouTube (oOBlackscreenOo)

Diese farblich markierten Zonen können über das Tool wie in einer Art Paint bearbeitet und angepasst werden.

Da verschiedenen Objekten ein solches tier zugeordnet ist, kann man somit bestimmen,

in welchen Gebieten diese spawnen können und dürfen.

Um am besten zu zeigen, wie das ganze funktioniert, gibt es hierzu auch schon 2 sehr gute Tutorials.

Ein deutschsprachiges Tutorial vom YouTube-Kanal oOBlackscreenOo mit einem zweiteiligen Tutorial,

Tutorial: DayZ Console areaflags.map 1/2 Loot Einstellen mit [DayZ Tool]

Und auch ein Englischsprachiges vom YouTube-Kanal Josie Garfunkle

Tutorial: DayZ areaflags.map | How to Add and Change Tiers!!!

So wie ein Tutorial von Elliot Rosewater

Tutorial: DayZ server: how to customize loot tiers and spawn loot for custom buildings

Dieses habe ich in einem älteren Beitrag mit dem Namen: areaflags bearbeiten gefunden.

Bei allen Tutorials wird finde ich sehr gut erklärt, wie mit dem Tool gearbeitet wird und wie es funktioniert.

Damit würde ich fürs Erste das erste Thema abschließen und wir sehen uns beim nächsten Thema 😁.

Ihr könnt auch gerne Wünsche äußern, welches Thema vorrangig als Nächstes kommen soll.
Ich mache es so wie es gerade zeitlich passt und nächste Woche hab ich etwas weniger Zeit,

da hab ich leider eine anstehende Apfelernte 😅

Thema:

serverDZ.cfg

Hier gibt es einige Wichtige Punkte die für den Server und seine Grundfunktionen sind.

Fangen wir aber nochmal beim Ort dieser Datei an, dem Basisverzeichnis.

Im Regelfall ist dies unter:

C:\Programme (x86)\Steam\steamapps\common\DayZserver

Bzw.

Euer Steam Installationsverzeichnis\Steam\steamapps\common\DayZserver

In dieser Datei schaut es dann im Vanilla Zustand wie folgt aus:

hostname = "EXAMPLE NAME";  // Server name
password = "";              // Password to connect to the server
passwordAdmin = "";         // Password to become a server admin

enableWhitelist = 0;        // Enable/disable whitelist (value 0-1)
 
maxPlayers = 60;            // Maximum amount of players
 
verifySignatures = 2;       // Verifies .pbos against .bisign files. (only 2 is supported)
forceSameBuild = 1;         // When enabled, the server will allow the connection only to clients with same the .exe revision as the server (value 0-1)
 
disableVoN = 0;             // Enable/disable voice over network (value 0-1)
vonCodecQuality = 20;        // Voice over network codec quality, the higher the better (values 0-30)
 
disable3rdPerson=0;         // Toggles the 3rd person view for players (value 0-1)
disableCrosshair=0;         // Toggles the cross-hair (value 0-1)

disablePersonalLight = 1;   // Disables personal light for all clients connected to server
lightingConfig = 0;         // 0 for brighter night setup, 1 for darker night setup
 
serverTime="SystemTime";    // Initial in-game time of the server. "SystemTime" means the local time of the machine. Another possibility is to set the time to some value in "YYYY/MM/DD/HH/MM" format, f.e. "2015/4/8/17/23" .
serverTimeAcceleration=12;  // Accelerated Time (value 0-24)// This is a time multiplier for in-game time. In this case, the time would move 24 times faster than normal, so an entire day would pass in one hour.
serverNightTimeAcceleration=1;  // Accelerated Nigh Time - The numerical value being a multiplier (0.1-64) and also multiplied by serverTimeAcceleration value. Thus, in case it is set to 4 and serverTimeAcceleration is set to 2, night time would move 8 times faster than normal. An entire night would pass in 3 hours.
serverTimePersistent=0;     // Persistent Time (value 0-1)// The actual server time is saved to storage, so when active, the next server start will use the saved time value.
 
guaranteedUpdates=1;        // Communication protocol used with game server (use only number 1)
 
loginQueueConcurrentPlayers=5;  // The number of players concurrently processed during the login process. Should prevent massive performance drop during connection when a lot of people are connecting at the same time.
loginQueueMaxPlayers=500;       // The maximum number of players that can wait in login queue
 
instanceId = 1;             // DayZ server instance id, to identify the number of instances per box and their storage folders with persistence files

storageAutoFix = 1;         // Checks if the persistence files are corrupted and replaces corrupted ones with empty ones (value 0-1)

 
class Missions
{
    class DayZ
    {
        template="dayzOffline.chernarusplus"; // Mission to load on server startup. <MissionName>.<TerrainName>
                          // Vanilla mission: dayzOffline.chernarusplus
                          // DLC mission: dayzOffline.enoch
    };
};

Alles ein wenig in seine Bestandteile zerlegt und zur besseren Erklärung hier die einzelnen Zeilen für sich erklärt.

hostname = ""; ==================> Wie euer Server heißt und mit welchem Namen er am ende auch im DayZ Launcher zu finden ist

password = ""; ==================> Password welches benötigt wird um dem Server beizutreten

passwordAdmin = ""; =============> Password für den oder die Server Admins

Da ich dies selber nicht nutze oder noch nie genutzt habe, kann man mich gerne Verbessern 😂.

Aber im Grunde geht ihr ins Spiel, geht in den Chat und gebt dort einfach #login (euer Admin Passwort).

Hier ein Link vom BohemiaInteractive Wiki zu den einzelnen befehlen die euch anschließend zur Verfügung stehen.

Wen gewünscht kann ich dazu auch nochmal ein extra Theme hier mit rein nehmen in sofern da noch nichts existiert 😅.

enableWhitelist = 0; ============> Eine Einstellung um die Whitelist zu Aktivieren (1) oder Deaktivieren (0)

Dabei Handelt es sich mehr oder weniger wie um eine Art Gästeliste, bei der nur Geladene Spieler auf den Server kommen und man sich dadurch das Passwort sparen könnte.

Da das Thema nicht so relevant ist, würde ich dazu auch maximal ein kleines Extra Thema anlegen wenn man es wünscht 😊.

maxPlayers = 60; ================> Das maximum an gleichzeitigen Spielern auf dem Server

Wer nur z.B. nur einen 20 Slot Server hat, muss hier nix einstellen. Dies wird erst ab 60 Slots wichtig und sollte am besten auch nicht den Wert 110 Übersteigen 😅

verifySignatures = 2; ===========> Überprüfung der Mod .pbo Dateien anhand der .bisign Dateien

Im Grunde wird mit dieser Einstellung garantiert, das man nur mit den auf dem Server Übereinstimmenden Mods auf den Server kommt.

auch diesen sollte man am besten nicht ändern. Laut Entwickler und den Dateien soll nur der Wert "2" unterstützt wird, kann ich das aus eigener Erfahrung Verneinen.

Bei dem Wert "0" wird z.B. nichts mehr Überprüft und man könnte auch ohne Selber eine Mod auf einen mit Mods Vollgepackten Server gehen Bzw. Spieler auf den Server Lassen.

Es hat nur Leider zur Folge das in meinem Fall ich für Mitspieler in einem Unsichtbaren Auto unterwegs war oder sie mit Unsichtbaren Waffen erschossen wurden 🤣.

Man kann also lustige Sachen damit machen aber sollte diese Einstellung Tatsächlich lieber so lassen wie sie ist.

forceSameBuild = 1; =============> Hiermit kann die Überprüfung der .exe Datei zwischen Server und Client Aktiviert "1" oder Deaktiviert "0" werden.

Sollte im Regelfall auf "1" gestellt werden, da man sonst Mit der 1.25 Version Clientseitig auf einen Server der 1.26 Spielen könnte und dadurch Probleme haben und Verursachen kann.

disableVoN = 0; =================> Hier kann der In-Game Voice Aktiviert "1" oder Deaktiviert "0" werden

vonCodecQuality = 20; ===========> Einfach gesagt wird hier die Qualität vom In-Game Voice eingestellt wobei 30 der maximal Wert ist oder sein sollte

disable3rdPerson=0; =============> Aktivierung oder Deaktivierung (wieder "1" oder "0") der 3rdPerson Ansicht, wodurch nur noch die EGO Perspektive erlaubt ist

disableCrosshair=0; =============> zusätzlich kann hier noch das Fadenkreuz De- und Aktiviert werden, das macht es den Spielern besonders einfach 😉😅🤣

disablePersonalLight = 1;

lightingConfig = 0;

Diese beiden Einstellungen befassen sich mit den Lichtverhältnissen.

Da sie aber in der cfggameplay.json genauso eingestellt werden können,

gehe ich darauf in diesem Post nicht so genau darauf ein.

Bei den nächsten Einstellungen gehe ich nur an die Grundlegenden Einstellungen und Mache wie bei anderen etwas ausführlicheren Themen einen kleinen Extra Post,

der sich in diesem Fall nur mit der Serverzeit Berechnung befasst.

Allerdings möchte ich hier gerne schon mal ein Dankeschön aussprechen und einen Link zu einem schon bestehenden Post Namens Tag/Nacht Rechner für DayZ Serverbetreiber aufnehmen.

serverTime="SystemTime"; ========> Server Startzeit

Hiermit wird die Startzeit des Servers festgelegt, dabei kann in verschiedene Einstellungen Unterteilt werden

"SystemTime" nimmt die lokale Zeit, vom Standort des Servers ausgehend, zu der der Server gestartet wird.

Als zweite Variante lässt sich ein Datum (welches sich natürlich in der Vergangenheit befindet) eintragen.

Dies muss im Format "YYYY/MM/DD/HH/MM" eingetragen werden und kann z.B. wie folgt aussehen "2011/11/11/11/11".

Es gilt also: "Jahr/Monat/Tag/Stunde/Minute"

serverTimeAcceleration=12; ======> Server Tageszeit Zeit Multiplikator

Diese Einstellung ist ein Multiplikator, der die Zeit beschleunigen kann, um z.B. meinen oder mehrere Tage innerhalb eines Echtzeit Tages

vergehen zu lassen

serverNightTimeAcceleration=12; => Server Nacht Zeit Multiplikator

Als Gegensatz haben wir hier noch einen Multiplikator für die Nachtzeit, der zusätzlich zum Gesamtzeit Multiplikator berechnet wird

serverTimePersistent=0; =========> Server Zeit Persistenz

Hiermit kann die Zeit des Servers so eingestellt werden, das diese auch nach einem Serverneustart da weiter macht wo er gestoppt hat.

Ist es also auf dem Server 3 Uhr Morgens und ihr habt diese Einstellung mit "1" Aktiviert, ist es nach dem Neustart wieder 3 Uhr.

Habt ihr es hingegen mit "0" Deaktiviert, fängt der server zur Startzeit des Servers wieder an.

guaranteedUpdates=1; ============> Einstellung für ein Kommunikation's Protokoll zwischen Server und Client und sollte einfach so bleiben wie es ist

loginQueueConcurrentPlayers=5; ==> maximal gleichzeitige logins

Die maximal Anzahl an Spielern, die sich gleichzeitig einloggen dürfen. Bei zu vielen Spielern würde die Serverperformance darunter leiden,

weshalb auch hier empfohlen wird die Einstellung so zu lassen wie sie ist. Bei mehr als 5 werden die restlichen in eine Warteschlange geschoben.

loginQueueMaxPlayers=500; =======> Die maximale Anzahl an Spielern für die login Warteschlange.

Hierbei kann man es sich wie das Nummern ziehen auf Ämtern vortstellen, insofern man dies noch kennt 🤣

Es können maximal 5 Spieler zur gleichen Zeit Spawnen, wodurch alle zusätzlichen Spieler Warten müssen.

Dabei gilt natürlich wer zuerst kommt Malt zuerst und hat also die nummer 001 auf seinem Warteschein.

Jeder nachvolgene Spieler hat also dann die Nummer 002, 003 und immer so weiter.

Dabei wirt hier aber Festgelegt, das der Wartebereich nur Platz für 500 Spieler bietet und alle anderen müssen leider draußen bleiben.

instanceId = 1; =================> Server Instanz ID

Hier muss ich leider zugeben, das ich mir da Unsicher bin weil ich da leider keine Konkrete Ahnung habe

Ich kann es mir nur daraus ableiten, dass es damit zu tun hat, das der Server die Map in mehrere Quadrate aufteilt

und diese Id dafür steht, das es auch nur eine Instanz, also ein Speicherdatei für dieses Quadrat geben soll,

die alles Persistente Speichert. Also Zelte, Autos, etc.

Wenn ich da falsch liege, Bitte ich natürlich um Berichtigung 😅 Ich lerne schließlich gerne auch noch was dazu 😁

storageAutoFix = 1; =============> Autoreperatur von beschädigten Speicherdateien

Hierbei wird dem Server gesagt, das er bei defekten oder Beschädigten Speicherdateien für die Persistence diese durch eine leere ersetzen soll.

Mit 1 ist es wieder Aktiviert und mit 0 wieder Deaktiviert.

Aber es bedeutet in in einem Bsp. Fall, das wenn in einem Quadrat ein Zelt stehen sollte und durch einen blöden Zufall wird genau die Datei Beschädigt,

in der dieses Zelt abgespeichert ist, dann wird sie durch eine neue und leere Datei ersetzt. Somit ist aber leider auch das Zelt nicht mehr da

und ist gelöscht. Wenn also mal was Verschwindet, muss es nicht unbedingt ein Spieler sein, der eure Sachen hat verschwinden lassen 🤣.

class Missions ==================> Server Map

Hier wird dem Server sozusagen gesagt welche Map er laden soll. Hierbei wird der Missions Name und der Terrain Name wie unten beschrieben eingetragen

template="dayzOffline.chernarusplus"; ====> Missions Name

Missions Name ist in diesem Fall = dayzOffline und der Terrain Name in diesem Falle = chernarusplus

Hier kann im Falle von DLC Maps aber auch die Livonia oder auch die Sakhal map eingetragen werden um

eben dem Server eine andere Map laden zu lassen, auf dem die Spieler ihr Unwesen Treiben können.

Selbes gilt auch für Mod Maps aber als Beispiel für Livonia würde es einfach wie folgt aussehen:

template="dayzOffline.enoch";

enoch ist in diesem Falle einfach die Einstellung der Vanilla Livonia Map.

Und um das ganze noch ein wenig zu ergänzen und auch ein klein wenig in die Richtung der offiziellen server zu gehen,

gibt es hier einen kleinen kniff mit dem man sich eventuell Zeit ersparen kann 😉.

Denn im Prinzip könnt ihr eine Kopie des Originalen dayzOffline.chernarusplus Ordners erstellen

und diesen Umbenennen in z.B. halloween.chernarusplusaus anschließend braucht ihr nur noch hier die Einstellung anpassen,

was dann wie Folgt ausschauen sollte:

template="halloween.chernarusplus";

Wenn ihr also schon eine Einstellung aller Dateien für Halloween habt oder eine andere Season oder Events, oder was auch immer,

könnt ihr somit umgehen, dass ihr alles Dateien hoch laden müsst, die Alten ersetzen und später das ganze wieder andersherum.

So kann man sich einfach schon vorher ales legen wie man es brauch, hochladen, am Tag X den Server herunter fahren, Zeile ändern

und anschließend wieder hochfahren ohne das Spieler ewig warten müssen 😉

Somit wäre dieses Thema erst mal Grob Fertig und würde es Zumindest für diesen Post auch dabei belassen, da es hier hauptsächlich um die Vanilla Einstellungen handelt,

Leider gibt es da noch ein paar mehr die man zusätzlich noch nutzen kann wenn man das möchte und sich noch Tiefer in den Bau des Kaninchens vorwagen möchte 😅

Dafür würde ich also noch eine Kleine Sektion für die serverDZ.cfg Extras anlegen, bei der ich ein klein wenig darauf eingehe.

Damit sehen wir uns also im Nächsten Thema und danke fürs Lesen und euer Interesse 😁

Thema:

serverDZ.cfg Extras

Hier gibt es ein paar Einträge die zusätzlich hinterlegt werden können. bei der ein oder anderen weiß ich leider nicht genau,

ob es sich dabei um veraltete Sachen handelt oder ob man Tatsächlich mit verschiedenen Dateien bestimmte Einstellungen erzeugen kann.

Aber fangen wir aber einfach mit allen Zusätzlichen Einträgen an.

adminLogPlayerHitsOnly = 0;        
adminLogPlacement = 0;            
adminLogBuildActions = 0;        
adminLogPlayerList = 0;            

storeHouseStateDisabled = true;

respawnTime = 5;           

maxPing = 200;            
 
timeStampFormat = "Short"; 
//logAverageFps = 300;      
logMemory = 300;            
logPlayers = 300;           
logFile = "server_console.log";
 
enableDebugMonitor = 0;    

steamQueryPort = 2305;     

allowFilePatching = 1;     

simulatedPlayersBatch = 10;   

multithreadedReplication = 1; 

disableMultiAccountMitigation = false;    

speedhackDetection = 1;            

networkRangeClose = 20;            
networkRangeNear = 150;            
networkRangeFar = 1000;            
networkRangeDistantEffect = 4000;        
networkObjectBatchLogSlow = 5;    
networkObjectBatchEnforceBandwidthLimits = 1;    
networkObjectBatchUseEstimatedBandwidth = 0;    
networkObjectBatchUseDynamicMaximumBandwidth = 1;    
networkObjectBatchBandwidthLimit = 0.8;    
networkObjectBatchCompute = 1000;    
networkObjectBatchSendCreate = 10;    
networkObjectBatchSendDelete = 10;    

defaultVisibility=1375;            
defaultObjectViewDistance=1375;

pingWarning = 200;                
pingCritical = 250;                
serverFpsWarning = 15;            

shotValidation = 1;                

motd[] = { "line1","line2" };    
motdInterval = 1;    

lightingConfig = 0;                
disablePersonalLight = 1;        

disableBaseDamage = 0;            
disableContainerDamage = 0;        
disableRespawnDialog = 0;    

steamProtocolMaxDataSize = 4000

Und hier nehmen wir die einzelnen Zeilen wieder auseinander.

WICHTIG!!! Sind diese Einstellungen nicht eingetragen oder Festgelegt, wie es unter den Standard Dateien meist der Fall ist, gilt Automatisch der Standartwert der hier in den Zeilen eingetragen ist.

adminLogPlayerHitsOnly = 0; =====> Hiermit kann man Einstellen ob nur Spieler Treffer Protokolliert werden sollen "1" oder alle Treffer "0" also auch von Tieren und Zombies

adminLogPlacement = 0; ==========> Hier kann ein- "1" oder ausgeschaltet "0" werden, ob das platzieren Protokolliert werden soll z.B. von Zelten, Fässern

adminLogBuildActions = 0; =======> Damit kann das Protokollieren von Basebuilding Aktionen wie Bauen oder Zerstören ein- "1" oder ausgeschaltet "0" werden

adminLogPlayerList = 0; =========> Hier kann auch wieder ein- "1" oder ausgeschaltet "0" werden ob der Server alle 5 min eine Liste mit der Position aller Spieler auf dem Server anlegen soll

Diese Einstellungen sind für Admins und Serverbesitzer wichtig, wenn es z.B. um das nachweisen von Spieler Aktivitäten bei Regelbrüchen geht.

Wenn eine Base in einem Gebiet Zerstört wird wo es nicht erlaubt ist, kann man so herausfinden wer und wann dies Passiert ist.

Oder wenn man aus einer PvP zone heraus in einer PvE Zone erschossen oder angegriffen wurde.

storeHouseStateDisabled = true; => Persistenz von Türen

Hier kann man einstellen ob Türen an Gebäuden Persistent sein sollen. Mit "true" bleiben Türen z.B. nach einem Server Neustart offen,

bei "false" sind sie geschlossen.

respawnTime = 5; ================> Respawn Zeit ein Sekunden

Dies ist eine Art Timer, der einem Spieler in diesem fall nach 5 sec. erlaubt einen neuen Charakter zu spawnen.

Bei 10 wären es 10 sec. und da ich nirgends einen max Wert gefunden habe,

könnt man mit 604800 einen Spieler erst nach 7 Tage das spawnen eines neuen Charakters auf dem Server erlauben 🤣.

maxPing = 200; ==================> Maximal Zulässiger Ping

Dies ist die Einstellung für den maximal erlaubten ping. Wird dieser von einem Spieler überschritten, wir dieser vom Server geschmissen.

Die Angabe ist hierbei in Millisekunden angegeben

timeStampFormat = "Short"; ======> Zeitstempelformat für log files

Dies ist eher unwichtig wenn man sich nicht unbedingt näher mit dieser Ganzen Server Sache auseinander setzten möchte, da diese Einstellung nur

festlegt, welches Format der Zeitstempel in z.B log files / crash Dateien hat. bei "Full" wird eben ein kompletter Zeitstempel hinterlegt

und bei "Short" nur ein kleiner und nicht ganz so ausführlicher

WICHTIG!!! Hier geht es langsam auch schon wieder etwas tiefer in den Kaninchenbau, denn Hierfür muss in den Startparametern des Servers "-doLogs" aktiv sein.

Dies läuft über eine .bat / "batch" Datei mit der der Server gestartet wird. Da es aber je nach Hoster oder Server Anbieter unterschiedlich ist,

Erstelle ich ein Thema für diese "batch" Datei bzw. die Startparameter.

//logAverageFps = 300; ==========> Durchschnittliche FPS Protokollierung

Hier wird die Zeit in Sekunden angegeben, in welcher der Server die Durchschnittliche FPS Protokolliert

Der Standardwert 300 entspricht also alle 5 min. ("-doLogs" muss hierfür in den Startparametern aktiv sein)

logMemory = 300; ================> Protokollierung der Speichernutzung

Hiermit wird auch die Zeit in Sekunden festgelegt, mit der die Speichernutzung Protokolliert wird

Der Standardwert 300 entspricht also auch hier wieder alle 5 min. ("-doLogs" muss hierfür auch in den Startparametern aktiv sein)

logPlayers = 300; ===============> Protokollierung verbundener Spieler

Und auch hier wieder die Zeit in Sekunden mit der diesmal die Anzahl der Aktiven bzw. Aktuell verbundenen Spieler Protokolliert wird

Dies entspricht also auch wieder das alle 5 min Protokolliert wird wie viele Spieler zum Zeitpunkt der Erstellung auf dem Server sind

(auch hierfür muss "-doLogs" in den Startparametern aktiv sein)

logFile = "server_console.log"; => Hiermit wird festgelegt, dass das Server Konsolen-Protokoll in einer Datei im Ordner mit den anderen Serverprotokollen gespeichert wird

enableDebugMonitor = 0; =========> DebugMonitor Aktivierung

Hiermit kann eine Art Infomonitor aktiviert "1" oder deaktiviert "0" werden

dabei handelt es sich um ein so genanntes "debug Window" oder eben einen "debug Minitor", der ein paar Infos über den Charakter

in einem kleinen Fenster an der oberen rechten Ecke eingeblendet

Ich selber hab es lange nicht benutzt, aber im Grunde sollte es sich nicht viel geändert haben und schaut in etwa so aus:

steamQueryPort = 2305; ==========> Abfrageport für Steam

Dies ist eine Port Definition für Steam und soll ein Problem beheben,

wenn der Server im Server-Browser des Clients also Spielers nicht auffindbar ist.

allowFilePatching = 1; ==========> Erlauben von Classenänderungen der Original Dateien

Zu aller erst, sollte dieser wert nicht geändert werden wenn man Mods auf seinem Server haben möchte, daher sollte es auf "1" und somit aktiviert bleiben

Wenn auf "0" gestellt und somit die Einstellung deaktiviert ist, könnte kein Spieler mit Mods oder geänderten Dateien auf den Server,

da diese Einstellung dafür zuständig ist ob durch z.B. Mods geänderte Klassen, die im Grundspiel vertreten sind erlaubt sind.

das bedeutet grob gesagt, würde man eine Mod haben die das Inventar der Vanilla Rucksäcke ändert, und somit die Klasse des Vanilla Objektes Damit ändern,

könnte man nicht mehr auf den server. So in etwa kann man sich es zumindest Vorstellen 😅

simulatedPlayersBatch = 10; =====> Spieler dargestellung pro Frame

Hier kann eingestellt werden, wie viele Spieler sozusagen pro Frame dargestellt werden können um ein wenig die Performance zu verbessern.

Da wahrscheinlich hier keiner groß etwas einstellt, und das ganze glaube und hoffe Selbsterklärend ist, würde ich hier nicht weiter drauf eingehen 🤣

multithreadedReplication = 1; ===> Erlauben von multiplen Prozessen mit verschiedenen Kernen

Das ist eine einstellung, bei der ich auch behaupten würde, das abgesehen von Experimentierfreudigen Bastlern, keiner an dieser Einstellung herumspielt 😅

Und da auch ich kein IT Spezi bin, der einem das Komplett erklären kann, versuche ich es mal so einfach zu halten, wie ich es zumindest Verstehe.

Denn hier wird mehr oder weniger dem Spiel erlaubt multiple Prozesse mit Verschiedenen Kernen besser zu verarbeiten.

Je mehr Kerne ein Server Bzw. der PC auf dem der Server läuft hat, desto mehr Jobs kann das Spiel gleichzeitig Verarbeiten,

da diese auf die einzelnen Kerne aufgeteilt werden

hierfür gibt es noch eine Datei, zu der ich ein kleines Minithema namens: "dayzsettings.xml" erstellen würde, da ich da nicht wirklich viel gefunden habe.

disableMultiAccountMitigation = false; ===> ReLog verzögerung bei mehreren Accounts

Diese Einstellung ist eher für Konsolen Spieler wichtig, da man hier den Timer für den wieder einstieg Mehrerer Accounts auf einer Konsole mit

"true" deaktivieren und mit "false" aktivieren kann.

Im Falle der Standard Einstellung "false" bedeutet es, das der ReLog mit einem anderen Account eine längere Wiedereinstiegszeit hat.

Dies wurde im Grunde geschaffen, das man sich nicht einfach Mehrere Charaktere erstellt, die dann z.B. den ganzen Loot Horten.

speedhackDetection = 1; ===========> Dies ist für die Speed-Hack Erkennung und kann mit den Werten 1 bis 10 versehen werden, wobei 1 die höchste und 10 die Niedrigste Einstellung ist.

networkRangeClose = 20; ===========> Spawn-Distanz für Container Objekte

Dies ist eine Spawn-Distanz in Metern (20m = Standartwert) für Objekte mit Inhalt, wie z.B. Kleidung, Rucksäcke oder Kisten

networkRangeNear = 150; ===========> Spawn-Distanz für Normale Inventar Objekte

Hier noch eine Spawn-Distanz in Metern (150m = Standartwert) für Normale Inventar Objekte, wie z.B. Dosenöffner, Nähset oder Taschenlampen und die Despwan-Distanz mit +10% (also 165 Meter)

networkRangeFar = 1000; ===========> Spawn-Distanz für Nicht-Inventar Objekte

Die Spawn-Distanz in Metern (1000m = Standartwert) für Nicht-Inventar Objekte, wie z.B. Fahrzeuge, Zäune oder aufgestellte Zelte, wieder mit einer Despwan-Distanz mit +10% (1100 Meter)

networkRangeDistantEffect = 4000; ===> Spawn-Distanz für Effekte

Nochmal eine Spawn-Distanz für Effekte, auch wieder in Metern (4000m = Standartwert) und bisher beziehen sich Effekte nur auf Geräusche und Wahrscheinlich auf die Toxischen Zonen,

aber da bin ich mir nicht zu 100% sicher 😅

networkObjectBatchLogSlow = 5; ====> Zeitabstand der Spawabfrage

Mehr oder weniger kann hier die Zeit in Sekunden angegeben werden in welchen Abständen der Server versuchen soll z.B. ein Objekt zu Spawnen.

Er fragt sozusagen alle 5 sec ab, ob in einem radius von 20m ein Spieler ist oder nicht.

networkObjectBatchEnforceBandwidthLimits = 1; =====> Bandbreiten spaw Limitierung

Eine Einstellung für die Limitierung zum spawnen von Objekten anhand der Bandbreite,

Je niedriger also die Bandbreite des Servers, desto weniger Objekte werden gespawnt um die Performance ein wenig aufrecht zu erhalten.

Aktiviert mit "1" lässt also weniger und deaktiviert lässt also Normal Objekte auf kosten der Performance Spawnen

networkObjectBatchUseEstimatedBandwidth = 0; ======> Bandbreiten Erkennung

Dies ist eine Einstellung bei der mit "0" die Bandbreiten Erkennung der letzten Verbindung bzw. der letzten Datenübermittlung stattfindet oder mit "1" eine grobe Schätzung vollzogen wird

networkObjectBatchUseDynamicMaximumBandwidth = 1; => Bandbreitenbegrenzung

Hier wird Festgelegt, ob eine Bandbreitenbegrenzung ein Faktor für die Maximale Bandbreite sein soll oder ob es ein definierter Wert ist.

Ich bin halt kein IT Techniker aber wenn sich jemand findet der es Genauer erklären kann, der werfe den ersten Stein 🤣

networkObjectBatchBandwidthLimit = 0.8; ===========> Limit für die Bandbreitenbegrenzung

Das Limit für die networkObjectBatchUseDynamicMaximumBandwidth

Auch hier kann wieder Jemand mit nem Stein nach mir werfen, insofern dies Überhaupt noch nach den Heutigen Möglichkeiten und wie die Server laufen wichtig ist 😅

networkObjectBatchCompute = 1000; ===========> Spawn Anzahl der Objekte festgelegt pro Server-Frame

Damit wird die maximale Anzahl an Objekten festgelegt, die in einem Server-Frame in einer art Liste überprüft und abgearbeitet werden um sie zu spawnen oder zu despawnen

networkObjectBatchSendCreate = 10; ================> Hiermit wird die Maximale Anzahl gleichzeitiger zu übertragenden Objekte zum spawnen festgelegt

networkObjectBatchSendDelete = 10; ================> Und hier die Maximale Anzahl gleichzeitiger zu übertragenden Objekte zum despawnen

Diese Einstellungen beziehen sich in erster Linie auf eine so genannte Network-Bubble oder zum besseren Verständnis kann man es sich so Vorstellen,

das um Jedes Objekt, Jeden Spieler und jede KI (ob Zombie oder Tier) eine Unsichtbare Blase befindet und erst wenn eine Blase die andere verlässt,

dann kann z.B. ein Objekt Despawnen oder spawnen.

🤔 Stellt man sich das ganze Bildlich mit Seifenblasen vor, wäre das Spiel also eine einzig Riesige Schaumparty 🤣😅

Des weiteren sind die Einstellungen für die Übertragungen und Verarbeitungen des Servers wichtig

und wenn man sich damit nicht befassen möchte (was man glaube ich auch nicht unbedingt muss) oder sich nicht 100%tig auskennt und da zähle ich mich dazu 😅

gilt wie bei vielen anderen Einstellungen : Lieber die Finger davon lassen 🤣 aber man hat mal was davon gehört

defaultVisibility=1375; ===========> Sichtweite des Geländes

Hiermit kann man die Maximale "viewDistance" für das Terrain, also die Sichtweite des Geländes eines Servers einstellen.

Diese wird somit Voreingestellt, kann einen Maximalwert aber nicht übersteigen und ist dieser Wert höher als die Clientseitige Einstellung,

wird immer die Einstellung des Spielers verwendet, um Spieler mit einem nicht so guten PC nicht nicht zu benachteiligen.

defaultObjectViewDistance=1375; ===========> Sichtweite für Objekte

Hier nochmal in etwa das selbe, nur kann man die Maximale Sichtweite für Objekte eines Servers einstellen.

Ergänzen möchte ich auch noch die Client Einstellung unter Dokumente/Dayz/"EuerName"_settings.DayZProfile,

die Ihr einsehen und darunter eure "viewDistance" und die "preferredObjectViewDistance" Einstellung anpassen könntet.

pingWarning = 200; ==========> Hier wird der minimal Wert für die gelbe Ping Warnung festgelegt, also ab welchem Ping wert diese angezeigt werden soll

pingCritical = 250; ===========> Nochmal das selbe für die rote Ping Warnung

serverFpsWarning = 15; ======> Und hiermit wird der Server FPS-Wert definiert ab wann die Server FPS Warnung ausgelöst werden soll

shotValidation = 1; ===========> Reproduzierung der Projektil-Flugbahn

Hiermit kann Aktiviert "1" oder Deaktiviert "0" werden ob der Server eine Art Flugbahn für Projektile Nachverfolgen soll.

Wenn Aktiviert kann oder soll der Server sozusagen z.B. AimBots oder der gleichen ausfindig machen,

da er versucht einen Schuss zu Reproduzieren um sicherzustellen, das alles Rechtens ist.

motd[] = { "line1","line2" }; ===========> Nachricht für InGame-Chat

Damit lässt sich die "Nachricht des Tages" im InGame-Chat einstellen oder erstellen

line1 oder line2 wird in dem Fall durch die Nachricht ersetzt

motdInterval = 1; ===========> Zeitintervall zwischen den "Nachricht des Tages"

Damit lässt sich der Zeitintervall zwischen den Nachrichten in Sekunden festlegen.

Wenn also 2 Nachrichten Festgelegt sind, kann man z.B. mit dem Wert "30"

alle 30 Sekunden eine Nachricht im Chat erscheinnen lassen.

Folgende Einstellungen können auch in der cfggameplay.json eingestellt werden.

Da sie darin auch schon Standardmäßig eingestellt sind würde ich das hier eher als Veraltet betrachten, nur als

"AHA, das geht wohl auch" abstempeln 🤣 und diese so stehen lasse,

da ich auf diese Einstellungen imcfggameplay.json Thema näher darauf eingehe.

disableBaseDamage = 0; ===========> Basebuildingschaden Einstellung

disableContainerDamage = 0; =======> Containerschaden Einstellung

disableRespawnDialog = 0; ========> Respawn Dialog Einstellung

steamProtocolMaxDataSize = 4000; ==> Maximale Steam Protokoll Paketgröße

Hier ist noch eine Etwas in Vergessenheit geratene Einstellung, die Vor allem durch das Update 1.26 wieder etwas in den Vordergrund rückt.

Dabei handelt es sich um die Paketgröße an Daten die Steam Nutzt und mit den Werten "1024", "2048" und "4000" erhöht werden kann.

Da ich selbst kein IT und Technik Spezialist bin, kann ich nur Grob das erklären was mir Bekannt ist 😅,

denn im Prinzip erlaubt diese Einstellung eine längere Mod-Listenlänge auf Grund der erlaubten Paketgrößen

und lässt den Launcher auch wieder die Server anzeigen und Finden.

Ich glaube mehr muss man auch nicht unbedingt wissen, Hauptsache es läuft wieder 🤣.

Damit würde ich auch diese kurze Exkursion abschließen und mich dem nächsten Thema Widmen 😉

Ich hoffe aber es sit soweit Verständlich und Lesen uns Später wieder weiter.

Thema:

dayzsettings.xml

Wie schon gesagt, habe ich mich mit dieser Datei selber noch nicht so viel befasst und finde darüber leider auch nicht so viel,

daher würde ich dieses Thema so kurz und so knapp wie möglich halten, denn ich glaube hiermit befassen sich nur die wenigsten

und diejenigen, die sich damit befassen, denen brauch man das glaube ich auch nicht erklären 😅🤣

Hier können aber, so weit wie ich es verstehe, schon serverseitig Sachen eingestellt werden, die zum Teil am Ende clientseitig voreingestellt werden,

Wie bei allem anderen auch erst mal die Version, wie sie meist auch zu finden ist und in den Dateien stehen sollte.

<config version="1.0">
    <video noshadergen="1" screenwidth="1520" screenheight="892" posX="355" posY="97" ratio3D="1" vsync="0" fullscreen="0" gamma="0" contrast="0" brightness="0" texturefilter="2" maxaniso="16" texturedetail="0" modeldetail="0" shadow="3" shadowcascades="4" omnishadow="0" llevel="2" windowmode="1" fsaa="8" atoc="15" rvterrainshaders="3" stabilizecascades="1" />
    <render geometricdetail="2" postprocess="5" reflections="0" waterdetail="1" terraindetail="1" terrainsalpha="1" />
    <controls>
        <mousespeed horizontal="100" vertical="100" />
    </controls>
    <workbench>
        <launchbar>
            <executable path="DayZIntDX11.exe" parameters="-noPause -window -x=1280 -y=720" icon="Icons/myIcon.png" tooltip="Launch game" />
            <executable path="DataExporterApp_d.exe" parameters="" icon="" tooltip="Launch data exporter" />
        </launchbar>
    </workbench>
    <jobsystem globalqueue="4096" threadqueue="1024">
        <pc maxcores="2" reservedcores="1" />
        <ps4 threadcount="4" />
        <xb1 threadcount="4" />
    </jobsystem>
</config>

Wieder einzeln aufgeteilt haben wir Folgendes:

<video noshadergen="1" screenwidth="1520" screenheight="892" posX="355" posY="97" ratio3D="1" vsync="0" fullscreen="0" gamma="0" contrast="0" brightness="0" texturefilter="2" maxaniso="16" texturedetail="0" modeldetail="0" shadow="3" shadowcascades="4" omnishadow="0" llevel="2" windowmode="1" fsaa="8" atoc="15" rvterrainshaders="3" stabilizecascades="1" />

Dies sind einzelne Grafikeinstellungen, wie die Auflösung, die full-screen (Vollbild) oder Fenstermodus Einstellung, die Gamma und Kontrasteinstellungen oder Texturdetails und noch vieles mehr.

Da es aber hauptsächlich eine Clienteinstellung ist, glaube ich das dies eher eine Grundausführung von Standardwerten ist.

<render geometricdetail="2" postprocess="5" reflections="0" waterdetail="1" terraindetail="1" terrainsalpha="1" />

Hier sind noch ein paar Grafikeinstellungen, die sich mehr mit dem Randering und den Details befassen und sollten auch nur eine Art Grundeinstellung darstellen.

<mousespeed horizontal="100" vertical="100" />

Dies sind nochmal ein paar Voreinstellungen für die Mausempfindlichkeit.

<executable path="DayZIntDX11.exe" parameters="-noPause -window -x=1280 -y=720" icon="Icons/myIcon.png" tooltip="Launch game" />

<executable path="DataExporterApp_d.exe" parameters="" icon="" tooltip="Launch data exporter" />

Dies sind auch nochmal ein paar Startparameter für den Server.

<jobsystem globalqueue="4096" threadqueue="1024">

<pc maxcores="2" reservedcores="1" />

<ps4 threadcount="4" />

<xb1 threadcount="4" />

</jobsystem>

Im Groben ist dies eine Einstellung, in der die Anzahl der zur Verfügung stehenden Kerne und der Reserve Kerne eingestellt werden kann.

maxcores - Ist die maximale Anzahl von CPU-Kernen, die für das Jobsystem und die damit verbundenen Arbeiten verwendet werden

reservedcores - Bezeichnet die Anzahl der CPU-Kerne, die für andere Threads und Prozesse verwendet werden

Die Anzahl der Arbeitsthreads beträgt "maxcores - reservedcores", also 2 - 1.

Wodurch immer noch ein Arbeitsthread übrig ist, womit der Server arbeiten kann.

Inwieweit es hilft hierbei, die Anzahl der Kerne zu erhöhen und ob der Server damit besser läuft,

kann ich leider nicht beurteilen.

Wie gesagt bin auch ich da eher überfragt und wenn sich jemand findet, der dies erklären kann, kann er sich dem gerne annehmen.😂

Aber so hat man auch diese Datei wenigstens mal gesehen 🤣😅

Thema:

cfggameplay.json

Was ist die cfggameplay.json?

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

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

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

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

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

erstellt oder geändert werden.

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

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

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

{
    "version": 122,
    "GeneralData":
    {
        "disableBaseDamage": false,
        "disableContainerDamage": false,
        "disableRespawnDialog": false,
        "disableRespawnInUnconsciousness": false
    },
    "PlayerData":
    {
        "disablePersonalLight": false,
        "StaminaData":
        {
            "sprintStaminaModifierErc": 1.0,
            "sprintStaminaModifierCro": 1.0,
            "staminaWeightLimitThreshold": 6000.0,
            "staminaMax": 100.0,
            "staminaKgToStaminaPercentPenalty": 1.75,
            "staminaMinCap": 5.0,
            "sprintSwimmingStaminaModifier": 1.0,
            "sprintLadderStaminaModifier": 1.0,
            "meleeStaminaModifier": 1.0,
            "obstacleTraversalStaminaModifier": 1.0,
            "holdBreathStaminaModifier": 1.0
        },
        "ShockHandlingData":
        {
            "shockRefillSpeedConscious": 5.0,
            "shockRefillSpeedUnconscious": 1.0,
            "allowRefillSpeedModifier": true
        },
        "MovementData":
        {
            "timeToStrafeJog": 0.1,
            "rotationSpeedJog": 0.3,
            "timeToSprint": 0.45,
            "timeToStrafeSprint": 0.3,
            "rotationSpeedSprint": 0.15,
            "allowStaminaAffectInertia": true
        },
        "DrowningData":
        {
            "staminaDepletionSpeed": 10.0,
            "healthDepletionSpeed": 10.0,
            "shockDepletionSpeed": 10.0
        }
    },
    "WorldsData":
    {
        "lightingConfig": 0,
        "objectSpawnersArr": [],
        "environmentMinTemps": [-3, -2, 0, 4, 9, 14, 18, 17, 13, 11, 9, 0],
        "environmentMaxTemps": [3, 5, 7, 14, 19, 24, 26, 25, 18, 14, 10, 5],
        "wetnessWeightModifiers": [1.0, 1.0, 1.33, 1.66, 2.0]
    },
    "BaseBuildingData":
    {
        "HologramData":
        {
            "disableIsCollidingBBoxCheck": false,
            "disableIsCollidingPlayerCheck": false,
            "disableIsClippingRoofCheck": false,
            "disableIsBaseViableCheck": false,
            "disableIsCollidingGPlotCheck": false,
            "disableIsCollidingAngleCheck": false,
            "disableIsPlacementPermittedCheck": false,
            "disableHeightPlacementCheck": false,
            "disableIsUnderwaterCheck": false,
            "disableIsInTerrainCheck": false,
            "disallowedTypesInUnderground": ["FenceKit","TerritoryFlagKit","WatchtowerKit"]
        },
        "ConstructionData":
        {
            "disablePerformRoofCheck": false,
            "disableIsCollidingCheck": false,
            "disableDistanceCheck": false
        }
    },
    "UIData":
    {
        "use3DMap": false,
        "HitIndicationData":
        {
            "hitDirectionOverrideEnabled": false,
            "hitDirectionBehaviour": 1,
            "hitDirectionStyle": 0,
            "hitDirectionIndicatorColorStr": "0xffbb0a1e",
            "hitDirectionMaxDuration": 2.0,
            "hitDirectionBreakPointRelative": 0.2,
            "hitDirectionScatter": 10.0,
            "hitIndicationPostProcessEnabled": true
        }
    },
    "MapData":
    {
        "ignoreMapOwnership": false,
        "ignoreNavItemsOwnership": false,
        "displayPlayerPosition": false,
        "displayNavInfo": true
    }
}

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

"version": 122, = Versionsnummer

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

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

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

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

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

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

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

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

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

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

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

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

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

Und aus diesem Grund als Antwort richtig oder Falsch.

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

und ausreichend😅.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Also schaut einfach unter dem Thema Schockberechnung.

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

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

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

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

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

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

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

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

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

"timeToStrafeJog": 0.1, = 6 ms

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

"rotationSpeedJog": 0.3, = 18 ms

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

"timeToSprint": 0.45, = 27 ms

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

"timeToStrafeSprint": 0.3, = 18 ms

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

"rotationSpeedSprint": 0.15, = 9 ms

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

"allowStaminaAffectInertia": true

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

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

Aktion schneller wird.

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

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

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

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

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

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

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

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

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

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

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

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

"0" = eine relativ helle Nacht

"1" = eine dunkle Nacht und

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Daher nehme ich einfach mal eine Daunenjacke als Bsp.:

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

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

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

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

Klitschnass => 2.0 = 200% = 4 Kg

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

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

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

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

oder schwerer machen kann.

"HologramData": = Einteilungen für Hologramme

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

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

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

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

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

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

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

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

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

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

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

oder Events (Heli Crashes, Konvois) verboten.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nehmen wir das Fass als kleines Beispiel.

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

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

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

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

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

"ConstructionData": = Einteilungen für Konstruktionen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"use3DMap": false, = Map Einstellung

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

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

Hierzu ein Bild zum besseren Verständnis

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

wie der Charakter diese in der Hand hält.

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

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

"HitIndicationData": = Treffer Einstellungen

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

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

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

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

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

und einem Prototypen der heutigen Blutflecken am Bildschirmrand 😅.

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

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

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

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

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

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

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

"0" = Deaktiviert

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

"1" = Statisch

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

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

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

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

des Treffers beibehalten und sich nicht mit dem Charakter bewegen.

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

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

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

0 = Blutflecken

1 = eine Spitze

2 = ein Pfeil

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

Hier kann die Farbe Richtungsmarkierung Eingestellt werden.

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

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

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

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

das es zum einen auf die schwere des Treffers ankommt.

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

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

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

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

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

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

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

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

und wird zufällig im angegebenen Bereich angezeigt.

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

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

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

selbst wenn man genau von Vorne Getroffen wurde 😅.

Totale Verwirrung also 🤣.

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

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

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

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

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

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

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

"use3DMap" ist hierbei mit zu Berücksichtigen.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

von einem Kompass oder GPS Gerätes Deaktiviert.

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

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

sind diese also nicht Vorhanden.

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

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

Mit "false" wird es eben wieder Deaktiviert.

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

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

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

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

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

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

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

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

Thema:

init.c

Placeholder ☕🍪

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

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

Je nachdem, wie ich die Themen fertig habe.

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

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

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

Willkommen im nächsten Abschnitt 👋

Und freut mich das ihr bis hier durchgehalten

oder das ganze bis hier hin weiter verfolgt habt 😊.

Ab hier beginnen wir mit den Setting-Extras:

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

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

Als Erstes die Serverzeit Berechnung,

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

Die Schock-Berechnung,

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

Die Ausdauer Berechnung,

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

Des Weiteren haben wir noch die cfggameplay.json Extras,

mit der objectSpawnersArr,

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

Und den spawnGearPresetFiles,

mit Einstellung und dem Anpassen von Startausrüstungen.

Als Letztes haben wir noch das Thema server_manager,

der sich mit einer anderen Art der Mod Installation befasst.

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

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

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

🤔 Er hatte bedauerlicherweise recht 🤣.

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

Thema:

Serverzeit Berechnung

Placeholder / in Arbeit ☕🍪

Thema:

Schock Berechnung

Placeholder ☕🍪

Thema:

Ausdauer Berechnung

Placeholder ☕🍪

Thema:

cfggameplay.json Extras:

objectSpawnersArr

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

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

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

Zumindest nicht ohne Mods 😅.

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

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

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

Risiko verbunden und jedem sich selbst überlassen.

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

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

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

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

In der cfggameplay.json eintragen.

Dies sollte dann so aussehen:

"WorldsData":

{

"lightingConfig": 0,

"objectSpawnersArr": [],

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

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

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

},

Jetzt haben wir 2 Möglichkeiten,

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

Diese nenne ich für in dem Fall einfach:

Haus.json

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

und .txt durch .json ersetzen.)

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

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

Jetzt kommen wir zur Möglichkeit 1:

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

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

Basisverzeichnis\mpmissions\dayzOffline.chernarusplus

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

Dies sollte am ende wie folgt aussehen:

"WorldsData":

{

"lightingConfig": 0,

"objectSpawnersArr": ["Haus.json"],

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

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

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

},

Kommen wir zur Möglichkeit 2:

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

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

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

Basisverzeichnis\mpmissions\dayzOffline.chernarusplus\Buildings

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

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

"WorldsData":

{

"lightingConfig": 0,

"objectSpawnersArr": ["Buildings/Haus.json"],

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

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

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

},

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

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

"WorldsData":

{

"lightingConfig": 0,

"objectSpawnersArr": ["Haus.json","Baum.json"],

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

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

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

},

Oder mit einem neu erstellten Ordner:

"WorldsData":

{

"lightingConfig": 0,

"objectSpawnersArr": ["Buildings/Haus.json","Buildings/Baum.json"],

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

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

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

},

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

"WorldsData":

{

"lightingConfig": 0,

"objectSpawnersArr": ["Buildings/Haus.json","Natur/Baum.json"],

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

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

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

},

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

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

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

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

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

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

vorhanden sein sollte und kommt meiner Meinung nach weniger durcheinander.

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

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

Es dient nur als kleines Beispiel und zur Anschauung 😅.

{

"Objects": [

{

"name": "Haus",

"pos": [

5520.15,

2024.56,

10.55

],

"ypr": [

0.0,

0.0,

0.0

],

"scale": 2

},

{

"name": "Tisch",

"pos": [

5520.00,

2023.80,

10.55

],

"ypr": [

0.0,

0.0,

0.0

],

"scale": 2

},

{

"name": "Apfel",

"pos": [

5520.00,

2023.80,

10.65

],

"ypr": [

0.0,

0.0,

0.0

],

"scale": 1,

"enableCEPersistency": true

}

]

}

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

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

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

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

5520.00, = X Achsen Koordinate

2023.80, = Y Achsen Koordinate

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

],

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

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

Dies ist dann leider eher ein Experimentieren.

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

und dort auch Objekte platzieren und bearbeiten kann.

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

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

0.0, = Drehung um die eigene Achse in °

0.0, = Neigung nach links oder rechts in °

0.0 = Kippen nach vorn oder hinten in °

],

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

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

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

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

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

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

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

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

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

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

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

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

Bei einem Apfel hingegen ist dies eben anders.

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

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

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

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

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

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

nach 4 Stunden verschwinden.

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

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

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

Thema:

cfggameplay.json Extras:

spawnGearPresetFiles

Placeholder ☕🍪

Thema:

server_manager

Placeholder ☕🍪

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

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

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

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

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

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

werden Objekte nicht hergestellt, sondern ebenso gespawnt 🤣.

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

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

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

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

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

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

mit einer Art Inhaltsangabe an.

Als Erstes haben wir die economy.xml,

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

Danach haben wir die globals.xml,

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

Als Nächstes haben wir die cfgeconomycore.xml,

für die Kerneinstellungen der Economy und die Dateien.

Gefolgt von der cfgignorelist.xml,

als "Limitierungsliste" für Objekte.

Danach kommen wir zur cfglimitsdefinition.xml,

als eine Art Orientierungs- und Kategorien Verzeichnis.

Als Nächstes die cfglimitsdefinitionuser.xml,

die ebenso als eine Art Kategorien Verzeichnis dient.

Gefolgt von der types.xml,

als Loot Einstellung für sämtliche Objekte.

Die events.xml,

für dynamische Events.

Der cfgeventspawns.xml,

als Koordinatenverzeichnis der einzelnen Events.

Dann haben wir noch die cfgspawnabletypes.xml,

als Gruppenverzeichnis für das spawnen an Objekten.

Und als Letztes noch die cfgrandompresets.xml,

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

Das sollten dann so weit alle wichtigen Dateien sein.

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

fangen wir auch gleich mit dem ersten Thema an 😁.