Beiträge von JackHusky

Zitat von Deichkind

Wenn du Realismus möchtest, musst du die dritte Dimension mit einbeziehen. Du kannst ja auch Dinge übereinander in die Kiste stapeln. Dann könnte die Kiste eine 7*6*24 sein von den Proportionen her und dann 8 Quadrate weniger wegen der Verstärkung innen

Ich gehe schon von dem aus, was aktuell an "Realismus" geboten wird Aber ja, am Ende arbeiten wir nur noch mit m³

Ok, schaue ich mir mal an, thx

//Edit

Also die Mod nutzt eine CFG, keine JSON, da kann der Inhalt beliebig aussehen. Aber ich habe mittlerweile die Klasse JsonFileLoader gefunden, da gibts mit der Methode JsonSaveFile eine Möglichkeit die Inhalte korrekt zu serialisieren.

Grundsätzlich war es nicht verkehrt, die Mod anzuschauen.

Ok, wenn ich die Slots für meinen Mod umbenenne, wäre es für meinen Mod als Standalone ok. Allerdings, darum dreht sich diese ganze Problematik, kann jeder andere Mod, wenn man mehrere Mods verwendet, die Rifle_Base mit seinem eigenen überschreiben und ich kann Plötzlich keine Waffen mehr an die Attachments packen.

Ich glaube du möchtest mir sagen, ich sollte das Ganze aus der config.cpp nehmen. Dies war ja meine Grundfrage, wie ich die Slots sicher laden kann, ohne das andere Mods diese überschreiben können. Es muss ja Methoden dafür geben, anders geht das ja nicht, man kann nicht einfach nen Array nutzen.

Zitat von Urs

Das ist harte Programmierung was du dir da wünscht. Viele Mods erstellen Jsons wo du dir das abschauen kannst wie das funktioniert

Das ist mir schon klar, ist ja nicht so, dass ich mich als Software-Entwickler vor sowas scheue

Hast Du da Beispiele, wo Du dies mit Sicherheit weist? Ansonsten schreibe ich sowas selber, ist immer noch C als Basis. Wollte nur, wenn möglich, bestehende Funktionalitäten nutzen.

Ok, dann versuche ich dies mal etwas zu spezifizieren.

Als erstes ein Auszug aus der config.cpp, wo die inventorySlot vom Standard-Items überschrieben werden.

class cfgWeapons
{
    class RifleCore;
    class Rifle_Base: RifleCore
    {
        inventorySlot[]=
        {
            "Shoulder",
            "Melee",
            "Shoulder1",
            "Shoulder2",
            "Shoulder3",
            "Shoulder4",
            "Shoulder5",
            "Shoulder6",
            "Shoulder7",
            "Shoulder8",
            "Shoulder9",
            "Shoulder10",
            "Shoulder11",
            "Shoulder12",
            "Shoulder13",
            "Shoulder14",
            "Shoulder15",
            "Shoulder16",
            "Shoulder17",
            "Shoulder18",
            "Shoulder19",
            "Shoulder20",
            "Shoulder21",
            "Shoulder22",
            "Shoulder23",
            "Shoulder24"
        };
    };
};

Als weiteres die Verwendung der Attachments in einem der eigenen Items (verkürzt) aus dem Bereich cfgVehicles.

class GunRack: Inventory_Base
{
   attachments[]=
       {
           "Shoulder1",
           "Shoulder2",
           "Shoulder3",
           "Shoulder4",
           "Shoulder5",
           "Shoulder6",
           "Shoulder7",
           "Shoulder8",
           "Shoulder9",
           "Shoulder10",
           "Shoulder11",
           "Shoulder12",
           "Shoulder13",
           "Shoulder14",
           "Shoulder15",
           "Shoulder16",
           "Shoulder17",
           "Shoulder18",
           "Shoulder19",
           "Shoulder20",
           "Shoulder21",
           "Shoulder22",
           "Shoulder23",
           "Shoulder24"
       };
   class GUIInventoryAttachmentsProps
   {
      class Row_01
      {
         name="$STR_AttGunRackRow1";
         description="";
         attachmentSlots[]=
         {
            "Shoulder1",
                   "Shoulder2",
                   "Shoulder3",
                   "Shoulder4",
                   "Shoulder5",
                   "Shoulder6",
                   "Shoulder7",
                   "Shoulder8"
         };
         icon="shoulderright";
         view_index=1;
      };
      class Row_02
      {
         name="$STR_AttGunRackRow2";
         description="";
         attachmentSlots[]=
         {
            "Shoulder9",
                   "Shoulder10",
                   "Shoulder11",
                   "Shoulder12",
                   "Shoulder13",
                   "Shoulder14",
                   "Shoulder15",
                   "Shoulder16"
         };
         icon="shoulderright";
         view_index=2;
      };
      class Row_03
      {
         name="$STR_AttGunRackRow3";
         description="";
         attachmentSlots[]=
         {
            "Shoulder17",
                   "Shoulder18",
                   "Shoulder19",
                   "Shoulder20",
                   "Shoulder21",
                   "Shoulder22",
                   "Shoulder23",
                   "Shoulder24"
         };
         icon="shoulderright";
         view_index=3;
      };
   }
};

