cl_entityreport 1 This shows you a list of all entities and bars to show how much networking their doing.
On Thu, Sep 17, 2009 at 1:54 AM, Andrew Armstrong <and...@mammoth.com.au>wrote: > I forget the command (check this lists archives or the wiki?) but you can > turn on a cvar to make network packet info appear above the head of each > entity, so you can immediately see who is responsible for sending how much > data per packet, pretty neat. > > - Andrew > > -----Original Message----- > From: hlcoders-boun...@list.valvesoftware.com > [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Adam > "amckern" > McKern > Sent: Thursday, 17 September 2009 12:07 PM > To: Discussion of Half-Life Programming > Subject: Re: [hlcoders] Optimising projectile bandwidth > > 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 > > > > _______________________________________________ > 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
