Netquake demo tools?

[Lorfa]

I'm looking for a tool for netquake ala wolfcam in QL.

I tried running Camquake but it doesn't run on my system (crashes).

Was there ever anything like this? I want to convert chasecam or floatcam demos to pov.

Thanks for any info.

[bluntz]

I am just glad to have helped.Spike did all the heavy lifting.I am always happy to see someone actually put out the effort to complete a project to it's goal.We see so little of that kind of fortitude these days.2 thumbs WAY up!!!

[Lorfa]

Anyways just wanted to say thanks for all your help, couldn't have done it otherwise.

Here's the famous thresh vs. high roller demo converted to thresh pov :-P

https://www.dropbox.com/s/hn2i7wv26v...rhigh.dem?dl=0

[Lorfa]

I did it!!

There are some issues:

1. The hanging cameras get player models, and these show up in the game. Could probably hide them by changing their model or not giving them one, but that would take a tremendous amount of work. Just have to live with it, so sometimes there's a guy there and you're like why is nobody shooting him :-p
To make matters worse, the player models move as they track the player they're 'spectating', so sometimes they resemble live players.

2. The pov cuts out when the player goes somewhere the camera can't see well, and their angles are apparently culled from the demo at that point. It also understandably cuts out when the cameras select the other player to view which happens from time to time. Sometimes it appears to happen automatically.

It would be theoretically possible to switch the setview and mine the angles when the camera switches, but this would be very much not worth the enormous amount of effort. It would require timestamping during the game, writing them down, carefully adding a setview entry for certain parts of the demo text, modifying the program to look for those specifically and mine the angles. I mean just.. meh.

3. Sometimes entities are lost such as moving platforms or potentially moving platforms. This might be part of the culling or perhaps it could just be ezquake's handling of .dem playback, not sure. I didn't try winquake yet.

4. The viewheight is a little off, it's a bit too low. I might be able to set v_viewheight a bit higher than default to compensate, but probably it would need something like qrack. It's not terribly dramatic and imo not worth the trouble.

Here's a sample game:

https://www.dropbox.com/s/zuics7sbzd...rufix.dem?dl=0

I'm very happy that I managed to do this, but after all of this work some of the magic is gone somehow. Shrug.

It's kind of a pita, because I have to decompile the demo with lmpc, look for the entity I want, fix setview, remove setangles, modify and recompile the angle mining program for the entity I want and run it. Run the camera angle replace program and finally lmpc it back into a demo.

I have some other demos from the event, so I might find some other interesting ones to convert, and different maps than dm2 might behave better with the cameras.

[Lorfa]

Spike gave pitch angle as 1/3 of the players view,so did you recalculate that value or just copy it?

Yes I forgot to do this. Although I still cannot fathom why this needs to be done.

It would seem from his info that you should multiply the value by 3 and enter the products for angles_1.

Should be something more along the lines of the other way around. I'm taking angles info and putting them into camera, so it is as if the demo taker was making the motions.

Also meh, I had the angles wrong again. It's just confusing that it's pitch yaw roll.

Upon closer inspection in the demo, there is pitch movement, but it barely moves just a couple iotas once in a while. So my hypothesis is that when the value is bad it means the pitch would be if the player was upside-down somewhere, not sure. Either way the only way forward is to do this multiplication on the pitch value and see what happens.

This might not be so simple. I brought it in as a string, converted it to double, used fixed and increased the precision, but the output is still odd on some values, like sometimes I get a ~270, instead of 270.0000000, other times I get all the following zeros, so I'm going to have to sort that out.

The other issue is that there aren't any values greater than |360|, and it might not be smart enough to understand that greater values just wrap around. I might have to explain that to the multiplication calculation.

Maybe those values are why the artifacts are showing up.

I took care of the output text artifacts. There's still the issue of my search and replace with regular expressions blanking out the line setangles was on instead of removing it entirely, but lmpc doesn't seem to care about this luckily (it can be VERY picky).

You can download Challenge-TV's demo archive from this site: demos.igmdb.org

Awesome!!

[bluntz]

Spike gave pitch angle as 1/3 of the players view,so did you recalculate that value or just copy it?It would seem from his info that you should multiply the value by 3 and enter the products for angles_1.Maybe those values are why the artifacts are showing up.

[vegetous]

..., (edit FUCKING CHRIST WHAT THE FUCK SOMEONE ELSE HAS CHALLENGE-TV NOW.............................YES MAD...............................)


Watch yourself grow Healthier and Stronger | Challenge-TV

^ I just want to kick and scream and scream and kick

Sigh

You can download Challenge-TV's demo archive from this site: demos.igmdb.org - /