Und zuguterletzt die Definitionen der Slots im Bereich CfgSlots.

class Slot_Shoulder1
{
   name="Shoulder1";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder2
{
   name="Shoulder2";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder3
{
   name="Shoulder3";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder4
{
   name="Shoulder4";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder5
{
   name="Shoulder5";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder6
{
   name="Shoulder6";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder7
{
   name="Shoulder7";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder8
{
   name="Shoulder8";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder9
{
   name="Shoulder9";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder10
{
   name="Shoulder10";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder11
{
   name="Shoulder11";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder12
{
   name="Shoulder12";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder13
{
   name="Shoulder13";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder14
{
   name="Shoulder14";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder15
{
   name="Shoulder15";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder16
{
   name="Shoulder16";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder17
{
   name="Shoulder17";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder18
{
   name="Shoulder18";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder19
{
   name="Shoulder19";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder20
{
   name="Shoulder20";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder21
{
   name="Shoulder21";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder22
{
   name="Shoulder22";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder23
{
   name="Shoulder23";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};
class Slot_Shoulder24
{
   name="Shoulder24";
   displayName="$STR_GunRackSlot";
   ghostIcon="";
};

Das Problem, welches mir hier aufgefallen ist, jeder Mod kann hier die Rifle_Base mit seinen eigenen Werten überschreiben und nur die Werte des letzten Mods zählen schlussendlich. Ich schätze, desswegen verwenden einige Mod-Ersteller die selten Bezeichnungen für ihre Slots, damit andere Mods weiterhin funktionsfähig bleiben.

Dieses Vorgehen ist aber zum einen aufwendig, außerdem bleibt man dann fest bei den Werten, zum anderen kann jeder Mod, welcher es anders definiert, diese Mods unfunktional machen.

Mein Idee dahinter war, dass man in den jeweiligen Klassen die Slots manuell zuweist. Es muss irgendwo eine Auswertung der Arrays geben, dort könnte man ansetzen. Allerdings habe ich noch nix in der Richtung finden können. Das muss entweder in der Inventory_Base liegen oder darüber, an so viel anderen Stellen wäre das logisch unsinnig. Leider habe ich nix finden können.

Ah ok, mit dem habe ich noch nicht gearbeitet. Wenn dem so ist, sollte das dann auch passen, thx

Der zweite Teil bezog sich auf eine Default-Config, falls man vergisst diese anzulegen. Auslesen von JSON ist kein Problem aber schreiben habe ich noch nicht gesehen. Natürlich kann ich allerhand Dateien selber erzeugen aber der Inhalt ist eine andere Sache, JSON ist speziell formatiert.

Das Problem sind ja nicht sie Slots an sich und wie die benannt sind, es geht eher darum, dass in den jeweiligen config.cpp immer wieder die selben Klassen überschrieben werden können.

Was meinst du mit der ClientMod genau? Auf überlagerungen in der config.cpp möchte ich verzichten aber eine optimierte Variante via Class kenne ich noch nicht. Wenn Dir da etwas bekannt ist, wäre das natürlich sehr hilfreich.

Btw. habe ich mir schon diverse andere Mods angeschaut, leider wurde mein genanntes Problem nirgends gelöst.

Hoffentlich reden wir nicht aneinander vorbei, ansonsten muss ich etwas mehr ins Detail gehen.

Hiho,

eine Frage an den Realismus, wie kann man die 1000er Kiste transportieren? Rein theoretisch müsste diese eine Größe von 10x100 haben und passt damit in kein Fahrzeug, heißt man kann sie nur in der Hand tragen. Ansonsten wäre der Innenraum größer als wie die Kiste selber benötigt.

LG

Zitat von Urs

Es ist üblich neben den Addons Ordner ein Keys Ordner zu erstellen in dem der Public Key liegt.

Wenn du den User weitere Dateien zukommen willst, erstellst du einen weiteren Ordner mit der Benennung deiner Wahl

Genau, diese werden aber im Addon Builder nicht mit übernommen. Im fertigen Mod habe ich nur die Ordner Addons und Keys, sowie die mod.cpp. Auch wenn ich die Ausnamen in den Einstellungen hinzufüge.

Oder passiert dies erst im Veröffentlichungsprozess? So weit war ich noch nicht, habe bisher nur immer den Mod bauen lassen um ihn testen zu können.

Zitat von Urs

Du erstellst deine eigene ClientMod, in der du dies alles bereinigst und dies nach den entsprechenden Mods lädst.

Das würde aber voraussetzen, dass ich Abhänigkeiten schaffen, was ich aber nicht vor habe. Zumindest klingt es so, als sollte ich die fremden Mods auflisten.

Da draußen können ja diverse Mods existieren, welche die selben Klassen in der config.cpp überschreiben. Deswegen dachte ich, dass man diese Problem generell umgehen kann, wenn man die Klassen nicht in der config.cpp anpasst, sondern in ihrer eigenen überläd, denn da wäre es durch die Vererbung egal.

Hiho,

ich frage mich, wie man das fertige Release eines Mods um eigene Dateien für die Benutzer erweitern kann. Sowas wie eine vorgefertigte types.xml, welche man nur übertragen muss, eine Lizensdatei oder diverse Konfigurationen. Muss dies im Addon Builder mit definiert werden?

Auch wäre es gut, wenn man die Config vergisst zu übertragen, dass diese aus einem Default automatisch bei Serverstart angelegt wird.

Vielleicht weis dazu jemand mehr. Soll am Ende den Benutzer unterstützen.

LG

Hiho,

theoretisch kann man das Problem lösen, wenn man die Funktionalität des Fahenmastes auf die gesamte Welt anwendet, welcher dauerhaft aktiv ist. Allerdings gibt es diverse Gründe, warum Gegenstände nach einer gewissen Zeit despawnen sollten. Einer davon wäre, dass Gegenstände immer nur weiter spawnen und logischerweise irgendwann der Speicher aufgebraucht ist. So wie ich den Code kenne, ist dieser nicht unbedingt auf Performance optimiert. Dies merkt man aktuell z.B. deutlich in Fahrzeugen.

Also es wäre möglich aber absolut nicht zu empfehlen.

LG

Hiho,

also "versteckt" kann man diese nicht unbedingt nennen, sie spawnen nur nicht standardmäßig. Warum das so ist? Nun dies kann mehrere Gründe haben. Einige sind schlussendlich nicht funktionsfähig.

Habe da schon diverse Waffen entdeckt, welche bereits als Model vorhanden sind und im Code rudimentär inkludiert wurden. Sowas wie der RPG 7 und LAW, samt Munition. Auch eine M249, der nicht tödliche Elektroschoker, sowie diverse Bögen und Pfeile.

DayZ selber soll ja keine Kriegssimulation darstellen, daher ist fraglich, ob einige Gegenstände jemals im Spiel verwendbar sein werden. Es waren auch mal gepanzerte Fahrzeuge geplant, weswegen die Raketenwerfer Sinn machen. Aber für das normale Spiel sind diese viel zu stark.

Wenn du eine vollständige Liste haben möchtest, musst Du nur mal alle vorhanden Modelle im Code durchgehen.

LG

Hiho,

mir ist in der letzten Zeit des öftern aufgefallen, dass diverse Mods die gleichen Items unter eigenen Namen verwenden, z.B. das Gun Rack, dabei aber bestehende "inventorySlot" überschreiben. Habe beim testen gemerkt, dass der letzte Mod, welcher geladen wird, die Oberhand hat. Generell sollten Mods so aufgebaut sein, dass sie die Funktion anderer Mods nicht beeinflussen. Der Weg, die gleichen Bezeichnungen für Slots zu verwenden, ist nur ein Workaround, keine Lösung.

Statt die Slots in der config.cpp zuzuweisen, muss es auch irgendwie Codeseitig funktionieren, allerdings habe ich dazu noch nix gefunden. Generell möchte ich den Steinofen erweitern, dabei stoße ich auf selbiges Problem, bzw werden die Erweiterungen nicht angezeigt.

Hat hier jemand Erfahrungen?

LG

Die schnelle Suche hatte das ergeben:

Server Init.c

DayZ Standalone Server - Tutorial - Spawnitems verändern

So, gestern habe ich das nochmal ausprobiert. Ich bin nie auf die Idee gekommen, mit Samen in der Hand, diese einzupflanzen, wenn Erde im Kasten ist. Da macht das mit den Attachments im Kasten auch nicht viel Sinn, zumindest ist es nicht intuitiv.

Pflanzen, düngen, wässern klappt damit auch im Kasten und Kübel. Die Pflanzen wachsen, man kann die Früchte ernten und ggf. neues einpflanzen.

Ok das ist interessant MaVerick[LAS] an sowas habe ich noch nicht gedacht Heißt das kann ich auch nicht behandeln? Muss ich mich mal informieren. Danke für den Hinweis!

Das mit der Temperatur ist mir klar^^ Im LKW wird mir komischerweise auch nicht kalt. Aber ich kann es heute Abend nur nochmal versuchen. Genug Vorräte haben wir ja mittlerweile gesammelt.

Thx ErnaVII.

Heißt ich habe am Ende nur das Problem, dass sich mein Leben nicht mehr vollständig aufladen kann. Zumal ich es auf Namalsk noch nicht geschafft habe, Wasser und Nahrung voll zu bekommen. Muss ich mal bis zum Erbrechen versuchen

Hansdieter wie gesagt, dass Leben füllt sich auch nicht mehr vollständig auf, es bleibt bei der Hälfte stehen. Ansonsten mache ich alles mögliche um nicht erneut krank zu werden. Alles erwärmen, desinfizieren, vor allem eine Vitamintablette und ständig unter Antibiotika.