Talk:Simulated Bullets

From Valve Developer Community
Revision as of 18:57, 3 December 2005 by Maven (talk | contribs)
Jump to: navigation, search

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 [email protected] --Amckern 01:07, 21 Nov 2005 (PST)


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 you have that?—ts2do (Talk | @) 20:30, 27 Nov 2005 (PST)

Oops. Yes, I did miss that. —Maven (talk) 07:29, 28 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 ); in C_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 );
		g_pBulletManager = (C_BulletManager *)CreateEntityByName("bullet_manager");

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) 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 until this is no longer invalid, then look for illegal memory access. If you find the general area but don't know exactly what's wrong, scatter Asserts 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 the CUtlMemory 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 what seems to be the problem is in the CUtlMemory 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 the CUtlMemory code made a mistake. This is unlikely. What's more likely is that the CUtlMemory 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. If this (which points to the CUtlMemory object) is null or is reported as CXX0030, then the answer is, "Yes, the CUtlMemory object is corrupt." (Because it's not really a CUtlMemory object—it's some random chunk of memory being treated as a CUtlMemory object.) So please check the this pointer first.
If the CUtlMemory object is corrupt, then how did it get that way? Well, that object is CUtlMemory CUtlLinkedList::m_Memory. The most reasonable first guess as to why CUtlLinkedList::m_Memory is corrupt is that the CUtlLinkedList object is corrupt. So again, use the debugger to see whether it's either null or CXX0030.
If the CUtlLinkedList object is corrupt, then check where it came from. What code called the function that called the CUtlLinkedList 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 in Assert 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)