Talk:Simulated Bullets
I'd really like assistance with this if anyone can do any implementation of this or any fixes to the bullet simulator... implementation includes making the gun shoot them out, making the bullets hurt, and making clientside effects... I have a feeling that other mods WILL want to use timed bullets, and this code will do the trick... I just need help (or plenty of time) getting it finished first and then it will be available to everyone!—ts2do (Talk | @) 23:06, 20 Nov 2005 (PST)
- Yes ts2do (you went away before i came back), the myth was busted, best to contact Wrayith at Nightfall mod for more info. He was interested, and was implementing something like this with the quake 2 code, and was going to port it to hl2 latter. MSN wraiyth@gmail.com --Amckern 01:07, 21 Nov 2005 (PST)
[snip]
I was thinking that too...I put a constructor and deconstructor in the manager that prints warnings saying created and destroyed...I'll see if it's destroying it too soon then—ts2do (Talk | @) 19:19, 27 Nov 2005 (PST)
Ok...I made it so it creates the manager when it does the clientshared thing...haven't tried restarting the server and seeing if it's still intact yet tho...what I did b4 was made it when the clientdll initialized WHICH ISN"T GOODZ!—ts2do (Talk | @) 19:32, 27 Nov 2005 (PST)
Now it fails Assert( !"CreateNoSpawn: only works for CBaseEntities" );
.
server.dll!CBaseEntity::CreateNoSpawn(const char * szName=0x22a8b92c, const Vector & vecOrigin={...}, const QAngle & vecAngles={...}, CBaseEntity * pOwner=0x00000000) Line 2451 + 0x69 C++ server.dll!CBaseEntity::Create(const char * szName=0x22a8b92c, const Vector & vecOrigin={...}, const QAngle & vecAngles={...}, CBaseEntity * pOwner=0x00000000) Line 2436 + 0x15 C++ server.dll!CGameRules::CreateStandardEntities() Line 552 + 0x16 C++ server.dll!CHL2MPRules::CreateStandardEntities() Line 183 C++ server.dll!CWorld::Precache() Line 605 C++ server.dll!CWorld::Spawn() Line 513 C++ server.dll!DispatchSpawn(CBaseEntity * pEntity=0x0bd13400) Line 1727 C++ server.dll!MapEntity_ParseAllEntities(const char * pMapData=0x118cf1d8, IMapEntityFilter * pFilter=0x00000000, bool bActivateEntities=false) Line 329 + 0xc C++ server.dll!CServerGameDLL::LevelInit_ParseAllEntities(const char * pMapEntities=0x118cf040) Line 27 + 0xd C++ server.dll!CServerGameDLL::LevelInit(const char * pMapName=0x0de1fb10, const char * pMapEntities=0x118cf040, const char * pOldLevel=0x00000000, const char * pLandmarkName=0x00000000, bool loadGame=false, bool background=false) Line 700 C++
szName "bullet_manager" const char * vecOrigin {x=0.00000000 y=0.00000000 z=0.00000000 } const Vector & vecAngles {x=0.00000000 y=0.00000000 z=0.00000000 } const QAngle & pOwner 0x00000000 CBaseEntity *
—Maven (talk) 20:10, 27 Nov 2005 (PST)
well I did LINK_ENTITY_TO_CLASS...do you have that?—ts2do (Talk | @) 20:30, 27 Nov 2005 (PST)
I solved it not thinking on the client...but now it's giving me an assert when SetNextClientThink( TICK_NEVER_THINK );
in RemoveBullet
is done—ts2do (Talk | @) 20:53, 27 Nov 2005 (PST)
- Do you mean
Assert( GetClientHandle() != INVALID_CLIENTENTITY_HANDLE );
inC_BaseEntity::SetNextClientThink
? —Maven (talk) 08:59, 28 Nov 2005 (PST)
ok it did crash on restart...what's also notable is the fact that there's a slight difference between the serverside and clientside direction vectors (normal)—ts2do (Talk | @) 23:38, 27 Nov 2005 (PST)
I'm currently failing the if ( !m_ThinkEntries.IsInList( (unsigned long)hThink ) )
line in CClientThinkList::PerformThinkFunctions()
. It fires the assert in CUtlLinkedList<T,I>::Previous
with i==42, m_TotalElements==43, and unknown contents of m_Memory[i]. If I rerun it I get different values of i, but it's always one less than m_TotalElements. This might be related to the SetNextClientThink( TICK_NEVER_THINK );
problem you mentioned. —Maven (talk) 08:59, 28 Nov 2005 (PST)
Did you catch my edit?
in clientmode_shared.cpp
HOOK_MESSAGE( Bullet ); if(!g_pBulletManager) { g_pBulletManager = (C_BulletManager *)CreateEntityByName("bullet_manager"); ClientEntityList().AddNonNetworkableEntity(g_pBulletManager); }
—ts2do (Talk | @) 16:26, 28 Nov 2005 (PST)
- Yup, I have that. Running it again, I had several successful shots before one caused the error. I intend to do more testing later. —Maven (talk) 19:39, 28 Nov 2005 (PST)
Maven...you must help me...I've been looking at:
inline T& CUtlMemory<T>::operator[]( int i ) { Assert( IsIdxValid(i) ); return m_pMemory[i]; }
And I did a break while debugging and it said m_pMemory = 0x00000000
is taht a bad thing?—ts2do (Talk | @) 23:02, 30 Nov 2005 (PST)
- I'm confident that you already know that it is bad, so I'm guessing that the actual question is "What now?". The SDK utility classes are pretty solid, despite their peccadillos, so I doubt that they caused the error. You should check
this
(via the debugger; do a Quick Watch if you need) to make sure that it's not null or an error. If it is, keep going up the call stack untilthis
is no longer invalid, then look for illegal memory access. If you find the general area but don't know exactly what's wrong, scatterAssert
s around liberally—check everything you pass to SDK code, and check every pointer before dereferencing.
- If, on the other hand,
this
is valid, you'll have to examine how theCUtlMemory
object was constructed, with attention to what might have gone wrong there. —Maven (talk) 17:52, 1 Dec 2005 (PST)
Yes but how could it be the bullet_manager giving the problems? it's only destroyed on level shutdown
There must be something going on with the utllinkedlist! It has this ref to utlmemory:
CUtlMemory<ListElem_t> m_Memory;
I don't know how that will help...it what seems to be the problem is in the CUtlMemory constructor...it initializes the m_pMemory
the default constructor is
CUtlMemory( int nGrowSize = 0, int nInitSize = 0 );
when it gets 0 passed in, it doesn't initialize m_pMemory, hence the error...the question is is why is it working the first time though? Calling EnsureCapacity(2) on the CUtlLinkedListseems to be the right thing to do...nothing happened
what I could do that would work fine is I could make the whole linked list static...since it's an important part of the game...that way I can forget about this problem—ts2do (Talk | @) 21:15, 2 Dec 2005 (PST)
- Apparently I wasn't clear.
CUtlMemory::m_pMemory
is null, you say. It could be that theCUtlMemory
code made a mistake. This is unlikely. What's more likely is that theCUtlMemory
object is corrupt. To find out, we have two questions:- Is it corrupt?
- How could it have become corrupt?
- To find the first, check
this
. Ifthis
(which points to theCUtlMemory
object) is null or is reported asCXX0030
, then the answer is, "Yes, theCUtlMemory
object is corrupt." (Because it's not really aCUtlMemory
object—it's some random chunk of memory being treated as aCUtlMemory
object.) So please check thethis
pointer first. - If the
CUtlMemory
object is corrupt, then how did it get that way? Well, that object isCUtlMemory CUtlLinkedList::m_Memory
. The most reasonable first guess as to whyCUtlLinkedList::m_Memory
is corrupt is that theCUtlLinkedList
object is corrupt. So again, use the debugger to see whether it's either null orCXX0030
. - If the
CUtlLinkedList
object is corrupt, then check where it came from. What code called the function that called theCUtlLinkedList
object? Check that code for bad pointer usage, for uninitialized pointers, for out-of-bounds array access, etc. If nothing obvious shows up, start putting inAssert
statements for things that you know must be true. Eventually you should find something that you know must be true, but the code thinks is false—and that's your bug. - It might be that I'm completely wrong, and that
this
isn't null. In that case please let me know, and I'll tinker with the code again when I get the opportunity. —Maven (talk) 17:49, 3 Dec 2005 (PST)
Wait, maybe I'm talking about something else... You said that in CUtlMemory<T>::operator[]( int )
you found m_pMemory
to be null. Where in the function were you? I assumed (foolishly) that you meant at the second line. If you were checking as you first entered the function, though, then it's OK, because m_nAllocationCount
will be zero and therefore the Assert
will fail. If CUtlMemory<T>::operator[]( int )
is being called when m_nAllocationCount
is zero, though, then the calling code is at fault for using an illegal index. —Maven (talk) 17:57, 3 Dec 2005 (PST)
I don't see why it's doing what it's doing...I'm so lost; I'm just gonna make the linked list global...that should solve it—ts2do (Talk | @) 18:30, 3 Dec 2005 (PST)