Prediction aside, everything on the client is always out of sync by the same amount. Not necessarily so in our rocket's case.
Joel R. wrote: > Tom Edwards Wrote: "I realised earlier today > however that what I'm trying to do is a bad idea no matter how I handle > it, because if either the client or the server ever started to choke on > some frames the rockets risk going out of sync." > > > Your going to be out-of-sync regardless unless you forward predict the > rocket based on the latency. > > > > On Tue, Sep 15, 2009 at 8:36 AM, Joel R. <joelru...@gmail.com> wrote: > > >> Prediction doesn't stop the server from sending you updates, because if >> your clientside values go out of range you have set, it snaps to the >> server's values. >> >> >> On Tue, Sep 15, 2009 at 8:02 AM, Andrew Armstrong >> <and...@mammoth.com.au>wrote: >> >> >>> I have not played with the game SDK before (just for server plugins), but >>> surely client side prediction can step in here and you can relax how often >>> you send updates? >>> >>> If the client received the origin, direction and velocity of the rocket, >>> client side prediction would take care of movnig the projectile fine (like >>> player movements). >>> >>> Can you maybe make it client side predicted (is there a flag? how do >>> players >>> and other entities auto predict?) and just relax how often you send >>> updates, >>> given that the rocket won't be changing direction/velocity? >>> >>> - Andrew >>> >>> -----Original Message----- >>> From: hlcoders-boun...@list.valvesoftware.com >>> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tom Edwards >>> Sent: Tuesday, 15 September 2009 8:28 PM >>> To: Discussion of Half-Life Programming >>> Subject: Re: [hlcoders] Optimising projectile bandwidth >>> >>> Thanks Joel, that sounds like it would work. I realised earlier today >>> however that what I'm trying to do is a bad idea no matter how I handle >>> it, because if either the client or the server ever started to choke on >>> some frames the rockets risk going out of sync. >>> >>> It might be possible to overcome that issue, but only by writing a lot >>> of fairly low-level code: I can only assume that Valve's existing code >>> all assumes that the origin is being transmitted if the position of an >>> entity is in any way important. >>> >>> Oh well. It was worth thinking about. :-) >>> >>> Joel R. wrote: >>> >>>> It's kind of tricky to do something like this. >>>> >>>> I recommend using a server-side only rocket entity that has >>>> >>> TransmitState >>> >>>> disabled. Then use a *reliable* UserMessage with the Origin and >>>> >>> Velocity >>> >>>> attached and sent to all players. When a player receives this >>>> >>> information, >>> >>>> create a clientside only entity of this rocket and duplicate the way the >>>> server moves the rocket in a straight line. Use PhysicsSimulate to move >>>> your rocket through the world, think functions are time based and not >>>> >>> very >>> >>>> efficient for this. >>>> >>>> There is a way to do it using the network tables of a client/server >>>> >>> entity >>> >>>> but you still have to deal with entity creation which is a lot of >>>> >>> useless >>> >>>> data in itself. It gets really hacky though since you have to manage >>>> stopping the transmitting and letting the client take over, but it still >>>> uses the origin that the server has for PVS culling, so yea it gets ugly >>>> really fast. >>>> >>>> >>>> >>>> On Mon, Sep 14, 2009 at 6:15 AM, Tom Edwards >>>> >>> <t_edwa...@btinternet.com>wrote: >>> >>>> >>>>> I have a simple rocket entity that travels in a straight line until it >>>>> hits something and explodes. Since the rocket travels in straight lines >>>>> at a constant speed all that the client needs to know is its starting >>>>> position and angles, but I'm having trouble getting the engine to only >>>>> network that particular data. Nothing I've tried works: >>>>> >>>>> * Standard CBaseAnimating entity >>>>> o Sends m_flSimulationTime and m_vecOrigin in every update, >>>>> which together create 11 bytes of useless data per rocket. >>>>> If 16 players at cl_updaterate 30 each have one rocket in >>>>> the air, that's 844.8Kb/s leaving the server*, none of it >>>>> useful in any way. Standard entities also run into the >>>>> interp problem I was talking about the other week. >>>>> * CBaseAnimating with SendPropExclude on m_flSimulationTime and >>>>> m_vecOrigin >>>>> o Rocket never appears on the client, even though I set the >>>>> AbsOrigin there with a backdoor variable. >>>>> * CBaseAnimating with UpdateTransmitState() logic >>>>> o Rocket disappears from client when transmission stops. Grr! >>>>> * Temporary entity >>>>> o Unreliable, start to be dropped if more than 32 are in a >>>>> single update. Clearly a bad idea. >>>>> >>>>> The only method I've not tried yet is a networked dummy entity that >>>>> spawns non-networked rockets at both ends (which would pretty much be a >>>>> reliable temp ent). Since the client isn't supposed to spawn its own >>>>> entities I don't hold much hope for this approach either. >>>>> >>>>> What on earth can I do here? Give up would be one option I suppose... >>>>> >>>>> * Okay, PVS culling would help. But still... >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> > _______________________________________________ > 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
