Smooth turning of actors using ActorMover possible? [Fixed]

[Enjay]

I can't remember if this has been reported properly as a bug yet or not. If not, it would be a good idea to do so just to stop it getting lost in the depths of the editing forum. I suspect, however, that it might be more relevant, or at least easier to demonstrate, in GZdoom because you can really only see it when the actor uses a model given that sprites are only drawn from a limited number of angles anyway.

Oh, and BTW, it might be worth trying with a new SVN version. As far as I know, there is nothing in it that would affect this but there were some changes to the model code recently. I think that it was only to do with fixing multiple skin support on MD3s though. If you do try it, you'll need to go back to the official version afterwards because the current SVN version has the (now fixed) Zdoom bug of thrusting things massively with the rocket explosion.

[Enjay]

Hmmm, OK, actually trying this, I'm not getting the reported error, certainly not with the current GZdoom anyway. Try this file (just load up the whole zip).

http://www.zen64060.zen.co.uk/examples/rotate.zip

On the left you will see an actor that uses the zombieman sprite. On the right is a model. Both are being rotated by the script that was posted in this thread earlier. As expected, the Zombie "jumps" because he is only drawn from a limited number of angles but the model rotates smoothly. Using IDDT IDDT at the automap confirms that both actors are turning smoothly.

(BTW, apologies for the model - it was just the first one that I found in my working directory already set up for GZdoom. And no I didn't make it it was part of some pack or other for Duke Nukem.)

[ReX]

Yes, your model clearly turns very smoothly. If it's using the same script that I developed, then I am at a loss for why I can't get it to work. Perhaps it's a camera thing? Remember that the actor is being moved by an actor mover, and is being followed by a camera.

[The simplest thing would be for you to look at the entire set-up, which will be ready soon.]

[ReX]

Okay, let me ask this question somewhat differently. Can interpolation points (Thing Type 9070) be used to accept angles other than multiples of 45 degrees? I think the key problem may be with the inability of interpolation points to accept angles other than multiples of 45 degrees. This is manifesting itself in-game by the model's actor-mover ignoring the angle specified via the editor, and aligning itself with the nearest multiple of 45 degrees. This also seems to be the case with a regular moving camera; it ignores any angle assigned to an IP other than a multiple of 45 degrees.

If this is the case, then I'd like to take the next step and make it a feature suggestion.

[ReX]

Randy confirms that interpolation points do, indeed, accept all angles. So next I thought that perhaps I need to instruct the actor mover (which "drives" the model) to also adopt the angles of the IP. I have code for another actor mover (a helicopter), but it uses 2 parts - fuselage & rotor, whereas the model (of a tram) with which I'm having a problem only has a single part. I'm unable to figure out how the Osprey code can be adapted for the tram, but perhaps someone here can help. Here is the script for the Osprey mover:

---

Code: Select all

//****
// Script 33-34: Activates Osprey flight
//****

int OspreyParts[2];
int PartOffset[2][3] = {{340.0, 0, 0.25}, {342.0, 0, -0.25}};
str PartName[2] = {"OspreyBlade", "OspreyBlade"};

#define OSPREY_MOVER_TID   100   //the moving camera tid you want to fix the Osprey to
#define OSPREY_TID		1000
#define OFFSET_RADIUS	0
#define OFFSET_VERTICAL	1
#define OFFSET_ANGLE	2

int OspreyBob;
bool InFlight;

script 33 (void)
{
  int i, a, b, z;
  Thing_Activate(OSPREY_MOVER_TID);
  while (TRUE)
  {
    a = GetActorAngle(OSPREY_MOVER_TID);
    SetActorAngle(OSPREY_TID, a);
    SetActorPosition(OSPREY_TID,
      GetActorX(OSPREY_MOVER_TID),
      GetActorY(OSPREY_MOVER_TID),
      GetActorZ(OSPREY_MOVER_TID) + FixedMul(sin(OspreyBob), 16.0),
      0);
     
    for (i=0; i<2; i++)
    {
      a = (GetActorAngle(OSPREY_MOVER_TID) + PartOffset[i][OFFSET_ANGLE] + 1.0) % 1.0;
      SetActorPosition(OSPREY_TID + 1 + i,
        GetActorX(OSPREY_MOVER_TID) + FixedMul(cos(a), PartOffset[i][OFFSET_RADIUS]),
        GetActorY(OSPREY_MOVER_TID) + FixedMul(sin(a), PartOffset[i][OFFSET_RADIUS]),
        GetActorZ(OSPREY_MOVER_TID) + PartOffset[i][OFFSET_VERTICAL] + FixedMul(sin(OspreyBob), 16.0),
        0);
      SetActorAngle(OSPREY_TID + 1 + i, GetActorAngle(OSPREY_MOVER_TID));
      delay(1);
    }
  }
}

script 34 (void)
{
   InFlight = TRUE;
   while (InFlight)
   {
      OspreyBob += 512;
      OspreyBob %= 1.0;
      delay(1);
   }
}

[ReX]

Well, finally I believe I have a fix for the tram models (and cameras) not turning smoothly. Eruanna had indicated that ZDooM places interpolation points into the map oriented towards the closest multiple of 45 degrees that the IP has been assigned in an editor. [In other words, this is a bug/limitation of ZDooM, where the IP is never placed in-game at angles other than multiples of 45 degrees.] I had tried rotating the IPs using Interpolation Specials that triggered scripts that adjusted SetSectorAngle, and it seemed to be turning the tram fractionally before the tram simply resumed adoption of the appropriate multiple of 45 degrees. Eruanna pointed out to me that I was rotating the tram, not the interpolation points. Anyway, I went in and messed around with the IP and scripts, and finally figured out that the scripts for SetActorAngle for the IPs could be put into the OPEN script. Et Voila! It now works like it's supposed to.

At any rate, what Randy said notwithstanding, this appears to be a limitation of ZDooM. The game should automatically accept the angles assigned to an interpolation point, and not require adjustment via a script. I'll report it in the Bugs Forum.