Coders, Just wondering, how do you find the bandwidth, and the packet size of your code?
I have always messed around with sp code, and had NO Need to worry about this before, but SvenCoop is having heaps of new features tossed in at the moment, and i want to check that we are not going to flood, or starve the client with net data. Adam -------- Owner Nigredo Studios http://www.nigredostudios.com --- On Wed, 16/9/09, Andrew Armstrong <and...@mammoth.com.au> wrote: From: Andrew Armstrong <and...@mammoth.com.au> Subject: Re: [hlcoders] Optimising projectile bandwidth To: "'Discussion of Half-Life Programming'" <hlcoders@list.valvesoftware.com> Received: Wednesday, 16 September, 2009, 7:48 AM Yeah of course, I was just thinking though you may be able to alter how often updates are sent since the rocket won't be making a right angle turn :) after its been shot and given a constant velocity the client should be pretty accurate as to where the rocket is (so more updates, and bandwidth usage, should not be necessary). - Andrew -----Original Message----- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Joel R. Sent: Tuesday, 15 September 2009 11:37 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Optimising projectile bandwidth 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 __________________________________________________________________________________ Get more done like never before with Yahoo!7 Mail. Learn more: http://au.overview.mail.yahoo.com/ _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
