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
