Rotierende Asteroiden

[Ded_Moros]

Wer kennt sie nicht, die pixeligen Klumpen, die uns in WingCommander als Asteroiden manchmal das Leben schwer gemacht haben, und die dabei wie betrunken durch das All torkelten? Irgendwie sorgen rotierende Asteroiden für mehr Atmosphäre im Spiel.

Ich habe hier mal ein kleines Script, welches ich für Reunion benutzt habe, ausgebuddelt und für TC passend gemacht.
Es beginnt seine Arbeit nach dem nächsten Sektorwechsel.

Im Scripten bin ich ABC-Schütze, und in den alten Schädel geht auch nicht mehr so viel rein, aber vielleicht können sich ja mal ein paar Leute die Geschichte anschauen und verbessern. Es ist auf jeden Fall beeindruckend, mit einem kleinen Schiff mal eine enge Schleife um so einen behäbig herumtrudelnden Brocken zu fliegen.

Perfomancetechnisch ist bei mir keine große Änderung spürbar, auch in grausamer Vorstoß läuft es auf 180 Astros ohne Ruckler (wenn nicht viel Verkehr ist).

Edit 25.09.2010: die bekannten Versionen, neu eingestellt von MegaDeath http://www.file-upload.net/download-283 ... 2.zip.html

mfg
Väterchen Frost

[ScRaT_GER]

Wie ist denn das mit Minen?
Rotieren die auch - konnte ja schwer werden mit der Landung?
Auf jeden Fall ein nettes Skript, werde es mal ausprobieren.

MfG,
ScRaT

[Ded_Moros]

Minen nich.

[Reisser]

Zum Deinstallieren dann einfach wieder löschen?

Ach - ich find's ja immer schick wenn man dann gleich eine winzige Batch mit dazupackt (z.B. in einen Unterorder DeInstall) der sowas dann im Bedarfsfall für einen erledigt Irgendwann verliert man ja dann leider irgendwann immer die Übersicht über die ganzen Scripte die man so rumfliegen hat - da ist man für jede Hilfe dankbar.

[Ded_Moros]

Löschen und die globale Variable 'rotiere' zu null setzen.

mfg
Väterchen Frost

[-[e1337e.weazel]-]

Das hat mich schon immer geärgert das die alle starr im Raum hängen. Erstmal Danke für dieses Script. :thumb_up:

Das musste ich doch sofort testen und war erst enttäuscht als ich in "Heimat des Lichts" keinen Astro zum drehen bekam, dann fiel mir auf das die Astros dort auch garnciht auf der Karte verzeichnet werden und bin dann gleich mal einen Sektor südlich nach "Erzgürtel" und siehe da die großen Brocken bewegen sich. Hammer!

Wenn man jetzt noch einige kleine zum drehen bekommen würden wär das noch n Tick schicker und am besten wenn man evtl. noch einzelne zum stillstehen bewegen kann. Wie auch immer bis jetzt schon mal sehr gut.

Aber, ohne Bug kommen wir nicht aus oder?
Hab da leider einen kleinen Schönheitsfehler entdeckt. Wenn man den SINZA anstellt sollten die sich ja eigentlich schneller drehen, stattdessen rotieren sie dann langsamer. Sieht etwas seltsam aus wenn alles um einen herum sich schneller bewegt und nur die Astros werden träger.

[Ded_Moros]

Das mit dem Sinza ist mir auch aufgefallen, auch früher schon bei Reunion, keine Ahnung, wie man das richtig hinbekommt. Aber wer ist denn so hart und nennt das gleich nen Bug? (Im Übrigen sieht es echt fürchterlich aus, wenn die Steps größer werden.)

Für Tipps und Verbesserungen bin ich jederzeit empfangsbereit. Vielleicht gibts auch 'n Bier...

