Actions not always blending

I’m making a game engine, and some of the transitions between animations will always blend, but some of them will only sometimes blend, and other times not blend, which is very annoying.

For example, I have a walk animation and a jog animation, and I have the frames for both perfectly lined up in python so that when the walk animation blends into the jog animation, there is a seamless transition. The transition from walk to jog almost always works flawlessly. However, when in jog mode, I line up the frames perfectly so that there should be a seamless transition back to the walk animation when my character slows down, but I’d say 2/3 times it does not blend, which causes a very ugly transition.

Anybody have any ideas on what to check?

I have the same problem going back to my ‘always sensor’, for my static/idle animation.
It is glaringly obvious when jumping… his arms blend nicely as he jumps, raising them in the air, and then snap back to his sides when descending…

So you haven’t found a solution yet?

My guess is that you may be trying to run both actuators at the same time; perhaps you should deactivate the stopped actuator (if you’re walking and you speed up to jog, just activate the jogging animation and deactivate the walking animation). I, too, though, have had this problem before.

thanks @Joeman! helped work out the exact logical operators i needed.

i just realised i also have the same problem as OP, going from run to walk, and i believe i understand why now…

@morphinapg, what we both failed to notice, is that if the condition never ends, then it will never blend back to the other state.
What i mean is, my idle anim was ‘always’ and so it never stopped doing the idle anim, so it would snap back to the idle anim when any key was released.

Likewise, i presume your jog / walk keys is something like ‘w’ for walk and ‘shift+w’ for jog.
In this case, adding a ‘nor’ and attaching to the ‘shift’ sensor, and attaching that nor to the walk anim actuator, should resolve both our problems!
(it worked for mine anyways!)

Post a screenshot of your logic bricks if this doesnt make sense, and i’ll try to do some drawings to make it clearer :slight_smile:

Actually my game is quite advanced so I can’t really show the logic bricks here. To break it down in simple terms I’ll say this: In python, I determine my object’s overall speed based on the Pythagorean theorem (sqrt(vx^2+vy^2)) and save that value to a property. Then, in my logic bricks, I do the following:

Property sensor, =0: Idle Animation

Property sensor, 0.001 to 3.0356: Walk Animation

Property sensor, 3.0357 to 32.3808 (represents maximum speed): Jog Animation

I’m also planning on adding a running animation later which will run from 12.1428 to max speed.

When one animation starts, the others stop. There shouldn’t be a conflict. I thought that might be a problem but I already made sure everything wasn’t conflicting.

btw, there’s a reason for those strange numbers, but I won’t take the time to explain them here lol.

My guess is that you’re not deactivating the running actuator when you’re walking (and vice-versa). Are you deactivating the jog actuator when property sensor reads < 3.0357, for example?

I’m not sure if this fits into your situation.

I noticed a bug with 2.49 a while ago. The blending does not work if you use the one action actuator to play another action (by changing the action value). It was no problem in the version before.

The solution is quite simple. Use two action actuators alternating activated.
(a) = activated (d) = deactivated

Actuator 1 - Actuator 2
idle (a) - empty (d)

start walking
idle (d) - walking (a)

start running
running (a) - walking (d)

The WIP Bit-of-Magic contains a Demo where you can look for this method.

As far as I noticed blending in the BGE means:
Blending from the current Pose to the Pose of the active action.

Yes, each of those property sensors are connected to an AND controller, and should deactivate the action actuator they are connected to when the property sensors return false, correct?

fixed a bug that needed to