Okay, lassen wir den Eigendrehimpuls/Spin weg. Was bleibt dann noch übrig. Da wäre zunächst noch die Sache wie im botf-3D-Kampf, dass ein Warbird z.B. schlagartig drehen (mit dem Geschwindigkeitsvektor mit) konnte z.B. wenn man in einer neuen Kampfrunde ein neues Ziel für einen Nahangriff ausgewählt hat. Da müssen wir wenigstens dran denken, dass die Engine später das nicht erlaubt, sonst gibts ein unlogisches Gefühl für den Spieler, warum das Schiff so schön-schnelle Drehungen nicht immer hinkriegt oder öfters diese Taktik anwendet. Aber das ist nur Nebensache.
Wenn wir also nicht allzuviel beachten und damit optimieren, was die Firearcs angeht und optimale Feuerpotenzialausnutzung, sondern alles über Umkreisen und Ausweichen-Taktiken regeln und die Schiffe einfach fliegen lassen so wie man es eingestellt hat, ist das okay. Bestimmte Taktiken bevorzugen eben Schiffe mit großen Gesamtfirearcs aber geringer Firepower und umgekehrt. Optimierung teilen wir einfach raus
.
Für den Firearc betrachten wir einfach die Einheitsvektoren (alle Vektoren durch ihre Norm teilen). Wir gehen immer vom Kegelfall aus und der Firearc ist der Öffnungswinkel des Kegels, wobei der Kegel gerichtet ist, d.h. ein 90° Firearc eines frontal befestigten und nach vorn gerichten Geschützes hat einen Winkel von 45° zur Seite (Zirkelprinzip). Wir checken also am Schluss ob der cos des Winkels zwischen Geschwindigkeitsvektor v und Abstandsvektor diff zwischen den beiden Schiffen, der beim Skalarprodukt der beiden (auch in 3D) rauskommt, und damit der Winkel im Firearc-Bereich abhängig von den montierten Position des Geschützes ist.
diff=Position(Gegner)-Position(Eigene)/Norm(...)
rot= Höhenvektor Richtung oberes Ende des Schiffs, liegt immer senkrecht auf v (Definition von v siehe unten). Wenn wir davon ausgehen, dass Schiffe sich nicht völlig starr bewegen, gibt es in 3D noch die Eigendrehung um diese Achse. Sie ist komplementär zu der Eigenspindrehung, die ich vorher genannt habe, lässt sich aber nur schwer wegdiskutieren, weil Schiffsbewegungen sonst sehr seltsam aussehen würden, wenn das Schiff diese Bewegung nicht vollführen dürfte. Nehmen wir das simple Beispiel Looping. Nach halbem Looping ist der "Kopf" des Schiffes unten und die Unterseite oben, dreht man nun eben zur Seite nochmal 180° ist man am Ausgangspunkt, allerdings über Kopf. Trotzdem ist der Geschwindigkeitsvektor und auch der Bug nach vorn gerichtet, wie vorhin. Wir haben also durch erlaubte Operationen diese Situation erzeugt, daher müssen wir sie beachten. Umgehen könnte man das indem man eine Oberseite fest definiert in der alle Schiffe ausgerichtet bleiben, das sieht aber wie gesagt sehr schlecht aus im 3D-Kampf nachher.
v=Geschwindigkeitsvektor (alles normiert wie gesagt), quasi die "Ausrichtung", die du schnell berechnen kannst.
Um das rot dreht sich noch mal ne ganze Vorlesung, sprich der Höhenvektor verändert sich fortlaufend durch das v und man muss ihn daraus irgendwie sinnvoll bestimmen. Wenn ich z.B. in einer Ebene ne halbe Drehung mache, ist das bei Flugzeugen so, dass diese erst sich um die momentane "v-Achse" 90° drehen und dann "hochziehen" (jeder der schon mal einen Flugsimulator gespielt hat, weiß wovon ich rede) um nach vollendeter Drehung wieder zurückzudrehen. Aber während der Drehung hat das Flugzeug ne andere Neigung. Das rührt vom Auftrieb her und ist zunächst einmal im Weltraum nicht nötig. Allerdings gibts ja in 3D keinen Bezugspunkt, wann also hochziehen und wann einfach nur seitlich "verdrehen"?
Dumm ist in so einem Fall wenn die Geschütz "on top" montiert sind und ihre Feuerwinkel nach oben zeigen. Bei einer Drehung dreht man sich so gerne mal ungewollt aus dem Feuerwinkel raus und wollte eigentlich nur ein klein wenig ausweichen. Also muss man die Lage doch noch nach den Geschützpositionen ausrichten.
rot muss immer absichtlich ausgerichtet werden, um die seitliche Phalanx im Raum auf den Gegner beim Umkreisen einsetzen zu können. Dabei wird einfach rot so lange verändert bis rot, v und diff jeweils im Skalarprodukt 0 ergeben, dann sind nämlich alle Achsen richtig ausgerichtet für seitliches Feuer, wobei rot hier 2 Möglichkeiten hat, einmal stehts aufm Kopf und einmal nicht, macht aber nix, da wir einfach mal davon ausgehen, dass seitliche Geschütze gleichmäßig auf beide Seiten verteilt sind. Beim Umkreisen wird v natürlich immer tangential gehalten und der Abstand r variiert.
Bei echten Frontalgeschützen (direkt vorne Spitze montiert) spielt rot keine Rolle, ich wäre auch dafür, nicht beliebige Positionen der Geschütze (also frontal, aber leicht nach unten rechts versetzt), denn dann würde rot bei solchen Frontalgeschützen wieder ne Rolle spielen. Wir müssen also die Positionen einschränken. Ich wäre für ganz vorne, ganz hinten und "ganz" seitlich.
Wenn wir es nämlich so machen, spielt rot überhaupt keine Rolle mehr (ich habs nur zur Veranschaulichung genommen, welche Probleme auftreten, wenn wir andere Geschützpositionen zulassen, bei Nicht-Pi/2-Werten müssen ansonsten die Geschütze vierfach gleichverteilt sein, so dass es auf die rot-abhängige Seitenlage des Schiffes nicht ankommt).
Wenn wir nicht visualisieren, könnte man behaupten, immer die richtige rot-Einstellung stellt sich automatisch ein und man geht zu jedem Zeitpunkt die ganzen 360° für rot durch und checkt alle möglichen Ziele. Das geht natürlich, aber halt nicht wenn wir visualisieren. Es sei denn, man checkt das im Hintergrund und lässt dann nach Zielerfassung eines so gefundenen Zieles rot sich so einstellen, wie es bei der Zielfindung hatte.
Ohne rot ist es dann einfach. If ((arccos(Skalarprodukt(diff,v))*180/Pi) enthalten in [-firearc/2 +90+180+270,firearc/2 +90+180+270] oder ) then allowfire [vorne, seitlich, hinten, seitlich] else allowfire=0. (bissel blöd aufgeschrieben aber es ist klar was gemeint ist)
In botf war das Umkreisen auch so geregelt, dass sich die Schiffe erstmal an der Verbindungsachse zum Gegner ausgerichtet haben und dem Gegner die Seite und nicht etwa wie beim Flugzeug den Kopf zugedreht haben.