Edit: Tatsächlich hatte ich auch schon mal probiert, die Minis und Trümmerfelder mit einzuschließen, aber das geht dann von der Performance echt ans Eingemachte.
Und das mit dem langsamer werden der Astros bei Sinza, vielleicht ist es nur Optik, und es ist wie bei Speichenrädern, die sich bei ner bestimmten Drehzahl auch rückwärts zu drehen scheinen.

mfg
Väterchen Frost

[-[e1337e.weazel]-]

Kein Bug? Hallo? Die werden laaaangsaaammeerrr!

Wäre echt cool wenn das jemand fixen kann, weil an und für sich müsstest Du schon für das Script nen Pitcher Bier bekommen.

[Ded_Moros]

Edit oben.

[-[e1337e.weazel]-]

Tatsächlich hatte ich auch schon mal probiert, die Minis und Trümmerfelder mit einzuschließen, aber das geht dann von der Performance echt ans Eingemachte.
Und das mit dem langsamer werden der Astros bei Sinza, vielleicht ist es nur Optik, und es ist wie bei Speichenrädern, die sich bei ner bestimmten Drehzahl auch rückwärts zu drehen scheinen.

Wäre schön wenn man das als optionale Varianten einbauen könnte, damit Leute mit stärkeren Maschinchen nicht drauf verzichten müssen.
Drehende Schiffstrümmer hört sich auch gut an.

btw: Kann man evtl einen Zufallsfaktor bei kleinen Astros einbauen? Das einige sich drehen und andere nicht?

Ach und da wir schon dabei sind: Wir können also Objekte per Script zum drehen bekommen? Ich sage nur WERBETAFLEN!

[Gazz]

Kein Bug? Hallo? Die werden laaaangsaaammeerrr! :lol:

Und wie er schon sagte - das ist normal.
Auch bei meinem "Align to Ecliptic" Script ist das so weil ich den Aufwand der FPS-Angleichung nicht gerechtfertigt fand.

Unter SETA werden sämtliche Scripts ausgebremst da die kleinste Zeiteinheit im Spiel 1 Frame ist und das ist nun mal eine höchst variable Zeitrechnung.

Der einzige Weg drumherum:
Ein unabhängiges script (mit Wait 1 ms) muß ständig die FPS messen (einfach jede Sekunde Playtime die Frames zählen...)
und in eine globale Variable schreiben.

Dann kann man die Drehung pro Sekunde festlegen und nicht mehr nur / Frame.

Auf die Art wäre das Script komplett SETA-kompatibel.
Ob das den Aufwand wert ist sei dahingestellt.

Übrigens sollte jeder Astro eine eigene Drehgeschwindigkeit haben.
Vielleicht +/- 50 % vom Staqndard?

Trümmerfelder wären schon möglich aber man muß sie auf jeden Fall auf den sichtbaren Bereich begrenzen.
Also nur Trümmer innerhalb von (z.B.) 8km und Asteroiden innerhalb von 20 km drehen sich.
Und "player tracking aim" nicht vergessen.

Die Auswahl der "aktiven" Asteroiden wird dann so alle 30 sec aktualisiert (= in das "aktive" Array gepackt) so daß nicht ein ganzer Sektor voll mit Trümmern berechnet werden muß.

So kann das Script auch allgemein effizienter arbeiten da weniger Astros gedreht werden müssen und die Entfernungsmessung / Auswahl auch nur alle 30 sec läuft.

Für Tipps und Verbesserungen bin ich jederzeit empfangsbereit. Vielleicht gibts auch 'n Bier...

Also ich nehm Bitburger! =)

[-[e1337e.weazel]-]

Wenn die Möglichkeit besteht ein Script zu verbessern hoffe ich auch das sich jemand dem annimmt, klingt ja schon fast so als wenn es dem Scriptersteller aus welchen Gründen auch immer nicht gelingen wird.

Im Scripten bin ich ABC-Schütze, und in den alten Schädel geht auch nicht mehr so viel rein, aber vielleicht können sich ja mal ein paar Leute die Geschichte anschauen und verbessern.

Wäre schade wenn eine tolle Idee nur ansatzweise umgesetzt wird.

