Wallwalkable buildings?

[rotacak]

Hi, Is technically possible make buildings wallwalkable for aliens?

[Taiyo.uk]

What exactly do you mean? Be able to build all buildings on walls?

[rotacak]

No, you can walk with dretch on walls, but you can't walk on armoury, overmind etc. You can only jump there, if that building is not too tall.
Also climbing on player models will be funny too :-)

[Plague Bringer]

Suggested and shot down, but not deemed impossible as of yet. I dare say I'd enjoy replacing a human's battery pack with my dretch.

[kevlarman]

Suggested and shot down

this isn't the place to discuss whether or not it's a good idea.
it's possible to do while buildings can't move, but as soon as they start moving (shrinking barricades) it becomes much more difficult to do without causing big problems.

[rotacak]

I dare say I'd enjoy replacing a human's battery pack with my dretch.

 

it's possible to do while buildings can't move, but as soon as they start moving (shrinking barricades) it becomes much more difficult to do without causing big problems.

But hitbox does not change form when shrinking, isn't? And can you teach me in what source file or function name should be modified this?

[kevlarman]

the whole point of shrinking barricades was to make the bbox shrink and let aliens over the top of the barricade.

[rotacak]

In bg_pmove.c is function PM_GroundClimbTrace() and there:

Code: [Select]

   
//if we hit something
    if( trace.fraction < 1.0f && !( trace.surfaceFlags & ( SURF_SKY | SURF_SLICK ) ) &&
        !( trace.entityNum != ENTITYNUM_WORLD && i != 4 ) )

If I remove " && !( trace.entityNum != ENTITYNUM_WORLD && i != 4 )" then is possible climb on buildables, but my view is still same, like when I am on ground :-( And position on buildables is little gummy.

Any help?

[kevlarman]

you'll have to mess with the normal to fix your view, or add a special case where the view angles are set for when you are stuck to a buildable. not sure what you mean by position on buildables being gummy

[Risujin]

It isn't just shrinkable barricades, if a building is shot out from under you, the game might not update. Either way I think this is something to look into, I will add it to the MGDev TODO list.

[kevlarman]

just please don't do anything like this on the server side only, misspredictions are almost as good at making 9 year old girls cry as apple's lawyers

[rotacak]

not sure what you mean by position on buildables being gummy

When I climb on wall then I am there like stone.
When I climb on OM etc. then I am jitter. Something probably pushing me milimeter down and milimeter up in cycle.

When someone (I probably no, because my knowlege C language and understandig sources is very poor) make this done, then will be that mod very very funny, especially when make this:


Not like this:

[kevlarman]

not sure what you mean by position on buildables being gummy

When I climb on wall then I am there like stone.
When I climb on OM etc. then I am jitter. Something probably pushing me milimeter down and milimeter up in cycle.

When someone (I probably no, because my knowlege C language and understandig sources is very poor) make this done, then will be that mod very very funny, especially when make this:

that's your client misspredicting a fall, in general bad things happen when the cgame's pmove is different than the game's pmove. wallwalking on anything that has the ability to move will probably never work well enough to be practical (unless the client has the ability to predict that movement, but players don't fall into this category)

[Risujin]

that's your client misspredicting a fall, in general bad things happen when the cgame's pmove is different than the game's pmove.

No, we get this on MGDev too. The server sends client positions snapped to integer values. Because some of the models' bounding boxes or perhaps their bounding box height + origin are not rounded to an integer, the client rightly expects you to fall some fraction of a unit.

[jal]

that's your client misspredicting a fall, in general bad things happen when the cgame's pmove is different than the game's pmove. wallwalking on anything that has the ability to move will probably never work well enough to be practical (unless the client has the ability to predict that movement, but players don't fall into this category)

Yeah, and even stuff with constant velocity vectors will be very hard to predict. I think allowing wallwalking on certain entities can be an all positive addition, but only to stuff that can't move (ie: buildables).

That been said. Doesn't Q3 have a pmove flag for disabling prediction? If yes, the less disgusting "fix" for the prediction missmatches when wallwalking players is setting that bit flag from the server. And I say the less disgusting implying I would choose to not allow to wallwalk on players, but if you insist, that should be the way to go.

[Risujin]

This patch lets you wallwalk on buildables and players:

Code: [Select]

