USE key code

[evil_admin]

Here is some code sent to me before the SDK was out
That resulted in Hullu's plugin to disable the USE key.
It is based on stopping the USE key rather than
stopping the problem of blocking push discs but it
might be a good start to just enable it when an arena
map is loaded. I am way too tired to look at it this evening
but will look at it closer when I load .asm's latest fix.

..\SDK\Multiplayer Source\common\in_buttons.h

void PlayerPreThink (edict_t *pEntity)
{
if (!FStrEq(STRING(pEntity->v.netname), "") &&
(FStrEq(STRING(pEntity->v.classname), "player"))) {
if (pEntity->v.button & (IN_USE)) {
pEntity->v.button = 0;
}
}

RETURN_META (MRES_IGNORED);
}

[Guest]

Yup, that looks like a complete block to me. However, with white disc being solved, then if we could find that peice of code that enables a body to be hit whilst dead... the use key would become redundant, thus the block would be enough.

[kermit]

what sparked this whole thing is that we don't want to discourage mappers from putting 'use' key triggered events in their maps. the block may be good enough for most things but you won't be able to operate the elevator in rc_stalkyard w/ it for example.

i would rather do what wha was suggesting in the other thread. it's not a perfect solution (the 'use' key will be completely disabled for a short while after you're 'pushed'), but it's not bad...and i can already see how i could possibly implement it.

if we could find that peice of code that enables a body to be hit whilst dead...

that's going to be easy to take care of i think.

ty evil for the post.

[Guest]

Ah. I'd forgotten about the elevator-type stuff, or doors, etc.

[GRITS]

too tired evil?
must be partying too hard these days:P

GRITS Ricochet Server still has the 'bug' because we couldnt install the 'Hullu fix' and still use the rc_stalkyard and rc_crossfire maps to their full capabilities. It would be nice to have the ability to use the 'use key' for it intended purpose while fixing the bug.

[Guest]

