Beiträge von commy2

    Das kann hier aber nicht der Fall sein, jokoho. Dann hätte das Entfernen des call das Problem ausgelöst, und nicht der Fakt, dass es nun sichtbar geworden ist.


    NSCT täuscht sich einfach. Das CBA-Update hat hier nichts kaputt gemacht. Nur weil jemand sagt, dass er es reproduzieren kann, ist es nicht reproduzierbar. So funktioniert es nun mal nicht.


    Und btw, dass jetzt lokale Variablen in der Init-Box nicht mehr funktionieren, ist für mich nicht Grund genug den Fix beizubehalten.


    Außerdem waren lokale Variablen nicht "ausversehen" durch CBA möglich. Siehe: Improve initbox by commy2 · Pull Request #612 · CBATeam/CBA_A3 · GitHub


    Ich zitiere mich selbst:

    optionally removes code validation which enables using local variables and return values

    Passiert, wenn nicht alle Klienten, das gleiche Modset haben. Das schließt auch den Server mit ein < da würde ich prüfen.


    > Die Waffen sind per Mod direkt an die Einheiten geben worden.


    Warum macht man denn so einen Käse?

    So eine CBA-Funktion gibt es nicht.


    Das sind Auszüge aus dem ACE-Quellcode für dieses Feature:

    Das Problem ist, dass du die Pfade auf P gelegt hast. Da sucht er die auch. Es müssen aber relative Pfade zum virtuellen Addons-Ordner sein. z.B.


    \bwa3_leopard2\bwa3_leopard2.p3d


    Ob nun mit oder ohne führendem Backslash hängt davon ab, wo dieser Pfad genau angegeben werden soll.

    Sowohl thisList als auch _target sind lokale Variablen. Lokale Variablen existieren nur in der Skriptinstanz in der sie definiert wurden.


    thisList ist eine magische Variable, d.h. sie wird vom Spiel automatisch "wie von Zauberhand" und nur für diesen Kontext erstellt. Andere Beispiele dafür sind this in der Init-Box oder _x bei Schleifen-Befehlen.


    Von dir definierte lokale Variablen müssen immer mit führendem _ geschrieben werden. Daran hält sich BI nicht immer, aber wenn du das führende _ weglässt, dann interpretiert das Spiel das stattdessen als globale Variable. Diese wäre in allen Skriptinstanzen verfügbar und hat damit den Nachteil, dass sie auch vorherige Werte überschreibt und damit besonders bei gleichzeitiger Ausführung vieler Skriptinstanzen zu unvorhergesehenem Verhalten der Skripte führt ("Namenskollisionen"). Bedenke außerdem, dass nicht nur deine Skripte existieren, sondern auch BI und die Mods die du verwendest Skripte benutzen.


    Globale Variablen sollten daher nie oder nur für Spezialanwendungen wie Funktionsnamen verwendet werden. Wenn globale Variablen verwendet werden, dann sollten sie immer mit "Tag" beginnen, um Kollisionen zu reduzieren. Bsp. für einen Tag: "CBA" in CBA_fnc_addKeybind.


    Wichtig ist, dass das Adjektiv "global" in globale Variable nichts mit den Multiplayer & Server/Client-Konzepten von "lokal", "remote" und "global" zu tun hat. Tatsächlich globale (im Sinne von "existiert auf allen Maschinen im Multiplayer") globale Variablen heißen "public globale Variablen", aber das ist ein anderes Thema.


    Das Keyword private sorgt dafür, dass die folgende lokale Variable nur im derzeitigen Scope der Skriptinstanz definiert wird. Das ist notwendig, um zu vermeiden, dass deine Variable freie Variablen mit gleichem Namen überschreibt. Bei Funktionen ist das essentiell, denn ansonsten haben diese immer den Nachteil, dass sie als Nebeneffekt bestimmte Variablen überschreiben. Freie Variablen sind solche, die aus höheren Scopes übernommen wurden und damit können das Variablen sein, die überhaupt nicht in deiner *.SQF-Datei auftauchen sondern in dem Skript, dass deine Funktion aufruft.


    Technisch spielt es zwar keine Rolle, wenn du in selbst erstellten und nur von dir verwendeten Skriptinstanzen das private weglässt, aber es ist eben ein Design-Defekt, der die Übertragbarkeit deines Skripts reduziert. Außerdem erhöht das private die Lesbarkeit deines Skripts, da es markiert wo Variablen eingeführt werden, was besonders in SQF hilfreich ist, da hier Variablen im Gegensatz zu vielen anderen Skript- und Programmiersprachen nicht deklariert werden können/müssen.


    Dir ist es natürlich freigestellt eine riesen Sauerrei anzustellen indem du globale Variablen benutzt und lokale Variablen ohne private einführst. SQF zwingt dich da nicht dich an Konventionen zu halten, sondern behandelt dich als Erwachsenen (oder verwahrlost seine Kinder - ansichtssache). Keine Ahnung ob du das alles wissen wolltest, aber du erschienst mir mit deiner letzten Frage ziemlich "lost".