Invisible weapons bug

[Adrianilloo]

It has been months since I started to research very deeply about this problem, without any solution. Problem happens at least on HL2MP, but may happen on the rest of multiplayers. Steps to reproduce the issue:

1. Run the game and join your dedicated server or another, with sv_cheats 1 enabled (bug does not happen on listenservers).
2. Think of any weapon you spawned with, or give yourself one with command "give weapon_XYZ".
3. (This step must come after 2. of bug will not happen) Now spawn a weapon of the same type, command "ent_create weapon_XYZ".

It will have a great change to show invisible. Keep spawning it and you will check it shows invisible most of the attempts. Few workarounds to fix invisibility at this point: do a demo record and stop it / reconnect to server / type command "mat_reloadallmaterials".

I am attempting sometimes to fix it on my SDK2013 mod, but haven't come to anything.

[kisak-valve]

Hello @Adrianilloo, please copy your system information from steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

[Adrianilloo]

System info:
https://gist.github.com/AdRiAnIlloO/bbd1f2823b903ec2b29f753b4af6bd92

[gtamike]

Have you tried this temporarily fix? (It's the same demo fix but with bindable keyboard key.
https://gamebanana.com/scripts/9664
Works in all source engine games.

[Adrianilloo]

Have you tried this temporarily fix? (It's the same demo fix but with bindable keyboard key.
https://gamebanana.com/scripts/9664
Works in all source engine games.

Not like it's a convenient solution, given that this bug seems to happen with independency of graphics driver or similar and thus be widespread. But thanks, I'll use it.

[Adrianilloo]

After debugging the problem, I determined the following semi-accurate behaviour of what's happening.

1. When client has a certain weapon and a new one of the same class is spawned during map (e.g. via ent_create), even when you don't pick it up, the new weapon somehow initially assigns its m_hOwner to the player (incoherently), which may cause a next UpdateVisibility() call on client not to make the weapon worldmodel's visible due to the m_hOwner pointing to a valid handle and other derived conditions.
2. Then, the server transfers the correct m_hOwner encoding a NULL value as it should (no owner), but it may happen to arrive at client either before or after some other initially-changing netprops which trigger the UpdateVisibility() call. Note that when m_hOwner is NULL, the UpdateVisibility() logic allows to draw the weapon worldmodel. So, in the case m_hOwner update arrives later, client still has this handle value pointing to his player instance and thus the calls to UpdateVisibility() triggered by these other netprops may cause the weapon's worldmodel to stay invisible (per step 1), and this function won't be called again while the weapon stays there on the ground, unequipped. Otherwise (if the m_hOwner update happens earlier), the weapon's worldmodel will draw and keep visible forever.

Since netprops networking order of arrival is involved, the chance of bug arising depends also on the latency of the client to the server, that's why it doesn't seem to happen ever on a listenserver.

An appropiate permanent fix involves triggering an UpdateVisibility() call when m_hOwner is received on client, through a RecvProxy. Not casually, few other netprops are doing the same to trigger this call on receival. Indeed, the function CBaseCombatWeapon::SetOwner(), also calls it at the client DLL, but naturally it isn't called automatically when m_hOwner at client changes through network. So this patch does it:

diff --git a/mp/src/game/shared/basecombatweapon_shared.cpp b/mp/src/game/shared/basecombatweapon_shared.cpp
index 57d76685..1d7d3f32 100644
--- a/mp/src/game/shared/basecombatweapon_shared.cpp
+++ b/mp/src/game/shared/basecombatweapon_shared.cpp
@@ -2827,6 +2827,17 @@ void CBaseCombatWeapon::RecvProxy_WeaponState( const CRecvProxyData *pData, void
        pWeapon->m_iState = pData->m_Value.m_Int;
        pWeapon->UpdateVisibility();
 }
+
+static void RecvProxy_WeaponOwner(const CRecvProxyData* pData, void* pStruct, void* pOut)
+{
+       RecvProxy_IntToEHandle(pData, pStruct, pOut);
+
+       // Fix weapons spawned during level possibly becoming invisible for some clients
+       CBaseCombatWeapon* pWeapon = (CBaseCombatWeapon*)pStruct;
+       pWeapon->UpdateVisibility();
+}
 #endif

 #if PREDICTION_ERROR_CHECK_LEVEL > 1
@@ -2901,6 +2912,6 @@ BEGIN_NETWORK_TABLE(CBaseCombatWeapon, DT_BaseCombatWeapon)
        RecvPropInt( RECVINFO(m_iViewModelIndex)),
        RecvPropInt( RECVINFO(m_iWorldModelIndex)),
        RecvPropInt( RECVINFO(m_iState), 0, &CBaseCombatWeapon::RecvProxy_WeaponState ),
-       RecvPropEHandle( RECVINFO(m_hOwner ) ),
+       RecvPropEHandle( RECVINFO(m_hOwner ), RecvProxy_WeaponOwner ),
 #endif
 END_NETWORK_TABLE()

[Yetoo1]

Please reopen this. The chances this will get fixed or patched with this closed is significantly more slim than if it was open.