Changing the speed an animations plays at

Tutorials and discussions about Mapping - Introduce your own ones!
Post Reply
User avatar
makemeunreal
Masterful
Posts: 546
Joined: Tue Mar 26, 2013 6:34 pm

Changing the speed an animations plays at

Post by 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! :highfive:
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Changing the speed an animations plays at

Post by 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.
Attachments
TestSlowFlag.unr
(5.5 KiB) Downloaded 35 times
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
User avatar
makemeunreal
Masterful
Posts: 546
Joined: Tue Mar 26, 2013 6:34 pm

Re: Changing the speed an animations plays at

Post by makemeunreal »

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

Just've modified a MyLeveled flag and it works flawless. You have even pinpointed the right speed!
Thank you!
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Changing the speed an animations plays at

Post by 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 ?
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Changing the speed an animations plays at

Post by Barbie »

sektor2111 wrote: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.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Changing the speed an animations plays at

Post by 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.
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Changing the speed an animations plays at

Post by Barbie »

sektor2111 wrote: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.
sektor2111 wrote:the Evil Queen teleporting case
I don't know that.
sektor2111 wrote: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.
sektor2111 wrote: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.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Changing the speed an animations plays at

Post by 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.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Changing the speed an animations plays at

Post by 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.
Post Reply