Problems getting BattleMech working in Darkplaces

[Wazat]

Hey all, long time no see.

I'm trying to get my BattleMech mod working in Darkplaces stable release 20070311. When I first ran it the mech's head would not turn at all, and there was a long delay between camera angle resets so the player's camera actually turned a lot when he tried to turn his head (the angle resets are supposed to keep the camera from turning at all). Now with my temp fix there's still a huge delay in updating the camera.

The way BattleMech detects the player's mouse movement to turn the head is kind of a hack. Every frame it checks if the player's v_angle has deviated from his camera angle and, if it has, detects how much and turns the mech head by that much. Then it sends the MSG_ONE to force his view to the camera's angle again:

Code: Select all

   msg_entity = self;
   WriteByte (MSG_ONE,5);   
   WriteEntity (MSG_ONE, self.ccam);

   WriteByte (MSG_ONE,10);
   WriteAngle (MSG_ONE,self.ccam.angles_x);
   WriteAngle (MSG_ONE,self.ccam.angles_y);
   WriteAngle (MSG_ONE,self.ccam.angles_z);


This evil hack works just fine in older engines like TomazQuake and the classic GLQuake. Unfortunately, as said above the head wasn't turning in DP. With some searching I discovered that the MSG_ONE used to reset the player's view angle to the camera was wiping out any angles on the player before they could ever be detected by my head turning code, even when I broadcast them after the detection code (as if the previous call lags behind by 1 frame and then hits before the next detect).

To try to counter this, I added this check before the call to reset the player's view:

Code: Select all

   if(lookyawset > 0.0001 || lookyawset < -0.0001)
      PlayerSetCamView();


This code says only reset the player's view angle IF his angle has changed. This gives the head turning code (above those lines) a chance to detect changes and act on them.

Unfortunately, the code also adds a nasty lag to the angle updates, both in DP and TomazQuake. DP suffers the most, with very noticeable and common delays between updates (although that delay was already mostly present before). TomazQuake also has little skips where the camera turns to the side slightly from time to time while the player is turning his head (and TQ had no problem before). So this isn't the best solution.

Another thing I've noticed that might explain the difference is DP's update rate for the playerprethink appears to be slower. That would explain why the camera is turning so much before the update snaps it back into position. Perhaps upping this to a much faster frequency would help? Is there a DP setting for that?

If LordHavoc or anyone else can tell me what's going on, I'd be very pleased and relieved, as this has my mind boggled. Getting BM to work in DP again has long been one of my desires because I want so many of DP's features, and I have a suspicion that the multiplayer camera bug (where each player's turn angles affect other players) may be TQ-related.

If anyone wants to get ahold of BattleMech's current source I'd be happy to send it to them, or attach it to my post if the forum allows. I could also be available through a Skype or TeamSpeak chat if needed.

[LordHavoc]

Hey all, long time no see.

Stop disappearing on us, we miss you

I had a fairly long reply to this post, but it didn't work well as a point by point reply to a larger problem, so I scrapped it.

TargetQuake and TAoV use the same method to read turning, and they do work.

Don't skip angle updates when the yaw change is minor, that breaks DP's spectator interpolation (which makes camera turns smooth rather than jerky when constantly setting the angles like you are).

You should be using this method:

Code: Select all

   WriteByte (MSG_ONE,5);   
   WriteEntity (MSG_ONE, self.ccam);

   self.angles = self.ccam.angles;
   self.fixangle = TRUE;


It is important to use self.fixangle instead of MSG_ONE for such angle updates because reliable messages can not be sent as often, leading to choppy motion in multiplayer.

It's also important to understand that DP has predicted player movement and non-predicted movement modes, the predicted mode is only active if the client has the cl_movement cvar set to 1, and the server self entity has self.movetype set to MOVETYPE_WALK, any other case shuts off prediction.

When predicted, PlayerPreThink/PlayerPostThink are called once per client packet received (containing movement data - these sometimes come in at irregular frequencies due to network issues), and also once per server frame (the normal timing) with frametime set to 0, just to make sure that the QC can do what it wants to every frame (particularly important if the player is spectating someone, for smooth viewing).

When not predicted, PlayerPreThink/PlayerPostThink are only called once per frame, as in Quake.

Anyway, my main guess is that the fact you're not using self.fixangle is the main problem.

I'd be interested in fixing compatibility with the original battlemech as well however, when I get time.

[leileilol]

