Page 1 of 2

Smooth turning of actors using ActorMover possible? [Fixed]

Posted: Thu Jan 07, 2010 7:24 am
by ReX
I have a model that is moving along a path using an ActorMover. The path curves in a couple of places, and I've placed interpolation points that are angled appropriately along the curve (i.e., 12, 23, 34, 45, 56, 67, 78, and 90). Unfortunately, what seems to be happening is that as soon as the model reaches the first IP in the curve, it immediately assumes a 45 degree angle, instead of a 12 degree angle. It remains that way until it passes the IP angled at 45 degrees, and then it turns to 90 degrees. In other words, it seems to be ignoring the angles that are not multiples of 45 degrees, and looks very awkward and unrealistic.

Am I doing something wrong, or is this simply a limitation of ActorMovers & interpolation points?

(Incidentally, this seems to be happening even with my moving camera.)

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Thu Jan 07, 2010 7:33 am
by Enjay

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Thu Jan 07, 2010 11:22 am
by ReX
I'll certainly give it a shot, but that would mean setting up interpolation specials at each point where the path curves and writing a script for each interpolation special. While this is manageable for a limited number of IS points, it could get quite cumbersome if there were dozens of such points. In my post above I was wondering why the actor is not assuming the proper angle, even though the ActorMover has the proper argument for (in this case, the 3rd parameter - Options - is set to 2: Thing will adjust its angle to match those of the points it passes).

Thanks, anyway.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 7:09 am
by ReX
I tried the SectorSetAngle method, but it doesn't materially affect the angle of the model. The model still only assumes angles that are multiples of 45 degrees, but now it occasionally flickers, as if it is trying to assume the angles defined in the scripts via SectorSetAngle.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 7:13 am
by Cutmanmike
If the monster is constantly calling A_Chase then it will change the angle every time. It's a tricky one.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 7:17 am
by Xaser
Are you trying to animate a monster, perchance? I'm not that experienced with using models in GZDoom, but I do know for an unfortunate fact that monsters can only face one of eight directions (an internal Doom limitation that's not easily changed). This may extend to other or all actor types as well, though whether or not that is true is out of the bounds of my knowledge.

[EDIT] What Cutty said. Perhaps he knows more. ;P

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 7:29 am
by ReX
Cutmanmike wrote:If the monster is constantly calling A_Chase then it will change the angle every time. It's a tricky one.
Actually, this is a static actor (a model of a tram that runs on tracks), that does not have an A_Chase function built in. Using an ActorMover, I have set it in motion on a path along the track. It's when the track curves that I'm having this problem.

In answer to Xaser's point, I realize that with monster sprites where there are only 8 angles, there would be a limitation. But we're dealing with a model here, so there should not be that issue.

Here is the DECORATE definition:

Code: Select all

ACTOR Tram 30313
{
	Radius 40
	Height 32
	Mass 0x7FFFFFF
	+FLOORCLIP
	+SOLID
	States
	{
	Spawn:
		POSS A 3
		Loop
	}
}

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 7:30 am
by Enjay
Now that I think of it, I have also noticed models "jumping" in 45 degree steps when moving (you can see this in the converted pig tanks in my Burghead mod).

I wonder, however, if this can be affected at all by giving the underlying actor 16 angle sprites? Or is visual appearance and physical direction not related at all?

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 7:47 am
by Cutmanmike
ReX wrote:
Cutmanmike wrote:If the monster is constantly calling A_Chase then it will change the angle every time. It's a tricky one.
Actually, this is a static actor (a model of a tram that runs on tracks), that does not have an A_Chase function built in. Using an ActorMover, I have set it in motion on a path along the track. It's when the track curves that I'm having this problem.
Oh right, my bad. I should actually learn to read the initial post.

I haven't had too much experience with actor mover. For cinematics and such I tend program it hackily myself for reasons such as this one. If you have a huge track that may not be desirable but can't think of any cleaner way to do this.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 8:17 am
by Enjay
ReX wrote:I tried the SectorSetAngle method, but it doesn't materially affect the angle of the model. The model still only assumes angles that are multiples of 45 degrees, but now it occasionally flickers, as if it is trying to assume the angles defined in the scripts via SectorSetAngle.
I suspect that movement and turning are conflicting. It would seem, as already stated, that things can only mode in 8 directions though, clearly, they can be viewed from far more angles.

