Shared entities CSQC

[Urre]

[daemon]

[Urre]

Yes I recall that, but I also recall someone saying that it should be possible to only have it available on the client, without the server knowing about it.

[Spike]

[LordHavoc]

[Urre]

[LordHavoc]

[Spike]

[LordHavoc]

[Urre]

[Spike]

shared entity is perhaps not the best name...
replicated entity seems more apropriate somehow.

The server is meant to stay in overall control of everything. These entities then are either one-time events that trigger when they appear on the client (isnew == true), or actual entities that move around.
'Events' need to be left spawned, and removed when the client says to do so, as a means to cover any packet loss/resends. This can be done fairly genericly. Use the initial update to spawn any other ents you want and remove the parent as soon as asked. That's the easiest way.
Actual entities will rarely be removed clientside first. In the case of a rocket explosion, you ought to remember where it exploded to be able to adjust prediction properly anyway (although my own code never got to this stage, it is perhaps the biggest advantage of csqc in id-like deathmatch mods).

Entities duplicated in csqc are really no different from entities that could be obtained from the deltaing in the engine (except that you have to do interpolation yourself). The big advantage is that you can do interpolation yourself, instead of having the engine resend every single detail that changed every single packet.

Its more complicated, this makes it a pain by definition. :P

But I admit that making your own interpolation code is a major pain though.

[Urre]

[Spike]

This nearly reminds me of Total Annihilation.
For the uninitiated, Total Annihilation is a peer-to-peer real-time strategy game.
Basically, each client runs the units belonging to the local player, with the other clients seeing copies of those units. There's some sort of interpolation in there too, to keep it smooth.

The effects of lag in this game proves to be fairly interesting. Other people's units that are killed by you linger after death until your client has told the other player's client that you just hit them for X damage, and for their client to tell yours that they've actually died. Until that response, their unit will continue moving around shooting at stuff.

In your mod's case, the server ultimately controls all units, preventing any manipulation by lag (aka: invincible units).

Your mod is still a pure client/server architecture. The server owns all units. If a unit is destroyed by another unit ('enemy dead'), then the server will be removing the unit shortly anyway. Entities required for 'Shooting and everything' are never known by the server, so can be removed freely.

If the 'unit dead' event is the same unit, but morphed, you can spawn an explosion where the unit died. On the plus side, you can extend the remove/spawn grace period. :)

So, if a unit is killed locally, set its health to 0 and wait for the server to kill it properly. This is safest when it comes to prediction inaccuracies anyway, and may prevent inaccuracies from building up further.

[Urre]

Aye, will do. Not sure wether I'll spawn the explosion at its current origin, or the actual one. If I do it at the actual origin, it makes more sense to the player, knowing that unit was out of sync, rather than "ah, spontaneous unit explosions. makes sense."

[LordHavoc]

I believe Total Annihilation actually ran the units on all peers simultaneously, and units only took damage from projectiles that hit them in their owner's simulation, meaning a peer could say a unit now exists, and could say a unit exploded, but could not do anything else, and someone else might damage their own units when that message is received for example (if within radius).

I do remember its handling of resyncs being rather bruteforce - basically every peer was continuously sending entity updates to all other peers, whether they thought they needed them or not, this caused units to teleport to other locations, some units every second (it was clearly a cyclic process), so it gradually fixed desyncs.

I also remember that the units only began shooting if their owner's simulation knew about the targets being close enough.

It was pretty strange playing in a very lagged game.