------------------------------
FETT Loadouts Einleitung
------------------------------

Dieses configbasierte Loadoutsystem erlaubt es Missionsbauern schnell Loadouts zu erstellen und auf häufige Redundanzen zu verzichten.

------------------------------
Funktionsweise
------------------------------

Um mit diesen Loadouts umgehen zu können sollte man rudimentär mit Configs unter ArmA umgehen können. Wer das nicht kann, wirft besser einen schnellen Blick auf das COnfigtutorial am Ende dieser Datei.

Jedes Loadout spiegelt eine Klasse wieder und besteht aus vier Unterklassen:
1. Container - Enthält die Uniform, Weste und Rucksack
2. Gear - Hier wird gespeichert, was für Ausrüstung das Loadout beinhaltet, Dinge wie z.B. Helm, Karte, Fernglas, etc.
3. Weapons - Diese Klasse enthält die drei Unterklassen nämlich die primaryWeapon (Gewehr), die secondaryWeapon (z.B. Raketenwerfer) und die handGun (Pistole). Jeder dieser drei Klassen ist vom Typ der WeaponClass, mehr Erklärung dazu später.
4. Items - Diese Klasse speichert alle weiteren Items des Loadouts, Granaten, Medic Material und sonstiges.

Wie diese Klassen aufgebaut sind, kann in der CfgDefines gesehen werden. Die meisten Variablen sind vom Namen her selbsterklärend. Der Suffix "_pool" bedeutet, dass nicht der gesamte Inhalt des Arrays dem Soldaten gegeben wird, sondern eines der Elemente ausgewählt wird. Daher dürfen in diesen Arrays nur Strings enthalten sein, die Classnames der Items darstellen.
Alle weiteren Arrays werden dem Loadout komplett hinzugefügt und können folgendes enthalten: Entweder einen String, der den Classname eines Items direkt darstellt, oder ein Array nach der Struktur {"CLASSNAME",ANZAHL}, das vom gegebenen Typ CLASSNAME ANZAHL Items hinzufügt.

Ein besonderer Blick sollte aber auf den Aufbau der WeaponClass gelegt werden. Die Variable weapon_pool[] beinhaltet die Waffen, aus denen ausgewählt werden soll. Es ist nicht möglich Waffen verschiedener Kaliber einzubauen, bzw. man sollte es nicht tun, weil das Magazin ebenfalls definiert wird und dazu kein Pool zur Verfügung steht. Dieser weapon_pool[] dient eher dazu, z.B. verschiedene Waffenskins zufällig auswählen zu lassen.
Diese vier Pools wählen die Attachments für die Waffe aus: muzzleAttachment_pool[], weaponRestingAttachment_pool[], barrelAttachment_poo[] und der scope_pool[], dazu sollte keine weitere Erklärung notwendig sein.
magazine definiert das Magazin, magazineTracer das Tracer Magazin. magazinesMax definiert die maximale Anzahl an Magazinen inklusive Tracern. magazinesTracersEvery definiert das "Tracer-Intervall". Ist magazinesTracersEvery auf 3 gesetzt, bedeutet das, dass jedes dritte Magazin ein Tracer Magazin wird.
Es ist lediglich möglich eine Maximalanzahl von Magazinen anzugeben, weil das Loadout sich automatisch darum kümmern wird, die Anzahl an Magazinen auszugleichen. Dazu werden die Magazine für alle Waffen gleichmäßig verteilt. Sollte der Soldat also zu wenig Platz im Rucksack (oder sonstigen Containern) haben, dann wird er trotzdem alle Arten von Magazinen erhalten. Nur von allen anteilsmäßig weniger.

------------------------------
Aufbau eines Loadouts & Verwendung
------------------------------

Um ein Loadout zu erstellen, muss an nur alle Variablen entsprechend setzen.
Jeder Configeintrag, der in der CfgDefines.hpp gelistet ist, muss in jedem Loadout enthalten sein. Um sicherzugehen, dass jeder Eintrag enthalten ist, sollte immer mit Vererbungen gearbeitet werden.

Alle Loadouts, die verwendet werden sollen, müssen in der description.ext in der class CfgLoadouts {}; und als Unterklasse in der entsprechenden Fraktion enthalten sein.
Der Name der Fraktion wird durch den Namen der Unterklasse in der CfgLoadouts definiert.

------------------------------
Loadout anwenden
------------------------------

Um ein Loadout anzuwenden, muss man lediglich folgenden Funktionsaufruf verwenden:
["NAME DES LOADOUTS","NAME DER FRATKION",OBJEKT] call FETT_fnc_applyCfgLoadout;
Dabei stellt "NAME DES LOADOUTS" einen Eintrag in der CfgLoadouts dar. Wird er ausgelassen, wird der Classname des Objekts verwendet, dem das Loadout zugeteilt wird.
"NAME DER FRAKTION" die entsprechende Fraktion. Wird er ausgelassen, wird die Fraktion in den CfgVehicles des Objekts verwendet, dem das Loadout zugeteilt wird.
OBJEKT ist ein optionaler Parameter, der das Objekt darstellt, dem das Loadout hnizugefügt werden soll. Wird dieser Parameter weggelassen, wird player verwendet.

------------------------------
Kleines Cfg Tutorial
------------------------------

Configs sind nichts als Daten. Aber sie haben ein paar Vorteile, die den Aufbau und die Strukturierung dieser Daten erheblich vereinfachen.

