Tag zusammen,

ich spiel im Moment so ein bisschen am Half-Life 1 Code (SDK 2.3) rum, und probier mal so ein paar Sachen aus. Ich hab vorher nie irgendwelches 3D-Zeug programmiert, von daher tu ich mich momentan etwas schwer mit der Sache - bin daher auch noch nicht so ganz im HL-Code drin..

Ich sitz jetzt schon seit mehreren Tagen daran und suche vergebens irgendeine Möglichkeit, die Gravity zu "richten". Ich gehe mal davon aus, dass das Serverseitig passieren muss - und da ich am Multiplayercode rumspiele stellt sich ja die Frage ob das dann serverseitig global umgestellt werden würde, oder einzeln pro Player.
Aber die Überlegungen haben ja noch Zeit - was mir überhaupt fehlt ist die Stelle, an der die Gravity eingerechnet wird. Ich hab zwar in /pm_shared/pm_shared.c ein bisschen was interessantes gefunden (void PM_AirMove (void)), wo zwar die ganzen Bewegungsrichtungen in der Luft berechnet werden, aber ich trotzdem nichts direkt von Einwirkungen der Schwerkraft finden konnte.

Dann gibts da in derselben File noch die Funktion
Quellcode:void PM_AddGravity ()
{
    float    ent_gravity;

    if (pmove->gravity)
        ent_gravity = pmove->gravity;
    else
        ent_gravity = 1.0;

    // Add gravity incorrectly
    pmove->velocity[2] -= (ent_gravity * pmove->movevars->gravity * pmove->frametime );
    pmove->velocity[2] += pmove->basevelocity[2] * pmove->frametime;
    pmove->basevelocity[2] = 0;
    PM_CheckVelocity();
} Die sieht ja noch viel interessanter aus, ich seh ja auch dass die Geschwindigkeiten in der z-Richtung berechnet werden, aber das ist ja einfach alles fest reingecodet. Wenn ich das jetzt als Vektor anpassen will, gehe ich richtig der Annahme, dass der Aufwand nicht ganz unerheblich ist? ;)
Aber das wär ja noch durchaus machbar. Jetzt noch: ist diese PM_AddGravity() überall eingesetzt, wo solche Einwirkungen gebraucht werden, oder ist das so wie bei dem AirMove-Teil, dass da einfach direkt die z-Richtung genullt wird etc.?
Bisher konnte ich nämlich die AddGravity-Funktion nur eingesetzt sehen, wenn z.B. die toten Player nachher durch die Luft fliegen.

Edit:
Wenn ich in o.g. AddGravity-Funktion einfach mal die Vektorkomponente 2 (z) durch 1 (y) ersetze, dann bleibt alles ingame beim alten, nur dass die toten Player nachher tatsächlich in ne andere Richtung "fallen".. allerdings auch nur bis sie dann aufgekommen sind und 1 Sek gelegen haben, dann fallen sie nochmal "richtig" in Z-Richtung runter. Irgendwie is das ganz schön durcheinander alles...

MfG Jean

Wenn du einfach nur die Gravity fest entlang einer anderen Koordinatenachse richten willst sollte das relativ einfach sein. Dazu reicht es allerdings nicht alleine die PM_AddGravity Funktion zu ändern, da alleine in der pm_shared.c mindestens diese Funktionen auch noch die Velocity behandeln:

Quellcode:PM_AddGravity
PM_AddCorrectGravity
PM_FixupGravityVelocity
PM_Physics_Toss
Das Problem wird aber sein, dass der gesamt Code für Gravity in negative Z Richtung geschreiben ist, d.h. dass du den restlichen Code auch mal nach der velocity Variable durchsuchen musst, um zu sehen was dort möglichweise geändert werden muss.

Ich habe den Code mal gerade oberflächlich durchsucht und des Grossteil des Code der mit der velocity arbeitet scheint richtungsneutral zu sein.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

Ja.. ich hab jetzt die vuser1-Variable aus pmove für meinen Gravity-Vektor genommen. Der muss halt normalisiert sein, damit man damit gescheit arbeiten kann.. hab dann in der AddCorrectGravity mal n bisschen was geändert und die Anziehungskraft Komponentenweise errechnet:

