Wolkenbeisser

Hallo zusammen. Ich habe wieder einmal Lokalitätsprobleme (mein Lieblings Arma-Motivationskiller ). Bei einer meiner gehosteten Coop-MP-Missionen (OA ohne Addons, aktueller Patch) funktionieren zwei Dinge nicht:

1. Beamauslöser bei Missionsbeginn
Über dem Ort, wo ich die spielbaren Soldaten im Editor platziert habe, liegen Auslöser (für jeden der 6 Spieler einen) wie folgt:

---
Auslöser 10/10 (jeder, vorhanden, mehrfach)
BED: this and Spieler6 in thislist and vehicle player == Spieler6
AKT: Spieler6 moveInCargo Panzer1
---

Ziel ist es, dass nur diejenigen spielbaren Figuren in den Frachtraum des Panzer1 gebeamt werden, welche tatsächlich durch einen Spieler besetzt wurden. Die nicht verwendeten spielbaren Soldaten sollen im Lager stehen bleiben. Leider funktioniert das zu Beginn der Mission nur bei mir (Host). Alle anderen Teilnehmer (Clients) müssen respawnen, damit es klappt (wenigstens klappt es dann zuverlässig). Wie kann ich erreichen, dass der Auslöser auch bei Spielbeginn das tut, was er soll?


2. Fallschirmabsprung 6 Mann KI aus KI-Heli
Hier sollten 6 KI-Soldaten über dem Zielgebiet abspringen, sobald BLUFOR in einem bestimmten bereich ist. Der Auslöser dazu sieht so aus:

---
Auslöser 100/100 (BLUFOR, vorhanden, einmal)
BED: this
AKT: [N1, Nachschubheli] exec "para.sqs"
---

Ziel ist es, dass die 6 KI-Soldaten aus dem Heli abspringen. Leider vervielfacht Arma2 jedoch die Fallschirme. Bei zwei Teilnehmern (Host und Client) springen die sechs Soldaten plus sechs leere Fallschirme. Wie muss die Bed. Zeile angepasst werden, dass nur die sechs Fallschirme der KI-Soldaten erscheinen?

Ich vermute, man muss irgendwie ein "! isServer exit" verwenden oder so. Ich kann es mir aber einfach nicht zusammenreimen, wie die AKT Zeile genau heissen muss.

Ich wäre für jeden Tip dankbar.

Buliwyf

Das Beamen zu Mapbeginn würde ich in der Init.sqf durch den Server übernehmen lassen:

Zu 2:

btw... komm mal von diesem SQS-Schei** los...

__________________

Wolkenbeisser

Zitat von Buliwyf

Das Beamen zu Mapbeginn würde ich in der Init.sqf durch den Server übernehmen lassen:

Code:

if (isServer) then {
    {
        _x moveInCargo Panzer1;
    } forEach playableUnits;
};

Zu 2:

Code:

Bed.: this AND isServer

btw... komm mal von diesem SQS-Schei** los...

Danke für die Antwort Buliwyf

Dein Code zu meinem ersten Problem sieht aber für mich ein bisschen so aus, als würde jede spielbare Einheit beim Start in den Panzer gebeamt. Ich möchte aber eigentlich nur die von einem Spieler besetzten.

Beispiel:
Sechs Spielbare Figuren. Die Drei Spieler picken sich daraus z.B. den ersten (Host), den dritten (Client) und den sechsten (Client) aus der Liste zu Beginn. Bei Missionsbeginn sollten nun die "vehicle" Spieler1, Spieler3 und Spieler6 in den Panzer gebeamt werden, während Spieler2, Spieler4 und Spieler5 draussen stehen bleiben sollen. Wie kann man sowas lösen?

Buliwyf

Ups.. die Macht der Gewohnheit... ich spiele immer ohne KI in den eigenen Reihen...

__________________

Wolkenbeisser

Zitat von Buliwyf

Ups.. die Macht der Gewohnheit... ich spiele immer ohne KI in den eigenen Reihen...

Code:

if (isServer) then {
    {
        if (isPlayer _x AND alive _x) then {
            _x moveInCargo Panzer1;
        };
    } forEach playableUnits;
};

