Markiere alle Trigger in init.sqf

Lehmann · 15. März 2015

Hallo,
mein Ziel:
Ich habe eine Menge Trigger auf der Map. Diese sollen alle eigene Marker an derselben (ihrer) Position haben, damit ich Einheiten zu diesen triggern schicken kann, sie auf der Karte markiert sind, und weil ich sie noch für andere Scripts brauche.

genauer kann ich es auch nicht beschreiben, da ich ja selber noch am experimentieren bin, was denn vom Missionsaufbau funktionieren kann, und was nicht.

Das Problem:
Ich möchte die Marker in der init.sqf generieren, weiß aber nicht, wie ich die Positionen der Trigger erreichen kann. (Ich habe in der nähe jedes Triggers auch eine Gruppe der AAF Fraktion, falls das hilft)

[edit]
für alle, die eine Antwort suchen:

_alleMeineTriggerlein = allMissionObjects "EmptyDetector"

von T-800a passt wohl am besten. Anschließend muss auf den Positionen der Objekte dann auch ein createMarker und verschiedene setMarkerType, setMarkerText usw. folgen. Der Rest des Threads weitet sich dann etwas über das Thema hinweg aus.

X39 · 16. März 2015

ums kurz zu sagen ...
der post ist komplettes wirrwarr ...

hast du die trigger im missions editor oder in der init.sqf erstellt?
was meinst du mit "die Positionen der Trigger erreichen"?

bitte kläre doch was du genau vor hast und schildere anschließend deine aktuelle lage (die mission irgend wo hoch zu laden könnte auch noch hilfreich sein am rande kurz erwähnt)

Lehmann · 16. März 2015

ok, ich versuche es nochmal:

Ich habe eine Funktion wie getAllMarkers oder allGroups für Trigger gesucht, also sowas wie getAllTriggers, aber im wiki kann ich sowas nicht finden und in der Funktionsdatenbank von BI auch nicht.
Ich habe sie im Editor erstellt als Teil eines sector-moduls. Jetzt möchte ich gespawnte Einheiten in diese Trigger schicken, aber selber in einem Skript kontrollieren, welche der Sektoren angesteuert werden sollen. Um diese "manuelle" Steuerung der Einheiten einfacher zu gestalten, wollte ich mir ein globales Array "OUTPOSTS" erstellen, wo die Sektoren und jede Menge Metadaten gespeichert und ansprechbar sind. Unter anderem wird dann z.B. ein Netz (graph) aus den Sektoren erstellt, sodass jeder Sektor mit anderen Sektoren verbunden ist.

Zitat

was meinst du mit "die Positionen der Trigger erreichen"?

Wenn ich in einem anderen Script z.B. eine Einheit zu diesem Trigger schicken will, muss ich ja zuerst wissen, wie ich den trigger ansprechen soll

Mir ist es persönlich lieber, wenn ich alle für mich wichtigen Sektordaten im Array OUTPOSTS selber verwalten kann, weil es schon ziemlich auf den Wecker geht, wenn man eine Funktion braucht, und diese nicht im Wiki bei scripting commands findet. (wie getAllTriggers oder TriggersFromSector "airbase").

T-800a · 16. März 2015

PHP

_alleMeineTriggerlein = allMissionObjects "EmptyDetector";

so kannst du dir schonmal alle trigger in der mission auslesen!

Lehmann · 16. März 2015

Zitat von T-800a

PHP

_alleMeineTriggerlein = allMissionObjects "EmptyDetector";

so kannst du dir schonmal alle trigger in der mission auslesen!

also das hört sich schon mal recht gut an. Vielen Dank, Ich werde es dann später ausprobieren.

Woher weißt du, dass ein Trigger ein EmptyDetector ist? Gibt es neben dem Wiki und den Configs noch andere Archive, in denen man Typdefinitionen nachschlagen kann? In keinem der beiden konnte ich einen Eintrag für Trigger oder EmptyDetector sehen.

T-800a · 16. März 2015

die info gibts hier beim script befehl zum erstellen von einem trigger (example 1): https://community.bistudio.com/wiki/createTrigger

und die seite hier lohnt sich auf jeden fall auch zu verfolgen: http://www.killzonekid.com/ den ein oder anderen kniff kann man sich da mitnehmen!

Lord-MDB · 16. März 2015

Ich habe noch Probleme den Sinn dahinter zu verstehen.
Was soll den damit bezweckt werden ?
Willst du einheiten zu einem Punktschicken könnte wo ein Trigger ist?

Lehmann · 17. März 2015

Zitat

Was soll den damit bezweckt werden ?

Ich weis noch nicht, Wie ich meinen Programmablauf organisieren will. Daran experimentiere ich gerade.

Kurzfassung:
- Ich hab "die Städte" der Map als einnehmbare Positionen
- Die Armeen sollen selbstständig von Stadt zu Stadt, und diese einnehmen
- ich will ein Array, was alle diese Positionen in meinem eigenen Format speichert, damit ich leicht zur Laufzeit Änderungen vornehmen kann
- Außerdem brauche ich so viele Elemente auf der Karte, dass ich anstatt Sie in der init.sqf zu erstellen, Platzhalter im Editor setzen möchte, die ich dann nur in einer Schleife umwandeln muss.

