Beiträge von commy2

ACE3/XEH_postInit.sqf at master · acemod/ACE3 · GitHub

Es wird dazu benutzt, um setCaptive auf remote Maschinen auszuführen.

!captive _x

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

Glaub ich dir nicht. Du täuscht dich da.

Nein, dass ist Käse. Da war ein anderer Fehler. Sonst hätte der Trigger auch vor dem Update schon nicht ausgelöst

startEngine in der Subklasse von Turrets.

Init-Skript auf die Klasse und setLoadout. Dann muss man keine Konfig schreiben und die Waffensounds gehen nicht kaputt.

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?

> respawnDialog=true;

> disabledAI=true;

Die werden vom Kompiler zu Zeichenketten "true" verarbeitet und vom Spiel dann als 0 (also Falsch) interpretiert. Die implizite Ersetzung von false und true zu Arma 0 und 1 Floats gibts nur in Mikeros Tools (und macht dabei viel kaputt).

Schon mal probiert ... etwas anderes anzuklicken ???

Das geht nicht. Das sieht immer so aus. Wenn dir die VR nicht zusagt, dann spiele eine andere Mission.

?

Es gibt kein Problem. Das soll so aussehen. Wirklich.

Nekro und Doppelpost: Grafik im Spiel lädt nicht

Geiler Einstieg.

Das soll so aussehen. Ist die VR.

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".

Aber warum? enableSimulation ist doch bereits perfekt, um den Trigger gezielt zu de(re)aktivieren. Das wurde doch in A3 extra so geändert, dass Trigger nur mit laufender Simulation ihre Bedingung abfragen.

Angenommen:

_wp1 addWaypoint [<?>, 0];

ist Teil der Trigger On-Activation-Codebox. Dann kannst du die magische lokale Variable `thisList` benutzen: