Was ist denn das Problem an Dorbedos Skript?
Beiträge von commy2
-
-
_classname call CBA_fnc_getItemConfig
Oder selbst implementieren. Ist relativ simpel: CBA_A3/fnc_getItemConfig.sqf at master · CBATeam/CBA_A3 · GitHub
-
Da braucht es das gesamte Logfile um darüber etwas sagen zu können. Der Schnipsel ist da nutzlos. Und als Screenshot nichtmal für eine schnelle >Google -Suche geeignet.
-
Grundsätzlich immer side group <unit> benutzen. Was zeigt das an?
-
> if (isNull _myVehicle && { alive (driver _myVehicle) }) then {
Also wenn _myVehicle das Nullobjekt ist, dann ist der Fahrer auch das Nullobjekt, und damit ist gibt "alive" immer falsch zurück. Das Beispiel ist nicht geeignet, da die Bedingung trivial falsch ist.
Zu findIf würde ich noch schreiben, dass man sie als Quantoren missbrauchen kann. Das finde ich hundert mal nützlicher als "finde den ersten Index".
Beispiele:
-
In welchem Rahmen soll das ganze sein? Sprich, ein Skript für eine Mission und alles ohne Mods, oder kann ich Zeugs wie CBA benutzen?
-
> Du sagtest selber oben schon, dass man das in der Form gar nicht als Script vernünftig hinbekommt.
Natürlich geht das, nur nicht als prozedurales Skript. Also müsste man, wenn man es richtig machen will, komplett bei Null anfangen.
-
Da können sich immernoch zwei auf den gleichen Stuhl setzen, wenn sie die Aktion gleichzeitig benutzen. Außerdem wird die JIP-Queue immer länger, je mehr Spieler sich setzen und wiederaufstehen.
-
> _unit attachTo [_chair];
nach der setPosX-Zeile
Dein ganzes Skript ist super kaputt im Multiplayer. Setz dich vier mal und steh drei mal wieder auf beim selben Stuhl. Dann lass einen zweiten Spieler verbinden. Der kann sich jetzt auf den bereits benutzten Stuhl setzen und sieht sogar mehrere Aktionsmenü-Einträge dafür. Außerdem können zwei Spieler sich auf den selben Stuhl setzen, wenn sie die Aktion zur gleichen Zeit auswählen.
Das ist auch alles nicht leicht behoben. Sowas kann man nicht richtig als prozedurales Skript mit remoteExec usw. schreiben.
-
> - Spieler kann sich drehen in der Animation (bekomme ich nicht weg mit meinem Kenntnisstand)
forceAim = 1; in der CfgMovesBasic-Unterklasse gibt die Mauskontrolle an den Kopf statt die Beine.
-
-
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).