Re: [hlcoders] Vehicle View Judder
Yeah I've seen that, it's way out of date and not was pre-OB MP. On Sun, Jan 24, 2010 at 12:26 PM, Chief Whosm < chiefwhosmoralsareelas...@googlemail.com> wrote: > > http://www.chatbear.com/board.plm?a=viewthread&t=573,1125931904,10177&id=901881&b=4991&v=flatold > > Might be worth taking a look at it, it's been around for a while though and > I never got it working mind (but that's not saying much considering my > skill > as a coder is quite near to zilch). > ___ > 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] Vehicle View Judder
http://www.chatbear.com/board.plm?a=viewthread&t=573,1125931904,10177&id=901881&b=4991&v=flatold Might be worth taking a look at it, it's been around for a while though and I never got it working mind (but that's not saying much considering my skill as a coder is quite near to zilch). ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicle View Judder
Could you ask your team if it would be okay to post the code up? I think it'd be great if there was a completed VDC article for mostly fixed vehicles with passengers in MP. On Sun, Jan 24, 2010 at 12:09 PM, Christopher Harris wrote: > We have a multiple passenger system. Basically it is a matter of having a > hitbox, and attachments per role and then modifying some of the vehicle > logic to work with more roles. > > Chris > > -Original Message- > From: hlcoders-boun...@list.valvesoftware.com > [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Matt Hoffman > Sent: Sunday, January 24, 2010 2:34 PM > To: Discussion of Half-Life Programming > Subject: Re: [hlcoders] Vehicle View Judder > > So now that we have a plausible fix for movement, has anyone looked at > multiple passengers? > > My understanding of it is the vehicles are set up with a passenger system. > Just Passenger 0 (1?) is considered the driver. > > My guess on implementing multiple-passengers in the vehicle would require > checking hitboxes and making a second vehicle.eyes bone/attachment. > > However, last time I looked I couldn't find (in the code) where getting > into > the vehicle picked your eyeposition and moved you into it. I might go poke > around it later today though. > > On Sun, Jan 24, 2010 at 11:07 AM, Chief Whosm < > chiefwhosmoralsareelas...@googlemail.com> wrote: > > > Wow! Thanks for that code it works beautifully for the interior view. > > ___ > > 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 > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicle View Judder
We have a multiple passenger system. Basically it is a matter of having a hitbox, and attachments per role and then modifying some of the vehicle logic to work with more roles. Chris -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Matt Hoffman Sent: Sunday, January 24, 2010 2:34 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Vehicle View Judder So now that we have a plausible fix for movement, has anyone looked at multiple passengers? My understanding of it is the vehicles are set up with a passenger system. Just Passenger 0 (1?) is considered the driver. My guess on implementing multiple-passengers in the vehicle would require checking hitboxes and making a second vehicle.eyes bone/attachment. However, last time I looked I couldn't find (in the code) where getting into the vehicle picked your eyeposition and moved you into it. I might go poke around it later today though. On Sun, Jan 24, 2010 at 11:07 AM, Chief Whosm < chiefwhosmoralsareelas...@googlemail.com> wrote: > Wow! Thanks for that code it works beautifully for the interior view. > ___ > 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] Vehicle View Judder
So now that we have a plausible fix for movement, has anyone looked at multiple passengers? My understanding of it is the vehicles are set up with a passenger system. Just Passenger 0 (1?) is considered the driver. My guess on implementing multiple-passengers in the vehicle would require checking hitboxes and making a second vehicle.eyes bone/attachment. However, last time I looked I couldn't find (in the code) where getting into the vehicle picked your eyeposition and moved you into it. I might go poke around it later today though. On Sun, Jan 24, 2010 at 11:07 AM, Chief Whosm < chiefwhosmoralsareelas...@googlemail.com> wrote: > Wow! Thanks for that code it works beautifully for the interior view. > ___ > 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] Vehicle View Judder
Wow! Thanks for that code it works beautifully for the interior view. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicle View Judder
Also note that all this does is smooth out the local players camera (so the vehicle doesn't jitter around); if you have visible players on it, you also have to invalidate all of the players that are in it's bonecaches, as well as the vehicle to lookup the correct locations. (the easiest way to actually do that is by creating a GetRenderOrigin() override on the player, and if they're in a vehicle.. override it (on the server they'll already be in the correct place, just the client is not rendering them in the correct location). -Tony On Mon, Jan 25, 2010 at 12:33 AM, Tony "omega" Sergi wrote: > Here, I whipped this up in the SDK a few months ago to test out my theory > and it completely smoothed them out: > Add this to iviewrender: > virtual voidMP_PostSimulate() = 0; > and to viewrender: > virtual voidMP_PostSimulate(); > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicle View Judder
Here, I whipped this up in the SDK a few months ago to test out my theory
and it completely smoothed them out:
Add this to iviewrender:
virtual voidMP_PostSimulate() = 0;
and to viewrender:
virtual voidMP_PostSimulate();
then in cdll_client_int, inside OnRenderStart() after
simulateentities/physicssimulate and threadedbonesetup:
//Tony; in multiplayer do some extra stuff. like re-calc the view if in
a vehicle!
if ( engine->GetMaxClients() > 1 )
view->MP_PostSimulate();
and finally the post simulate function itself.
I slapped it in view.cpp with the rest of the class:
void CViewRender::MP_PostSimulate()
{
C_BasePlayer *pLocal = C_BasePlayer::GetLocalPlayer();
if ( !pLocal )
return;
//Tony; if the local player is in a vehicle, then we need to kill the
bone cache, and re-calculate the view.
if ( !pLocal->IsInAVehicle() && !pLocal->GetVehicle())
return;
IClientVehicle *pVehicle = pLocal->GetVehicle();
Assert( pVehicle );
CBaseAnimating *pVehicleEntity =
(CBaseAnimating*)pVehicle->GetVehicleEnt();
Assert( pVehicleEntity );
int nRole = pVehicle->GetPassengerRole( pLocal );
//Tony; we have to invalidate the bone cache in order for the attachment
lookups to be correct!
pVehicleEntity->InvalidateBoneCache();
pVehicle->GetVehicleViewPosition( nRole, &m_View.origin, &m_View.angles,
&m_View.fov );
//Tony; everything below is from SetupView - the things that should be
recalculated.. are recalculated!
pLocal->CalcViewModelView( m_View.origin, m_View.angles );
// Compute the world->main camera transform
ComputeCameraVariables( m_View.origin, m_View.angles,
&g_vecVForward, &g_vecVRight, &g_vecVUp, &g_matCamInverse );
// set up the hearing origin...
AudioState_t audioState;
audioState.m_Origin = m_View.origin;
audioState.m_Angles = m_View.angles;
audioState.m_bIsUnderwater = pLocal && pLocal->AudioStateIsUnderwater(
m_View.origin );
ToolFramework_SetupAudioState( audioState );
m_View.origin = audioState.m_Origin;
m_View.angles = audioState.m_Angles;
engine->SetAudioState( audioState );
g_vecPrevRenderOrigin = g_vecRenderOrigin;
g_vecPrevRenderAngles = g_vecRenderAngles;
g_vecRenderOrigin = m_View.origin;
g_vecRenderAngles = m_View.angles;
#ifdef _DEBUG
s_DbgSetupOrigin = m_View.origin;
s_DbgSetupAngles = m_View.angles;
#endif
}
That should be sufficient. You're still going to have input lag as the
vehicles are server side, but depending on what you are trying to accomplish
it's actually not that bad.
-Tony
On Sun, Jan 24, 2010 at 9:21 PM, Chief Whosm <
chiefwhosmoralsareelas...@googlemail.com> wrote:
> Odd, got no warning to all those replies when I posted my last post - maybe
> gmail is slow today.
>
> So is the "*InvalidateBoneCache();"* the reason why Scratch SDK mp vehicles
> are fine, while hl2mp vehicles aren't since its all the same vehicle code
> for the most part? It's just Ive hunted the code and none of the sdk folder
> items have invalidatebonecache listed in their code.
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
-Tony
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicle View Judder
Odd, got no warning to all those replies when I posted my last post - maybe gmail is slow today. So is the "*InvalidateBoneCache();"* the reason why Scratch SDK mp vehicles are fine, while hl2mp vehicles aren't since its all the same vehicle code for the most part? It's just Ive hunted the code and none of the sdk folder items have invalidatebonecache listed in their code. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicle View Judder
Sorry, should have mentioned that I'd tried that code (on the wiki), and it seems not to work with the latest OB SDK. It doesn't seem to do anything, the problem remains as it was. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicle View Judder
Why would there be interpolation for server side objects? You would really have to write that for your vehicles for them to work without jitter. Currently the client side is interpolated because the client is told what to do by the server, so it interpolates movements. Source was never designed to have total client side control of objects unless they were just effects. Its dangerous, since the hackers will just have a party. Best solution is to write a new physics object from scratch and write movement code for that. Have the code exactly alike on both the client and server and bingo, a fully predictable object. Its a lot of work and getting the object to cooperate with the source physics engine might be a problem. Maybe not.. cheers! On Sat, Jan 23, 2010 at 10:00 PM, Tony "omega" Sergi wrote: > All you have to do for the stock vehicles to smooth out the local view is > to > invalidate the local playres bone cache after the entities have simulated, > and then do a partial view recalculation so that the local player is seated > in the vehicle correctly. > > The issue arrives in MP because the local player is simulated before the > vehicle has been moved, so once the vehicle moves it is no longer in sync > with the local player. > > > On Sun, Jan 24, 2010 at 11:14 AM, Saul Rennison >wrote: > > > YES! THAT'S ME! omgomgomgomgomg. Wait till I tell my girlfriends who > > came by the say hi! > > > > On Sunday, January 24, 2010, Minh wrote: > > > Saul Rennison ?!?! THE Saul Rennison ?!? The Saul that posts on > HLCoders? > > > > > > /me takes a cold shower > > > > > > Saul Rennison wrote: > > >> Minh Le? THE Minh Le? :O The original creator of CS? > > >> > > >> On Sunday, January 24, 2010, Minh wrote: > > >> > > >>> Yea, that's definitely an issue.. but if the server did some checks > on > > >>> his end, the server can see if the updates were "valid" or not and > > >>> basically just ignore the invalid updates or do something > accordingly. > > >>> Like if the client sent an update that he was at position X, and then > > >>> half a second later, he is at position Y (which is like halfway > across > > >>> the map), that could raise a red flag. > > >>> > > >>> Client side physics objects are interpolated.. other players are > > >>> interpolated.. > > >>> are you sure server side physics objects are interpolated? God, I > > gotta > > >>> go install hl2dm and play with the gravity gun... > > >>> > > >>> Saul Rennison wrote: > > >>> > > All objects are interpolated I think... the problem is the client > > could send bogus origins and result in hacking. Never trust the > > client! > > > > On Sunday, January 24, 2010, Minh wrote: > > > > > > > We actually managed to do a vehicle implementation that made the > > > controls strictly client authorative. Basically, the driver of the > > > vehicle gets his own vphysics object created and he controls it on > > his > > > client machine, and passes the origin and angles to the server. > > > The server then passes that info to the rest of the clients. > > > > > > The result is perfectly lag free controls for the driver. The > > only > > > hitch is, since the client is the one actually moving the vehicle, > > > vehicle collisions become a problem. In our first implementation, > > when a > > > vehicle ran into another vehicle, it would stop dead in its tracks. > > > There was no collision forces being imparted on either vehicle. We > > > managed to come up with a hacky method to fix this but it didn't > > result > > > in the most realistic collisions. > > > > > > Another problem we encountered was that there was no > > interpolation > > > going on for the other players, so when they saw the vehicle > moving, > > it > > > wasn't smooth. I'm not sure if this is a problem inherent in the > > Source > > > SDK though. > > > When you take a server side physics object, and throw it, do all > the > > > clients see it move in a smooth fashion? The object's position is > > > getting sent to each client at about 10 updates/sec (in a best case > > > scenario). There is no interpolation going on between each update, > so > > > the object would exhibit a slight jerkiness. Maybe we broke > something > > in > > > our code but I think this is something the SDK didn't do properly > > > (interpolate server-side vphysics objects). > > > I think I need to go play HL2DM and throw a toilet around... > > > > > > > > > Matt Hoffman wrote: > > > > > > > > >> I take it that it would be a lot of work and take a skilled > > programmer to > > >> re-write prediction for the vehicles to put more of it > client-side? > > >> > > >> On Sat, Jan 23, 2010 at 2:33 PM, Christopher Harris > > >> wrote: > > >> > > >> > > >> > > >> > > >>> Here is a page which has needed fixes: > > >>> > http://developer.va