Für Tipps und Verbesserungen bin ich jederzeit empfangsbereit. Vielleicht gibts auch 'n Bier...

Also ich nehm Bitburger! =)

Er sagte Bier!

[Gazz]

Wenn die Möglichkeit besteht ein Script zu verbessern hoffe ich auch das sich jemand dem annimmt, klingt ja schon fast so als wenn es dem Scriptersteller aus welchen Gründen auch immer nicht gelingen wird.

Hier im Forum sind einige alte Schädel unterwegs und nicht alle Scripter sind "richtige" Programmierer.
(Ich zum Beispiel =)

Ist auch gar nicht schlimm wenn man nicht jedes Problem sofort lösen kann. Ist allen Scriptern schon mal passiert.
"Gut" zu sein heißt ja nur, daß man solange dabei bleibt bis die ganzen peinlichen Anfängerfehler in Vergessenheit geraten sind. =P

[Ded_Moros]

Übrigens sollte jeder Astro eine eigene Drehgeschwindigkeit haben.
Vielleicht +/- 50 % vom Staqndard?

Jeder Astro hat Zufallswerte für dir Rotation für alle drei Achsen, manche drehen langsam, manche langsamer, richtig schnell keiner. Gleich schnell und gleiche Richtung wäre Zufall. Extremer Zufall.

Bei den Minis weiß ich nicht so recht, ob vielleicht irgendwelche Schürfer ihre Hetze kriegen und sich die Karossen verbeulen. Vielleicht probiere ichs mal aus (oder wer anders? ).

mfg
Väterchen Frost

[DonMichael71]

Hi Ded_Moros

Danke für das geile Script, werds mir heute abend gleich mal ziehen. Bin auch alter Wing Commander Veteran, und die drehenden Astros hab ich noch gut in Erinnerung

MfG
DonMichael71

[laux]

Ach und da wir schon dabei sind: Wir können also Objekte per Script zum drehen bekommen? Ich sage nur WERBETAFLEN!

Also die Werbetafeln kann man auch ganz ohne Script zum Drehen bringen. Einfach in eine Scene packen und dort dann die Rotationsanimation hinterlegen. Dann musst du nur noch in der Spezial.txt an den entsprechenden Stellen von Body auf Scene umstellen und fertig

Und das Beste dabei ist, dass sie sich dann bei Sinza auch wirklich schneller drehen.

[|K.O.S.H.]

jaja, is klar.
jetzt kommen auf einmal die ganzen wing commander fans angeschissen


zum thema:
die szene verändenr würde ich nicht.
grund: alle astros würden gleich rotieren.

besser das script verfeinern.
ich habs mit noch nicht angeguckt, aber folgender algorythmus komtm mir auf die schnelle in den sinn.

(über machbarkeit, oder nicht sei jetzt erstmal keine aussage getroffen)

was muss rotieren?
alle asteoriden im sektor, die im sichtbereich liegen.

also bei sektorwechsel jedem objekt soweit möglich ne lokale veribel mitgeben, die die rotation festlegt.
bei jedem sektrowechsel einmal alle astros und miniastros prüfen.
sind neue dazu gekommen, dann denen die enstprechende loc.var hinzufügen.

eventuell diese prüfung öfter durchführen, je nach performance.

dann muss man einschränken, welche man rotieren will.
1. einschränkung größe relativ zur entfernung.
große astros müssen auch auf 10km rotieren, kleine weniger.
spart ne menge rechenaufwand.

2. einschränkung: sichtbarkeit.
hier liegt der hase im pfeffer.
wie messe ich, ob ein objekt sichtbar ist?
1. schritt: alles ins koordinatensystem der kamera transferieren und alels mit positiven z-werten rauswerfen.

so und jetzt braucht man nen cleveren algo, der weiter filtert.

brutforce wäre nen vektor von der kamera zum astro zu erstellen und den winkel mit (0,0,-1) zu bilden und mit dem sichtwinkel zu vergleichen.