If I use this adaptation of the script in the Wiki:

Code: Select all

#include "zcommon.acs"

script 1 (void)
{
    SetActorAngle (1, GetActorAngle (1) - 0.02);
    Delay (1);
    Restart;
}
I can get a model-based item to spin on the spot quite happily.

Try loading the attached on top of the Bangcrate demo pk3 (or Paranoid PK3 if it is all consolidated) and puke script 1. You should see the crate start rotating smoothly.

If this works, it might be possible to stop the tram and rotate it when it gets to certain junction points or whatever. That may not be as satisfying as a curved track but it is not inconsistent with how the tram in the original HL intro behaved.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 8:42 am
by Graf Zahl
This should work. Needs some investigation so please don't use any hacks. If it's really an engine bug chances are that if the bug gets fixed the hacks stop working.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Fri Jan 08, 2010 8:58 am
by ReX
Cutmanmike wrote:For cinematics and such I tend program it hackily myself for reasons such as this one. If you have a huge track that may not be desirable but can't think of any cleaner way to do this.
The track is indeed quite long, but most of it is straight stretches, on which there are no issues. It's only in the two curved sections of track that the problem manifests itself.
Enjay wrote:If this works, it might be possible to stop the tram and rotate it when it gets to certain junction points or whatever. That may not be as satisfying as a curved track but it is not inconsistent with how the tram in the original HL intro behaved.
Yes, your demo has indeed shown that a model can turn at every possible angle. Let me try the stop/start method, and see how that works. (I'll first put in a small holdtime in each IP, and see if that works. Otherwise I may have to put the stop/rotate/start instructions into each script.)

EDIT: OK, I tried the holdtime method, and here's my report: The model will briefly align itself according to the SetActorAngle in each script, then align itself to the closest multiple of 45 degrees along the track. Clearly, we are getting closer to a solution, but it still eludes me. The trick lies in getting the actor to retain its angle until the next script is triggered. Here's the relevant portion of the script:
Spoiler:
And here's the set of parameters for one of the IP & IS. The parameters for the others are similar:

Interpolation Point: (0, 15, 4, 241, 0) = (pitch, traveltime, holdtime, next IP, hi-byte); angled at 78 degrees; tag = 242
Interpolation Special: ACS_Execute (7, 0, 0 , 0, 0); tag = 242
Graf wrote:This should work. Needs some investigation so please don't use any hacks. If it's really an engine bug chances are that if the bug gets fixed the hacks stop working.
Not to worry. At present, the only techniques I'm using are via simple scripting, which can easily be deleted once a permanent solution emerges. Thanks.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Sun Jan 24, 2010 1:22 pm
by ReX
Graf Zahl wrote:This should work. Needs some investigation so please don't use any hacks. If it's really an engine bug chances are that if the bug gets fixed the hacks stop working.
Not to seem impatient, but I'm bumping this thread in case this issue may have been forgotten.

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Wed Jan 27, 2010 5:55 am
by Cutmanmike
I know Graf said no hacks but I think this could work for the time being. Instead of just having the actor mover, have two. One should be a dummy actor that does nothing but follows the track JUST in front of the actor with your model. Now have the actor with the model hate the actor in front (using Thing_Hate, may need to make it shootable too.) and give it repeated calls for A_FaceTarget. This should make the actor ALWAYS look at the thing in front of it, not restricting it to A_Chase calls and such.

I.e

Code: Select all

See:
MODL A 1 A_FaceTarget
loop

Re: Smooth turning of actors (using ActorMover) possible?

Posted: Mon Feb 01, 2010 7:32 am
by ReX
Cutmanmike wrote:I know Graf said no hacks but I think this could work for the time being. Instead of just having the actor mover, have two. One should be a dummy actor that does nothing but follows the track JUST in front of the actor with your model. Now have the actor with the model hate the actor in front (using Thing_Hate, may need to make it shootable too.) and give it repeated calls for A_FaceTarget. This should make the actor ALWAYS look at the thing in front of it, not restricting it to A_Chase calls and such.

I.e

Code: Select all

See:
MODL A 1 A_FaceTarget
loop
I think I understand what you are suggesting. I am hoping that Randy or Graf will resolve this issue, but if not I'll certainly give your idea a shot.