Es gibt zwei Arten von Datentypen: Klassen und Elementardaten.
Klassen werden folgendermaßen definiert:
class NAME {};
Eine Klasse enthält mehrere weitere Klassen oder andere Elementardaten, die ihr untergeordnet sind, sodass man mittels eines Pfades darauf zugreifen kann.
Elementardaten werden wiefolgt definiert:
NAME = DATEN;
Ein paar Unterschiede zu Datentypen in .sqf gibt es dennoch, denn Arrays müssen definiert werden. Will man Arrays darstellen, muss man dies darstellen indem man [] hinter den Namen des Arrays schreibt. Außerdem werden Arrays mit geschweiften Klammern umschlossen, hier ein kleines Beispiel:
ichBinEinArray[] = {1,2,3,"viertesElement"};

Ein wichtiger Teil von Configs ist die Vererbung. Eine andere Klasse kann von einer weiteren erbenund das sieht ungefähr so aus:

class ParentClass {
string = "abc";
number = 1;
array[] = {1, 2, 3};
};
class ChildClass : ParentClass {
number = 2;
};

Bei der Vererbung passiert folgendes: Die ChildClass "erbt" alle Inhalte der ParentClass. Sie werden einfach reinkopiert. Und ihr könnt sie überschreiben, indem ihr sie einfach neu schreibt. So könnt ihr komplexe Beziehungen aufbauen und somit Redundanzen vermeiden und den Code sicherer gestalten.

GitHub
(Zum Download unten rechts auf Download ZIP klicken)

[img]http://i.imgur.com/Dat8mUu.jpg[/img] is not a valid Image.

Ich weiß ja nicht, das System klingt sehr umfangreich, aber auch etwas nach overkill. Ich persönlich kenne und benutze folgendes System das ähnlich, aber deutlich einfacher arbeitet und auch einfacher zu benutzen ist:
https://github.co...g-loadout/
Es erlaubt den direkten Export aus dem Virtual Arsenal, arbeitet auch mit Configs und erlaubt Vererbung, Generalisierung, Spezialisierung uvm. Ich kann es nur empfehlen.

Dein System ist halt schön, weil es exportiert werden kann.
Aber was ich halt schön finde ist, dass man seine Waffen z.B. einzeln definieren kann.
Bei dir sind die Vererbungen nur unter den gesamten Loadouts möglich, richtig?

Ich weiß nicht genau was du jetzt meinst mit Waffen einzeln definieren? Meinst du mit Attachments usw.? Nein, das geht nicht wirklich. Eine Waffe mit Attachments zu definieren geht allerdings mit zwei Zeilen.

Vererbung sind nur über die gesamten Loadouts möglich, ja, macht aber wirklich keine Arbeit. Ich mache immer ein normales Loadout mit AllBlufor welches den Standard Rifleman darstellt. Die einzelnen Klassen erben dann davon, sind oft nur kleine Änderungen wie Waffe und Magazine. Ich kann heute abend mal ein kleines Beispiel posten, dann sieht man eher wie viel bzw. wenig Arbeit das ist.

Ne, musst du nicht, habe ich schon verstanden.
Aber ich kann einfach die Waffen einzeln definieren, d.h. ich sage einfach

Und jetzt kann ich jedem, der eine MX bekommen soll, einfach diese Waffe geben!

Ich weiß nicht, klar dein System ist ziemlich mächtig in dem Bereich, ob das wirklich nötig ist ist eine andere Sache - ich glaube ein komplettes Loadout für eine ganze Mission wird bei dir einfach sehr sehr groß (das meinte ich mit Overkill) da es extrem detailliert ist. Vielleicht wäre ein Skript das ein VA Loadout in dein Format umwandelt sinnvoll.

Abgesehen davon, vielleicht kann man irgendwie kennzeichnen welche Einträge einen Pool darstellen, aus dem zufällig gewählt wird und welche das komplette Array übernehmen? Vielleicht wenn der erste Eintrag "select all" ist oder so?

Das habe ich mir auch schon überlegt. Ich glaube, ich werde alle Arrays, aus denen ausgewählt wird mit dem Suffix _pool versehen.

Bumms, da ist der Release. Ein wenig überarbeitet und mit einer kompletten Erklärung!

Mein Vorschlag noch: Erweiterung um eine Fahrzeug-Sektion

Meiner Meinung nach nicht notwendig, weil Fahrzeuge nicht so dedizierten Kram brauchen. Das ist ja alles ein Container und eben ein paar Items. Die bekommen keine Uniformen, Westen, Waffen, etc.

FETT_CfgLoadouts auf v0.1.1 geupdatet!

Änderung:

• Bugfix, der Kram funktioniert wieder (da es aber eh keinem von euch aufgefallen ist, denke ich, dass es keiner benutzt hat - außer Hawk )

Schönes Ding!

FETT_CfgLoadouts auf v0.2.0 geupdatet!

Änderung:

• Bugfix, Pfade korrigiert
• Mehrere Loadouts hinzugefügt

FETT_CfgLoadouts auf v0.2.1 geupdatet!

Änderung:

• Loadout hinzugefügt

FETT_CfgLoadouts auf v0.2.2 geupdatet!

Änderung:

• Loadout hinzugefügt (jetzt aber wirklich)

Vorschlag für dein Script: Auch auf Github verfügbar machen :>

Man kann im Repo suchen, usw. ^^

......Beziehungen aufbauen und somit Redundanzen vermeiden und den Code sicherer gestalten.

Download<-----

@Omniman:

Dropbox != Github

Downloadlink zu GitHub geändert.