SDK Known Issues List: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (use subheaders so that a table of contents will appear)
Line 1: Line 1:
=This page contains the list of current known issues in the SDK=
Todo: need to link to a good page about using the diff/patch programs, since I noticed a question about that on http://www.chatbear.com/board.plm?a=viewthread&b=4991&t=564,1108968683,28591&s=20&id=809917#22
Todo: need to link to a good page about using the diff/patch programs, since I noticed a question about that on http://www.chatbear.com/board.plm?a=viewthread&b=4991&t=564,1108968683,28591&s=20&id=809917#22


----
== Server: Host_Error: SV_PackEntity: SendTable_Encode returned false (ent 20). ==
 
'''Issue:''' Host_Error: SV_PackEntity: SendTable_Encode returned false (ent 20).


'''Fix:''' From Jay Stelly: No single entity is allowed to write more than 2KB to the network stream. This error happens when an entity overflows that buffer. It's giving you the entity index which appears to be in the range of players. So I would interpret this to mean that you've got a player attempting to send too much data.
'''Fix:''' From Jay Stelly: No single entity is allowed to write more than 2KB to the network stream. This error happens when an entity overflows that buffer. It's giving you the entity index which appears to be in the range of players. So I would interpret this to mean that you've got a player attempting to send too much data.


----
== Server: The client's health variable is pointlessly sent across the wire twice. ==
 
'''Issue:''' The client's health variable is pointlessly sent across the wire twice.  


