Re: [hlcoders] Physics becoming out of sync
I'd seen this in my mod too and hadn't really had time to investigate.
Added a KI for this:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Bot_physics.2Fhitbox_not_accurate
At 2006/08/23 12:18 PM, Jeremy Swigart wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks for the help. I put the code you posted above at the bottom of
PhysicsSimulate wrapped in an IsBot check(since we dont subclass for bots).
So far everything seems to work now. Hopefully there aren't unintended side
effects.
On 8/22/06, Paul Peloski [EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ]
Well, I just tried this
class CSDKBot ..
{
public:
...
virtual void PhysicsSimulate()
{
BaseClass::PhysicsSimulate();
// Since this isn't called for bots.. call it here?
UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
m_vNewVPhysicsVelocity, gpGlobals-frametime );
}
..
};
It fixed the problem (ie, I can hit bots with combine ball now, so I'm
pretty sure their physics is following them around properly) and didn't
seem
to break anything..
I think this is okay, what do you think Jay?
--
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
Thanks for the help. I put the code you posted above at the bottom of
PhysicsSimulate wrapped in an IsBot check(since we dont subclass for bots).
So far everything seems to work now. Hopefully there aren't unintended side
effects.
On 8/22/06, Paul Peloski [EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ]
Well, I just tried this
class CSDKBot ..
{
public:
...
virtual void PhysicsSimulate()
{
BaseClass::PhysicsSimulate();
// Since this isn't called for bots.. call it here?
UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
m_vNewVPhysicsVelocity, gpGlobals-frametime );
}
..
};
It fixed the problem (ie, I can hit bots with combine ball now, so I'm
pretty sure their physics is following them around properly) and didn't
seem
to break anything..
I think this is okay, what do you think Jay?
--
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] So I'm doing bots for Fortress Forever and I have run into a problem that appears to be a bug with the game. The odd thing is that I can't reproduce it myself as a player, and so far have only observed it happen to the bot players. There is a func_door being used as a lift, and when someone gets under the lift, when it comes down and hits the player it will go back up. The problem is that when the bot gets underneath just once, the lift is stuck in a perpetual up and down oscillation. After some debugging it became clears that the problem was physics related, since the physics system was calling CCollisionEvent::AddTouchEvent every time the lift came down, even though the bot had already ran off and was nowhere near the lift. I added some debug drawing stuff in the function CCollisionEvent::AddTouchEvent, to draw the bounds of the collidable, like so: debugoverlay-AddBoxOverlay( pEntity0-GetCollideable()-GetCollisionOrigin(), pEntity0-GetCollideable()-OBBMins(), pEntity0-GetCollideable()-OBBMaxs(), pEntity0-GetCollideable()-GetCollisionAngles(), 255, 0, 255, 0, 10.0f); debugoverlay-AddBoxOverlay( pEntity1-GetCollideable()-GetCollisionOrigin(), pEntity1-GetCollideable()-OBBMins(), pEntity1-GetCollideable()-OBBMaxs(), pEntity1-GetCollideable()-GetCollisionAngles(), 255, 0, 255, 0, 10.0f); Here is a picture of that. http://i8.tinypic.com/258z4zk.jpg As you can see, the collidables bounding boxes at least are where they should be, and not touching. The small red lines under the lift are the collision position and collision normal also passed to the function, so there is clearly something being registered as hitting. After digging around for more stuff I came across the cvar physicsshadowupdate_render, and when enabled finally showed the problem. http://i7.tinypic.com/258z5u8.jpg The rendering for these boxes is in CBasePlayer::VPhysicsShadowUpdate. The blue box is the players IPhysicsObject-GetPosition(), the red box is at the GetAbsOrigin() of the character. Clearly they are out of sync. These boxes should be pretty much together, but for some reason they aren't. I noticed the comment at the bottom of the function that reads // UNDONE: Force physics object to be at player position when not touching phys??? Why was this undone? Anyone know what part of the code is responsible for keeping the physics synced with the entity and vice versa? Stepping through the code in CBasePlayer::VPhysicsShadowUpdate How could these get out of sync like this? I haven't been able to reproduce this as a player, only happens to the bot so far, but I can't see any reason at all that it would be bot related. We aren't messing with the physics for the bot in any way. This is really annoying. Any feedback is appreciated. Jeremy -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
I think the bot's physics object has fallen asleep. If you look at the call
stack for VPhysicsShadowUpdate its called like this in physics.cppPhysFrame:
// apply updates
if ( pPhysics !pPhysics-IsAsleep() )
{
pEntity-VPhysicsShadowUpdate( pPhysics );
}
Stepping through PhysFrame shows that the SDK bots have a valid physics
object but that its asleep. This would also explain why SDK bots are hard to
hit with combine balls, as the combine ball does its damage/dissolve effect
in VPhysicsCollision, which wouldn't happen correctly if the bots vphysics
shadow is not being updated because its fallen asleep and is lingering
somewhere else on the map.
Anyways, we just need to find why the bots physics object is sleeping on the
job and it would be fine. A really bad way to test if this would fix your
problem is to just replace the if statement in PhysFrame with
// apply updates
if ( pPhysics (!pPhysics-IsAsleep() || pEntity-IsPlayer()) )
{
pEntity-VPhysicsShadowUpdate( pPhysics );
}
If that fixes your bots physics shadow then at least you know you just need
to figure out why its falling asleep. I'll keep looking for an answer there
as well.
Regards,
Paul
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Okay, seems like the problem is in CBasePlayer::PhysicsSimulate, where the UpdateVPhysicsPosition is not being called for bots. PhysicsSimulate is the main place where UpdateVPhysicsPosition is called. There's also a wrapper for UpdateVPhysicsPosition called UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for example when being pushed by your lift! So basically what's happening is that PhysicsSimulate is not updating physics shadow for every game frame, but some touch events are calling a function that moves the shadow into place. Whenever the shadow moves, it wakes up, but when its idle for too long (because PhysicsSimulate isnt updating it) it falls asleep. One way to fix this would be to override PhysicsSimulate in the bot's entity class and make sure that UpdateVPhsyicsPosition is called (just hack up the PhysicsSimulate from CBasePlayer so that it calls it under the right circumstances for your bots instead of actual players) I hope this helps. Fortress Forever is looking terrific these days, best of luck to you guys. Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Thanks the help. Are you having the same problem with your bots or just going out of your way to be helpful? Either way I appreciate it. On further investigation, it appears the problem is due to the bots user commands going through a different code path. AFAIK, we're supposed to be calling RunPlayerMove(cmd); and PostClientMessagesSent(); on the bot controller for the bot. This works fine and all, but it bypasses the codepath that the players usercommand takes, which is CBasePlayer::ProcessUsercmds Since CBasePlayer::ProcessUsercmds doesn't get called for bots, AllocCommandContext() doesn't get called for bots, and therefor why int command_context_count = GetCommandContextCount(); is always 0 for bots(in CBasePlayer::PhysicsSimulate), and its within that loop that UpdateVPhysicsPosition is called. Are there any special considerations to UpdateVPhysicsPosition being called? Or can I safely call it every frame at the end of the bot block in CPlayerInfo::RunPlayerMove. Think, first I'll see what happens if I call ProcessUsercmds on the bot player directly. Calling UpdateVPhysics on my own feels like a dirty hack. I'm hesitant about doing stuff like just calling the function directly. IMO that's masking the symptoms of a potentially bigger problem. It looks like this is another problem that needs addressing if Valve gets around to fixing the broken bot support, as that is the only way to feed user commands from server plugins. On 8/22/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Okay, seems like the problem is in CBasePlayer::PhysicsSimulate, where the UpdateVPhysicsPosition is not being called for bots. PhysicsSimulate is the main place where UpdateVPhysicsPosition is called. There's also a wrapper for UpdateVPhysicsPosition called UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for example when being pushed by your lift! So basically what's happening is that PhysicsSimulate is not updating physics shadow for every game frame, but some touch events are calling a function that moves the shadow into place. Whenever the shadow moves, it wakes up, but when its idle for too long (because PhysicsSimulate isnt updating it) it falls asleep. One way to fix this would be to override PhysicsSimulate in the bot's entity class and make sure that UpdateVPhsyicsPosition is called (just hack up the PhysicsSimulate from CBasePlayer so that it calls it under the right circumstances for your bots instead of actual players) I hope this helps. Fortress Forever is looking terrific these days, best of luck to you guys. Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Not working on bots myself just trying to be helpful. You're right about the user command stuff, that's why the UpdateVPhysicsPosition is not being called, maybe someone from Valve can suggest potential problems with calling UpdateVPhysicsPosition or ProcessUsercmds on the bots, I wonder what the CS: Source bots do? Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics becoming out of sync
It's safe to call UpdateVPhysicsPosition() directly. It's setting a target for the player's physics controller in the next frame of physics simulation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Swigart Sent: Tuesday, August 22, 2006 8:35 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Physics becoming out of sync -- [ Picked text/plain from multipart/alternative ] Thanks the help. Are you having the same problem with your bots or just going out of your way to be helpful? Either way I appreciate it. On further investigation, it appears the problem is due to the bots user commands going through a different code path. AFAIK, we're supposed to be calling RunPlayerMove(cmd); and PostClientMessagesSent(); on the bot controller for the bot. This works fine and all, but it bypasses the codepath that the players usercommand takes, which is CBasePlayer::ProcessUsercmds Since CBasePlayer::ProcessUsercmds doesn't get called for bots, AllocCommandContext() doesn't get called for bots, and therefor why int command_context_count = GetCommandContextCount(); is always 0 for bots(in CBasePlayer::PhysicsSimulate), and its within that loop that UpdateVPhysicsPosition is called. Are there any special considerations to UpdateVPhysicsPosition being called? Or can I safely call it every frame at the end of the bot block in CPlayerInfo::RunPlayerMove. Think, first I'll see what happens if I call ProcessUsercmds on the bot player directly. Calling UpdateVPhysics on my own feels like a dirty hack. I'm hesitant about doing stuff like just calling the function directly. IMO that's masking the symptoms of a potentially bigger problem. It looks like this is another problem that needs addressing if Valve gets around to fixing the broken bot support, as that is the only way to feed user commands from server plugins. On 8/22/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Okay, seems like the problem is in CBasePlayer::PhysicsSimulate, where the UpdateVPhysicsPosition is not being called for bots. PhysicsSimulate is the main place where UpdateVPhysicsPosition is called. There's also a wrapper for UpdateVPhysicsPosition called UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for example when being pushed by your lift! So basically what's happening is that PhysicsSimulate is not updating physics shadow for every game frame, but some touch events are calling a function that moves the shadow into place. Whenever the shadow moves, it wakes up, but when its idle for too long (because PhysicsSimulate isnt updating it) it falls asleep. One way to fix this would be to override PhysicsSimulate in the bot's entity class and make sure that UpdateVPhsyicsPosition is called (just hack up the PhysicsSimulate from CBasePlayer so that it calls it under the right circumstances for your bots instead of actual players) I hope this helps. Fortress Forever is looking terrific these days, best of luck to you guys. Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Ok, so I tried ProcessUsercmds(cmd, 1, 1, 0, false); in place of IBotController::RunPlayerMove(cmd); It fixed the lift bug it seems but broke the view angles, and the bot kept facing his spawn direction or something. That's probably not too hard to fix, but after that I also tried m_pParent-UpdatePhysicsShadowToCurrentPosition(); in CPlayerInfo::RunPlayerMove and kept my previous user command method of IBotController::RunPlayerMove(cmd); This way he could move normally, but the lift bug wasn't fixed. I don't know what m_pPhysicsController-Update is doing in CBasePlayer::UpdateVPhysicsPosition, but apparently it isn't updating the physics position. Can't tell yet if theres an order of operation I'm missing. I guess after work I'll change it back to ProcessUsercmds method and figure out why their view angles are busted. Probably less work than trying to debug this broken bot command codepath. If theres anyone at valve who has any input or a possible 'right' solution to fixing the issue please let me know. I hate to deviate too far from the functionality that is also usable in server plugins, as I still hold out hope of that stuff being fixed in a future sdk update. J On 8/22/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Not working on bots myself just trying to be helpful. You're right about the user command stuff, that's why the UpdateVPhysicsPosition is not being called, maybe someone from Valve can suggest potential problems with calling UpdateVPhysicsPosition or ProcessUsercmds on the bots, I wonder what the CS: Source bots do? Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Is there anything that would mess that up? I tried calling UpdatePhysicsShadowToCurrentPosition(), which calls UpdateVPhysicsPosition( GetAbsOrigin(), vec3_origin, gpGlobals-frametime ); but it didn't fix the problem. The blue box shown in the above linked screenshots remained stuck under the lift. The blue box is drawn at the location IPhysicsObject::GetPosition(), while the other is drawn at the players GetAbsOrigin(). It would seem that the calling of UpdateVPhysicsPosition( GetAbsOrigin(), vec3_origin, gpGlobals-frametime ); above would bring this physics object in sync with the entity, but it doesn't seem to. Is there a specific time that function should be called? I tried calling it right after the processing of the bots user command in CPlayerInfo::RunPlayerMove( CBotCmd *ucmd ) so far. I'm tempted to call m_pParent-VPhysicsGetObject()-SetPosition( GetAbsOrigin(), vec3_angle, true ); in there as well, but I don't want to cause any additional problems. Any ideas? J On 8/22/06, Jay Stelly [EMAIL PROTECTED] wrote: It's safe to call UpdateVPhysicsPosition() directly. It's setting a target for the player's physics controller in the next frame of physics simulation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Swigart Sent: Tuesday, August 22, 2006 8:35 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Physics becoming out of sync -- [ Picked text/plain from multipart/alternative ] Thanks the help. Are you having the same problem with your bots or just going out of your way to be helpful? Either way I appreciate it. On further investigation, it appears the problem is due to the bots user commands going through a different code path. AFAIK, we're supposed to be calling RunPlayerMove(cmd); and PostClientMessagesSent(); on the bot controller for the bot. This works fine and all, but it bypasses the codepath that the players usercommand takes, which is CBasePlayer::ProcessUsercmds Since CBasePlayer::ProcessUsercmds doesn't get called for bots, AllocCommandContext() doesn't get called for bots, and therefor why int command_context_count = GetCommandContextCount(); is always 0 for bots(in CBasePlayer::PhysicsSimulate), and its within that loop that UpdateVPhysicsPosition is called. Are there any special considerations to UpdateVPhysicsPosition being called? Or can I safely call it every frame at the end of the bot block in CPlayerInfo::RunPlayerMove. Think, first I'll see what happens if I call ProcessUsercmds on the bot player directly. Calling UpdateVPhysics on my own feels like a dirty hack. I'm hesitant about doing stuff like just calling the function directly. IMO that's masking the symptoms of a potentially bigger problem. It looks like this is another problem that needs addressing if Valve gets around to fixing the broken bot support, as that is the only way to feed user commands from server plugins. On 8/22/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Okay, seems like the problem is in CBasePlayer::PhysicsSimulate, where the UpdateVPhysicsPosition is not being called for bots. PhysicsSimulate is the main place where UpdateVPhysicsPosition is called. There's also a wrapper for UpdateVPhysicsPosition called UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for example when being pushed by your lift! So basically what's happening is that PhysicsSimulate is not updating physics shadow for every game frame, but some touch events are calling a function that moves the shadow into place. Whenever the shadow moves, it wakes up, but when its idle for too long (because PhysicsSimulate isnt updating it) it falls asleep. One way to fix this would be to override PhysicsSimulate in the bot's entity class and make sure that UpdateVPhsyicsPosition is called (just hack up the PhysicsSimulate from CBasePlayer so that it calls it under the right circumstances for your bots instead of actual players) I hope this helps. Fortress Forever is looking terrific these days, best of luck to you guys. Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
Well, I just tried this
class CSDKBot ..
{
public:
...
virtual void PhysicsSimulate()
{
BaseClass::PhysicsSimulate();
// Since this isn't called for bots.. call it here?
UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
m_vNewVPhysicsVelocity, gpGlobals-frametime );
}
..
};
It fixed the problem (ie, I can hit bots with combine ball now, so I'm
pretty sure their physics is following them around properly) and didn't seem
to break anything..
I think this is okay, what do you think Jay?
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
Hmm, I didn't use m_vNewVPhysics* in my call. perhaps thats the problem. I
called UpdatePhysicsShadowToCurrentPosition(), which is apparently a rather
useless function. I'll try that when i get home. Thanks
On 8/22/06, Paul Peloski [EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ]
Well, I just tried this
class CSDKBot ..
{
public:
...
virtual void PhysicsSimulate()
{
BaseClass::PhysicsSimulate();
// Since this isn't called for bots.. call it here?
UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
m_vNewVPhysicsVelocity, gpGlobals-frametime );
}
..
};
It fixed the problem (ie, I can hit bots with combine ball now, so I'm
pretty sure their physics is following them around properly) and didn't
seem
to break anything..
I think this is okay, what do you think Jay?
--
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
