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