void ClientCommand( edict_t *pEntity )
{
const char *pcmd = CMD_ARGV(0);
const char *pstr;

// Is the client spawned yet?
if ( !pEntity->pvPrivateData )
  return;

entvars_t *pev = &pEntity->v;

if ( FStrEq(pcmd, "say" ) )
{
  Host_Say( pEntity, 0 );
}
else if ( FStrEq(pcmd, "say_team" ) )
{
  Host_Say( pEntity, 1 );
}
else if ( FStrEq(pcmd, "spectate" ) )
{
  // Prevent this is the cvar is set
  if ( allow_spectators.value )
  {
   CBasePlayer *pPlayer = GetClassPtr((CBasePlayer *)pev);
   edict_t *pentSpawnSpot = EntSelectSpawnPoint( pPlayer );
   pPlayer->StartObserver( VARS(pentSpawnSpot)->origin, VARS(pentSpawnSpot)->angles);
  }
}

else if ( FStrEq(pcmd, "ob_mode" ) )
{
  CBasePlayer *pPlayer = GetClassPtr((CBasePlayer *)pev);
  pPlayer->ObserverInput_ChangeMode();
}
else if ( FStrEq(pcmd, "ob_prev" ) )
{
  CBasePlayer *pPlayer = GetClassPtr((CBasePlayer *)pev);
  pPlayer->ObserverInput_PrevPlayer();
}
else if ( FStrEq(pcmd, "ob_next" ) )
{
  CBasePlayer *pPlayer = GetClassPtr((CBasePlayer *)pev);
  pPlayer->ObserverInput_NextPlayer();
}

else if ( FStrEq(pcmd, "give" ) )
{
  if ( g_flWeaponCheat != 0.0)
  {
   int iszItem = ALLOC_STRING( CMD_ARGV(1) ); // Make a copy of the classname
   GetClassPtr((CBasePlayer *)pev)->GiveNamedItem( STRING(iszItem) );
  }
}

else if ( FStrEq(pcmd, "drop" ) )
{
  // player is dropping an item.
  GetClassPtr((CBasePlayer *)pev)->DropPlayerItem((char *)CMD_ARGV(1));
}
else if ( FStrEq(pcmd, "fov" ) )
{
  if ( g_flWeaponCheat && CMD_ARGC() > 1)
  {
   GetClassPtr((CBasePlayer *)pev)->m_iFOV = atoi( CMD_ARGV(1) );
  }
  else
  {
   CLIENT_PRINTF( pEntity, print_console, UTIL_VarArgs( "\"fov\" is \"%d\"\n", (int)GetClassPtr((CBasePlayer *)pev)->m_iFOV ) );
  }
}
else if ( FStrEq(pcmd, "use" ) )
{
  GetClassPtr((CBasePlayer *)pev)->SelectItem((char *)CMD_ARGV(1));
}

The client is obviously issuing that command. Therefore, wtf is behind CMD_ARGV(1) ? Not sure ... but it's got to be a bad pointer of some sort. Thinking about the multiplayer game, when you are in the Towers using the guns on rc_crossfire, you aren't allowed to move, so maybe what it does is set your body mass to some high figure so you don't actually move if hit.

[Guest]

Bingo!

int CDiscWeapon::GetItemInfo(ItemInfo *p)
{
p->pszName = STRING(pev->classname);
p->pszAmmo1 = "disc";
p->iMaxAmmo1 = MAX_DISCS;
p->pszAmmo2 = NULL;
p->iMaxAmmo2 = -1;
p->iMaxClip = WEAPON_NOCLIP;
p->iSlot = 4;
p->iPosition = 0;
p->iId = WEAPON_DISC;
p->iWeight = 100;
p->iFlags = ITEM_FLAG_NOAUTORELOAD | ITEM_FLAG_NOAUTOSWITCHEMPTY;

return 1;
}

I am pretty sure that the above iWeight is what is doing it.

[Pique]

i havn't really read anything above but i remember hearing you guys had trouble with use key and that modifying the friction doesn't work.

What if you make it so that it doesn't affect your velocity...cause thats what happens when ur hit with a push disc...ur velocity shoots up

here's what shows that its velocity...but i dont code so i dont know how to fix this.

#define DISC_PUSH_MULTIPLIER 1200 // Velocity multiplier used to push a player when hit by a disc

In discwar.h

[evil_admin]

I was able to essentially block the USE key when I wanted but the problem I am seeing is that in arena (where it is blocked) I think the when the button is push, it is blocking the push disc until it is determined to be ignored....like I am not excluding it early enough in the "THINK" process.

I will continue to look at it while the White Disc fix dll continues through testing and on to production.

I am looking at the DISK_PUSH_MULTIPLIER section of code to see if that will shed any light...thanks Pique

[Guest]

Ok, I did a lot of code looking the other day when I came with the above two sections... I did continue looking, and I thought it was to do with MaxSpeed. I looked at m_vecHitVelocity:

disc_weapon_disc.cpp (271):
    // Push the player
    Vector vecDir = pev->velocity.Normalize();
    pOther->pev->flags &= ~FL_ONGROUND;
    ((CBasePlayer*)pOther)->m_vecHitVelocity = vecDir * DISC_PUSH_MULTIPLIER;

Then I looked at Normalize:

util_vector.h (95):
inline Vector Normalize(void) const
{
  float flLen = Length();
  if (flLen == 0) return Vector(0,0,1); // ????
  flLen = 1 / flLen;
  return Vector(x * flLen, y * flLen, z * flLen);
}

This would suggest that if flLen is zero that no vector movement occurs. Not sure why, or what that is for, but it does explain why someone only moves back slightly - the 1.

Length is simply:

util_vector.h (92):
inline float Length(void) const    { return (float)sqrt(x*x + y*y + z*z); }

However, I'm still sure that it has more to do with the Deploy() situation rather than the vectors... but I still can't see what's gonna be causing it.

[kermit]

where in the code are you blocking the use key evil? i can disable the use key's intended purpose by placing that code snippet in the first post in the PlayerPreThink() function in client.cpp but it doesn't stop the blocking or anything...which implies the problem must come into play before the physics is calculated for the current frame right?

[evil_admin]

You are right .asm, I was trying to block it there but it still allowed push disc blocking.

What I found if I block out the following code in /pm_shared/pm_shared.c I can block the USE key:

Code:

    
// Slow down, I'm pulling it! (a box maybe) but only when I'm standing on ground

    if ( ( pmove->onground != -1 ) && ( pmove->cmd.buttons & IN_USE) )
 {
     VectorScale( pmove->velocity, 0.3, pmove->velocity );
 }

pm_shared is the section of code that talks with the client.dll and although the code looks like it wouldn't be for this, it works. Now, if I can pull the map type (arena/deathmatch) at that point I can block it for arena and allow it for deathmatch. Unfortunately map type is not sent to the HL engine so I am trying to set up a global variable that will update during map change.

[evil_admin]

I think I got it...this is the modified code checking for map type. I checked it on rc_stalkyard to ensure I could use the elevator and PnG helped me test on rc_arena. I need to clean up testing code and then port it over to the linux side.

Code:

    // Slow down, I'm pulling it! (a box maybe) but only when I'm standing on ground
 if ( ( pmove->onground != -1 ) && ( pmove->cmd.buttons & IN_USE) )
 {
   //Block if map is arena-type - desNotes
     if (!m_iArenaOff)
     {
   VectorScale( pmove->velocity, 0.3, pmove->velocity );
     }
 }

[kermit]

cool! but maybe we can one-up that a little bit and make it so it "blocks" the use key for dm too while allowing the use key to trigger events like it's intended.

just a thought...that way, it would be independent of the map type and we would be giving the mapper the freedom to add user-triggerable events in any future arena maps (unlikely i know). i'm going to give it a shot this evening and i'll report back.

[evil_admin]

Give it a shot...I think it is possible but I believe it will be very involved. It looks like they tried to write that way in player.cpp but the code in pm_shared.c is taking precedence. I found the tricky part was getting the global variables to update during map change...to make it update when a person gets near an 'object' will be trickier.

[kermit]

evil, you went too far...you're allready done...:D:

in pm_shared.c:

// just comment out this code block:
/*
// Slow down, I'm pulling it! (a box maybe) but only when I'm standing on ground
if ( ( pmove->onground != -1 ) && ( pmove->cmd.buttons & IN_USE) )
{
VectorScale( pmove->velocity, 0.3, pmove->velocity );
}
*/

i tested it on dm, arena and stalkyard...the perfect solution (although pulling a box in rico won't seem all that realistic anymore...:rolleyes:) and it's map independant of course. i can get pushed AND i can trigger events. we don't need it and besides, you will still be able to push boxes in ricochet like normal...hehe.

gj evil :thumb:

[evil_admin]

Thanks .asm....I thought I had tested it commented out but I must have had the player.cpp changes still in....it is cool that USE key is blocked on all maps but still works for triggering.

I will set it up on my linux server and test it tomorrow. If nothing unusual happens I will release it to GRITS' servers.

Thanks again...it is always good to have another pair of eyes!