NLA Editor/Actions get funky

I seem to have a large problem with my actions getting all funky whenever my characters are facing in new directions.

For example, I defined an action for my character to reach upwards. However, when I defined this action, I defined it as if my character would be facing the (-)Y axis (facing the default camera when Blender starts). But now My character has turned right, and run down a path I made for it and is facing the (-)X axis.

However, when I add the “reach” as a strip and continue to animate, odd things happen. his orientation faces a strange unexpected 45degree angle and everything is not synced up right. I am assuredly in Strip mode in the NLA editor. In fact, before I click on the swimming man in the NLA, everything looks fine, it’s when I click over to strip mode everything gets all funky.

My only solution to this has been to bake the action before adding it as a strip. The downside to this is that I might want to go back and work on it later (which makes it difficult when its baked) and also, it takes up tons of memory and increases the .blend file size tremendously.

Does anyone have a workaround for this? It’s not the first time this sort of thing has driver me crazy, and it’s not been the easiest thing to research.


Is this NLA / path / reach problem when you’re using the stride-path / Object parenting method?

Blender 2.42a ?

If so, try using the new NLA walk / deform features in 2.43rc1 as described in this thread :


Indeed, I am using stride. Sheesh, and I had thought that learning stride a few months ago was going to be worth it! And here a software improvement comes along and blows that away. :slight_smile: However, is this only for the cvs build? I am just a little reluctant to jumping over to cvs, especially at the moment while i’m in the middle of a project.


However, is this only for the cvs build? I am just a little reluctant to jumping over to cvs, especially at the moment while i’m in the middle of a project.

It will be in 2.43. And the functionality rocks. But if you’re in the middle of a project you should be cautious. Keep a copy of 2.42 installed, backup your work, test things out before switching over completely. But also, 2.43 isn’t a total revolution. It shouldn’t be a big problem to switch over.

It’s in 2.43rc1 which is kind of a “stable CVS” I suppose you could call it. It’s the pre-release of 2.43, which apprently will be released in a matter of weeks AFAIK.

On the other hand, I’ve been using CVS exclusively for about a year, and primarily for animation, and have found CVS to be as stable or moreso than the released versions.

While I suppose there are sometimes “experimental” features added to CVS that can and do crash, there are also a lot of bug fixes made, usually at least a couple or more every day. Sometimes those bugs are related to the new experimental features, but often bug fixes are made to bugs that are in the current released version. Many times the bug fixes are made within days of the bug being reported.

So my view is that CVS is the most current version of Blender available.

I use JMS’ build found here.

2.43Rc1 builds are here :

And while crashes can sometimes happen unexpectedly, if you test a CVS build, running through the main features you are planning to use, with a test file, you can be fairly confident they are going to work “for real”.

My feeling is that the more people that use CVS or at least test it, the more stable it becomes.


as stable or moreso than the released versions.

Or moreso? That’s not good.

But depending on the project, there are other reasons to be careful switching over. For example, if you plan to use a renderfarm, make sure that you’re not outpacing them in your upgrades, or you won’t be able to render your work. Stuff like that. Just make sure that you’re sure the new version fits into your pipeline. I don’t really expect it to be a stability issue. Blender’s good that way.

Well it’s a simple fact that bug fixes are in CVS and not seen until obviously the next release. Not all bugs are “crashers” … most aren’t . . I guess I rank “feature improvements” in the same category of “stable”, although I guess technically only crash-non crash factors are what most people think of as stability. Useablilty / features is a close second IMO to

Most of the time that I’ve discovered a crash, either with CVS or released versions, the crash is easily reproducible with usually an isolated series of steps. I.e. an animation crash may happen regardless of what color / material is changed. This is a good testament to the modular structure of the program, and the generally very solid coding.

Unlike another 3d program I have used that crashed all the time when I used to use it … and sunk $$$$$ into :mad:

Even on rare crashes, I rarely lose anything, I always save often, (even with released versions), and always have multiple versions of files. I don’t have much sympathy for anyone who loses " xx hours of work, because they “forgot” to save.


Well it’s a simple fact that bug fixes are in CVS

Oh, yeah, good point. I was spacing out there…


thanks for all the input. I can’t wait for 2.43 to release, and after I’m done with this project I might attempt a peak at some of these CVS builds. Thanks again.