Trigger before loop is changing?

[PeterAdventure]

hi all,

Is it possible to play a animation before a change of loop while ego is walking ? (i can do it after the change, but i can't find a way to do it before).
The reason that i don't want it after the change is because then the first frame of new loop is displayed and this messes up my animation.

eg.

Let's say cEgo's walkpath is going up and then going left. I would like to let cEgo do a animation before he's turning left (before the 1st frame of the left view is displayed).

can someone help?
Thanks!

[Slasher]

Hi,

would this be a predefined walking of free walking?

One 'free walking' way is to use a region and use Lockview with the animation when walking onto the region just before left loop (1) kicks in so the character is still loop up (3) when animation finishes.


With a predefined walking it's easier to set up.

Hope this helps.

[PeterAdventure]

Thanks for the reply slasher.

It's for free walking. I want the character do a turninganimation when he is turning.
in "function repeatedly_execute()" i did a script to see if the loop changed and then do a lockview, the turninganimation and unlock the view again.
The problem with that is that the loop is already changed when i do my animation.

I don't know how i can use regions for that because i can't know what directions the character will take. maybe i'm wrong ?

[Dadalus]

The only way I can think of doing this is have a cDummy character (no sprites just blank loops). You would send this character first and record when it changes loop and the xy coordinates of where it happens, you could then send cEgo along the same route and do your turn animation at the xy. Im working on something to do this automatically but its not a priority for me at the moment. Hopefully someone of more experience creating games with AGS already has a solution.

[PeterAdventure]

thanks Dadalus,

won't this slow down the respond time of cEgo ? Or should I let cEgo follow the cDummy ?

[Dadalus]

You can speed up cDummy's walkspeed, but it will delay cEgo though not by anything noticeable. I suggest doing a few tests to see if this works for your problem.

[PeterAdventure]

I tried the method with the Dummy.
It is working but there are lot of issues.

ego sometimes makes extra moves and sometimes he stops in a different direction as the dummy.
Also Walkable areas and objects in the scene are problems. probably because the size of ego is bigger than the dummy.

I wish ags had something build in to make turnanimations.

[Slasher]

There is always a way of doing something if you think about it and have the knowledge..

AGS is a vehicle that you can customize to suit.

Think about what you are trying to achieve. Then think about how are you going to achieve it.

Keep trying

[Dadalus]

Perhaps leave it for a bit.

I'm gonna be tackling the same problem soon. I'll let you know what I come up with (wont be for a week or two I'm busy with something else at the moment). I cant promise I'll find a neat solution but it might help you. There are plenty of more experienced people with AGS out there so I have to think this issue has come up before.

Try searching the forums for some ideas I used 'walking turn' and found a couple.

EDIT: Maybe use cDummy.on=false when not using cDummy, then cDummy.on=true when using it(you would also have to set the location and loop of cDummy to the same as cEgo before sending it). Good luck.

[geork]

What you could do is reset the first frame of all the other animations when a character's direction is determined - something generic which would suite all 3 turning animations (depending on which way the character turns). Say if you stored which way the character was last walking in an array, and when they are not in that loop anymore, you execute the relevant animation, re-assign the first frame of the direction the character is now travelling in, and re-issue the walk command. It will require a few custom functions...

So:

1: -> When character starts to walk, set ALL the frames of the Loop your character is NOT in to a generic "about to turn" graphic

2: -> When this character's loop changes, stop the character and execute the relevant turning animation depending on their new loop

3: -> Now check for when the animation is on it's last frame...

4: -> Reset the first frame of the character's current loop to it's original, and set ALL the other frames to another generic "about to turn" graphic (this will be different as the character's loop is different)

5: -> Give your character the same walk command as was first given. This will mean you have to store coordinates and all that stuff yourself as well, so lots of custom functions!

!Make sure to be specific about when the game checks for loops and stuff, since you don't want the game to start doing weird stuff when you have other animations. I would have at the very least a custom walking function and custom stopping function, and variables telling the game whether the characters are walking from these functions.

!Also, repeatedly_execute_always() is a better function to check in, as it means that if the game is blocked for some reason, your character won't do weird stuff. Just beware that you can't give any commands in this function, or any function it calls, that are blocking. This is why I have included step 3 - if you animate your character and pass a blocking clause, then repeatedly_execute_always() won't be very happy with you.

Hope that helps!

[PeterAdventure]

Just started the script all over again with the dummy and it was going pretty well now (at the moment )

But geork suggestion is worth trying out.
I'll try that out tommorow and let you know how it goes

Thanks again!!

[Slasher]

Is this not over complicating a fairly simple issue?

[geork]

Well, it's a matter of preference I suppose...personally I'm more inclined to my method, but that's just psychiatry I think it's mostly a difference in the level of control that you have over the process - there is a slight chance that the dummy character's walk-way is different to the characters, because it has no (or less) baseline for collision detection, and because it's a certain way ahead of the character, so the character could get intercepted for some reason. But that is a very slight chance, and the dummy method is far quicker...

So yah, personal preference