Danke Buliwyf .

Werde Deine Lösungen sobald wie möglich ausprobieren (hoffe, ich komme heute Abend dazu).

Grüsse aus der Schweiz

Vienna

Zitat von Wolkenbeisser

1. Beamauslöser bei Missionsbeginn
Über dem Ort, wo ich die spielbaren Soldaten im Editor platziert habe, liegen Auslöser (für jeden der 6 Spieler einen) wie folgt:

---
Auslöser 10/10 (jeder, vorhanden, mehrfach)
BED: this and Spieler6 in thislist and vehicle player == Spieler6
AKT: Spieler6 moveInCargo Panzer1
---

Ziel ist es, dass nur diejenigen spielbaren Figuren in den Frachtraum des Panzer1 gebeamt werden, welche tatsächlich durch einen Spieler besetzt wurden. Die nicht verwendeten spielbaren Soldaten sollen im Lager stehen bleiben. Leider funktioniert das zu Beginn der Mission nur bei mir (Host). Alle anderen Teilnehmer (Clients) müssen respawnen, damit es klappt (wenigstens klappt es dann zuverlässig). Wie kann ich erreichen, dass der Auslöser auch bei Spielbeginn das tut, was er soll?

Versuche einmal in die drei Zeitverzögerungsfelder im Auslöser überall eine 1 einzugeben. Das ändert die Reihenfolge der Routinen beim Starten des Spiels.

Falls die 1 nicht reicht, dann erhöhe alles auf 10. Nur zum Testen ob hier die Ursache des Fehlers liegt.

Wolkenbeisser

Hallo Vienna

Danke, das werde ich ausprobieren. Der Test heute Abend hat nämlich gezeigt, dass Buliwyf's Version nicht funktioniert hat.

Vielleicht liegts wirklich an der Zeit. Denn das läuft bei uns etwa so ab:

1. Der Host klickt aus der Lobby auf "spielen", worauf bei ihm die Karte erscheint und den anderen Spielern die Mission übermittelt wird.

2. Sobald alle Spieler die Mission haben (erkennbar am ausgefüllten blauen Viereckchen) lesen die Spieler die Ausgangslage und besprechen die erste Etappe des Auftrags.

3. Und erst jetzt (das kann mehrere Minuten dauern, bis hierhin) klickt der Host auf weiter und das Spiel "beginnt".

Dieses Vorgehen lässt bei mir immer noch einige Fragen offen:

Ab wann - in dem oben beschriebenen Ablauf - zünden z.B. die Auslöser, welche in der Bed. Zeile ein "true" stehen haben?

oder...

Sind KI-gesteuerte Einheiten während dem die Spieler den Text lesen schon unterwegs zu ihrem ersten Wegpunkt?

Ich habe mir schon überlegt, dass ich vielleicht per Funkbefehl die Spielbaren Figuren in den Panzer beamen soll. Dann könnte ich selbst wählen WANN das geschehen soll. Es wäre jedoch bedeutend schöner, wenn das automatisch funktionieren würde.

Ich probiere die Sache mit der Zeitverzögerung mal aus...

Buliwyf

Hm, wie haste das denn getestet? Lokal oder auf einem Dedicated Server? Die Variable playableUnits gibt es nämlich nur im Multiplayer. Wenn Du das also lokal getestet hast, dann wirds auch nicht gehen. Es sei denn Du setzt vorweg in der Init.sqf folgendes:

...dann kann man auch im Singleplayer/lokal mit playableUnits arbeiten...

__________________

Wolkenbeisser

Zitat von Buliwyf

Hm, wie haste das denn getestet? Lokal oder auf einem Dedicated Server? Die Variable playableUnits gibt es nämlich nur im Multiplayer. Wenn Du das also lokal getestet hast, dann wirds auch nicht gehen. Es sei denn Du setzt vorweg in der Init.sqf folgendes:

Code:

if (!isMultiplayer) then {
    playableUnits=switchableUnits;
};

...dann kann man auch im Singleplayer/lokal mit playableUnits arbeiten...

