"playable object" variable auslesen *Gelöst*

  • Servus Leute, ich arbeite gegenwärtig an einen "Script" welches einen Patrouillen Hubschrauber ermöglichen soll, Spieler mit hilfe eines Triggers zu finden.

    Der Trigger ist per "attachTo" am Hubschrauber gebunden. Momentan ist der Trigger auf if:"BluforPresent" gestellt. (natürlich ginge auch AnyPlayer, aber darauf komme ich gleich zu sprechen)

    Soweit klappt alles wie gewollt.

    Mein Problem ist, das es dem Missions Lead freigestellt ist, wie er seine 12 man in drei Gruppen aufteilt um drei Missionsziele gleichzeitig "auszuschalten".

    Also muss mein Trigger genau auf den Spieler auslösen und Reagieren der in den Trigger gerät.

    "

    Damit ein anderer Hubschrauber per "_wp1 addWaypoint [position VARRIABLE-VON-SPIELER-DER-IM-TRIGGER-IST,0]" in die richtige Richtung geschickt wird.

    Natürlich könnte ich jetzt 12 Trigger an den Hubschrauber hängen, jeden zugeschnitten auf jeden anwesenden Spieler @.@, aber das muss doch eleganter funktionieren.

  • Angenommen:


    _wp1 addWaypoint [<?>, 0];


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

    Code
    1. private _target = selectRandom thisList;
    2. _wp1 addWaypoint [_target, 0];
  • WoW, Danke!

    Das war, "einfacher" als gedacht.



    EDIT:

    Nur damit ich es auch verstehe, die Variable _target funktioniert dann nur in diesen Trigger? Danach wird sie quasi gelöscht und steht wieder frei zur verwendung?

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

  • "lost" trifft zu, ich hab mit Programmieren und PC eigentlich überhaupt nix am Hut, in unserer Gruppe hat es sich halt irgendwann ergeben, dass ich Missionen Bauen darf/muss/soll. xD

    Ich werd, sobald ich Zeit finde, mal n paar Screenshots machen und Erklärungen dazu Formulieren.

    Dann hab ihr was zu lachen, wie Einfach & umständlich man so an sein Ziel gelangen kann.

    Auf jeden Fall schonmal danke für die Zeit und mühen.

  • Akahito

    Hat den Titel des Themas von „"playable object" variable auslesen“ zu „"playable object" variable auslesen *Gelöst*“ geändert.