(Server) Mod ersellen und testen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • (Server) Mod ersellen und testen

    Da ich feststellen musste, dass mit dem #include in normalen Mission eig nichts angefangenw erden kann, da man nicht auf parent directories verweisen kann, hab ich erfahren, dass es diese Limitation bei Mods/AddOns nicht gibt.

    Mein Poblem ist nur, dass ich keine Ahnung habe, wie man eine Mod schreiben muss... Was ich bisher raus gefunden habe ist folgendes:
    1. Die Mod muss in einen Modordner, der mit einem '@' beginnt (z.B. @MeineMod)
    2. Innerhalb dieses Ordners braucht man dann einen Unterordner names 'addons')
    3. In diesem Unterverzeichnis sind alle benötigten Dateien (als PBO?)


    Meine Frage ist nun, wie die benötigten Files in dem addons-Ordner eingebunden sein müssen und ob sie unbedingt als PBO gepackt sein müssen oder ob man sie während der Entwicklung auch "ganz normal" in den Ordner packen kann.
    Außerdem ist mir noch etwas schleierhaft, wie ich die entsprechenden Scripte zu gewünschten Zeitpunkten (z.B. zum Missionsstart) ausführen kann... Gibts da auch sowas wie ne cfgFunctions in der das geregelt ist?

    Und dann noch eine weitere Frage: Wie transferieren serverseitige Mods bestimmten Code zu den Clients?

    MFG Raven
    Entwickler von SQDev
  • Lies dir mal diesen Post im ACE3 Wiki durch. Dort wird gut erklärt welche Schritte nötig sind um eine Entwicklungsumgebung für einen Mod einzurichten.

    Wenn du filepatching nutzt kannst du die Skripte (leider keine Configs) auch nutzen ohne sie vorher zu einer PBO zu packen.
    Das Ausführen der Skripte kannst du genau wie bei einer Mission mit der cfgFunctions machen.

    101st Airborne Division
    airborne-division.de

    TaktiCool (ArmaAtWar, CLib, Streamator)
    github.com/TaktiCool
  • Raven schrieb:

    Da ich feststellen musste, dass mit dem #include in normalen Mission eig nichts angefangenw erden kann, da man nicht auf parent directories verweisen kann, hab ich erfahren, dass es diese Limitation bei Mods/AddOns nicht gibt.
    Naja, das geht schon. Du kannst immer in den höheren Ordner verweisen.
    Dadurch kannst du auch einen modularen Aufbau deiner Missionen erstellen. In der Art von der CBA-Struktur wie sie in ACE Anwendung findet. Man muss sich zwar durch jeden einzelnen Ordner durchhangeln, aber so schlimm finde ich das eigentlich nicht.
    Schaust du hier: Link
  • Der Unterordner "Keys" ist nicht zwingend notwendig. Er enthält lediglich eine *.BIKEY Datei, die von Serveradmins genutzt werden kann um die Nutzung von Client-Mods auf dem Server zu "erlauben". Da die Mod jedoch nur Serverseitig laufen soll ist kein Key notwendig.
    Die Unterverzeichnisse nach dem "\addons" müssen als *.pbo gepackt werden. Eine ArmA-Mod brauch in jeder *.pbo Datei eine "config.cpp" Datei, welche beim Initialisieren der Mod geladen wird. In der .pbo können auch Unterordner (wie in meinem Beispiel mit "scripts") erstellt werden.

    Beispiel:
    @MeineMod\addons\meinemod.pbo

    In der meinemod.pbo befindet sich ein "scripts" Unterordner und eine config.cpp
    In dem Unterordner kann sich zum Beispiel eine .hpp Datei befinden. (In meinem Fall eine "includes.hpp")

    Beispiel config.cpp:

    Quellcode

    1. #include "scripts\includes.hpp" //Inkludieren deiner .hpp Datei aus dem Unterordner "scripts"
    2. class CfgPatches
    3. {
    4. class MeinServerScript
    5. {
    6. units[] = { };
    7. weapons[] = { };
    8. requiredVersion = 0.108000;
    9. requiredAddons[] = { };
    10. };
    11. };
    Alles anzeigen
    In der Config.cpp kann selbstversändlich auch mit CfgFunctions gearbeitet werden.

    Korrigiert mich bitte, wenn ich falsch liege ;)

    MfG
    Fynn
  • Raven schrieb:

    Da ich feststellen musste, dass mit dem #include in normalen Mission eig nichts angefangenw erden kann, da man nicht auf parent directories verweisen kann, hab ich erfahren, dass es diese Limitation bei Mods/AddOns nicht gibt.
    Das funktioniert auch in Missionen einwandfrei (außer du meinst jetzt Ordner außerhalb deiner Mission) und habe ich schon öfters verwendet. Ich würde den include Befehl nochmal überprüfen.

    Für eine Mod brauchst du grundsätzlich eine config.cpp Datei die mindestens einen CfgPatches Eintrag hat. Der definiert den internen Namen der Mod, da sich der Dateiname ja ändern kann. Der Rest ist optional - eine CfgFunctions wirst du wahrscheinlich aber ebenfalls benötigen, je nach dem wie dein Mod aufgebaut ist. Die funktioniert eigentlich genau so wie in der Description.ext, welche wiederrum eine "light" Version der config.cpp ist (deswegen auch oft Missionconfig genannt). Die config.cpp kann/darf etwas mehr als die Description.ext.

    Wenn du deine Mod dann mit einem Tool deiner Wahl, etwa dem Addon Builder, Armake oder Mikeros Tools als PBO packst solltest du zusätzlich die config.cpp noch binarisieren (also in eine config.bin umwandeln), da dass die Ladezeit der PBO verkürzt. Oft kannst du das direkt mit dem entsprechenden Tool automatisch machen.

    NetFusion's Link ist etwas anspruchsvoller, aber wenn du damit arbeiten gelernt hast erleichtert es dir die Arbeit deutlich. Ich würde dir aber vorerst empfehlen klein anzufangen.

    Edit: da waren andere wohl schneller ¯\_(ツ)_/¯