Demo hacks: finding 'player_localentnum'

[OneManClan]

Ok I thought I had the basic idea of how CSQC works, but I'm struggling to understand the relationship between these two snippets of code:

Code A:
In CSQC_Init() we process a player entity:
// "everytime an entity using player.mdl comes into view, send that entity to the function updateplayer()"
deltalisten("progs/player.mdl", updateplayer, 0);


Code B:
In CSQC_UpdateView(), I have a line:
// literally "starting at world, find the first entity where .entnum matches player_localentnum"
// (this gets us the 'viewed player' when watching a demo)
entity theplayer = findfloat(world, entnum, player_localentnum);


When I comment out Code A, Code B no longer finds the player entity - why??

[Spike]

player_localnum = the 0-based player index, for use in getplayerkeyvalue so you can highlight yourself on the scoreboard or whatever.
player_localentnum = the entity that the player is controlling on the server. typically player_localnum+1 because world is 0. it can be different when you are spectating (qw) or if the server sends an (nq)svc_setview midgame, in which case it'll have a value that reflects that change of pov.

let me be clear: just because you know the entity number does NOT mean that the client has any other clue about it. The specified entity might not be in the PVS, it might not even be spawned.
it certainly doesn't affect any other client<->csqc interactions.
as documented elsewhere csqc is running in a completely separate VM from the ssqc. Just because an ent exists in the ssqc doesn't mean that you can just poke it in csqc - half the time its on a completely different machine.
And because its very probably on a different machine, the few fields that the client *MAY* know about are woefully incomplete, limited only to those that are useful for rendering and maybe prediction.
Either way, the fact that so little is known about these entities means that its a bit futile to create an entity (or possibly corrupt a csqc-protocol one) just to track it.
Additionally, copying *everything* into csqc only to copy it back out again is a complete waste of time when it isn't going to serve any purpose - deltalisten filters by modelindex for this reason.
More specifically, without explicitly asking for it in csqc with deltalisten, or using SendEntity in ssqc, csqc *DOES NOT* know about the entity, and the engine won't spawn any csqc ents for it.
Note that deltalisten("*", foo, 0) registers all models for csqc deltas. This is wasteful, which I already mentioned, but hey, sometimes it helps to repeat stuff when people don't read stuff the first time.

You can potentially spawn csqc ents for ssqc ents via writebytes or even stuffcmds, and set the entnum field yourself. Note that the client won't touch these ents (it accelerates ssqc->csqc conversions using its own lookup tables, and may even use separate tables for ents, players, and SendEntity ents). This can result in multiple csqc ents having the same entnum field, but is normally rare thanks to the 2-second rule (can potentially still happen after significant 2+ sec lag spikes).

You can also use the csqc-only getentity builtin if you wish to avoid deltalisten+SendEntity. Tell it which property (from an enum - GE_*), and it'll tell you what the client knows as a return value from the builtin. It will not create any csqc ents for you (thus find still won't work), and you cannot edit such ents. It won't work with SendEntity ents (the client-engine knows absolutely nothing about these other than their index and whether they're currently in the pvs, because csqc handles the rest), but can still be used to re-read deltalisten stuff if you overwrote it, although its obviously inefficient to do so.

[OneManClan]

[OneManClan]

Currently investigating a messy Scenario:

What happens if you're using deltalisten to 'do things' to one (SSQC) model... but the entity (back in SSQC) has changed model?

[toneddu2000]

I've never been able to use deltalisten (it didn't work as I would) but (I talking about FTEQW, dp dunno), using a ssqc player with model, sending data via sendentity + CSQC_EntUpdate and using a csqc model, csqc model "wins" everytime. This infact was the only method I found to use complex skeletal animations. With ssqc, some advanced functions (like ragdolls, for example) don't work. That's why I use always model only in csqc. But I also learned that, if you create a full csqc game, you should think to transport also player entity too in csqc, instead of using ssqc player entity + sendentity, otherwise player entity collision + csqc entities collision won't talk together because they live in different universe which (unfortunately) are not linked.

I also noticed that, with complex glsl shaders, csqc models are rendered "better" than csqc ones..