Beiträge von commy2

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

    > Wenn ich das richtig sehen stimmen X und Z Achse aber die Y Asche ist um das Doppelte zu zu groß.


    Nein, das ist Unsinn. Du solltest außerdem beim Testen generell auch deine "und" und "oder" die Ausrichtung des Fahrzeugs variieren.

    Um die Model Space-Koordinaten aus den ASL/World-Koordinaten zu bekommen solltest du dir den worldToModel ASLToAGL-Befehl anschauen. _intersectPosASL ist in der Tat was du brauchst. Schau dir außerdem die vectorX-Befehle an, denn dieses viele _xyzPos und select 0,1,2 verursacht doch einfach nur Kopfschmerzen.

    LIS hat Parameter für die LODs, die durchsucht werden sollen. Da könnte man ansetzen, falls noch nicht geschehen. Ansonsten muss man bei diesen Dingen genau auf das Pos-Format achten.

    Und was hattest du nun benutzt? Statt gleich die Segel zu streichen könnte man noch mal darüber nachdenken. Ich hatte ja ursprünglich gefragt, wie das originale Skript überhaupt ausgeführt wurde. Aber anstatt ordentlich Fehleranalyse zu betreiben, hast du dich von Zumi's Lösung (?) ablenken lassen.

    Das sieht mir ziemlich falsch aus, Zumi. this impliziert, dass es in einer Init-box läuft, also bereits global. Warum dann remoteExec mit Target? Bevor hier Fehlerbehebung stattfindet, sollte man erst einmal diagnostizieren, was überhaupt falsch läuft. Sonst ist es alles ein Ratespiel und hilft auch dem nächsten nicht.

    Probier erst einmal, ob es dann geht. Jedes andere Skript kann deinen RE-Block überschreiben, indem es die gleiche NetId (oder hier Objekt) als JIP-Ticket benutzt. Ich würde als JIP-Argument niemals etwas anderes als true oder eine eigene, einzigartige Zeichenkette benutzen. Ist einfach nicht sicher im Sinne von verlässlich.

    Ich denke das Objekt wird einfach nicht initialisiert, da es nicht XEH-kompatibel ist.


    Machste so:


    Allerdings überschreibt das für Fabi_DrugkitchenDeployed alle geereben Eventhandler von JD_Smelter. Da ich die Konfig und den Vererbungsbaum von JD_Smelter nicht kenne kann ich das aber nicht besser.

    Nochmal neu. Du hast einer Klasse eine Aktion gegeben. Diese wird aber an den Objekten nicht angezeigt. Wenn du dem Objekt dieser Klasse aber eine Aktion via Funktion hinzufügst, werden beide: die Konfig-Aktion und die Skript-Aktion angezeigt?