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
