Netquake demo tools?

[Lorfa]

Remaic
You do not have to make scripts to film though you can.It will generate them for you if when you mark where you want the cams and triggers,if you do not do any it defaults to chasecam.

I know. That's not what I want.

I have something like a hanging sportscam in each room that follows the player. I want to change it to POV.

I am able to change it to a type of chasecam using Remaic and this is nice and all but it's not POV. It doesn't turn as the player turns, just follows the player like if they had a drone with a GoPro following them at a fixed distance. The player can make a 360 turn and the camera doesn't move at all.

That's why I was saying I would have to make some sort of camera that mimics the player's turns exactly and this is impractical at best.

Same for LMPC you need to RTFM it does indeed support DEM and many others.

LMPC supports DEM for some things, and not others. It does not change the POV of a dem file. Try it if you don't believe me.

I do however use it to change dem to txt and vice versa and it's quite useful for this.

I already manually changed the value of setview, which is seen in only two places in the demo files and got the results I explained.

I guess I could try changing it in one place and not the other, but I don't see why this would make a difference.

I might be able to modify the resultant demo with qrack in an attempt to fix what's wrong with it, but I don't have high hopes because it appears to be inconsistent.

[Lorfa]

I figured out what was going on with the setview sportscam type demos.

When I changed the view to one of the players it places the cam on the player as if it were their own eyes, but it does not update their camera motions with what the player is doing.

Instead it uses the same view changes that the sportscam uses. So for example if the cam was up high on a corner ceiling somewhere looking down without moving much at that particular time in the game, the player's view will appear to be looking down at that time as well.

I think using demix I might be able to delete the 'follower of the cameras' so that his view info isn't even in the demo and then it will have to use the turn info from the entity I want, maybe. A lot of ways that that could fail.

Btw demix does support the view change that lmpc doesn't, so it saves me a small step of decompiling, changing setview and recompiling.

[Mindf!3ldzX]

I figured out what was going on with the setview sportscam type demos.

When I changed the view to one of the players it places the cam on the player as if it were their own eyes, but it does not update their camera motions with what the player is doing.

Instead it uses the same view changes that the sportscam uses. So for example if the cam was up high on a corner ceiling somewhere looking down without moving much at that particular time in the game, the player's view will appear to be looking down at that time as well.

I think using demix I might be able to delete the 'follower of the cameras' so that his view info isn't even in the demo and then it will have to use the turn info from the entity I want, maybe. A lot of ways that that could fail.

Btw demix does support the view change that lmpc doesn't, so it saves me a small step of decompiling, changing setview and recompiling.

I would love to see what your blood sweat and gibs results in @ the end. Be sure when you reach your goal to post a finalized demo. You seem to be digging in and not letting this thing get the best of you!

[Lorfa]

I would love to see what your blood sweat and gibs results in @ the end. Be sure when you reach your goal to post a finalized demo.

Sure, but you'd be bored to tears unless you're interested in ancient history! :-)

You seem to be digging in and not letting this thing get the best of you!

Time will tell!

Anyways I tried rearranging the setview, did nothing. I also tried demix's 'removal' option, it removed ~1 MB from the demo, but had no effect. I tried removing 1 2 and 3, and only when I removed 3 after removing 1 & 2 did I get any effect, and that effect was to just put my entity outside the map. It's not open source either, so I can't modify its removal process to suit my needs :-/

I suspect that setview is setting the origin to the entity, but still using entity 1's angles.

Assuming that's the case, one way to do what I want is to somehow replace the angle information in entity 1 with entity 3's (the pov I'm trying to get).

As a hacky idea I tried changing entity 1 to different numbers in the blocks (not in the spawnbaseline!) using the replace function on a word processor. Notepad and wordpad crashed trying to do this, well, I gave them an hour and they still weren't done so I shut them down. OpenOffice writer managed it though, although it took over 20 minutes. I guess I can't blame it, as there were 29591 entries. It also took 4-5 minutes to open, and a couple minutes to save (39 MB text file!).

This had no effect. I only tried changing entity 1 to entity 0 in one experiment, and entity 1 to entity 90 in another though. It takes so long that it isn't easy for me to run too many possibilities on that experiment. Maybe if I had changed entity 1 to 0, entity 2 to 1, and entity 3 to 2, it would work, but I'm not convinced and also this would take a long time.

I think demo playback may simply be going by the position in the file, assuming the entities are always enumerated consecutively which is a safe assumption.

Here's an example block:

 updateentity {
  entity 1;
  frame 14;
  origin_x 2564.00000;
  origin_y -747.625000;
  origin_z 136.000000;
  angles_2 90.0000000;
 }
 updateentity {
  entity 2;
  frame 10;
  origin_x 2372.12500;
  origin_y -490.250000;
  origin_z 8.00000000;
  angles_2 115.312500;
  angles_3 -4.21875000;
 }
 updateentity {
  entity 3;
  frame 7;
  origin_x 2508.00000;
  origin_y -1343.62500;
  origin_z 24.0000000;
  angles_1 0.000000000;
  angles_2 -90.0000000;
  angles_3 0.000000000;
 }

As you can see, not every entity gets an angle update for each angle, only when necessary, so that makes the generalization more difficult. Also, entities 1 & 2 are not updated every block, as sometimes I guess there's no action, or only action for one and not the other. Again making generalization more difficult. I'm also not sure about the 'frame' number, setview may be taking care of it, and it may not be. If not I'll have to address that as well.

So I need some kind of super smart text editor where I can explain to it that I want entity 3 angle info if it's there to overwrite entity 1's, and probably also remove the angle info otherwise. It has to realize that not every block will have angle info for entity 3, and that not every block will have an entry for entity 3.

This would probably be a cinch for a programmer with knowledge of string manipulation, but I am not such a person. Any ideas would be greatly appreciated.

[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?

[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 :-/

[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.

[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]

'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.

[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]

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

[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. :-/

[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 - /

[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.

[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!!