@R.D.: Bleibt die Frage, ob man einfach so auf ein solches GPS-Signal verzichten soll.
@Elsen: Jop, genauso sieht es aus, natürlich ein wenig geschminkt. Das heißt, statt einer Pixelbreite etwas dicker, damit Ereignisse wie Sprungschanzen und besondere Bodenflächen erkannt werden können.
Allerdings gibt es ein paar Probleme bei der Sache. Ich nehme mal als Beispiel deine - noch relativ simple - Streckenstruktur. Sie würde schon 20 Checkpoints enthalten und Bereiche, die in der tatsächlichen Bahn eine Kurve darstellen, in verschiedene Abschnitte unterteilen.
Das ist auf der einen Seite ein sehr großer Aufwand und verbraucht jede Menge Picture (2 pro Checkpoint im Pictureordner). Ich versuche das Erstellen von Bahnen relativ einfach zu halten, um in die Richtung eines Editors gehen zu können.
Auf der anderen Seite muss man daran denken, dass es ja immernoch Checkpoints sind, also durchfahren werden müssen. Sprungschanzen, die Abschnitte abkürzen, und Abzweigungen, die Abschnitte umfahren, sind immer nur innerhalb eines Checkpointabschnittes möglich. Dementsprechend darf man nicht jede Kurve mit zwei, drei Checkpoints zupflastern.
Ganz nebenbei kostet es auch noch ein wenig Rechenleistung, jedes Mal den nächsten Checkpoint anzupeilen.
Die Hardcorelösung die dabei herauskommt: Zwei Arten von "Checkpoints". Einmal spärlich verteilte echte Checkpoints, also Schranken, die überprüfen ob man tatsächlich die Bahn abfährt, und als zweites Minimap-Checkpoints, die die Position darstellen und nicht zwingend alle durchfahren werden müssen.
Das würde allerdings sehr viel Arbeit, eine Erweiterung/ Verkomplizierung des Quellcodes und eine starke Belastung des "Editors" bedeuten.
Rentiert sich das oder gibt es dann doch bessere Lösungen?
CapSeb
Zitieren