Lange version:
Ich möchte ein einfaches script erstellen, das KI-Einheiten nach eingestellten Regeln an die Front schickt. Dazu möchte ich zum Teil aus Performance gründen, zum Teil aus dem Wunsch heraus, das von BI errichtete Chaos der Prozeduralen Scriptsprache zu umgehen, meine benötigten Daten selber verwalten (etwas objektorientierter halt). Ein globales Array, aus dem ich informationen aller Schlüsselpunkte der Map lesen kann. Dieses muss am Anfang der Mission initialisiert werden.

Die ungefähre Struktur des Arrays (und der benötigten Strukturen "Outpost", "BattlePosition" und "Connection"):

Spoiler anzeigen

Code

Array BattlePosition {
Position position
Group group // wer ist da stationiert
Int type // Besteht aus bitflags für attackInf|defendInf|attackTank|defendTank|attackAA|defendAA damit ein script ermitteln kann, wozu diese Position verwendet werden kann. Damit sich die Panzer nicht zu dumm anstellen und die infanterie eine Stadt in die richtige Richtung verteidigt.
}
Array Outpost {
Side controlledBy
Position position
GuardsPosition positions[] // Eine Sammlung von Verteidigungspositionen, um mögliche Probleme mit Panzern in der Stadt zu umgehen, oder damit die einheiten besser positioniert werden können, anstatt nur in der mitte der "Outposts" zu gammeln
Marker mrk // ein marker, den man dann auf der karte anklicken kann, um Einstellungen an diesem Posten vorzunehmen
Connection connected[]
String name
Int ID
Group stationedGroups[]
Integer basecosts // Wie Teuer ist eine Aufwertung zur Basis
Boolean isBase
Array AIData{ // sollte einige grobe Daten haben, die von einem gegnerischen AI Piloten schneller verwendet werden können ohne die Performance zu sehr zu belasten
Int averageAmmo
Int supportBottleNeckID // wo ist die Versorgung bedroht. Beinhaltet die ID des wichtigsten outpost um die Aufmunitionierung nicht zu verlieren.
Float AverageStrength // Wie stark ist der Posten gesichert
Int supportBottleNeckValue // Wie wichtig ist dieser Outpost für die Seite.
}
}
Array Connection { // um
Outpost fromID // Die ID der Außenposten, welcher truppen schickt und ...
Outpost toID // wo die truppen hingehen
String type // Attack, Move, Close
}
Array OUTPOSTS {
outpost outposts[]
Int supportBottleNeckID // wo ist die Versorgung bedroht. Beinhaltet die ID des wichtigsten outpost um die Aufmunitionierung nicht zu verlieren.
}

Alles anzeigen

Das Problem ist jetzt erstmal, diese Struktur auch in Arma umzusetzen und so zu gestalten, dass man es leicht im editor anpassen kann, z.B. kann ich ja bestimmte Einheiten infanterie-einheiten nutzen, um durch ihre Gruppe eine Battleposition zu definieren. Eine Schütze wird dann zu einer "attackInf BattlePosition", eine AAInf/Schützenpanzer Gruppe wird zu einer "attackTank|defendAA Position" usw. nachdem diese Einheiten dann von der Init umgewandelt wurden, werden sie gelöscht, und das Match beginnt.
Um den Spielmodus zu verstehen, hier mal mein Spielkonzept:

Spoiler anzeigen

