A_ScaleVelocity does not work/play well with A_SeekerMissile

[Sir Cyril Fudgelot]

It seems as though when A_SeekerMissile is successfully called, it resets the speed of the projectile.

As an example, see the attached wad.

Pick up the minimissile launcher (looks exactly like a rocket launcher in this demo), hit IDDQD, and stand against the back wall of the room. Fire the minimissile launcher. The missiles will stop very quickly, and hang in the air.

However, when the cyberdemon comes within range of the minimissile's target acquisition range, the missiles will suddenly all revert to their base speed of 5 and swarm the cyberdemon.

I eventually wish for my minimissile launcher to have missiles that start off at a speed of 5 but then build up to a speed of 30. After trying and failing to get it to work, out of desperation, I tried lowering the speed, and in response, found this bug. Having my missiles speed up doesn't work, because as soon as they get close, they slow down again.

[NeuralStunner]

A_SeekerMissile uses Speed to determine the velocity to apply toward its Tracer.

Personally I don't think this is a bug, but I understand the annoyance and am curently trying to think of a way to work arround it.

So far, all I can think of is a script to [wiki=SetActorProperty]set the speed property directly[/wiki]. An all-in-one solution would be great: A_SetMissileSpeed, which would at once change the Speed property and adjust velocity to follow. (I'm sure there's code somewhere to extrapolate direction from current momentum...)

Though your troubles do inspire ideas of aggressive mines which leap at targets as they come in range.

[Sir Cyril Fudgelot]

So, have it run a script, which script increases the speed of the activator of the script?

That... works, I suppose. I know Graf has a thing against encouraging cheap hacks when fixing the engine would solve the problem in a more permanent way. Before doing such a hack (or programming those mines, which also might be kind of fun) I'd like to hear the word from the devs as to whether this issue should be fixed or not. (Lest we have another ifrit-like experience.)

[FDARI]

This isn't really a bug is it? I took it to be a feature to be desired.
The feature missing might be a flag for A_SeekerMissile to use the current velocity rather than the class/actor property "speed".

I've listed it for followup. A code submission in feature suggestions may follow. Unless this is considered a bug afterall.

[NeuralStunner]

The feature missing might be a flag for A_SeekerMissile to use the current velocity rather than the class/actor property "speed".

"Current velocity" is very subject to degredation (from fixed point inaccuracy, especially).

[FDARI]

That's true, but if you have attained your current velocity through calls to A_ScaleVelocity, what better measure of speed can you find?

Of course, there is also this... http://forum.zdoom.org/viewtopic.php?f=34&t=30672 (Feature suggestion for a_changevelocity and a_scalevelocity)
It allows you an alternate solution: Use some reliable integer value (such as a user-variable) to track the desired current speed, and use A_ScaleVelocity(user_targetspeed, SVELF_SETSPEED) to scale speed TO targetspeed instead of BY targetspeed. It is a useable trick.

Of course... It might be useful to add flags such as SVELF_SAVESPEED to update the actor's individual speed data. <speculation>I think actors have individual speed data, although they tend to match class speed data. However, we'd also need to validate that any relevant bundle of features references the actor's speed and not the class' speed. If the actor tracks speed; you usually fetch data using as few references as possible (actor->speed, as opposed to actor->class->speed).</speculation>

[Sir Cyril Fudgelot]

See, that's why I asked. I thought it was a bug, because it was a feature that didn't behave like I expected it to behave. (I naively thought velocity and speed were supposed to be the same. Meh.) I recognize that Graf and Randy might disagree with me, in which case I'd happily implement NeuralStunner's suggestion, and have fun with aggressive homing mines instead. However, if a Dev later goes back and fixes this issue, then I'm left with a broken set of mines and a kludgey homing missile. Right now, I'm actually more interested in word from the devs about whether this issue is a bug or not than I am in having it fixed immediately.

[NeuralStunner]

That's true, but if you have attained your current velocity through calls to A_ScaleVelocity, what better measure of speed can you find?

It would both solve the issue and open up a lot of modding possbilities if one could set speed, and access it as a [wiki=DECORATE_expressions]Decorate expression[/wiki]. An A_SetSpeed (or however you call it) property could work for anything with a Speed (such ss monsters), Give the function an "update immediately" property to adjust a missile's velocity* to the new Speed value...
A_SetSpeed (Speed * 0.5, SSF_UPDATEVELOCITY) - A_ScaleVelocity equivalent, but also sets the base Speed, for seeking missile coolness!
A_SetSpeed (Speed, SSF_UPDATEVELOCITY) - If you've scaled velocity and want to restore it to original Speed, this'll do the trick.

Could I convince you to work on such a thing?

I recognize that Graf and Randy might disagree with me, in which case I'd happily implement NeuralStunner's suggestion, and have fun with aggressive homing mines instead. However, if a Dev later goes back and fixes this issue, then I'm left with a broken set of mines and a kludgey homing missile.

If the current behavior isn't a bug then it shouldn't and won't change, that would rasie compatibility issues otherwise.


* Would still require extrapolation of velocity to get a missile's current direction, sadly.

[FDARI]

In reply to that, NeuralStunner, let me say http://forum.zdoom.org/viewtopic.php?f= ... 98#p592798 and ask your opinion. Anybody else is welcome to chip in.

EDIT: Can't take it slow, can I? The code submission is updated. Please review. And test, if you can.

[randi]

Added SMF_CURSPEED flag for A_SeekerMissile.