Ich habe ein Coop-Mulitiplayer Spiel gehostet (mit zwei meiner Kumpels). Dein Mechanismus hat zwar für mich (Host) funktioniert, für die anderen beiden aber nicht. Sie mussten 1 x respawnen um in den Panzer zu gelangen.

Buliwyf

Dann ist`s seltsam... ich verwende den Code nämlich in mehreren COOP_Maps um Spieler zu Mapbeginn in Schlauchboot zu verteilen undhabe noch keine Probleme damit gehabt... wenn ihr mit den letzten Beta-Patches spielt könnte das der Grund sein. BIS hat nämlich irgendwann irgendwas mit den Frames oder was auch immer geändert, sodass Scripte nicht richtig oder garnicht ausgeführt wurden. Soll aber meines Wissens mit der letzten Beta wieder gefixt sein...

Vielleicht hast Du den Code aber auch so in Deiner Init.sqf platziert, dass er ablauftechnisch nicht vor dem Briefing ausgeführt wird?! Könnte auch ein Grund sein...

Jedenfalls habe ich bislang kein Problem feststellen können...

__________________

Wolkenbeisser

Wir verwenden den aktuellen Patch (OA 1.59, soviel ich weiss). Meine init.sqf sieht so aus:

Interessanterweise funktioniert das mit dem Host. Die anderen Spieler jedoch müssen einen Respawn machen (danach klappts bei jedem weiteren Respawn problemlos).

Buliwyf

Tjoa.. ich poste mal das Grundgerüst meiner bevorzugten Standard-Init.sqf:

Das verwende ich so in der Form in jeder meiner COOP-Maps und hatte halt noch kein Problem damit, dass Einheiten anfangs nicht in Booten etc. gewesen wären. Wichtig ist, dass Du das Funktionsmodul auf der Karte platzierst... sonst klappt der Ablauf nicht.

__________________

Wolkenbeisser

Danke Buliwyf für Deine Init.sqf. Das sieht sehr viel versprechend aus.

Ich habe mir jedoch angewöhnt nur zu verwenden, was ich verstehe. Drum hätte ich da noch ein paar Fragen (sorry):

In deiner Init.sqf ist mir vieles klar, aber eben nicht alles (ich weiss, ich bin dahingehend noch ein blutiger Anfänger).

Was bewirkt dies?

und dies?

auch unklar wäre das hier:

bzw. zu guter Letzt das ominöse "mission_init" (wofür das nun wieder sein mag? ):

Und noch eine letzte Frage: Werden meine alten/bisherigen Missionen in irgendeiner Form beeinflusst, wenn ich nachträglich das Funktionsmanager Modul drauf setze (man bedenke, dass sie bisher auch ohne funktioniert haben)? Was für Vorteile bringt dieses Teil?

Ok, einiges könnte ich mir zusammengoogeln. Aber hier hätte ich alles gleich auf einen Schlag, quasi in dem von Dir erstellten Template. Das wäre natürlich Suuhuuppeeer .

Deshalb sorry für all die Fragen. Verweise mich ruhig auf Google, wenn Du sie nicht beantworten magst, dann suche ich mir die Puzzleteile zusammen.

Buliwyf

Also das Funktionsmodul beeinflusst Deine Scripte nicht. Im Funktionsmodul stecken nur von BIS vorgefertigte Scripte, die man bei Bedarf aufrufen kann. BIS liefert im Biki eine Anleitung, mit der Du Dir alle zur Verfügung gestellten Funktionen anschauen kannst: >> Link <<

Die Init.sqf habe ich mir aus den von BIS mitgelieferten Missionen kopiert, bzw. zusammengesetzt.
Hauptsächlich befasst sich das Grundgerüst damit, dass jeder Client und auch der Server das Funktionsmodul zunächst sauber lädt. Am Ende wartet jeder Client, bis er vom Server die Variable mission_init gesendet bekommt. Damit sollte sichergestellt sein, dass alle die Init.sqf sauber durchlaufen haben.

Die Zeilen:
...sind rein optional. War nur zu faul die rauszulöschen. Ich habe sie immer drin... erstere unterbindet das Gequassel (dieses Kommunikationsmodul) zwischen Spielern und KI. Und letzteres schaltet das Artilleriemodul in der Mission ab. Mit diesem Modul ist jeder Mörser und jede Artilleriekanone eine Hochpräzisionswaffe... das mag ich nicht und schalt es aus...

Achso.. anfangs war noch das waitUntil {!isNull player};. Die Init.sqf wartet halt darauf, das der Spieler bereit ist die Init.sqf auszuführen, damit ihm nichts verloren geht... so grob gesagt...

Ich hoffe da ist jetzt ein wenig Licht ins Dunkel gerückt?!

__________________

Xeno

*deleted*

Xeno

__________________
In arma everything is made of refined explodium, armored with wet paper towels.

Buliwyf

Der XENO nu wieder... Du magst ja recht haben mit dem was Du sagst, aber ich bin glücklich mit dem was funktioniert... und das tut es nunmal...

Nichts desto trotz nehme ich die isDedicated-Geschichte gern auf...

__________________

Wolkenbeisser

Ok, habe das mit "!isDedicated" von Xeno mitgekriegt und gleich in der Vorlage von Buliwyf geändert.

Ich hätte jetzt also Buliwyf's Vorlage in Zukunft als Template verwendet (wollte das heute Abend ausprobieren). Also standardmässig das hier verwenden (den Panzerbeam habe ich mal rausgenommen):

Nun machst Du mich aber usicher, Xeno. Wie müsste den die Init.sqf deiner Meinung nach Aussehen (also das Gegenstück von Buliwyf's *.sqf)?

P.S: Ich staune immer wieder, dass es da nicht Templates gibt, die sich seit langem bewährt haben, und die jeds Quäntchen Optimierung bereits in sich tragen. Ich bin doch sicher nicht der Einzige (nicht Programmierer), der sich mit der Init.sqf herumschlagen muss.

Vienna

Zitat von Wolkenbeisser

Wir verwenden den aktuellen Patch (OA 1.59, soviel ich weiss). Meine init.sqf sieht so aus:

Code:

// --- Mission briefing
[] execVM "Briefing.sqf";

// --- Spieler zu Beginn in Panzer1 beamen
if (isServer) then {
 {
  if (isPlayer _x AND alive _x) then {
   _x moveInCargo Panzer1;
  };
 } forEach playableUnits;
};

Interessanterweise funktioniert das mit dem Host. Die anderen Spieler jedoch müssen einen Respawn machen (danach klappts bei jedem weiteren Respawn problemlos).

Ich würde auch hier einmal versuchen der Spielinitialisierung bei allen Clients mehr Zeit zu geben.

z.B. dass der Server/Host nach seiner fertigen Initialisierung und einer kleinen Pause, durch eine globale Variable bei den Clients erst das Startzeichen gibt um die Initialisierung heikler Abläufe bei den Clients zu starten.

Damit diese Wartezeit nicht zu unschönen Verzögerungen führt, läßt man bei den Spielern einen "Vorspann" ablaufen.

Vielleicht reicht in deiner Init.sqf eine Verzögerung nach dem Briefing-Aufruf mit sleep einzufügen, um zu diesem frühen Zeitpunkt unwirksame Abläufe zu verhindern.

Ich habe den Eindruck, dass manche Skripte bereits während dem Briefing aufgerufen werden. Ein Skript wird aber durch eine Pause (egal wie lange diese ist) so lange gestoppt, bis das Spiel startet.

Wolkenbeisser

@Vienna. Das würde wahrscheinlich etwas ähnliches bewirken, wie Dein früherer Post (#6), oder? Ich werde zuerst mal das testen, und anschliessend - bei Misserfolg - einen "sleep 2;" vor dem Panzerbeam in der init.sqf einbauen.

Mal schauen, was dabei rauskommt. Wenn immer möglich bin ich für mein gutes altes Lieblingsmotto KISS... (--> Keep It Short and Simple)

Buliwyf

...während ich mich an das alt bewährte Motto "Never change a running system!" klammere...

__________________