'''Fix:'''  
'''Fix:'''  
Line 55: Line 49:
Then you can remove the SendPropInt and RecvPropInt for CBasePlayer::m_iHealth.  (However, I don't have a patch for that yet since it's not a backwards-compatible change.  Will post a patch once I've done so, if no on else beats me to it.)
Then you can remove the SendPropInt and RecvPropInt for CBasePlayer::m_iHealth.  (However, I don't have a patch for that yet since it's not a backwards-compatible change.  Will post a patch once I've done so, if no on else beats me to it.)


----
== Server: weapon_citizensuitcase Assert on startup ==
 
'''Issue:''' Server: weapon_citizensuitcase Assert on startup  


'''Fix:''' Install copy of the SP SDK, then copy the scripts/ directory over  
'''Fix:''' Install copy of the SP SDK, then copy the scripts/ directory over  


----
== Server: Some bullet weapons set to do 0 damage. ==
 
'''Issue:''' Server: Some bullet weapons set to do 0 damage.  


'''Fix:''' Need to edit their AddAmmoType which are strangely set to 0 for some reason.  
'''Fix:''' Need to edit their AddAmmoType which are strangely set to 0 for some reason.  


----
== Server: Some projectile weapons set to do 0 damage. ==
 
'''Issue:''' Server: Some projectile weapons set to do 0 damage.  


'''Fix:''' Need to edit their source files and set a damage.  
'''Fix:''' Need to edit their source files and set a damage.  


----
== Client: --- Missing Vgui material vgui/steam/games/icon_cz ==
 
'''Issue:''' Client: --- Missing Vgui material vgui/steam/games/icon_cz  


'''Fix:''' Create 4 vmts containing <code>"UnlitGeneric"{}</code> since these materials don't seem to be referenced
'''Fix:''' Create 4 vmts containing <code>"UnlitGeneric"{}</code> since these materials don't seem to be referenced
Line 86: Line 72:
'''Fix2:''' Add clear to your rc file in cfg (extract from gcf if non-existant)
'''Fix2:''' Add clear to your rc file in cfg (extract from gcf if non-existant)


----
== Server: The crossbow causes an assertion failure. ==
 
'''Issue:''' Server: The crossbow causes an assertion failure.  


'''Fix:''' Comment out ai_activity.cpp line 53. This doesn't appear to be something that can be fixed in code?  
'''Fix:''' Comment out ai_activity.cpp line 53. This doesn't appear to be something that can be fixed in code?  


----
== Server? Client?: RL explosion invisible, per http://www.chatbear.com/board.plm?a=viewthread&t=970,1107153392,30132&id=786504&b=4991&v=flatold ==
 
'''Issue:''' Server? Client?: RL explosion invisible, per http://www.chatbear.com/board.plm?a=viewthread&t=970,1107153392,30132&id=786504&b=4991&v=flatold  


'''Fix:''' No known workaround.  
'''Fix:''' No known workaround.  


----
== Server: util.cpp (531) : Assertion Failed: !"UTIL_GetLocalPlayer" ==
 
'''Issue:''' util.cpp (531) : Assertion Failed: !"UTIL_GetLocalPlayer"  
Occurs when taking damage to yourself from tossing a table straight up into the air.  
Occurs when taking damage to yourself from tossing a table straight up into the air.  


Line 169: Line 149:
(You could, though it's unlikely to impact performance much since this is not a frequently called function. [[User:Bloodykenny|Bloodykenny]] 17:55, 19 Jul 2005 (PDT))
(You could, though it's unlikely to impact performance much since this is not a frequently called function. [[User:Bloodykenny|Bloodykenny]] 17:55, 19 Jul 2005 (PDT))


----
== Assert !"UTIL_GetLocalPlayer" when using combine ball ==
 
'''Issue:''' Assert !"UTIL_GetLocalPlayer" when using combine ball  


'''Fix:'''
'''Fix:'''
Line 194: Line 172:
'''Note:''' This really is a dirty fix because the combine ball always has to face the player because the model was design without a back side
'''Note:''' This really is a dirty fix because the combine ball always has to face the player because the model was design without a back side


----
== Server: CreateEvent: event 'break_prop' not registered ==
 
'''Issue:''' CreateEvent: event 'break_prop' not registered  


'''Fix:''' This was implemented before breakable props were finished clientside  
'''Fix:''' This was implemented before breakable props were finished clientside  
Line 202: Line 178:
I'm not sure what you're saying the fix is here.  Or is that just a statement explaining why the bug exists in the SDK? [[User:Bloodykenny|Bloodykenny]] 17:57, 19 Jul 2005 (PDT)
I'm not sure what you're saying the fix is here.  Or is that just a statement explaining why the bug exists in the SDK? [[User:Bloodykenny|Bloodykenny]] 17:57, 19 Jul 2005 (PDT)


----
== HL2.exe mysteriously segfaults if you forget to put the client.dll and server.dll in your mod's bin directory ==
 
'''Issue:''' HL2.exe mysteriously segfaults if you forget to put the client.dll and server.dll in your mod's bin directory  


'''Fix:''' Don't do that.  
'''Fix:''' Don't do that.  


----
== Server: If you leave a server online on a certain map for roughly 12-24 hours straight, it begins using 100% CPU. ==


'''Issue:''' If you leave a server online on a certain map for roughly 12-24 hours straight, it begins using 100% CPU.  Possibly a core srcds.exe bug, not an SDK bug?  
Possibly a core srcds.exe bug, not an SDK bug?


I suppose there could be some [[array]] or something inside the HL2 core that grows over time, and must be iterated over each frame?
I suppose there could be some [[array]] or something inside the HL2 core that grows over time, and must be iterated over each frame?
Line 220: Line 194:
'''Fix:''' Ensure you have mp_timelimit set to something nonzero, but less than 12 hours or so.
'''Fix:''' Ensure you have mp_timelimit set to something nonzero, but less than 12 hours or so.


----
== Server/Client: Negative entitygroundcontact crash. ==


'''Issue:''' Negative entitygroundcontact crash. The implications of this SDK bug are not at all clear, but in debug mode you'll get an assert, and in release mode it will presumably segfault.  Update: count < 0 isn't enough - I've changed it to also check > 128 or so.
The implications of this SDK bug are not at all clear, but in debug mode you'll get an assert, and in release mode it will presumably segfault.  Update: count < 0 isn't enough - I've changed it to also check > 128 or so.


'''Fix:'''
'''Fix:'''
Line 245: Line 219:
</pre>
</pre>


----
== Client: Doing a 360 quickly with the Stun Baton as your active weapon causes the screen to flash white ==
 
'''Issue:''' Doing a 360 quickly with the Stun Baton as your active weapon causes the screen to flash white  


'''Fix:''' Fix unknown
'''Fix:''' Fix unknown


----
== Assert on line 866 of mod/src/game_shared/basecombatweapon_shared.cpp ==
 
'''Issue:''' Assert on line 866 of mod/src/game_shared/basecombatweapon_shared.cpp  


'''Fix:''' I haven't been able to determine exactly why this is an assert. It's just "Assert(0);" with no accompanying explanation, but commenting it out results in no problems it seems.
'''Fix:''' I haven't been able to determine exactly why this is an assert. It's just "Assert(0);" with no accompanying explanation, but commenting it out results in no problems it seems.
Line 270: Line 240:
</pre>
</pre>


----
== Client: The mod can appear to have frozen on initial startup ==
 
Originally posted by Garry here: http://www.chatbear.com/board.plm?a=viewthread&b=4991&t=234,1117553034,6915&s=0&id=868372
'''Issue:''' The mod can appear to have frozen on initial startup. Originally posted by Garry here: http://www.chatbear.com/board.plm?a=viewthread&b=4991&t=234,1117553034,6915&s=0&id=868372


'''Fix:''' Issue a "progress_enable" command just before "map <mapname>".
'''Fix:''' Issue a "progress_enable" command just before "map <mapname>".

Revision as of 17:34, 21 July 2005

Todo: need to link to a good page about using the diff/patch programs, since I noticed a question about that on http://www.chatbear.com/board.plm?a=viewthread&b=4991&t=564,1108968683,28591&s=20&id=809917#22

Server: Host_Error: SV_PackEntity: SendTable_Encode returned false (ent 20).

Fix: From Jay Stelly: No single entity is allowed to write more than 2KB to the network stream. This error happens when an entity overflows that buffer. It's giving you the entity index which appears to be in the range of players. So I would interpret this to mean that you've got a player attempting to send too much data.

Server: The client's health variable is pointlessly sent across the wire twice.

Fix:

--- mod/src/cl_dll/c_baseplayer.cpp     2005/06/30 05:54:09     1.6
+++ mod/src/cl_dll/c_baseplayer.cpp     2005/07/16 21:33:33
@@ -1888,3 +1888,7 @@
    BaseClass::SetGroundEntity(ground);
}

+
+int C_BasePlayer::GetHealth() const {
+    return g_PR->GetHealth(entindex());
+}


--- mod/src/cl_dll/c_baseplayer.h       2005/07/11 03:28:41     1.9
+++ mod/src/cl_dll/c_baseplayer.h       2005/07/16 21:05:31
@@ -103,7 +103,7 @@

        // Data handlers
        virtual bool    IsPlayer( void ) const { return true; };
-       virtual int             GetHealth() const { return m_iHealth; };
+       virtual int             GetHealth() const;

        // observer mode
        virtual int                     GetObserverMode() const;


--- mod/src/dlls/player.cpp     2005/07/12 07:38:04     1.33
+++ mod/src/dlls/player.cpp     2005/07/17 04:40:09
@@ -478,7 +478,7 @@
        pl.frags = 0;
        pl.deaths = 0;

-       m_iHealth = 0;
+       m_iHealth = 100;
        Weapon_SetLast( NULL );
        m_bitsDamageType = 0;

Then you can remove the SendPropInt and RecvPropInt for CBasePlayer::m_iHealth. (However, I don't have a patch for that yet since it's not a backwards-compatible change. Will post a patch once I've done so, if no on else beats me to it.)

Server: weapon_citizensuitcase Assert on startup

Fix: Install copy of the SP SDK, then copy the scripts/ directory over

Server: Some bullet weapons set to do 0 damage.

Fix: Need to edit their AddAmmoType which are strangely set to 0 for some reason.

Server: Some projectile weapons set to do 0 damage.

Fix: Need to edit their source files and set a damage.

Client: --- Missing Vgui material vgui/steam/games/icon_cz

Fix: Create 4 vmts containing "UnlitGeneric"{} since these materials don't seem to be referenced

  • materials\VGUI\steam\games\icon_cs.vmt
  • materials\VGUI\steam\games\icon_dod.vmt
  • materials\VGUI\steam\games\icon_hl2mp.vmt
  • materials\VGUI\servers\icon_secure_deny.vmt

Fix2: Add clear to your rc file in cfg (extract from gcf if non-existant)

Server: The crossbow causes an assertion failure.

Fix: Comment out ai_activity.cpp line 53. This doesn't appear to be something that can be fixed in code?

Server? Client?: RL explosion invisible, per http://www.chatbear.com/board.plm?a=viewthread&t=970,1107153392,30132&id=786504&b=4991&v=flatold

Fix: No known workaround.

Server: util.cpp (531) : Assertion Failed: !"UTIL_GetLocalPlayer"

Occurs when taking damage to yourself from tossing a table straight up into the air.

Fix: The following patch fixes the Assert, and appears to be more functionally correct as well. Validation from Valve that the patch is correct would be appreciated.

Index: mod/src/dlls/player.h
===================================================================
--- mod/src/dlls/player.h 2005/02/19 22:20:29 1.2
+++ mod/src/dlls/player.h 2005/02/24 00:35:30
@@ -459,6 +459,7 @@
     // mass/size limit set to zero for none
     static bool CanPickupObject( CBaseEntity *pObject, float massLimit, float sizeLimit );
     virtual void PickupObject( CBaseEntity *pObject, bool bLimitMassAndSize = true ) {}
+    virtual bool IsHoldingEntity( CBaseEntity *pEnt );
     virtual void ForceDropOfCarriedPhysObjects( CBaseEntity *pOnlyIfHoldindThis = NULL ) {}
     virtual float GetHeldObjectMass( IPhysicsObject *pHeldObject );

Index: mod/src/dlls/player.cpp
===================================================================
--- mod/src/dlls/player.cpp 2005/02/21 00:05:42 1.3
+++ mod/src/dlls/player.cpp 2005/02/24 00:35:33
@@ -7447,3 +7447,7 @@
     return cmd;
 }

+bool CBasePlayer::IsHoldingEntity( CBaseEntity *pEnt )
+{
+    return PlayerPickupControllerIsHoldingEntity( m_hUseEntity, pEnt );
+}

Index: mod/src/dlls/physics_impact_damage.cpp
===================================================================
--- mod/src/dlls/physics_impact_damage.cpp 2005/02/18 04:45:50 1.1.1.1
+++ mod/src/dlls/physics_impact_damage.cpp 2005/02/24 00:42:24
@@ -417,12 +417,22 @@
     else if ( pEvent->pObjects[index>GetGameFlags() & FVPHYSICS_PLAYER_HELD )
     {
     // if the player is holding the object, use it's real mass (player holding reduced the mass)
-    CBasePlayer *pPlayer = UTIL_GetLocalPlayer();
-    if ( pPlayer )
-    {
+    CBasePlayer* pPlayer = NULL;
+    {for (int i = 1; i <= gpGlobals->maxClients; i++) {
+        CBasePlayer *temp_player = UTIL_PlayerByIndex(i);
+        if (temp_player
+            && temp_player->edict()
+            && temp_player->IsHoldingEntity(pEvent->pEntities[index])
+        ) {
+            pPlayer = temp_player;
+            break;
+        }
+    }}
+    Assert(pPlayer && "object with FVPHYSICS_PLAYER_HELD but no player holding it");
+    if (pPlayer) {
     float mass = pPlayer->GetHeldObjectMass( pEvent->pObjects[index] );
-    if ( mass > 0 )
-    {
+        Assert((mass > 0) && "player was holding object so mass should be non-zero");
+        if (mass > 0) {
             invMass = 1.0f / mass;
         }
     }

Note: Instead of iterating all players, why not consider adding a m_pHolder var and GetHolder and SetHolder functions to CBaseEntity

(You could, though it's unlikely to impact performance much since this is not a frequently called function. Bloodykenny 17:55, 19 Jul 2005 (PDT))

Assert !"UTIL_GetLocalPlayer" when using combine ball

Fix:

diff -u -r1.1.1.1 prop_combine_ball.cpp 
--- mod/src/dlls/hl2_dll/prop_combine_ball.cpp 2005/02/18 04:45:52 1.1.1.1 
+++ mod/src/dlls/hl2_dll/prop_combine_ball.cpp 2005/02/24 01:34:21 
@@ -788,9 +788,9 @@ 
     pPhysicsObject->GetPosition( &vecPosition, NULL ); 
     pPhysicsObject->GetVelocity( &vecVelocity, NULL ); 

-    CBasePlayer *pPlayer = UTIL_GetLocalPlayer(); 
-    if ( pPlayer ) 
+    if (gpGlobals->maxClients == 1) 
     { 
+    CBasePlayer *pPlayer = UTIL_GetLocalPlayer(); 
     Vector vecDelta; 
     VectorSubtract( pPlayer->GetAbsOrigin(), vecPosition, vecDelta ); 
     VectorNormalize( vecDelta );

Note: This really is a dirty fix because the combine ball always has to face the player because the model was design without a back side

Server: CreateEvent: event 'break_prop' not registered

Fix: This was implemented before breakable props were finished clientside

I'm not sure what you're saying the fix is here. Or is that just a statement explaining why the bug exists in the SDK? Bloodykenny 17:57, 19 Jul 2005 (PDT)

HL2.exe mysteriously segfaults if you forget to put the client.dll and server.dll in your mod's bin directory

Fix: Don't do that.

Server: If you leave a server online on a certain map for roughly 12-24 hours straight, it begins using 100% CPU.

Possibly a core srcds.exe bug, not an SDK bug?

I suppose there could be some array or something inside the HL2 core that grows over time, and must be iterated over each frame?

I haven't run the long-running map scenario in a long time. The alpha server for my mod is full most of the day and players frag out so the map is always changing.

That said, I seem to recall that the move from the usual 5% cpu to 100% cpu was fairly drastic and immediate. I never saw an intermediate stage where the server used 25% cpu or 50% cpu etc. I would expect to see those intermediate levels if it was a memory leak.

Fix: Ensure you have mp_timelimit set to something nonzero, but less than 12 hours or so.

Server/Client: Negative entitygroundcontact crash.

The implications of this SDK bug are not at all clear, but in debug mode you'll get an assert, and in release mode it will presumably segfault. Update: count < 0 isn't enough - I've changed it to also check > 128 or so.

Fix:

--- mod/src/game_shared/usercmd.cpp 2005/02/18 04:45:54 1.1.1.1
+++ mod/src/game_shared/usercmd.cpp 2005/03/23 02:24:00
@@ -290,7 +290,12 @@
 #if defined( HL2_DLL )
     if ( buf->ReadOneBit() )
     {
-        move->entitygroundcontact.SetCount( buf->ReadShort() );
+        int count = buf->ReadShort();
+        if (count < 0) {
+        Msg("Ignoring strange entitygroundcontact count: %d\n", count);
+        return; // why can this be less than 0, Valve? change to ReadWord()???
+    }
+    move->entitygroundcontact.SetCount( count );

     int i;
     for (i = 0; i < move->entitygroundcontact.Count(); i++)

Client: Doing a 360 quickly with the Stun Baton as your active weapon causes the screen to flash white

Fix: Fix unknown

Assert on line 866 of mod/src/game_shared/basecombatweapon_shared.cpp

Fix: I haven't been able to determine exactly why this is an assert. It's just "Assert(0);" with no accompanying explanation, but commenting it out results in no problems it seems.

--- mod/src/game_shared/basecombatweapon_shared.cpp     2005/02/18 04:45:53     1.1
+++ mod/src/game_shared/basecombatweapon_shared.cpp     2005/03/04 03:45:36     1.2
@@ -863,7 +863,7 @@
        CBaseViewModel *vm = pOwner->GetViewModel( m_nViewModelIndex );
        if ( vm == NULL )
        {
-               Assert( false );
+               //Assert( false );
                return false;
        }

Client: The mod can appear to have frozen on initial startup

Originally posted by Garry here: http://www.chatbear.com/board.plm?a=viewthread&b=4991&t=234,1117553034,6915&s=0&id=868372

Fix: Issue a "progress_enable" command just before "map <mapname>".

I don't understand this solution. The client never issues a "map" command or any command. You just double-click the Steam window, the client connects to the server, and through all that time the HL2 window appears frozen. Can you point to a line of code? Bloodykenny 17:55, 19 Jul 2005 (PDT)