Talk:Simulated Bullets: Difference between revisions
mNo edit summary |
No edit summary |
||
Line 31: | Line 31: | ||
:If, with the private copy ctor and operator=, you get compiler errors complaining about them being private, then that means you need to either implement them or avoid the copy. Let me know if that's the case, please. —'''[[User:Maven|Maven]]''' <sup>([[User talk:Maven|talk]])</sup> 14:01, 23 Nov 2005 (PST) | :If, with the private copy ctor and operator=, you get compiler errors complaining about them being private, then that means you need to either implement them or avoid the copy. Let me know if that's the case, please. —'''[[User:Maven|Maven]]''' <sup>([[User talk:Maven|talk]])</sup> 14:01, 23 Nov 2005 (PST) | ||
I don't use pBullet anywhere else...but I had a feeling that the pointers were giving errors...why would they if I was just calling AddToTail...no code was run thru where a null pointer would be a problem....—'''[[User:Ts2do|ts2do]]''' <sup>([[User talk:Ts2do|Talk]] | [mailto:tsdodo@gmail.com @])</sup> 14:10, 23 Nov 2005 (PST) | I don't use pBullet anywhere else...but I had a feeling that the pointers were giving errors...why would they if I was just calling AddToTail...no code was run thru where a null pointer would be a problem....—'''[[User:Ts2do|ts2do]]''' <sup>([[User talk:Ts2do|Talk]] | [mailto:tsdodo@gmail.com @])</sup> 14:10, 23 Nov 2005 (PST) | ||
Still looking. By the way, <code>m_pBullets</code> shouldn't have a <code>p</code> in its name since it's not a pointer—<code>m_bullets</code> or <code>m_Bullets</code> would be correct. It won't hurt the code, but it confuses people who read it. Ditto <code>m_pCompensationConsiderations</code>. —'''[[User:Maven|Maven]]''' <sup>([[User talk:Maven|talk]])</sup> 14:19, 23 Nov 2005 (PST) |
Revision as of 15:19, 23 November 2005
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)
Does anyone know what it means if I'm getting this sort of error on the client:
client.dll!CUtlMemory<CSimulatedBullet *>::Base() Line 252 + 0x3 client.dll!CUtlVector<CSimulatedBullet *,CUtlMemory<CSimulatedBullet *> >::Base() Line 54 + 0x14 client.dll!CUtlVector<CSimulatedBullet *,CUtlMemory<CSimulatedBullet *> >::AddToTail(CSimulatedBullet * const & src=0x044fc440) Line 403 + 0x8
It seems to not like me adding an item to the utlvector on the client but it's fine with it on the server —ts2do (Talk | @) 10:52, 23 Nov 2005 (PST)
- How are you calling AddBullet? Is the parameter on the heap or stack? By the way, since CSimulatedBullet has dynamically-allocated members, you need a non-default copy constructor and copy assignment operator; otherwise you'll have leaks and possibly crashes if a CSimulatedBullet is ever copied. If it's never going to be copied, make the copy constructor and copy assignment operator private and undefined. —Maven (talk) 11:31, 23 Nov 2005 (PST)
I've tried a copy constructor b4... but what do you mean dynamically allocated...what objects? the pointers?
CSimulatedBullet *pBullet = new CSimulatedBullet(pAttacker, info.m_pAdditionalIgnoreEnt, info.m_iAmmoType, info.m_nFlags, vecDir, vecSrc, nDamageType #ifndef CLIENT_DLL , this, info.m_iDamage, 0.0f #endif ); BulletManager()->AddBullet(pBullet);
Also...I neglected to use a linked list because it would cost more allocation...—ts2do (Talk | @) 11:43, 23 Nov 2005 (PST)
why const ints instead of defines?—ts2do (Talk | @) 13:43, 23 Nov 2005 (PST)
- The dynamic allocation is at the
m_pIgnoreList = new CTraceFilterSimpleList(COLLISION_GROUP_NONE);
andm_pTwoEnts = new CTraceFilterSkipTwoEntities(pAttacker,pAdditionalIgnoreEnt,COLLISION_GROUP_NONE);
lines—the CTraceFilterSimpleList and CTraceFilterSkipTwoEntities objects are dynamically allocated. Youdelete
d them in the dtor, which is good, but if a CSimulatedBullet were copied both the original and the copy would point to the same CTraceFilterSimpleList and CTraceFilterSkipTwoEntities objects. When either CSimulatedBullet gets deleted, the other one is now pointing at CTraceFilterSimpleList and CTraceFilterSkipTwoEntities objects that have been deleted. As a rule of thumb, if you have to make a custom dtor you also need to make a custom copy constructor and assignment operator.
- For the
const int
s instead of#define
s: macros were fine in C but it's good practice to avoid them in C++. There are some reasons for this, but they're not particularly relevant. The SDK has them strewn everywhere anyway, so it's probably not going to hurt anything to add a few more, though.
- For the sample you gave, do you use
pBullet
anywhere else before it goes out of scope? —Maven (talk) 13:59, 23 Nov 2005 (PST)
- If, with the private copy ctor and operator=, you get compiler errors complaining about them being private, then that means you need to either implement them or avoid the copy. Let me know if that's the case, please. —Maven (talk) 14:01, 23 Nov 2005 (PST)
I don't use pBullet anywhere else...but I had a feeling that the pointers were giving errors...why would they if I was just calling AddToTail...no code was run thru where a null pointer would be a problem....—ts2do (Talk | @) 14:10, 23 Nov 2005 (PST)
Still looking. By the way, m_pBullets
shouldn't have a p
in its name since it's not a pointer—m_bullets
or m_Bullets
would be correct. It won't hurt the code, but it confuses people who read it. Ditto m_pCompensationConsiderations
. —Maven (talk) 14:19, 23 Nov 2005 (PST)