CSQC and multiplayer mvds

[OneManClan]

Hi all.

What's the situation with CSQC and (multiplayer) demos?

OBJECTIVE: To record and play back a demo of a multiplayer gamne, and be able to switch view from player to player, and see their CSQC HUD, ie see exactly what the player saw.

I asked Spike about this a few months back and IIUSC (If I Understood Spike Correctly), it can't be done.

But I'm hoping that I misunderstood..
Or that Spike meant 'cant be done easily'

I've tried playing back multiplayer demos and some CSQC things work (deltalisten mdl replacements) but others don't (each players HUD)

Since
1. csprogs.dat DOES run while playing back a demo, and
2. all clients use the same csprogs.dat
3. CSQC's isdemo() function lets us know when the client is in demo playback mode..

... why can't the CSQC playback client emulate each players HUD?

[Spike]

Use the track command to control which player you want to track. Or just hit jump (assuming your csqc isn't blocking that somehow).
Make sure you're not using auto/high track otherwise it'll just go and re-track someone at psudorandom.

mvds should work mostly the same as splitscreen, you can even set cl_splitscreen 0-3 and the client will start tracking more than one client at a time.
You can use VF_ACTIVESEAT to switch between different seats for purposes of csqc's globals and getstat[f|i|s]. However, CSQC does 'own' the screen so it'll need to make multiple renderscene calls itself (hint: you can directly change VF_VIEWENTITY in order to avoid clearing the scene, but you'll need to re-add the viewmodel each time).
You can use the track1-track4 console commands to control individual seats. Alternatively just give multiple arguments to the regular track command.
For splitscreen specifically, you can prefix any console commands you need with the p1|p2|p3|p4 commands, and it'll execute within the context of that seat - assuming the command understands per-seat contexts.

Unlike splitscreen, mvds internally track ALL players. This means that (when playing an mvd) you can use getplayerstat to read ANY player's stats (cast the result to an appropriate type). Not that you really need this, its really just if you want fancy stuff like showing which team members have rocket launchers without bothering to support it in regular gameplay too...

Unfortunately, isdemo won't tell you whether its an mvd or qwd or dem or dm2 etc, so watch out for that.

[toneddu2000]

Never tried demo (neither in ssqc) in my entire life, so probably I'm just sayings idiot words but: why not recreate a csqc demo func by yourself?
Something like, every time x player picks up a item/weapon, every time x player begins movement, save a playerx.whatever file on disk and when demo is closed, close that file.
When open "customdemo" file, creates several views, one of for each player. How? it's pretty basic, using setviewprop(VF_ORIGIN,..), setviewprop(VF_VF_ANGLES,..) and addentities you can "pilot" what you want to see right now in csqc. For example, in craFTEr I used setviewprop and addentities to switch on the fly from editor camera to player head camera, and to toggle on/off entities which lie on layers that were on/off.
I think the mechanism it's pretty the same. You should of course, for your sanity, start with a project from scratch and to obtain a minimum skeleton where is CSQC that manages input and movements and ssqc that only "rebounds" every player x origin,velocity,armor, etc. snapshot to any other player.
I did something like a bomberman multiplayer demo some time ago and it worked beautifully (I had to release it one day) because server was merely a semaphore which just said "ok, you player x moved, so replicate your position to the others, you player y no, so stay right there" and all the logic was clean and beautiful written in csqc without "update this, that no, this...uhm I dunno" and so on. Probably of course my idea is idiotic because works well for like 4 players but would go completely mad with 16 player or +. And probably there are ton of security issues which Spike would fill 4 pages of thread but, hey, this is what I'd do!

[pitchatan]

Full informatio and proper stat tracking can only be done by recording the demo server side with normal quake/quakeworld progs.
Reason why client recording is not enough is simpy because of the engine sorting/filtering players on PVS, as well as not sending "confidential" fields like health and armor.
If you want to get around this you might want to setup up your own sendflags function, as well as not use PVS to determine if something should be sent or not.


I have code up on github as an example (though it's incredibly sloppy as it was a weekend project, but meh).
here ya go:

It has some wonky behavior i havent bothered fixing yet, no interpolation for angles etc, and i haven't fixed the amount of bandwidth being used in it's sendflags (currently sending a full load of info every physics frame). But you should be able to watch other POVS and things like lg trails should show up (might not work for you as i haven't uploaded the particles or textures for it).


If security or confidentiality is a concern you should probably forget the usage of clients being able to record demos with every pos,health,armor etc.