Wird es so gemacht?
Wirkt sich dieses Wait(3) nicht irgenwie auf den Spielfluss\zombiebewegungen aus?
Wenn es irgenwie sichtbar wäre (kleine Ruckler in der bewegung\stillstand...), dann wäre das ja nicht so optimal.
Und theoretisch dürfte der Zombie während der Neuberechnung der Kollisionshülle
ohne Kollisionsabfrage sein... Wäre bei Trace_schüssen in dem Moment nicht so toll, denn die treffen direkt und würden in dem Moment durchgehen.
Was würdet ihr mir generell raten für meinen Shooter?:
lieber Boundingboxen (komplett sicher,schnell, aber sieht bescheuert aus) oder polygongenaue Abfrage (sieht super aus,langsam(??), scheint aber ohne Schwierigkeiten nicht umzusetzen zu sein)?

Oh.. und kann es sein, dass es bei C_updatehull wichtig ist, ob man Vertex- oder ob man Bonesanimationen benutzt?
Ich benutze Bones.

Ich habe heute nochmal mit C_updatehull herumexperimentiert und immer das gleiche Ergebniss bekommen. Der Zombie hat keine Kollisionsabfrage mehr.
Ich habe es auch mal ohne die Gravity-Funkrion probiert. Auch keine Kollision...
Also kann es kein Fehler in meinem Gravity-Script sein.
Ich habe C_updatehull verschiedentlich aufgerufen:
Ich habe C_updatehull immer nach dem ersten Wait(1) ausgeführt bevor der Loop beginnt:
bla set hitpoints to 999999
schadow = on
gewicht = 1000 kg
mtl=normalmapping blabla
Wait(1);
C_updatehull(my,my.frame); oder auch C_updatehull(my,diverse zahlen 1-20, animation hat 30 Einzebilder);
Wait(6);
While(1){blabalbalbalbla}
Ich steig da nicht durch weil irgendwas kann nicht stimmen....
Tolle Kollisionserkennung. Eigentlich wollte ich keine Kollisionerkennung benutzen, die schon zu Quake3 Zeiten alt war...
Habe bei Google, AU Ressources und GS-WIKI leider auch nur nichts bis wenig darüber gefunden, wie genaue Kollisionsabfragen funktionieren.
Notfalls muss ich Boundingboxen benutzen und das Balancing ganz anders ausrichten....