ALL PROPERTIES used by the Driver MUST BE SPECIFIED AS VARIABLES
OK, but:
it was not the case in 2.49
when i set up a var just as shown in post#4, it really isn’t set properly, is it ? And yet it works…
@test-dr: of course i did try to understand !
I am not sure about what you try to say in this post.
I am fully incompetent with the Game Engine.
If you did hope blender will take away this task, you are wrong.
Why ? That’s my whole point: 2.49 did it very well ! I could have my 48 drivers pointing to an external function defined in a pydrivers.py text-block and it worked, without having to declare loads of variables for each driver
The drivers are not thought to handle dozens or hundreds objects/properties!
Very well, but how do i do then ? I mean, seriously, i turn to pydrivers because that seems logical to me, but i really don’t know another way…
If you can program, i think you wont ask this question? (Thats, because i think for real programming one would look at things/problems from a different view)
Good point, that may well be something important: i know little about programming. Some scripts, a little javascript and some PHP that’s all. Your ant-example baffles me, and i don’t know where to start to understand what you did…
If there was some knid of way to let a script define some objects behaviour interactiveley, without drivers, how ?
I have tried the wiki, but 2.5 isn’t documented enough yet…
@test-dr:
So basically, what you say is :
if you have to setup 48 nearly identical drivers, than do it with python because the UI isn’t meant to deal with drivers this way.
All that is very well, and i can live with that (thankfully!). But i still find that system counter intuitive, odd.
If it were me, I’d have drivers available as datablocks, and you link a property of your object to this datablock (just like you do with images to image datablocks, to texture datablcks, etc…)
So let’s say “cube” has its location[0] set by a driver, you chose the driver-datablock of your choice in a drop-menu (like you do with mesh-datablocks for instance). This way 48 objects could share the same datablock
Within the datablock you specify the type of the driver (scripted expression, another objects-property, whatever) and you let scripted expressions use a any .py file registered in the .blend as a source of usable fonctions… without having to declare these “vars”.
Anyway, it seems i am trying to use drivers too much…
Nearly no one will try to build a big building with the smallest lego-bricks - Everyone will try to use bigger ones to build the structure and only will use small ones to make the details.
when i set up a var just as shown in post#4, it really isn’t set properly, is it ? And yet it works…
The key word is dependency. If you set up a variable, yes just one variable… using the scene object (current frame is handy) then you can manipulate all the objects in the scene with your driver function, and it will update.
then you can manipulate all the objects in the scene with your driver function, and it will update.
I have been down the road with this quite a bit. The statement is true up to the point. If your code in a driver alters bpy.data in a way that forces the internal dependency graph to update (like adding or removing a constraint) you can have crashes when you try to render (NOTE: It will work fine in the UI so test against rendering an animation). A better solution, if you are looking to manage a bunch of objects under a single code update, is to run a Modal Timer (see Template under Scripts window) and detect the frame change when the timer fires. It seems a bit more stable and offers a Context that your code can operate upon.