ein verbesserungsvorschlag: horizontale und vertikale clippingebenen definieren.
das erfordert pro objekt nur zwei integer-vergleiche und eventuell zwei vorzeichenwechsel.
und in einem zug gleich noch mit den vergleich auf der negativen z-achse.

damit hat man zwar nicht die richtigen entfernungen abgedeckt, aber man spart ne ganze menge rechenaufwand.

das allereinzigste problem wäre die transformation ins kamerakoordinatensystem.
dafür gibt es libraries, aber keine ahnung, wie effizient die sind..
könnte man direkt mit den matrizen arbeiten wäre es kein problem.

möglich wäre auch einen divide and conquer algorithmus zu implementieren, der beim sprung in den sektor alle astros in zonen einteilt, bzw. naheliegende gruppiert.
im grunde wäre das ein octtree.

das hat den vorteil, dass man gleich ganze gruppen rauswerfen kann.
grade bei den miniastros wäre das ne super sache.

abe rmit dem scripteditor wird man sowas wohl nicht sehr performant hinbekommen...

so.
wer jetzt lust hat das umzusetzen: viel spaß

[laux]

zum thema:
die szene verändenr würde ich nicht.
grund: alle astros würden gleich rotieren.

Tja gibt für die Astros leider keine Scenen, von daher keine Angst, es wird sich keiner mit einer solchen Animation beschäftigen können.

Also sorry, mein voriger Post war nicht wirklich OnTopic, **sich auf die Finger klopf**

[Gazz]

2. einschränkung: sichtbarkeit.
hier liegt der hase im pfeffer.
wie messe ich, ob ein objekt sichtbar ist?
1. schritt: alles ins koordinatensystem der kamera transferieren und alels mit positiven z-werten rauswerfen.

Entfernung und evtl. Objektgröße ist wohl der einzige brauchbare Filter.
Da man in der Außenansicht jeden Blickwinkel hat wäre die ganze Winkelakrobatik sinnlos.

Außerdem würde ein so komplexer Filter vermutlich schon weit mehr Rechenzeit verbraten als die vielleicht 10 Zeilen, die man braucht um einen Astro zu drehen.

Was denkbar wäre ist, die Frequenz des Drehscripts mit zunehmender Entfernung zu verringern.
Je weniger Pixel der Asteroid auf dem Bildschirm hoch ist, desto weniger fällt eine "grobe" Animation auf.

Die Objekte der z.B. 3 Entfernungsklassen würden dann in 3 Arrays gepackt und die Rotation läuft dann nach:
Array1
(wait)
Array1, Array2
(wait)
Array1, Array3
(wait)
Array1, Array2
(wait)
Array1
(wait)
Array1, Array2, Array3

So spart man gerade bei den weit entfernten Astros (die die größte Stückzahl ausmachen) schon wieder einen Großteil der Rechenzeit.

Jeder Astro hat Zufallswerte für dir Rotation für alle drei Achsen, manche drehen langsam, manche langsamer, richtig schnell keiner. Gleich schnell und gleiche Richtung wäre Zufall.

Gamma-Rotation kannst du vermutlich ohne "optischen Verlust" komplett rausnehmen.
Spart schon wieder Rechenzeit. =)

[Ded_Moros]

Ich habs gewusst: es artet aus in eine Variablenflut . Das wollte ich eigentlich vermeiden.

Also, bei mir wird jeder Astro im Sektor gleich behandelt! Sichtbar oder nicht, egal, drehen. Zum Start wird die aktuelle Rotation abgefragt, dann die Zufallshäppchen addiert, und beim Verlassen des Sektors (Beenden des Skriptes auf dem Astro) die Rotation auf null gesetzt.
Wahrscheinlich nicht perfekt, aber wenig Rechenaufwand. Und habe noch keine Probleme festgestellt.

Im Übrigen, bei mir gibt es jetzt schon mal Bier .

mfg
Väterchen Frost