Kein Realismus! Ein sehr "casual" Modus, der für Spieler gedacht ist, die einfach mal schnell in einen Jet springen und paar Ziele abschießen wollen. Aber durch ein Strategisches Element und ein größeres Ziel den Spielspaß erhöhen.
Jetzt kann man natürlich sagen: Aber der Jet ist in Arma ein veraltetes feature!
Ich weiß, aber in Future Cop LAPD hatte die eigene Figur gerade mal 3 Waffen, und noch nicht einmal manuelles Zielen. Ich hab's trotzdem gesuchtet. Es geht um andere Faktoren auf die ich mich konzentriere. Der Spielmodus bietet sehr abwechslungsreiche Szenarien
- man kann die feindliche KI dazu bringen, all ihre AA Munition in einem Gebiet zu verschießen,
- man kann wild einen outpost Bombardieren, wenn einen die Verteidiger schon zu sehr frustriert haben,
- der Strategische Aspekt (Umstellen der Verbindungen auf der Karte (kaufen von strategischen Schlüsselpositionen) erlaubt das Abschneiden der Verstärkungen (für den 2. Bonus). Ihr wisst ja, wie schnell der Inf die Raketen ausgehen können.
- man kann generierte tasks verwenden, um gezielt Einheiten auszuschalten
- das Verwalten der Bodenstreitkräfte ist so leicht, dass man es auch als Pilot im Flug verwalten kann.
Was mir noch fehlt ist ein Ersatz für die Mechanik des Zeitmanagements. Wie ihr im Video oben vielleicht gesehen habt, war es wichtig in FC-LAPD eine übersicht zu haben, wann wo die neutralen Türme spawnen, damit man sie erobern kann. Das war einer der wichtigen Faktoren, der weniger auf Glück basierte, sondern den Spieler nach seinen Fähigkeiten belohnt hat.

Zitat

Willst du Einheiten zu einem Punktschicken könnte wo ein Trigger ist?

Ja, und es wundert mich sehr, dass es dafür keine klare Funktion gibt.
Um das Spiel zu optimieren, ist es für mich wichtig, sehr schnell und einfach Änderungen an den positionen und Verbindungen der outposts machen zu können. Deswegen experimentiere ich derzeit ja noch mit verschiedenen Möglichkeiten, solche outposts auf die Karte zu setzen. Ich habe versucht, Multiplayer Sektoren zu verwenden, aber diese sind mir allmählich etwas zu nervig geworden, weil ich eben keine Möglichkeit sah, den frisch gespawnten Einheiten einen Wegpunkt in die Trigger zu setzen, ohne immer zu riskieren, dass sich die Panzer in den Häusern festfahren, oder ArmA mir sonst wieder irgendwie den Stinkefinger zeigt.
Vieleicht werde ich als nächstes versuchen, ein eigenes Modul dafür zu entwickeln. Das Projekt ist zwar schon jetzt ca. 163 mal umfangreicher geworden, als geplant, aber was soll's.

Das größte Hindernis sind für mich die Datentypen in arma. Manchmal wird Ding_1 durch ein string, manchmal ein pointer, manchmal ein Symbol angesprochen und ich blick da immer noch nicht durch.
Dann noch diese seltsame dokumentation ...
Hier wird ein Datentyp "Waypoint" genannt: https://community.bistudio.com/wiki/synchronizedTriggers
Wo finde ich informationen über diesen Typ und die Funktionen, die diesen verwenden? (So ist der ursprüngliche Titel "Was ist der Waypoint Typ" enstanden)

Ich denke, die Dokumentation ist das größte Problem für Einsteiger der Scriptsprache. Das wiki ist leider nicht das richtige Format für mich und ich bekomme das gefühl, den Server unnötig mit wikianfragen zu bombardieren, weil ich alles dreimal suchen muss.
Schön, dass BI die configs und funktionen in den editor zum anschauen gebracht hat, aber umso peinlicher, dass es keine richtigen Suchfunktionen in diesen Fenstern gibt ...

X39 · 17. März 2015

Zitat von Lehmann

Ich weis noch nicht, Wie ich meinen Programmablauf organisieren will. Daran experimentiere ich gerade.

Kurzfassung:
- Ich hab "die Städte" der Map als einnehmbare Positionen
- Die Armeen sollen selbstständig von Stadt zu Stadt, und diese einnehmen
- ich will ein Array, was alle diese Positionen in meinem eigenen Format speichert, damit ich leicht zur Laufzeit Änderungen vornehmen kann
- Außerdem brauche ich so viele Elemente auf der Karte, dass ich anstatt Sie in der init.sqf zu erstellen, Platzhalter im Editor setzen möchte, die ich dann nur in einer Schleife umwandeln muss.

Lange version:
Ich möchte ein einfaches script erstellen, das KI-Einheiten nach eingestellten Regeln an die Front schickt. Dazu möchte ich zum Teil aus Performance gründen, zum Teil aus dem Wunsch heraus, das von BI errichtete Chaos der Prozeduralen Scriptsprache zu umgehen, meine benötigten Daten selber verwalten (etwas objektorientierter halt). Ein globales Array, aus dem ich informationen aller Schlüsselpunkte der Map lesen kann. Dieses muss am Anfang der Mission initialisiert werden.

Die ungefähre Struktur des Arrays (und der benötigten Strukturen "Outpost", "BattlePosition" und "Connection"):

Spoiler anzeigen

Code

Array BattlePosition {

Position position

Group group // wer ist da stationiert

Int type // Besteht aus bitflags für attackInf|defendInf|attackTank|defendTank|attackAA|defendAA damit ein script ermitteln kann, wozu diese Position verwendet werden kann. Damit sich die Panzer nicht zu dumm anstellen und die infanterie eine Stadt in die richtige Richtung verteidigt.

}

Array Outpost {

Side controlledBy

Position position

GuardsPosition positions[] // Eine Sammlung von Verteidigungspositionen, um mögliche Probleme mit Panzern in der Stadt zu umgehen, oder damit die einheiten besser positioniert werden können, anstatt nur in der mitte der "Outposts" zu gammeln

Marker mrk // ein marker, den man dann auf der karte anklicken kann, um Einstellungen an diesem Posten vorzunehmen

Connection connected[]

String name

Int ID

Group stationedGroups[]

Integer basecosts // Wie Teuer ist eine Aufwertung zur Basis

Boolean isBase

Array AIData{ // sollte einige grobe Daten haben, die von einem gegnerischen AI Piloten schneller verwendet werden können ohne die Performance zu sehr zu belasten

Int averageAmmo

Int supportBottleNeckID // wo ist die Versorgung bedroht. Beinhaltet die ID des wichtigsten outpost um die Aufmunitionierung nicht zu verlieren.

Float AverageStrength // Wie stark ist der Posten gesichert

Int supportBottleNeckValue // Wie wichtig ist dieser Outpost für die Seite.

}

}

Array Connection { // um

Outpost fromID // Die ID der Außenposten, welcher truppen schickt und ...

Outpost toID // wo die truppen hingehen

String type // Attack, Move, Close

}

Array OUTPOSTS {

outpost outposts[]

Int supportBottleNeckID // wo ist die Versorgung bedroht. Beinhaltet die ID des wichtigsten outpost um die Aufmunitionierung nicht zu verlieren.

}

Alles anzeigen

Das Problem ist jetzt erstmal, diese Struktur auch in Arma umzusetzen und so zu gestalten, dass man es leicht im editor anpassen kann, z.B. kann ich ja bestimmte Einheiten infanterie-einheiten nutzen, um durch ihre Gruppe eine Battleposition zu definieren. Eine Schütze wird dann zu einer "attackInf BattlePosition", eine AAInf/Schützenpanzer Gruppe wird zu einer "attackTank|defendAA Position" usw. nachdem diese Einheiten dann von der Init umgewandelt wurden, werden sie gelöscht, und das Match beginnt.
Um den Spielmodus zu verstehen, hier mal mein Spielkonzept:

Spoiler anzeigen

Am Ende soll es ein Spiel-Modus für 1,2 oder vieleicht auch 3 Piloten sein, die gegeneinander antreten. Ich denke, man könnte es etwa mit dem "Kampf ums Revier" von "Future Cop LAPD" vergleichen:
https://youtu.be/dGnXhEV6SYk?t=1m49s
Der Spieler ist nicht selber derjenige, der den Sieg auslöst, sondern er soll durch die Luftunterstützung dafür sorgen, dass die KI am Boden die gegnerische Basis erobert.

Die Map hat mehrere "Outposts", die eingenommen werden können. Jeder Outpost ist mit mindestens einem anderen verbunden. Verbindungen sind gerichtet und haben verschiedene Status (Attack, Move, Close), um die Truppenbewegungen zu steuern. Wenn die Verbindung auf close gesetzt ist, werden keine Einheiten mehr diese Route benutzen.

In regelmäßigen Abständen spawnen dann verschiedene AI Gruppen in der Basis, und machen sich auf den Weg zu den mit der Basis verbundenen outposts.
Die variation der Einheiten ist sehr beschränkt. Es gibt nur 4 Gruppen
- Panzer,
- AA Fahrzeuge (nur mit Raketen ohne Kanone),
- AA / AT inf (kann outposts einnehmen und erstellt zufällige CAS Aufträge in anliegenden feindlichen outposts)
plus eine Bonusgruppe, die vom Spieler gekauft werden kann (Kampfkolossartig von Future Cop)

es gibt verschiedene Boni, die jeder Pilot (natürlich mit Kosten verbunden) einsetzen kann.
1. man kann zusätzliche Verstärkung (Kampfkoloss von oben) kaufen, um einen "lokalen Großangriff" zu starten.
2. Man kann seine Truppen aufmunitionieren. Wenn eingesetzt, haben alle eigene Truppen, die sich in einem von der Basis durch Verbindungen erreichbaren Knoten befinden wieder volle Munition.
3. Man kann einen eigenen mit der Basis verbundenen Outpost zur Basis aufrüsten. Diese spawnt dann ebenso wie die erste Basis eigene neue Einheiten, aber in zeitlich größeren Abständen.

Kein Realismus! Ein sehr "casual" Modus, der für Spieler gedacht ist, die einfach mal schnell in einen Jet springen und paar Ziele abschießen wollen. Aber durch ein Strategisches Element und ein größeres Ziel den Spielspaß erhöhen.
Jetzt kann man natürlich sagen: Aber der Jet ist in Arma ein veraltetes feature!
Ich weiß, aber in Future Cop LAPD hatte die eigene Figur gerade mal 3 Waffen, und noch nicht einmal manuelles Zielen. Ich hab's trotzdem gesuchtet. Es geht um andere Faktoren auf die ich mich konzentriere. Der Spielmodus bietet sehr abwechslungsreiche Szenarien
- man kann die feindliche KI dazu bringen, all ihre AA Munition in einem Gebiet zu verschießen,
- man kann wild einen outpost Bombardieren, wenn einen die Verteidiger schon zu sehr frustriert haben,
- der Strategische Aspekt (Umstellen der Verbindungen auf der Karte (kaufen von strategischen Schlüsselpositionen) erlaubt das Abschneiden der Verstärkungen (für den 2. Bonus). Ihr wisst ja, wie schnell der Inf die Raketen ausgehen können.
- man kann generierte tasks verwenden, um gezielt Einheiten auszuschalten
- das Verwalten der Bodenstreitkräfte ist so leicht, dass man es auch als Pilot im Flug verwalten kann.
Was mir noch fehlt ist ein Ersatz für die Mechanik des Zeitmanagements. Wie ihr im Video oben vielleicht gesehen habt, war es wichtig in FC-LAPD eine übersicht zu haben, wann wo die neutralen Türme spawnen, damit man sie erobern kann. Das war

Ja, und es wundert mich sehr, dass es dafür keine klare Funktion gibt.
Um das Spiel zu optimieren, ist es für mich wichtig, sehr schnell und einfach Änderungen an den positionen und Verbindungen der outposts machen zu können. Deswegen experimentiere ich derzeit ja noch mit verschiedenen Möglichkeiten, solche outposts auf die Karte zu setzen. Ich habe versucht, Multiplayer Sektoren zu verwenden, aber diese sind mir allmählich etwas zu nervig geworden, weil ich eben keine Möglichkeit sah, den frisch gespawnten Einheiten einen Wegpunkt in die Trigger zu setzen, ohne immer zu riskieren, dass sich die Panzer in den Häusern festfahren, oder ArmA mir sonst wieder irgendwie den Stinkefinger zeigt.
Vieleicht werde ich als nächstes versuchen, ein eigenes Modul dafür zu entwickeln. Das Projekt ist zwar schon jetzt ca. 163 mal umfangreicher geworden, als geplant, aber was soll's.

Das größte Hindernis sind für mich die Datentypen in arma. Manchmal wird Ding_1 durch ein string, manchmal ein pointer, manchmal ein Symbol angesprochen und ich blick da immer noch nicht durch.
Dann noch diese seltsame dokumentation ...
Hier wird ein Datentyp "Waypoint" genannt: https://community.bistudio.com/wiki/synchronizedTriggers
Wo finde ich informationen über diesen Typ und die Funktionen, die diesen verwenden? (So ist der ursprüngliche Titel "Was ist der Waypoint Typ" enstanden)

Ich denke, die Dokumentation ist das größte Problem für Einsteiger der Scriptsprache. Das wiki ist leider nicht das richtige Format für mich und ich bekomme das gefühl, den Server unnötig mit wikianfragen zu bombardieren, weil ich alles dreimal suchen muss.
Schön, dass BI die configs und funktionen in den editor zum anschauen gebracht hat, aber umso peinlicher, dass es keine richtigen Suchfunktionen in diesen Fenstern gibt ...

Alles anzeigen

Fehler 1: NIEMALS trigger verwenden für irgend etwas!
Fehler 2: Es gibt funktionen um gruppen zu einem punkt sich bewegen zu lassen, mithilfe von wegpunkten
Fehler 3: In ArmA ist vieles eigenartig ... die datentypen sind jedoch eines der wenigen dinge die nicht eigenartig sind ... die dokumentation wiederum ... ja ... die ist wirklich eigenartig (um herraus zu finden was für ein datentyp du hast kannst du typeName nutzen). Die datentypen die es gibt und mal geben soll(te) kannst du hier einsehen: https://community.bistudio.com/wiki/Category:Data_Types
Fehler 4: Du nimmst an das die BIS funktionen dir sonderlich weiter helfen, das tun sie nur in sehr speziellen fällen also vergiss sie lieber
Fehler 5: Du hast ein viel zu großes projekt für deine skripting kenntnisse dir vorgenommen
Fehler 6: Du versuchst objekte in ArmA zu realisieren (ist im grunde zwar möglich ... jedoch nur mit erheblichen umständen leider)

und nur noch erwähnt ... ich hab noch immer keinen dunst wofür du die trigger brauchst

Psychobastard · 17. März 2015

Ich glaub weil er so die Städte als Orte definieren will.
Das Stadtzentrum (also ein Position, mehr braucht er ja nicht) kann man aus der Config lesen. Das habe ich natürlich leider nicht im Kopf. Also Google oder z.B. in die Domi schauen, da wird das auch so gemacht.

T-800a · 17. März 2015

PHP

_locations = nearestLocations [ getPos player, [ 'NameCityCapital', 'NameCity', 'NameVillage' ], 2000 ];
_locations = nearestLocations [ getArray (configFile >> 'CfgWorlds' >> worldName >> 'centerPosition'), [ 'NameCityCapital', 'NameCity', 'NameVillage', 'Airport'], 25000 ];

das hier Psychobastard?

https://community.bistudio.com/wiki/nearestLocations

Lehmann · 18. März 2015

Zitat

Fehler 1: NIEMALS trigger verwenden für irgend etwas!

Warum nicht?

Zitat

Fehler 2: Es gibt funktionen um gruppen zu einem punkt sich bewegen zu lassen, mithilfe von wegpunkten

na toll, das hätte ich jetzt nicht gedacht
Ich benutze derzeit "BIS_fnc_taskPatrol", würde ich aber natürlich manuell machen, wenn das mit den Battlepositions implementiert ist.

Zitat

Fehler 3: In ArmA ist vieles eigenartig ... die datentypen sind jedoch eines der wenigen dinge die nicht eigenartig sind ... die dokumentation wiederum ... ja ... die ist wirklich eigenartig (um herraus zu finden was für ein datentyp du hast kannst du typeName nutzen). Die datentypen die es gibt und mal geben soll(te) kannst du hier einsehen: https://community.bistudio.com/wiki/Category:Data_Types

jaja, die Seite kenn ich. Ist ne schöne Seite, nur dass der "Waypoint" von dieser Seite oder dieser Seite nicht dabei ist ...

Zitat

Fehler 4: Du nimmst an das die BIS funktionen dir sonderlich weiter helfen, das tun sie nur in sehr speziellen fällen also vergiss sie lieber

Sie sind halt leicht erreichbar, und irgendwie in kategorien geordnet. Warum sollte man ihnen denn ausweichen?

Zitat

Fehler 5: Du hast ein viel zu großes projekt für deine skripting kenntnisse dir vorgenommen

Aus meiner Erfahrung heraus sind nicht die Kenntnisse der Sprache wichtig, sondern die Programmierkenntnisse allgemein. Ich hatte das ganze Projekt eigentlich vor, mal schnell übers wochenende zu machen. Ich war sicher, die Werte aller Instanzen ganz einfach ändern zu können. Also alles, was man mit einem Mausklick oder Tastendruck im editor machen kann, auch in der Scriptsprache möglich ist. Ich weiß, dass das Projekt jetzt ziemlich groß erscheint, aber eigentlich ist da nicht so viel drin.
Ich habe ja Programmierkenntnisse. Ich wusste nur nicht, dass mir ArmA so viele Steine in den weg legen wird. (noch ein Beispiel: Ich dachte mir, für einen zufälligen Task kann ich einfach eine IR Granate auf der Position einer zufälligen feindlichen Einheit spawnen nach dem Motto:

Code

spawnItem['IR_Grenade', position _someEnemyUnit] // höchstens noch die Granate einer Seite zuordnen, aber mehr nicht

Zitat

Fehler 6: Du versuchst objekte in ArmA zu realisieren (ist im Grunde zwar möglich ... jedoch nur mit erheblichen umständen leider)

Ich habe mir mal den OO bereich der BI Funktionen angesehen, aber dann gedacht, ich brauche ja nur paar einzelne Klassen ohne vererbung oder sonst einen schnickschnack. Das kann ich auch, indem ich Scripte wie Methoden in einem eigenen Ordner zusammenfüge und weil es nicht so viele Instanzen geben wird, mach ich die Membervariablen einfach Global: BLUFOR_OUTPOSTS und OPFOR_OUTPOSTS.
Zwei Arrays, in denen alle Wichtigen Infos gespeichert sind, kein Akt.

Zitat

und nur noch erwähnt ... ich hab noch immer keinen dunst wofür du die trigger brauchst

Ironisch?? Ich hab doch immer wieder gesagt, dass ich das Multiplayer Modul "Sector" verwendet hab. Und das braucht nun mal Trigger

Zitat

Ich habe versucht, Multiplayer Sektoren zu verwenden, aber diese sind mir allmählich etwas zu nervig geworden, weil ich eben keine Möglichkeit sah, den frisch gespawnten Einheiten einen Wegpunkt in die Trigger zu setzen

Zitat

Ich habe eine Funktion wie getAllMarkers oder allGroups für Trigger gesucht, also sowas wie getAllTriggers, aber im wiki kann ich sowas nicht finden und in der Funktionsdatenbank von BI auch nicht.
Ich habe sie im Editor erstellt als Teil eines sector-moduls.

Zitat

Mir ist es persönlich lieber, wenn ich alle für mich wichtigen Sektordaten im Array OUTPOSTS selber verwalten kann, weil es schon ziemlich auf den Wecker geht, wenn man eine Funktion braucht, und diese nicht im Wiki bei scripting commands findet. (wie getAllTriggers oder TriggersFromSector "airbase").

Also Das "Sector-Modul" verwendet Trigger z.B. als das Gebiet, in dem man die übermacht halten muss. Gibt es da eine andere Möglichkeit, die besser wäre? könnte man dann immernoch angeben, wie stark der "Eroberungswert" verschiedener einheitentypen sein soll?

Zitat

Also Google oder z.B. in die Domi schauen, da wird das auch so gemacht

Was ist denn die Domi? eine Domination mission?
Also Ich würde ungerne vorgefertigte Positionen von BI nehmen. Die Städte sind ja nicht sonderlich gleichmäßig verteilt. Da platziere ich mir lieber Entities im Editor, oder hab ich dich falsch verstanden?
Die Außenposten müssen keinen Sinn, sondern Spaß machen. wenn ich merke, "zwischen X und Y ist noch ein zu großer Abstand" dann ändere ich das einfach. Die "Städte" müssen also umziehen können. Deswegen habe ich auch den Begriff outpost vorgezogen. "Städte" war nur um nicht ins Detail gehen zu müssen.

X39 · 18. März 2015

Zitat von Lehmann

Warum nicht?

Trigger zerren extrem an der server performance und sind daher mehr als schlecht

Zitat von Lehmann

na toll, das hätte ich jetzt nicht gedacht
Ich benutze derzeit "BIS_fnc_taskPatrol", würde ich aber natürlich manuell machen, wenn das mit den Battlepositions implementiert ist.

https://community.bistudio.com…tegory:Scripting_Commands
selber machen
bringt weniger probleme und hat den vorteil das es dich für SQF "normalisiert" (oder versaut ... je nach dem wie man es sieht)

Zitat von Lehmann

jaja, die Seite kenn ich. Ist ne schöne Seite, nur dass der "Waypoint" von dieser Seite oder dieser Seite nicht dabei ist ...

Dann noch mal richtig gucken
waypoint1: Array - format Waypoint

Zitat von Lehmann

Sie sind halt leicht erreichbar, und irgendwie in kategorien geordnet. Warum sollte man ihnen denn ausweichen?

Sie lösen meist probleme mit einem extremen overhead oder sind schlicht weg nicht nützlich
viele probleme die sie lösen sind entweder trivial oder viel zu spezifisch
es gibt zwar einige gute ... jedoch ist der größte teil absoluter rotz gepaart mit bockmist

Zitat von Lehmann

Aus meiner Erfahrung heraus sind nicht die Kenntnisse der Sprache wichtig, sondern die Programmierkenntnisse allgemein. Ich hatte das ganze Projekt eigentlich vor, mal schnell übers wochenende zu machen. Ich war sicher, die Werte aller Instanzen ganz einfach ändern zu können. Also alles, was man mit einem Mausklick oder Tastendruck im editor machen kann, auch in der Scriptsprache möglich ist. Ich weiß, dass das Projekt jetzt ziemlich groß erscheint, aber eigentlich ist da nicht so viel drin.
Ich habe ja Programmierkenntnisse. Ich wusste nur nicht, dass mir ArmA so viele Steine in den weg legen wird. (noch ein Beispiel: Ich dachte mir, für einen zufälligen Task kann ich einfach eine IR Granate auf der Position einer zufälligen feindlichen Einheit spawnen nach dem Motto:

Code

spawnItem['IR_Grenade', position _someEnemyUnit] // höchstens noch die Granate einer Seite zuordnen, aber mehr nicht

die eigenheiten der sprache und die möglichen befehle sind sehr wohl wichtig!
SQF folgt keiner klassischen programmier sprache und gerade das macht es gefährlich

es nützt dir nichts wenn du programmieren kannst SQF jedoch nicht verstehst (und gerade mit programmier kenntnissen solltest du wissen das "mal schnell übers wochenende" nicht drin ist)

Zitat von Lehmann

Ich habe mir mal den OO bereich der BI Funktionen angesehen, aber dann gedacht, ich brauche ja nur paar einzelne Klassen ohne vererbung oder sonst einen schnickschnack. Das kann ich auch, indem ich Scripte wie Methoden in einem eigenen Ordner zusammenfüge und weil es nicht so viele Instanzen geben wird, mach ich die Membervariablen einfach Global: BLUFOR_OUTPOSTS und OPFOR_OUTPOSTS.
Zwei Arrays, in denen alle Wichtigen Infos gespeichert sind, kein Akt.

SQF unterstützt (ähnlich JavaScript) keine objekte und das was bis da gebastelt hat ... ja ... aus mist wird nicht gold nur weil man ihn golden anmalt
und was du planst ist daher schlicht weg schlechter coding stil und führt zu inperformanten missionen oder schlimmeres

Zitat von Lehmann

Ironisch?? Ich hab doch immer wieder gesagt, dass ich das Multiplayer Modul "Sector" verwendet hab. Und das braucht nun mal Trigger

nein ernst gemeint ...
ich bin mit den modulen nicht sonderlich bewandert um es ehrlich zu sagen (und das ist vermutlich auch gut so ...)
dann wirst du jedoch kaum um die trigger herrum kommen insofern du nicht planst dein eigenes systemchen hier zu schreiben

NetFusion · 18. März 2015

Falls du wirklich unbedingt OO mit sqf scripten willst:
https://github.com/dylanplecki…ripts/unitCaching/h/oop.h

Aber ich vermute, dass du bei dem Versuch dein Vorhaben damit umzusetzen, scheitern wirst.
Ausserdem rate ich von dem Vorhaben grundsätzlich ab und empfehle dir, dich mit dynamischer Typisierung auseinander zu setzen.
Scriptsprachen sind doch ein ganzes Stück anders als kompilierte Sprachen.

Creedcoder · 18. März 2015

Also ich würde dein Problem mit Hilfe eines simplen Arrays lösen:

PHP

Citys = [
['Stadt_1', [123,456,0], true, "west"], //Stadtname, Pos., eingenommen?, Unitside/Gruppe
['Stadt_2', [654,321,0], false, "none"]
];

wäre einfach zu managen und hast quasi alles was man brauch.

MfG

PS.: Trigger sind nicht Performance fressend wenn man weiß wie man sie verwenden sollte. Habe Tests wo die unterschiede minimal sind ob Script oder Trigger.

Lord-MDB · 19. März 2015

Ich versuche das jetzt mal wieder zu geben wie ich das verstanden habe.

Du mochtest eine Map bauen,in der KI selbstständig mehre Außenposten von einer Basis aus angreift.
Das soll dann NATO vs CSAT oder so sein und der Spieler ist ne Pilot und soll die KI dabei unterstützen aus der Luft.
Die soll selbständig auf den nächsten Außenposten wechseln wenn sie einen erobert hat.
Man soll die Map einfach abändern können in dem man nur Dinge auf der Map verschieben und die Einheiten eintragen muss

ist das so richtig ?

Wenn ja dann müssen einige Dinge gemacht werden.

1.Für die Anzahl der Außenposten müssen die Anzahl der Trigger auf der Map sein,die so gross sind wie der Außenposten groß seinen soll.Name des Triggers A1 bis Ax.
2.Einen Marker für jede Basis wo die KI startet mit Name NATOBasis und CSATBasis.

Das war der Einfache Teil.Der Schwirige Teil kommt nun wo man ein paar Scriptkenntnisse braucht.

1.Du muss einen Array schreiben in dem die Außenposten drin sind Ausenposten=[A1,A2,......];
2.Du muss in der Int.sqf einen Array schreiben in dem steht was für KI Einheiten unterwegs sein sollen.
3.Du muss nun ein Script haben das Einheiten erstellt und die zu einem Punkt schicken kannst,die dann am Punkt NATOBasis und CsatBasis starten und dann zu dem Ausgewählten Außenposten los ziehen.
4.Du muss dazu noch ein Script haben das die Trigger der Außenposten auswertet und danach Aktionen ausführt und der KI befehle gibt.

Gruppe erstellen
https://community.bistudio.com/wiki/createGroup
Einheiten erstellen.
https://community.bistudio.com/wiki/createUnit_array
Trigger auslesen
https://community.bistudio.com/wiki/list
KI zu einem Puntk bewegen
https://community.bistudio.com/wiki/doMove

NetFusion · 19. März 2015

Wenn die KI sich nicht aufteilt, wäre es für die Performance besser nur einen Trigger an dem aktuellen Ziel/Außenposten zu haben. Sobald der Außenposten genommen ist, berechnest du das nächste Ziel der KI und erstellst dort einen neuen Trigger (und entfernst natürlich den alten).

Grundsätzlich sollte man seine Berechnungen unabhängig von der Datenmenge halten. Ansonsten bekommt man immer bei größeren Missionen (egal ob große Spielerzahl oder KI-Anzahl, etc.) Probleme mit der Performance.

Noch dazu weshalb hier Trigger nicht geeignet sind:
Trigger werden zwischen allen Client synchronisiert. Das heißt, je mehr Spieler auf der Karte sind, desto mehr hat der Server mit dem Synchronisieren zu tun. Das ist unnötig, da es ausreicht, wenn der einzig der Server prüft, ob ein Außenposten eingenommen ist oder nicht. Nur bei einer Änderung des "Status" des Außenpostens muss dieser an die Clients verteilt werden.

Ich persönlich bevorzuge den dritten Weg:
Den Server hier komplett zu entlasten (da dieser, wie oben beschrieben, sowieso mit Synchronisieren von diversen Sachen beschäftigt ist). Ich würde also jeden Client selbst prüfen lassen, ob die KI einen Außenposten eingenommen hat oder nicht. Dann spart man sich auch den Netzwerktraffic um die "Statusänderung" an alle Clients zu verteilen.
Dann hat man zwar insgesamt/global mehr zu tun aber kann dabei die Clients wie ein Cluster nutzen und entlastet den Server und das Netzwerk.

Und bei wem es dann zuerst hackt, der hat den schlechtesten PC...

T-800a · 19. März 2015

er benutzt die sektor module im editor und dafür braucht er nun mal die trigger.
und da jeder mal irgendwo angefangen hat finde ich es nicht sehr sinvoll mit der performance-keule herumfuchtelnd hier wie die inquisition einzufallen (so kommts mir nämlich vor).

Lehmann · 20. März 2015

also erstmal danke für die Antworten.

gut möglich, dass ich mich erstmal mit dem Singleplayer Modus beschäftige, da ich die Erfahrung brauche etwas durch skripte zum laufen zu bekommen. Später konzentriere ich mich dann vielleicht mehr auf die Auslastungen zwischen Server und Clients.

Die Trigger habe ich getestet, und muss sagen, dass mir die doch eigentlich sehr optimiert vorkamen. Ich habe vielleicht 1000 Trigger eingesetzt, die prüfen sollten, ob sich Einheiten im bereich befinden, und paar Einheiten rumlaufen lassen, und die Performance schien nur wenig durch die Trigger betroffen zu sein, und vielmehr durch die Anzahl der Einheiten.
kann es sein, dass es mehr so eine ArmA 2 Geschichte war? Dass man damals die Zahl der Trigger minimal halten musste?
Aktuell macht mir hauptsächlich die Größe der Armeen eine Sorge und ich habe mal angefangen zu schauen, ob man die Standard KI der Bodentruppen etwas runterschrauben kann. Aus der Luft bekommt man davon eh nicht so viel mit.

Zitat

Du mochtest eine Map bauen,in der KI selbstständig mehre Außenposten von einer Basis aus angreift.
Das soll dann NATO vs CSAT oder so sein und der Spieler ist ne Pilot und soll die KI dabei unterstützen aus der Luft.
Die soll selbständig auf den nächsten Außenposten wechseln wenn sie einen erobert hat.
Man soll die Map einfach abändern können in dem man nur Dinge auf der Map verschieben und die Einheiten eintragen muss

ist das so richtig ?

richtig.

Zitat

KI zu einem Puntk bewegen
https://community.bistudio.com/wiki/doMove

Ich experimentiere noch, wie man zuverlässig dafür sorgen kann, dass sich keine Einheit festfährt und auch alle Einheiten in dem Gebiet bekämpft werden.
zum spawnen von Einheiten verwende ich derzeit das ModuleSpawnAI_F und auch BIS_fnc_spawnGroup was mir eigentlich ganz gut gefällt.

Ich denke, ich werde erstmal was auf die Beine stellen, bevor es hier weiter gehen kann (@NetFusion: derzeit mache ich noch das OO framework für mein Projekt selbst. Das ist wohl die Beste art, den Umgang mit der Sprache und der Umgebung zu lernen). Für einige dinge mach ich lieber einen neuen Thread, damit alle was davon haben.

Creedcoder · 20. März 2015

Lehmann das mit allmissionobjects kann dir im Multiplayer zum Problem werden. Dieser Befehl ist recht langsam und kann unter Umständen bei niedriger Server FPS extrem lange dauern, ist nen Tick Timeing Problem der Engine. Im Singleplayer sollte es nicht so ein Problem sein.

Also so sparsam wie möglich damit umgehen. Am besten wenn Loops vorhanden sind diese recht großzügig mit uisleep gestalten.
Sollte es dennoch zu FPS einbrüchen kommen gibt es schnellere wege als .SQF Scripte die das Timeing Problem umgehen.

MfG

Markiere alle Trigger in init.sqf

Teilen

Tags