Gahreesen - Falle durch`s Bild :(

[juliett666]

Hab mal ein Bild meines Problems angehangen. Ich falle beim Sprung vom Ausleger einfach ins nirgendwo.... Also direkt durchs Bild.
GraKa: NVidea GTX 260
System: Windoof Vista, 4 GB RAM
Patch: 1.2 vorhanden

Wo liegt das Problem?
Darf man nur in einem bestimmten Outfit weitermachen?

Danke für Eure Hilfe!

[TheSearcher]

Ich gehe mal davon aus, du benutzt Uru - AbM und nicht Uru CC (im letzteren Fall darfst du den Patch nämlich nicht installieren, denn in Form des mitgelieferten TPotS befindet sich Uru schon auf Version 2.0 (?)!).

Wenn du Uru - AbM besitzt empfehle ich dir To D'ni zu installieren (gibt es gratis im Netz: fügt zusätzliche Spielinhalte hinzu, aktualisiert Uru auf Version 1.3 und beseitigt somit "nebenher" noch ein paar Bugs (z. B. den als Feature missbrauchten Bug des "Balcony Jump"s)).

[juliett666]

Dankeschön!
Funktioniert wieder reibungslos

[schreckwurm]

Tja bei mir leider nicht.
Witzig ist, dass wenn ich am ende des Auslegers stehe und einfach weitergehe, falle ich nicht, sondern stehe schwupps wieder auf dem Ausleger um 180 Grad gedreht.
Auf diesen anderen Felsen mit dem Bodenlicht kann ich springen, aber nicht auf dem Felsen mit dem Weltentuch.
Jedesmal falle ich durch die Felsen echt frustrierend.
Hat jemand noch eine Idee?

[Kai-Uwe]

Hallo schreckwurm, willkommen im Forum!

Welche Uru-Version benutzt Du?

Kai-Uwe

[schreckwurm]

Ich denke ich habe eine alte Version.
Zuerst habe ich die auf 1.2 gepacht, aber ohne Erfolg, fiel immer noch durch den Felsen.
Dann habe ich neu installiert und To D'ni draufgespielt.
Leider immer noch keinen festen Boden auf dem Felsen.

[diafero]

Ein Freund hatte mal ein ähnliches Problem, da war der PC offenbar zu schnell. Er hat dann mit Fraps eine Video-Aufnahme machen wollen und prompt hat es geklappt. Das war tatsächlich reproduzierbar, nur wenn er mit fraps aufgenommen hat ist er auf dem Felsen gelandet. Klingt total bekloppt, aber vielleicht ist es einen Versuch wert

[schreckwurm]

Tja, was soll ich sagen es funzt tatsächlich, darauf wäre ich im Leben nicht gekommen.
Vielen Dank für diesen Supertipp.

[susi]

Aber nicht vergessen ab und zu die Videos auch zu löschen Sonnst ist die Festplatte ruck zuck voll

Gruß Susi

[diafero]

Tja, was soll ich sagen es funzt tatsächlich, darauf wäre ich im Leben nicht gekommen.
Vielen Dank für diesen Supertipp.

*lol* ich glaube darauf kommt niemand, wir konnten es damals auch kaum glauben. Schön, dass das Verhalten so reproduzierbar ist!
Versteh einer mal die Computer...

@susi: Stimmt, das geht ganz schnell bei unkomprimierten Videos wie fraps sie erzeugt

[TheSearcher]

Tja, was soll ich sagen es funzt tatsächlich, darauf wäre ich im Leben nicht gekommen.
Vielen Dank für diesen Supertipp.

*lol* ich glaube darauf kommt niemand, wir konnten es damals auch kaum glauben. Schön, dass das Verhalten so reproduzierbar ist!
Versteh einer mal die Computer...

Eigentlich ganz einfach, wodurch das entstehen könnte (ich behaupte nicht, dass dies die Ursache ist, aber es ist die einzig plausible, die mir auf die Schnelle einfällt.

Es kommen hier zwei Faktoren zusammen.

1. Adaptive Schrittmodi in der Verwendung der Physik-Engine in Abhängigkeit von Rechenleistung

Prinzipiell verwenden die meisten Physik-Engines einen mehr oder weniger ausgereiften numerischen Integrator, um den Ort zu berechnen.

Beispiel (an dem ich die Erklärung durchziehe):

Ort zum Zeitpunkt t0 sei s0. Die Geschwindigkeit in Abhängigkeit von der Zeit ist v(t). Dann ist der Ort zum Zeitpunkt t1 gleich

s0+Integral von t0 bis t1 über v(t) dt

Um dieses Integral am Computer zu berechnen, diskretisiert man es. Eine einfache Möglichkeit ist hierzu beispielsweise die Trapezregel (würde man in Uru jedoch nicht einsetzen).

Prinzipiell besteht aber bei den meisten Verfahren die Idee darin, die Funktion v(t) (eventuell auch v'(t)) an bestimmten Punkten t_i auszuwerten und aus den Paaren (t_i, v(t_i)) eine Approximation des Integrals zu berechnen.

Dann stellt sich die Frage: welche Zeitpunkte verwenden wir als Stützstellen für den numerischen Integrator?

Die einfachste Möglichkeit ist: alle konstante Zeiträume (z. B. 100 ms). Das Problem: manchmal führt dies zu unschönen Artefakten, wenn sich v(t) schnell ändert.

Deswegen die prinzipielle Idee: wir machen die Zeiträume adaptiv, d. h. wenn mehr "passiert", schalten wir die Schrittweite runter.

Nun denkt sich Cyan folgendes: wenn sehr viel Rechenleistung zur Verfügung steht, schalten wir die Intervalle nochmal kleiner. Dies sorgt für eine schönere Physik (so etwas sollte man natürlich eher nicht bei Online-Spielen machen, da sonst möglicherweise jede Person in der Welt etwas ganz anderes berechnet). Eine prinzipiell gute Idee, wenn nicht ein Fehler gemacht würde - aber dazu später.

2. Kollisionserkennung

Eine Kollisionserkennung implementiert man meist so, dass man als Invariante sichert, dass 2 Objekte nie miteinander kollidieren (bei sehr alten Physik-Engines kann man dies sogar daran erkennen, dass 2 Objekte, die sich berühren, wie Kiste auf Boden häufig einen kleinen Abstand zueinander haben).

Wenn sie dann doch irrtümlicherweise "ineinander" geraten, so wird die Kollisionserkennung dieser beiden abgeschaltet. Warum macht man das so? Weil in den meisten Implementierungen die Objekte sonst ineinander "verkeilen" würden - d. h. man kann nicht mehr durch "Herausspringen" o. ä. die Kollision aufheben, weil die Kollisionserkennung verhindert, dass die Verkeilung aufgelöst wird. Dieses Verkeilungsverhalten lässt sich ebenfalls an einigen schlecht programmierten älteren Computerspielen sehen.

Ich möchte anmerken, dass heutzutage (insbesondere dank Mehrkernprozessoren) ein deutlich intelligenteres Verhalten zum Auflösen von Verkeilungen möglich ist und daher das Problem heutzutage eine deutlich geringere Rolle spielt. Zu Zeiten als Uru - AbM herauskam, war dies jedoch nicht gegeben.

Was hat Cyan nun vermutlich falsch gemacht?

Durch die hohe Rechenleistung wurden die Zeitintervalle zu klein gewählt, so dass man auf numerische Probleme stößt.

Beispiel: für IEE-754-Gleitkommazahlen kann man ein eps>0 (das sogenannte Maschinen-Epsilon) angeben, so dass für alle Zahlen b, a mit

|b/a|<eps gilt:

a+b = a (!!!)

Also: wir addieren zu einer Zahl eine kleine, von 0 verschiedene, andere Zahl und kommen wieder bei der gleichen Zahl heraus.

Besonders, wenn man aus Geschwindigkeitsgründen einfache Genauigkeit wählt (dies ist auch das Datenformat, welches Grafikkarten verarbeiten - daher gehe ich davon aus, dass sie es gemacht haben), ist man recht empfindlich für solche Fehler.

Da diese Probleme bei der Implementierung wohl nicht bedacht wurden, kommt es zu einer Verletzung der Invariante, dass Objekte nicht miteinander kollidieren - mit den oben genannten Folgen.

---

Es ist also alles ganz logisch, wenn man sich klarmacht, was im Hintergrund geschieht. Wem dies zu kompliziert war, den verweise ich auf folgenden Comic: http://xkcd.com/676/

[Stefan]

Ich wollte es mir wirklich, wirklich... wirklich verkneifen. Ich konnte nicht!

[Coren-7]

Ich wollte es mir wirklich, wirklich... wirklich verkneifen. Ich konnte nicht!

[susi]

Ich wollte es mir wirklich, wirklich... wirklich verkneifen. Ich konnte nicht!

Susi

[hordath]

Ich wollte es mir wirklich, wirklich... wirklich verkneifen. Ich konnte nicht!

ouhh Stefan, du hast mir wieder mal ein herzhaftes Lachen beschert