Velocity code pointer improvements

[FDARI]

A_ChangeVelocity

Names assigned to existing flags: CVF_RELATIVE, CVF_SETSPEED

New flag: CVF_THINGSPEED
Effect: The provided vector is multiplied by the thing's defined speed, so that 1,0,0 means straight ahead. This is good for code organisation and inheritability. Wanted for the ability to call A_ChangeVelocity in several places with the vector magnitude defined only once, and for the ability to efficiently redefine vector magnitude in a child actor. (By assigning the child actor a different speed.)

---

The function was saving intermediate data that would not necessarily be used, as well as data that would evidently never be used. fixed_t vx, vy, vz are no longer defined. The parameters x,y,z are used in their stead. All variables and processing for rotation according to actor angle has been moved into the conditional branch for VELF_RELATIVE, so that it is not processed if it is not used.

A_ScaleVelocity

New parameter: int flags

New flag: SVF_SETSPEED
Effect: Scale velocity to the chosen magnitude, instead of scaling it BY the chosen magnitude. The direction remains unmodified.

New flag: SVF_THINGSPEED
Effect: Multiply the chosen magnitude by the actor's defined speed.

If the actor is not moving, A_ScaleVelocity has no effect, regardless of flags.

A_ScaleVelocity(1, SVF_SETSPEED|SVF_THINGSPEED) would reset any actor's velocity to its speed, without altering its direction. (Unless the actor has no current velocity, in which case nothing happens.)

---

The entire function is without effect if the caller is not already moving. The act of storing "has_moved" based on initial speed and checking it at the end is therefore unnecessary. This has been replaced with a condition for the rest of the function body; no further operation is performed unless the actor was moving in the first place. All subsequent operations consider it proven that the actor had a non-null initial vector.

Bitwise OR on boolean test of vector components has been changed to logical OR.

Recent additions (A_ScaleVelocity):

SVF_SAVESPEED (flag): Assign the resultant velocity as the actor's current speed (set speed property, not just velocity along x,y,z-axis).
SVF_NOUPDATE (flag): Omit the standard operation of updating the actor's speed. Must be used in conjunction with another behaviour. It is meaningless to disable update without adding another effect.
(Currently the only meaningful use of SVF_NOUPDATE is with SVF_SAVESPEED)

Special note: A_ScaleVelocity when the actor is not moving at all
A_ScaleVelocity normally has no effect whatsoever when the actor is not moving already.
I have added one exception to this, and that is when the flags show clearly that you are not using or affecting the current velocity at all:
SVF_NOUPDATE: This shows that you will not be affecting the current velocity, but requires you to provide an alternate operation.
SVF_SAVESPEED: This is the only alternate operation defined.
SVF_SETSPEED: This shows that you will not be using current velocity to calculate resultant velocity.

A_ScaleVelocity(float speed, SVF_SAVESPEED|SVF_NOUPDATE|SVF_SETSPEED) is guaranteed to behave like (ACS) SetActorProperty(0, APROP_SPEED, fixed speed), but also gives you the opportunity to include other relevant flags (SVF_THINGSPEED).

EDIT: The patch and the first post have been edited based on recommendations and new ideas. Flag names were different at the time they were first discussed.

[Gez]

VELF_RELATIVE, VELF_SETSPEED VELF_THINGSPEED
SVELF_SETSPEED SVELF_THINGSPEED

Why not use the same flag names (and values)? VELF_SETSPEED, VELF_THINGSPEED. I know, VELF_RELATIVE wouldn't be used by ScaleVelocity, but it doesn't matter.

If you name them VELF it looks like they're generic velocity flags, so the same set ought to be used by all velocity functions. Otherwise the names would be stuff like CVF_FOO and SVF_BAR to keep with the existing conventions of using the function's initials.

[Major Cooke]

@Gez: Nice Foobar reference.

@FDARI: DAMN! This will come in handy!

However, you make suggestive hints through the word "code pointer" in the title of the thread so immediately off the bat I was thinking "Did FDARI seriously implement the ability to use code pointers!? FUCKING SWEET!". So the title of the thread is a little bit deceptive, though I know no harm was meant.

