Changing the speed an animations plays at

[makemeunreal]

Well, I wonder if it's possible to change the speed of the flag decoration's waving animation to make it a lot slower.
Flags will have a pretty important role in my contest map, so I am desperate!

Thanks in advance!

[Barbie]

Quite easy, see code of Flag1 for example:

Code: Select all

class Flag1 extends Decoration;
...
function PostBeginPlay() {
   Super.PostBeginPlay();
   LoopAnim('Wave',0.7,0.1);
}

0.7 is the animation rate; set it to lower values to delay the movement:

Code: Select all

//=============================================================================
// MyFlag1.
//=============================================================================
class MyFlag1 expands Flag1;

function PostBeginPlay() {
   Super.PostBeginPlay();
   LoopAnim('Wave',0.1,0.1);
}

Test map attached.

[makemeunreal]

Thank you for taking the time explaining it and even making a test map. I'll post my results!

Just've modified a MyLeveled flag and it works flawless. You have even pinpointed the right speed!
Thank you!

[sektor2111]

I think it's way smaller/faster like this

Code: Select all

class MyFlag1 expands Flag1;

function PostBeginPlay() {
   Super(Decoration).PostBeginPlay(); //get over useless parent
   LoopAnim('Wave',0.1,0.1);
}


@Barbie
Why calling parent animation if is not needed ?

[Barbie]

Why calling parent animation if is not needed ?

For me it is a rule to call parent's functions (unless something really unwanted happens there), even if I know that it could have been left out. Why? Imagine someone has changed parent's or parent parent's functions code... Furthermore I don't have to look up what happens in the chain of superordinated functions to decide if a call could be left out.

[sektor2111]

Like that Humane package having duplicate call to weapon and monster spawning two weapons or the Evil Queen teleporting case ? Do you really think that calling parent is always a good practice ? I'd rather prefer to know parents up to Actor class which probably has a null PostBeginPlay - is not even defined.

[Barbie]

Like that Humane package having duplicate call to weapon and monster spawning two weapons

Do not bring in apples where pears have to be. In the Humane.u package the code is duplicated, executed and also parent's original code is executed. This is absurd has nothing to do with calling parent's function.

the Evil Queen teleporting case

I don't know that.

Do you really think that calling parent is always a good practice ?

With some exceptions I usually always do that, even if I know at that moment that no code will be executed there. But if I rework the code (I don't mean UScript necessarily) years later, I may change parent's code and then wonder and spend a lot time searching why sub class objects do not react as expected.

Actor class which probably has a null PostBeginPlay - is not even defined

The function is defined exactly there - I think you mean the function is empty. Calling a not defined function will cause a runtime error or not even compile. Again this may sound like hair splitting with words, but using the correct words is important especially in this medium where we only have words to communicate.

[Feralidragon]

The general rule of thumb is calling "super" when you want to extend, or override a single thing by just calling it again, and not when you want to replace the entire thing.
So it's like what Barbie is saying.

Of course, none of this would be necessary if the engine relied more in composition rather than inheritance, but it is what it is, and we have to live with it.

[sektor2111]

I understand your points but... as a matter of fact when I have something done expanding Actor or such, usually I look to the parent to see if worth a call there since is nothing to execute - especially at stock which no one will change too soon. Even if Epic will want to drop something there someday by accident, will badly fail as longs backward compatibility is gone by adding values and calls which client won't know what is about - it's the same as ReplaceFunction from XCGE, new variables added are not helping at all in compatibility. Exactly such problem is in Editor 451, it is rammed because of compatibility utterly screwed up; that's why I'm not interested to call null executions and neither future borks incompatible with old ones. Tick from actor - I see a lot of "generators" using that and I removed it without a single problem. Else code shown by you is not a critical thing, you can keep it as it is because nothing will explode, I only shared what I was thinking.