Hi Leute, ich habe mal wieder ein Problem mit der Kollisionserkennung.

Ich möchte wenn der Player von der „stand“ oder „walk“ Animation in „attack“ übergeht, die Bounding Box updaten. Dafür benutze ich „c_updatehull“. Da man aber ja sicherstellen muss, dass es beim vergrößern der Bounding Box zu keiner Überschneidung kommt, war meine Idee, ich setze die Events „BLOCK“ + „ENTITY“ und probiere erst mal die Bounding Box zu vergrößern. Wenn „EVENT_BLOCK“ oder „EVENT_ENTITY“ anspricht, läuft er Player solange rückwärts, bis die Bounding Box ohne Probleme vergrößert werden kann.

Leider reagiert „EVENT_BLOCK“ und „EVENT_ENTITY“ nicht darauf wenn die Bounding Box beim vergrößern durch die Wand oder ein Modell ragt.

Habt ihr eine Idee wie ich prüfen könnte, ob man die Bounding Box problemlos vergrößern kann?

Vielen Dank schon mal im Voraus.

Naja, wenn Du zum Beispiel die Bounding Box um 10 quants nach unten vergrößern willst, dann könntest Du den Player 10 quants nach unten bewegen und schauen ob es zu einer Kollision kommt. Wenn nicht addierst Du auf seinen z-wert einfach wieder zehn auf und vergrößerst die Box.

Also eigentlich geht es mir um die Bewegung nach vorne.

Du meinst also, ich sollte den Player auf Verdacht z.B. 20 Quants nach vorne laufen lassen, wenn er er nicht mit einem Levelblock oder Model kollidiert, läuft der Player wieder 20 Quants zurück und die BBox kann ohne Probleme vergrößert werden?

Was wäre aber, wenn jetzt z.B. ein Gegner auf den Player zukommt und er in der Bewegung nach hinten dann beim vergrößern der BBox doch kollidiert?

Danke trotzdem für die Hilfe.

Die einzige Lösung wäre dann den Player in alle Richtungen zu bewegen, in die Du die Bounding Box vergrössern willst. Alternativ kannst Du die Größe der Beounding Box berechnen und mit c_content überprüfen, ob die Ecken der Box frei sind. Aber mal ganz unter uns.. Warum willst Du die Überschneidungen denn unbedingt vermeiden. Das Handbuch sagt zu dem Thema

Da es um deine Spielerfigur geht, die nur die Animation austauscht, würde ich das einfach mal probieren, ob es ohne diese Tests geht. Die FIgur wird ihre Größe ja nicht schlagartig verdoppeln, oder handelt es sich um einen Transformer? ;-)

Na verdoppeln wird sich die BBox natürlich nicht, aber bei mir ist es so, ein Zombie kommt auf den Player zugelaufen, da der keine Waffe, sondern eben nur die Hände hat, muss er direkt vor dem Player stehen um ihn verletzen zu können.

Wenn jetzt beide direkt zusammen stehen und ihre BBox vergrößern, ohne zu prüfen ob genug Platz ist, überschneiden sich Player und Zombie und das war es. Keiner kann sich mehr bewegen und wer zu erst stirbt hat gewonnen.

So habe ich mir gedacht, ich prüfe ob ich die BBox ohne Probleme vergrößern kann, sonst läuft der Player a) so lange automatisch nach hinten bis es geht, oder b) er muss sich eben manuell eine Position suchen, damit er schießen kann.

Das ist natürlich ein Problem. Ideen, die mir in den Kopf kommen:

1. Bounding Box einfach so lassen wie sie ist. Wenn der Unterschied nicht so groß ist sollte der Spieler die nicht ganz korrekte Kollisionserkennung gar nicht bemerken. Mit vernünftigen Anfangswerten ist da viel zu machen. Problematisch sollte es nur beim Ducken werden.

2. Wenn der Spieler vom Zombie geschlagen wird, ihm einen kräftigen Schubs nach hinten geben, so dass er weggeschleudert wird.

Auch wenn ich dich vielleicht nerve, zu Nummer 1, das geht leider nicht. Ich arbeite an einem Spiel im Resident Evil Style und bei dem Kamerasystem (statisch wechselnde Kameras) sieht man leider fast jeden Fehler in der Kollisionserkennung.

Ich habe mir schon so viele Möglichkeiten überlegt, hier mal ein paar.


1. Ich erstelle ein Objekt ein paar Quants vor dem Player, das den Player immer begleitet. Ob das Objekt mit einer Wand oder Model kollidiert, würde EVENT_BLOCK und EVENT_ENTITY feststellen.

Das geht leider nicht, weil wenn man bei c_move die Flags IGNORE_MODELS und IGNORE_BMAPS setzt, geht EVENT_BLOCK und EVENT_ENTITY auch nicht.



2. Ich probiere einfach die BBox zu vergrößern, wenn sie mit einem Block oder Model kollidiert, läuft der Player zurück bis alles frei ist.

Das geht leider auch nicht, da wenn die BBox vergrößert wird, sie aber z.B. bereits durch eine Wand ragt, merkt EVENT_BLOCK das leider nicht.



3. Ich schicke einen Strahl mit c_trace nach vorne und schaue ob ein Objekt dazwischen war, oder nicht.

Das geht leider auch nicht, da ich nur einen Punkt damit prüfen könnte. Liegt jetzt z.B. ein Medipack vor den Füßen des Players, kann es sein, dass es nicht erfasst wird, weil der Stahl z.B. zu hoch ist. Würde jetzt die BBox vergrößert werden, würde der Player wieder steckenbleiben.


4. Ich würde ein Objekt mitten im Player erzeugen, das sich immer mit bewegt und die Player Entity ignoriert, wenn jetzt die Animation geändert werden soll, würde ich die Box einfach nach vorne fahren lassen (natürlich unsichtbar), wenn weder EVENT_BLOCK und EVENT_ENTITY ausgelöst wird, wäre es ja frei.

Das ganze geht leider auch nicht, weil ich bei c_move das Flag IGNORE_YOU für die Player Entity bräuchte, warum ich aber das Flag für IGNORE_YOU nicht mehr für die Waffenskripts hätte und so die Schüsse an der Box enden würden.



Wie du siehst, das ist gar nicht so einfach!

Ok, das einzige was mir noch einfällt: Lass die Bounding Box von Anfang an so groß, wie sie für die größte Animation benötigt wird.

Ja, das ist die einzige Lösung die mir ebenfalls einfällt, die auch zu 100% funktioniert. Ich glaube ich werde mich mal an JCL wenden. Bin ja wohl nicht der einzige der damit zu kämpfen hat.