Hey all, long time no see.

!!

that is all


why an old darkplaces? The later october/november releases have fancy water crap in them.

[Wazat]

Hi LordHavoc!

Thanks for the quick reply. I apologize for being so.... gone all the time. I haven't coded for Quake in ages, and I'm trying to get back into some of my old projects.

I've implemented the change you gave me, and it did fix the problem with the camera swinging to the side when the player aimed. However, it creates a problem and reintroduces one other.

1. The camera is facing forward instead of down. Does fixangle not handle angles_x? I know that TAOV and most mods are using an x angle of 0 (facing forward), so this probably isn't a problem for most situations.

2. The camera no longer responds to mouse input, as before. I'm sure I'm missing something simple though.

Here is the code I use to detect mouse input and reset the camera after. PlayerTurnHead is called at the very bottom of PlayerPreThink.

Code: Select all

void() PlayerSetCamView =
{
   msg_entity = self;
   WriteByte (MSG_ONE,5);   
   WriteEntity (MSG_ONE, self.ccam);

   self.angles = self.ccam.angles;
   self.fixangle = TRUE;
};

void() PlayerTurnHead =
{
   local float lookyawset;
   local vector o1, o2;

   if(!self.ishuman) // bots are pretty limited
   {
      //self.angles_y = self.vehicle.angles_y;

      if(self.keys & KEY_LOOKLEFT)
         lookyawset = -5;
      else if(self.keys & KEY_LOOKRIGHT)
         lookyawset = 5;

      return;
   }
   // turning head

   makevectors(self.v_angle); // variable (player's v_angle) we're testing against the control (our camera)
   o1 = self.v_angle;//v_forward * 100;// + '0 500 0';

   makevectors(self.ccam.angles); // control that should not change
   o2 = self.ccam.angles;//v_forward * 100;

   // debug
   bprint(vtos(self.v_angle));
   bprint(" = v_angle\n");
   bprint(vtos(self.ccam.angles));
   bprint(" = self.ccam.angles\n");

   // determine the angle difference
   lookyawset = (o1_y - o2_y) * 1.0;//vectoyaw(vorg) - 90;

   // more debug
   bprint(ftos(lookyawset));
   bprint(" = lookyawset\n");
   bprint(ftos(frametime));
   bprint(" = frametime\n");

   // self.lookyaw is a prettied up form of self.angles_y that is used elsewhere
   self.angles_y = self.lookyaw + lookyawset;
   self.lookyaw = self.angles_y;
   while(self.lookyaw >= 360)
      self.lookyaw = self.lookyaw - 360;
   while(self.lookyaw < 0)
      self.lookyaw = self.lookyaw + 360;

   // now snap the player's camera back into place so it looks good and will be ready for more detection later
   PlayerSetCamView();
};



At some point I want to look up TAOV's code and see how others have gotten it to work. But, if there's something glaringly wrong in my code, I'd love to just be told what it is.

Thanks LH!

[Wazat]

Hrm...

The camera not pointing down issue is clear to me now. It stems from a fundamental flaw with the way BattleMech does its aiming. In BM the player entity is the mech's head, and I set the mech's head's X angle to aim up or down.

With the new code, I also set the player's angles to force the camera with .fixangles. So it's just a matter of which code (reset view to camera or aim up/down) runs last. This wasn't a problem with the writebyte, but now since both use .angles it's a big conflict that I'll have to solve somehow.

Maybe the .veapon (visual weapon on the mech's shoulder) could be what aims, and the head always points forward... Or maybe I need to make the head another entity that follows the player, and the player is invisible.

*grumble, grumble* Wish I'd thought this stuff through back when I was writing it.

Also still working on the "not detecting any mouse movement" bug.

[LordHavoc]

*grumble, grumble* Wish I'd thought this stuff through back when I was writing it.

Also still working on the "not detecting any mouse movement" bug.

These camera hacks always give me a headache

The only clean way to do a camera in Quake is make the client be the camera entity (no need for svc_setview then), and make the character be a dummy that follows orders (based on trapping the input of the camera entity), like in Prydon Gate, The Ascension of Vigil, Envenom, and several other projects.

Mostly RenegadeC is the one to talk to about this, or FrikaC.

But as for accepting mouse turning input AND changing the camera too, that I'm not so sure about

Worth noting that DP now has a chase_overhead cvar (requires chase_active 1), if that's of any use for DP-specific mods (not BattleMech).