[hlcoders] Compile problems for teamplayer_roundbased

2009-09-27 Thread emiel_regis
Hi, Im trying to reuse TF2's teamplay roundbased code using latest SDK. I changed inheritance of sdk_gamerules to use the teamplay roundbased ones, and I added missing files (like teamplay_roundtimer, etc.). I'm having problem with strange crash happening in SetTimerInHud function: void

Re: [hlcoders] Compile problems for teamplayer_roundbased

2009-09-27 Thread Jonas 'Sortie' Termansen
Try using void SetTimerInHUD( CBaseEntity *pTimer ) { if ( pTimer ) { m_iTimerToShowInHUD = pTimer-entindex(); } else { m_iTimerToShowInHUD = NULL; } } instead. Somehow it looks like you are accessing a null pointer like a class, and then accessing a member of that

Re: [hlcoders] Compile problems for teamplayer_roundbased

2009-09-27 Thread Jorge Rodriguez
pTimer isn't NULL, its value is shown in that stack trace. Whatever CBaseTeamObjectiveResource object he's using is what's null. Emiel, it looks like ObjectiveResource() is returning NULL for you. You need to have your game create an objective resource. Create a class that extends

[hlcoders] ShouldCollide()

2009-09-27 Thread Bob Somers
So I'm looking through some previous source code we've got, and I noticed that gamerules.cpp used to expose a ShouldCollide function with this signature: ShouldCollide( int collisionGroup0, int collisionGroup1, CBaseEntity *pEnt, CBaseEntity *pPass ) but in the newest SDK code it only exposes a

Re: [hlcoders] ShouldCollide()

2009-09-27 Thread Joshua Scarsbrook
Well valve should have backwards compatabilty code, try the old version. aside from that Tony may have some sugestions for the older code, since it is defined in a libary then i can not change it. Bob Somers wrote: So I'm looking through some previous source code we've got, and I noticed that

Re: [hlcoders] ShouldCollide()

2009-09-27 Thread Bob Somers
I did try the old version, but the compiler complained that it couldn't find it. ;) --Bob On Sun, Sep 27, 2009 at 4:02 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Well valve should have backwards compatabilty code, try the old version. aside from that Tony may have some sugestions

Re: [hlcoders] ShouldCollide()

2009-09-27 Thread Jorge Rodriguez
The functionality probably wasn't taken out without adding another way to do it. What are you trying to do? -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit:

Re: [hlcoders] ShouldCollide()

2009-09-27 Thread Bob Somers
Well what I'd like to do is restrict certain areas so that only one team can enter them. I have these areas set up with their own collision group. It would be easiest to just check the GetTeamNumber() of the player that collides with the brush. I tried doing this by defining

Re: [hlcoders] ShouldCollide()

2009-09-27 Thread Jorge Rodriguez
ShouldCollide is okay for that but my ShouldCollide shows the second parameter as being a contents mask instead of another collision group. Maybe you can use that? My quick research shows that the mask is set by CGameMovement::PlayerSolidMask() so it should be pretty easy to overload that in

Re: [hlcoders] ShouldCollide()

2009-09-27 Thread Minh
This should work.. We do this for several of our entities and we get the behaviour as expected. Make sure something else isn't stamping out the collision group after you set it to COLLISION_GROUP_PLAYER_BLUE I tried doing this by defining COLLISION_GROUP_PLAYER_BLUE and

Re: [hlcoders] Is it possible to change particle properties via code?

2009-09-27 Thread Andreas Grimm
I use an info_particle_system entity to spawn those drips ... But I found solution and I think, valve is using very similar way. Another small problem was, that when I attach that entity to myself, the drips are not visible for me, just for everyone else. But when I use a teleporter I can see