Index: src/game/bg_pmove.c
===================================================================
--- src/game/bg_pmove.c (revision 93)
+++ src/game/bg_pmove.c (working copy)
@@ -1831,7 +1831,7 @@
   //used for delta correction
   vec3_t    traceCROSSsurf, traceCROSSref, surfCROSSref;
   float     traceDOTsurf, traceDOTref, surfDOTref, rTtDOTrTsTt;
-  float     traceANGsurf, traceANGref, surfANGref;
+  float     traceANGref, surfANGref;
   vec3_t    horizontal = { 1.0f, 0.0f, 0.0f }; //arbituary vector perpendicular to refNormal
   vec3_t    refTOtrace, refTOsurfTOtrace, tempVec;
   int       rTtANGrTsTt;
@@ -1908,10 +1908,9 @@
         pm->trace( &trace, pm->ps->origin, pm->mins, pm->maxs, point, pm->ps->clientNum, pm->tracemask );
         break;
     }
-
+   
     //if we hit something
-    if( trace.fraction < 1.0f && !( trace.surfaceFlags & ( SURF_SKY | SURF_SLICK ) ) &&
-        !( trace.entityNum != ENTITYNUM_WORLD && i != 4 ) )
+    if( trace.fraction < 1.0f && !( trace.surfaceFlags & ( SURF_SKY | SURF_SLICK ) ) )
     {
       if( i == 2 || i == 3 )
       {
@@ -1933,11 +1932,7 @@
 
       //calculate angle between surf and trace
       traceDOTsurf = DotProduct( trace.plane.normal, surfNormal );
-      traceANGsurf = RAD2DEG( acos( traceDOTsurf ) );
 
-      if( traceANGsurf > 180.0f )
-        traceANGsurf -= 180.0f;
-
       //calculate angle between trace and ref
       traceDOTref = DotProduct( trace.plane.normal, refNormal );
       traceANGref = RAD2DEG( acos( traceDOTref ) );
@@ -1968,7 +1963,6 @@
 
           //calculate reference rotated through to surf plane then to trace plane
           RotatePointAroundVector( tempVec, surfCROSSref, horizontal, -surfANGref );
-          RotatePointAroundVector( refTOsurfTOtrace, traceCROSSsurf, tempVec, -traceANGsurf );
 
           //calculate angle between refTOtrace and refTOsurfTOtrace
           rTtDOTrTsTt = DotProduct( refTOtrace, refTOsurfTOtrace );
@@ -1994,10 +1988,6 @@
         //construct a point representing where the player is looking
         VectorAdd( pm->ps->origin, lookdir, point );
 
-        //check whether point is on one side of the plane, if so invert the correction angle
-        if( ( abc[ 0 ] * point[ 0 ] + abc[ 1 ] * point[ 1 ] + abc[ 2 ] * point[ 2 ] - d ) > 0 )
-          traceANGsurf = -traceANGsurf;
-
         //find the . product of the lookdir and traceCROSSsurf
         if( ( ldDOTtCs = DotProduct( lookdir, traceCROSSsurf ) ) < 0.0f )
         {
@@ -2005,15 +1995,6 @@
           ldDOTtCs = DotProduct( lookdir, traceCROSSsurf );
         }
 
-        //set the correction angle
-        traceANGsurf *= 1.0f - ldDOTtCs;
-
-        if( !( pm->ps->persistant[ PERS_STATE ] & PS_WALLCLIMBINGFOLLOW ) )
-        {
-          //correct the angle
-          pm->ps->delta_angles[ PITCH ] -= ANGLE2SHORT( traceANGsurf );
-        }
-
         //transition from wall to ceiling
         //normal for subsequent viewangle rotations
         if( VectorCompare( trace.plane.normal, ceilingNormal ) )

More refined control and dealing with the gameplay consequences is left as an exercise for the reader. Note that if the entity you are wallwalking on moves, you are not carried with it.

Also, the patch is against MGDev SVN not Icculus but it should apply just fine. This is a client and server modification.

[rotacak]

Damm, I can't make it work. That solution giving me same result like my small change in source, that I describe before :-(
Or I must use also cgame.qvm?

[==Troy==]

the modification has to be both client and server side. Dont forget to update vms pack

[rotacak]

the modification has to be both client and server side. Dont forget to update vms pack

You tried it?