[Lorfa]

An update. After a lot of work writing two programs I've run into a weird problem.

First let me explain what I did. I wrote a program that takes the angle views from a particular entity, say entity 3, and places them in an output text file with a camera # # #; format.

I then wrote another program that rewrites the demo text (made from lmpc), replacing the camera line with the lines from my output text.

I then removed all instances of setangle, adjusted setview, and converted back into a binary .dem file.

Everything looked as good as expected until I realized that.. the camera had no pitch movement! Only yaw.

I checked the data files and the pitch information is there in all cases. There were some formatting artifacts, so I assumed that when lmpc parsed back into a binary dem that it was cutting out the y and x because this is where the formatting artifacts were (it sometimes put the next line at the end of camera # # #; ).

However, after lmpc'ing to text from a problem demo file, all the pitch information is there. So now I'm perplexed.

Is it possible that setangle is required? Should I replace that with the new camera angles as well? That doesn't make much sense though. I don't get it. :-/

[Lorfa]

You are right,change player is for Doom LMP files...Doh.The memory aint what it used to be.From your description it sounds like he demo was recorded set to QuakeTv? If so Maybe you could issue an eyecam instead or after setview?

An intriguing idea, I never even imagined that this could be possible after the fact. I suspect that there isn't enough of QTV left in the demo file alone to enable this, but maybe if I had the QTV server stuff, release notes and such there may be some way to make something happen. I was just looking through some old planetquake/bluesnews posts in the wayback machine and I remember seeing some QTV links.

I'll reserve this idea to use if I run into serious problems with the angle editing. Right now I'm pretty confident that changing the angles will work.

The 'eyecam' demos convert really well to pov with just setview alone, until someone switches players, at which point it goes haywire, but hey, all I did was edit a couple entries in a text file, should I expect miracles? :-p

[bluntz]

You are right,change player is for Doom LMP files...Doh.The memory aint what it used to be.From your description it sounds like he demo was recorded set to QuakeTv? If so Maybe you could issue an eyecam instead or after setview?

[Lorfa]

'camera' is the angles of the client's camera when the demo was recorded (if a server-side dem, will be whatever the client last reported so will have a little latency, but probably not enough that you'd notice). on playback, the client will interpolate between these.

When you say 'interpolate between these', what two things is it interpolating between? Camera and setangles?

'setangles' is the server trying to tell the client to snap to some other angle instead. strip these. the values specified here will generally roll over into the angles of the camera in the next packet. due to the camera info in demos this is basically redundant, but may still be useful to instantly snap the camera to the new angle, depending on the client.

That is very very interesting, and simplifies my task if true, and it appears to be.

So I could just remove the setangles line, copy entity3's angles_123 into camera # # #, using a 0 if no entry and then I'd have entity3's camera motions as if the demo were recorded by it, then I just use setview to move the camera onto the entity and I'm done? That's very promising.

angles_1 this is the pitch of an entity.

I'm surprised that it isn't x y z 1 2 3, but testing proves you correct that the first place is indeed the pitch, the second place the yaw, and the third the roll. So it is backwards, z y x corresponding to 1 2 3.

remember that player entity pitch angles are generally -1/3rd of the client's original view angle, meaning you can restore the camera angles from this information.

This doesn't seem to hold true. I also don't understand why it would be true if it was, can you elaborate? Are you also suggesting this would apply to yaw and roll?

angles_2 this is the yaw angle (ie: left or right)
angles_3 this is the roll angle of the client.

At first I didn't believe you, and I was blown away to find that cl_rollangle is in fact not entirely clientside, it just gets filtered by the client's rollangle setting so you never see a player's rollange. You could theoretically extract a player's rollangle value from a .dem by looking at how angles_3 typically changes, and I could theoretically (if so motivated) tell who was using cl_rollangle 0 way back in the day! Wild!

It still rolls upon certain types of damage though, and on death though yes? Like doesn't death roll you totally horizontal or does the engine have some other built-in way of handling this?

typically limited to +/- 2 (cl_rollangle). this may result in the player swaying like a boat, so often people try forcing this to 0.

It doesn't seem to hold true to +/- 2, I have a lot of -7.x, -5.x, and -4.x, even in a test demo with rollangle at its default of 2.0. Tangential issue of course, I'm infinitely more interested in the pitch and yaw.

[Spike]