Quellcode:for (i=0; i < 3; i++) {
        pmove->velocity[i] -= pmove->vuser1[i] * (ent_gravity * pmove->movevars->gravity * 0.5 * pmove->frametime );
        pmove->velocity[i] += pmove->vuser1[i] * pmove->basevelocity[i] * pmove->frametime;
        pmove->basevelocity[i] = 0;
    } Was sich jetzt als Problem stellt: momentan hab ich das so gelöst, dass bei einer Kollision zwischen Player und nem Plane der Normalenvektor des getroffenen Planes der neue Richtungsvektor für die Anziehungskraft ist. Funktioniert so weit auch, also das switcht hin und her, wenn ich in der Luft unterwegs irgendwo gegen klatsche *g*
Aber: auch wenn das Plane, was dann ja denselben Normalenvektor hat wie mein Richtungsvektor der Anziehungskraft, zwar Gravitätstechnisch exakt plan ist, slidet der Player daran rum und ich kann nicht drauf laufen, weil das irgendwie nicht als Boden erkannt wird.
Auszug aus der PM_FlyMove:

Quellcode:// If the plane we hit has a high z component in the normal, then
        //  it's probably a floor        
        //if (trace.plane.normal[1] > 0.7)
        if (1)
        {
            VectorCopy(trace.plane.normal, pmove->vuser1);
            blocked |= 1;        // floor
        } Das ehemalige if hab ich auskommentiert (und ja ich weiß, dass ich mir das if(1) auch sparen kann, aber ging grad schneller.. ich teste ja noch ;) )
Naja, dann kopier ich den Normalenvektor in den Anziehungskraftvektor und sage: das is ein Boden, auf dem du stehst. Ich muss jetzt natürlich noch Pitch/Yaw/Roll vom Playerview an den Vektor anpassen, damit das auch gescheit aussieht nachher.. aber daran kann das doch nicht liegen, dass ich nicht auf dem Plane laufen kann, oder?

MfG, Jean

Hast du mal die Werte der beteilgten Vektoren ausgegeben, um zu sehen was da passiert wenn du slidest und das Plane nicht als Floor erkannt wird?

Wie hast du denn überhaupt die Berechnug gemacht mit der du bestimmst, dass sich der Richtungsvektor der Anziehungskraft und die Planenormal ähnlich sind?

Da musst du im Prinzip das Skalarprodukt zwischen den beiden bilden:

Quellcode:if (DotProduct(trace.plane.normal, pmove->vuser1) > 0.7) {
    [...]
}
Je ähnlicher sich die beiden Vektoren desto näher ist das Skalarprodukt an 1, unter der Voraussetzung, dass beide normalisiert sind.

Ist fraglich ob du das so willst. Je nachdem was du erreichen willst. Mit dem Skalarprodukt und dem Vegleichswert 0.7 sollte man um Kugeln herlaufen können, wenn du das so lässt wie du es jetzt hast kannst du an jeder Wand herum laufen und der Decke, wenn ich das richtig verstanden habe.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

Ich berechne nicht, ob die beiden sich ähnlich sind, denn:
Egal welches Plane ich berühre: bei einer Kollision wird der Anziehungskraftvektor gleich dem Planenormal. D.h. ich gehe einfach davon aus dass die beiden nach einer Kollision gleich sind und muss nichts berechnen. Kann natürlich sein dass das dann irgendwann zu extrem wird, grad bei so ner Kugelsache oder so, bzw. viel eher noch bei Innenecken. In dem Fall müsst ich dann auf das Skalarprodukt zurückgreifen, aber im Moment gehts ja noch so ;)

Ich weiß doch noch nichtmal wie ich im HL-Code Werte auf der Console printen kann.. Hab zwischendurch mal so ne ALERT-Funktion gesehen, muss ich die nehmen oder kann ich ein normales printf nutzen?

Edit: ich glaub dass ich noch ein Problem in der ClipVelocity-Funktion hab. Denn da wird schon wieder auf die Z-Komponente geprüft und dementsprechend zurückgegeben obs Boden war oder irgendeine steile/senkrechte Wand.

Um etwas auf die Console auszugeen gibts mehrer Möglichkeiten, dazu zählt auch ALERT:

