How to stop Action Constraint giving different results when code is run in text editor vs python console?

I am currently developing a script that I hope will streamline the approach of adding keyframes to existing actions used by action constraints.

I am doing this by allowing the user to move an object to a new position, run an operator which will find the action attached to the action constraint for the selected object, load said action onto the object, insert a new keyframe into the action, before removing the action again.

The problem is that the action constraint seems to be adding any movement the user has made to the object and adding the action on top, creating an offset effect.

The annoying thing is that this code does work when entered line by line via the python console, but when run as a whole from the text editor I get the offset problem shown below (after having moved the object and controller 1 unit on the x axis and then running the script):

The Wiki explains that this is expected:

When the linked action affects some location properties, the owner’s existing location is added to the result of evaluating this constraint....

My existing (and simplified) code is below, hopefully the comments explain the steps, for test purposes it is presumed that the original x location is 0 and that the first keyframe is frame 1):

import bpy;
currentFrame = bpy.context.scene.frame_current;
object = bpy.data.objects['Cube'];
constraint = object.constraints[0];

currentLocation = object.location.copy();             #Store current position
object.location[0] = 0;                               #Undo movement
object.animation_data.action = constraint.action;     #Assign action
object.location = currentLocation;                    #Move object
object.keyframe_insert(data_path="location", frame=currentFrame, index=0) #Insert keyframe
object.animation_data.action = None;                  #Remove Action


So, how do I avoid the offsetting issue when running the script from the text editor (which will later be an operator)?

I have included a blend file here, it is already set up with one keyframe in the action on frame 1. Setting a second keyframe on frame 10 by running the code line by line in the python console will show the correct result, running the script from the text editor will not.

• For debugging efforts and clarity, I've gone through the procedures outlined above and my observation is that the effect of running it from the text editor is that the origin location (and by that I mean the location of the object in the first keyframe, the one that already exists at execution time) is offset on the x axis by the x displacement of the intended position. Interestingly, only the x axis seems to be affected. The y and z distances are correct as far as I understand the intended purpose. Perhaps this will help track down the problem. – DaveLeack Jan 22 '14 at 16:11
• @DaveLeack Thanks for looking, when I removed the 'index' property from the keyframe_insert command so that all 3 axis would be keyframed they did also seem to exhibit the same problem. – Ray Mairlot Jan 22 '14 at 16:48
• Rats. At least that indicates the problem is functionally within either the specification of the inputs to the keyframe insert command or the command itself. – DaveLeack Jan 22 '14 at 16:52
• You shouldn't use bpy.context.scene.frame_current = NUMBER, but bpy.context.scene.frame_set(NUMBER) – CoDEmanX Jan 22 '14 at 21:45
• @CoDEmanX That did indeed work, if you submitted this as an answer (preferably with the reasoning behind why I shouldn't use frame_current) that would be great. Thanks. – Ray Mairlot Jan 24 '14 at 18:05

bpy.context.scene.frame_current = NUMBER

By the way: although Python supports ; as punctuator, it is no good style.