-- [ Picked text/plain from multipart/alternative ] Well, I'm not sure how much bandwidth would really be saved by changing the networking of armor or health (only an int trimmed to 8 bits?) but here is something I found that might save a lot of bandwidth..
I got the idea for this from a comment in baseanimatingoverlay.cpp: // These are in their own separate data table so CCSPlayer can exclude all of these. SendPropDataTable( "overlay_vars", 0, &REFERENCE_SEND_TABLE( DT_OverlayVars ) ) My goal was then to be able to provide all the same stuff the SDK MP player needs, but be able to exclude DT_OverlayVars and possibly turn on UseClientSideAnimation(). So I decided to send an array of smaller layers (just seq. # and parity) instead of a utl vector of CAnimationLayers (seq #, cycle, prevcycle, weight, order). The layer cycle is instead worked out on the client and server seperately and in AccumulateLayers (client) and GetSkeleton (server) I do the pose accumulation like baseanimatingoverlay would. It works perfectly, although I haven't included all of the functionality of CBaseAnimatingOverlay I've got enough to reproduce HL2DM and exclude the following from my player class: SendPropExclude( "DT_OverlayVars", "m_AnimOverlay" ), SendPropExclude( "DT_AnimTimeMustBeFirst" , "m_flAnimTime" ), SendPropExclude( "DT_ServerAnimationData" , "m_flCycle" ), and turn on UseClientSideAnimation() in my player constructor. That looks like it'd save a bunch of bandwidth, no? On 9/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Although I'm not actively searching for this sort of thing, as some may > have noticed from http://tinyurl.com/m2n5j I'm concerned about possible > wasted bandwidth. > > So, is the armor network code more of a bandwidth hog, with the > MsgFunc_Battery() message-passing, than the normal SendPropInt() > networking? If so, why is it done this way? Is there some advantage in the > closed-source side of things? > > _______________________________________________ > 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