Now, could you provide an example for the A_ChangeVelocity change as well, please? I mean, a bit more indepth I should say. For instance, does 1,0,0 also cover the projectile moving downwards too, or in order to cover that will we need to use 1,0,1?

[Gez]

The ability to use code pointers has been around since dehacked. What do you think all those A_Whatever things are?

[Major Cooke]

Okay, you got me there. That actually makes perfect sense. Heh.

[FDARI]

Send something straight ahead using relative vector, pitch and actor speed: A_ChangeVelocity(cos(pitch), 0, -sin(pitch), VELF_RELATIVE | VELF_THINGSPEED | VELF_SETSPEED)
Send something straight ahead using absolute vector, pitch and actor speed: A_ChangeVelocity(cos(pitch) * cos(angle), cos(pitch) * sin(angle), -sin(pitch), VELF_THINGSPEED | VELF_SETSPEED)

These are very simple uses, made to demonstrate the a viable method. All the parameters used for xyz will be in the range 0.0, 1.0. (1.0 is 100% of speed) 2.0 is a valid value (double of speed), as is -5 .

You can choose to add these speeds instead of assigning them, by not including the SETSPEED flag.

Gez: I wrote one function, and then realised I actually needed the other myself, so the first one got a generic name, and for the second one I realised that flags would not equally apply to both.

I / anybody can submit a second patch where this is corrected to either of your recommendations. I think two enums and adherence to existing conventions is the safer route.

[Major Cooke]

Pitch? I thought that was only factored into things fired off from the player... Hmm. Well I suppose it would work with them.

[FDARI]

Pitch isn't set automatically for monsters, but you can set it, and you can use the value. The examples above suggest that you want an actor to move exactly at its speed in exactly the direction it is facing, and assume that pitch has the correct value. If you set up a player with no gravity to call these continously, he's liable to drift ahead at a speed of 1 or so. I tested it. On a monster, you'd have to use A_SetPitch to provide a pitch first, or use some completely different approach.

[FDARI]

Reuploaded with new flag names; CVF and SVF.

[FDARI]

http://forum.zdoom.org/viewtopic.php?f= ... 45#p592784

The code pointer A_SetSpeed or something similar seems requested. It is almost the same as A_ScaleVelocity() with SVELF_SETSPEED. Differences are:
- My submitted A_ScaleVelocity will update speed immediately. I think the request entails the ability to change specified speed without affecting current motion.
- My submitted A_ScaleVelocity features no means of storing the resultant speed as the actor's current speed property (for use by A_SeekerMissile and possibly other features).

Both of those capabilities could be provided as flags:
- SVELF_NOUPDATE (don't update actual vector)
- SVELF_SAVESPEED


A_ScaleVelocity(target_velocity, SVELF_SETSPEED | SVELF_SAVESPEED) to set speed and update velocity, A_ScaleVelocity(target_velocity, SVELF_SETSPEED | SVELF_SAVESPEED | SVELF_NOUPDATE) to set speed without further effects.

I want to do it here, rather than in a new function, because flexibility is greater that way. This would also give you:

A_ScaleVelocity(scaling_factor, SVELF_NOUPDATE | SVELF_SAVESPEED) to multiply current velocity by a factor (may be 1, if you just want to record the current speed) and save it as actor speed.
A_ScaleVelocity(scaling_factor, SVELF_NOUPDATE | SVELF_SAVESPEED | SVELF_THINGSPEED) to multiply assigned speed (not current velocity) by a factor and save that as new assigned speed.

And of course, noupdate can be removed from the above to put the change into action directly.

Are those flags good; should I add them?

Also: Time to verify that this is at all viable, and to check whether SVELF_DEFAULTSPEED (fetch speed from class, as opposed to SVELF_THINGSPEED fetching speed from the possibly modified thing) is an idea.
(SVELF_DEFAULTSPEED does not seem all that viable. Unless it turns out to be hugely desirable, it will probably never be made.)

All flagnames are to be prefixed SVF; not SVELF.

EDIT: It seems investigating is doing. Done. Let's hope it's good. First post updated.

[Major Cooke]

I shall give this a shot immediately.