Vague "driver has invalid target" console error.
Closed, ResolvedPublic


When a driver has an invalid target (i.e. one of its variables points to something that doesn't exist) Blender emits a "Error: driver has an invalid target to use" message in the console.

Unfortunately, this message does not contain enough information to track down the offending driver in e.g. rigs with hundreds of drivers. The object and RNA path of the driven property should be included in the error message.

A file that produces the vague error is attached. In this example, the error message should additionally say that the issue is in the driver that's on Armature->Bone->location.x



This issue is not exactly the most straightforward to address, as the place where the error is raised is several layers down with no knowledge of the very info we need/want to report.

While I could try to improve these error messages a bit in some way (keyingsets + anim channel filtering also need some tweaks), would it be helpful to have a filtering mode in the drivers editor which just displays "broken" drivers? This could help make reduce the dependency on being able to view the console for errors here :)

Yes! That would be awesome, Joshua! That would also be a great verification tool ("yay, none of my drivers are broken!")

What is the status of this?

I also think it's interesting to improve errors in general... if the code that throws up the error has no knowledge about what the error is, it better gets handled more proper internally.

The filtering mode is now in place (r. 51246), which kindof eliminates the need to check on the console prints.

However, when checking this, I found that it would still benefit a bit from actually highlighting in the UI where the errors were. That's perhaps more todo though.

You mean as todo, to make buttons show 'red alert' theme color? That shouldn't be too hard?

Ok, red alerts tagging is now in SVN. I guess this report can now be closed :)

There are meaningful driver errors that don't show up in the filter yet. Attached is a simple blend file ("broken_drivers.blend") demonstrating this. Note that only the Z Location driver shows up in the filter, even though the X and Y Location drivers are also broken.

Also, although the Rotation X driver is technically functioning since the broken driver variable isn't used, it would still be nice for it to show up in the error filter for clean-up purposes.

The idea of the feature is great! It just needs a little bit more love. :-)

Ok, r.55070 fixes the problems with these "harmless errors" not showing up. It seems the pydrivers eval code clears the top-level error flag, which meant that the filter heuristic wouldn't see any errors.

Joshua Leung (aligorith) closed this task as "Resolved".Mar 6 2013, 3:00 AM