Quellcode:// allgemein etwas auf die Console des Players ausgeben zu dem das edict_t* pev gehört
edict_t* pev = ...
ClientPrint(pev, HUD_PRINTCONSOLE,
            UTIL_VarArgs("normal: %f %f %f, vuser1: %f %f %f\n",
                         trace.plane.normal[0], trace.plane.normal[1], trace.plane.normal[2],
                         pmove->vuser1[0], pmove->vuser1[1], pmove->vuser1[2]));

// da man aber im PM Code kein edict_t* zu haben scheint gibt's wohl diese Funktion
pmove->Con_Printf("normal: %f %f %f, vuser1: %f %f %f\n",
                  trace.plane.normal[0], trace.plane.normal[1], trace.plane.normal[2],
                  pmove->vuser1[0], pmove->vuser1[1], pmove->vuser1[2]);


Zitat:

LeJean postete
Edit: ich glaub dass ich noch ein Problem in der ClipVelocity-Funktion hab. Denn da wird schon wieder auf die Z-Komponente geprüft und dementsprechend zurückgegeben obs Boden war oder irgendeine steile/senkrechte Wand.

Quellcode:backoff = DotProduct (in, normal) * overbounce;


"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

Jo, Ausgabe hab ich schon rausgefunden.

in der ClipVelocity hatte ich die beiden ifs schon umgangen und das blocked-Flag in jedem Fall setzen lassen. Die dann folgende Geschwindigkeitsberechnung, die ja die Teilgeschwindigkeit beim Entlangsliden an der Fläche berechnet, hab ich rauskommentiert und den output-Vektor einfach genullt.
Immerhin klappts jetzt dass ich sofort an ner Wand klebe wenn ich sie berühre. Ich kann nur nicht richtig laufen, sondern mich nur gaaanz langsam mittels Air-Control in der Luft fortbewegen. Sind die Bewegungsrichtungen des Spielers abhängig von den Pitch-Yaw-Roll Werten zum Boden? Ich kann mir nicht vorstellen, dass ich den Player erstmal drehen müsste um dann an der Wand laufen zu können.. schätzungsweise muss ich sowieso bei den ganzen Bewegungen erstmal zusehen, dass ich die auf den Vektor umgemünzt bekomme.
Auf jeden Fall schonmal vielen Dank bis hierher!

MfG, Jean

Es kann sein das auf die Bewegungskommandos +forward usw. gleich mit Änderung der velocity reagiert wird, siehe CL_CreateMove in cl_dlls\input.cpp. Da werden die Tastenbefehle in Befehle an den Server umgesetzt und da gibts sowas wie:

Quellcode:cmd->forwardmove
cmd->sidemove
cmd->upmove
Ich weiss nur gerade nicht wie und wo das in der server.dll verarbeitet wird, mal herausfinden.

Edit:

In PM_WalkMove wird das usercmd_s*, das in CL_CreateMove erzeugt wird, übersetzt:

Quellcode:// Copy movement amounts
fmove = pmove->cmd.forwardmove;
smove = pmove->cmd.sidemove;

// Zero out z components of movement vectors
pmove->forward[2] = 0;
pmove->right[2]   = 0;

VectorNormalize (pmove->forward);  // Normalize remainder of vectors.
VectorNormalize (pmove->right);    //

for (i=0 ; i<2 ; i++)       // Determine x and y parts of velocity
    wishvel[i] = pmove->forward[i]*fmove + pmove->right[i]*smove;

wishvel[2] = 0;             // Zero out z part of velocity

VectorCopy (wishvel, wishdir);   // Determine maginitude of speed of move
wishspeed = VectorNormalize(wishdir);

[...]
Da musst du dann wohl mit deinem aktuellen Gravitiyvektor die passenden Bewegungsvektoren berechnen.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

Ja genau, an der Stelle sitz ich jetzt auch schon wieder seit einiger Zeit. Ergibt sich nur die Problematik, dass ich eine Transformation des Koordinatensystems über Eulersche Winkel, Rotationsmatrix oder Quanternionen machen muss, was sich doch als etwas komplizierter herausstellt.
Es sind zwar Vektoren mit 4 Komponenten in der Engine vorgesehen, aber noch nicht vollständig implementiert.