'camera' is the angles of the client's camera when the demo was recorded (if a server-side dem, will be whatever the client last reported so will have a little latency, but probably not enough that you'd notice). on playback, the client will interpolate between these.
'setangles' is the server trying to tell the client to snap to some other angle instead. strip these. the values specified here will generally roll over into the angles of the camera in the next packet. due to the camera info in demos this is basically redundant, but may still be useful to instantly snap the camera to the new angle, depending on the client.
angles_1 this is the pitch of an entity. remember that player entity pitch angles are generally -1/3rd of the client's original view angle, meaning you can restore the camera angles from this information.
angles_2 this is the yaw angle (ie: left or right)
angles_3 this is the roll angle of the client. typically limited to +/- 2 (cl_rollangle). this may result in the player swaying like a boat, so often people try forcing this to 0.

[Lorfa]

Ok, now I'm perplexed, and the demo spec by Girlich isn't helping.

Take for example this:

block {
 camera 26.7187500 299.531250 0.000000000;
 time 4:18.48760986m;
 setangle 30.9375000 -52.0312500 0.000000000;
 clientdata {
  uk_bit_b10;
  weaponmodel 0;
  health 998;
  currentammo 1;
  ammo_shells 0;
  ammo_nails 0;
  ammo_rockets 0;
  ammo_cells 0;
  weapon 9;
 }
 updateentity {
  entity 1;
  frame 13;
  origin_x 1689.00000;
  origin_y -828.000000;
  origin_z 172.000000;
  angles_1 30.9375000;
  angles_2 -52.0312500;
 }
 updateentity {
  entity 2;
  frame 16;
  origin_x 1368.75000;
  origin_y -1015.75000;
  origin_z 344.000000;
  angles_1 -5.62500000;
 }
 updateentity {
  entity 3;
  frame 7;
  origin_x 1842.12500;
  origin_y -1009.87500;
  origin_z 20.0000000;
  angles_1 11.2500000;
  angles_2 -180.000000;
  angles_3 7.03125000;
 }

I have 3 different places for angle information.

One is 'camera' followed by some numbers, another 'setangle' followed by numbers, and yet another is angles_1-3 listed under their respective entities.

In the block above, presumably entity 1 is the demo taker that looks through the 'hanging sports cam'. Notice that entity 1's angles match that of setangle.

That makes sense because entity 1 is player 1, which is an observer that's looking through the 'hanging sportscam'.

That doesn't explain the numbers after 'camera' though. I thought they might be some sort of origin coordinates, but I tested this with by making a demo and it's 0 0 0 if I never move the mouse (but move the player with forward/back/strafes). If I do move the mouse the numbers change. I never get a setangle though, and the numbers for my entity are different than the numbers for 'camera', as they are in the example block as well.

So I'm a bit confused. Do I need to use entity 3's numbers in setangle, entity 1, or both, and how does this relate to the camera's numbers?

I plan to test the results of setting camera to 0 0 0 as soon as I figure out how to edit a text file this way.

Girlich mentions nothing about camera and its values.

[Lorfa]

in .dem, the angle the camera looks is not part of any entity

Is this what explains why setview uses the position of the different entity but not its camera angles?

The angles are listed under their respective entities though yes?

(as logically it is recorded clientside to avoid latency issues).

Isn't this put together during the recording though? The resultant file appears to have angles under each entity that needs it.

instead, the camera angle is present in every single packet regardless of whether it has any entities or not.

Which explains why there are no blocks without entity 1.. I think.

this pitch (_x) angle should be -3 times the pitch angle of the entity you wish to attach the camera to. yes, negative.

First of all, which angle is the pitch? Is it always angle_3? (as in 1-2-3 x-y-z)

Second, the entity I wish to attach the camera to? I can already do this with setview, but it will only use the camera angles of entity 1.

Third, why -3 times? Why should there be any changes to the camera angles of the entity whose angles I'm trying to use for the demo?

because negatives are fun. the yaw and roll angles should match exactly (bar precision, but if they're all expressed as floats in your dump then it doesn't make any difference).

I'm more leaning towards a simple copy and paste string type operation so not a bit is changed.

I don't think I'm understanding you since they would have to be at least floats to have a decimal point yes? The snippet I gave is what lmpc outputs when it converts .dem to text.

try truncating your file so you can do your test adaptations a little faster?

Excellent idea. I just wish that adjusting the entity numbers was a more promising strategy :-/

[Spike]

in .dem, the angle the camera looks is not part of any entity (as logically it is recorded clientside to avoid latency issues). instead, the camera angle is present in every single packet regardless of whether it has any entities or not.
this pitch (_x) angle should be -3 times the pitch angle of the entity you wish to attach the camera to. yes, negative. because negatives are fun. the yaw and roll angles should match exactly (bar precision, but if they're all expressed as floats in your dump then it doesn't make any difference).

try truncating your file so you can do your test adaptations a little faster?