Handle 'XPresso' Visual Indicator

Helper

On 13/08/2017 at 14:08, xxxxxxxx wrote:

Hi folks,

I'm pretty new to the whole Python (and C4D) programming in general, so this might be an obvious thing... maybe not.

I'm currently dynamically set various attributes of an object's tags via a "Python" node in XPresso, something like this (as a very simplified example) :

tag = MyObject.GetTag(c4d.Ttargetexpression)
tag[c4d.TARGETEXPRESSIONTAG_LINK] = MyNewTarget

Now in C4D's UI there's no indication in the tag's attribute panel that the value gets updated automatically. This is often rather confusing. Is there a way to enable the 'This Value is Controlled by XPresso' visual indicator for the respective value via the Python node's code?

XPresso Indicator

(left: how it is now, right: how I would like to have it)

We're still with R16 here (if it matters.) Thanks in advance for any kind of information, help, or tips.

Helper

On 14/08/2017 at 09:27, xxxxxxxx wrote:

Hi,

welcome to the Plugin Café forums

Unfortunately this is not possible, at least not in the way you want to do it. And I also think, you are actually misusing the Python Scripting node in Xpresso. You shouldn't change the scene directly with your Python code. Instead you should only process input parameters of the node and produce resulting output parameters. And if you do it in this way (connecting result outputs of the Python node to actual parameters of a tag node for example), you will automatically get the "driven by Xpresso" overlay for free.

Helper

On 20/08/2017 at 01:11, xxxxxxxx wrote:

Thanks for the quick reply.

Originally posted by xxxxxxxx

Hi,
welcome to the Plugin Café forums

Thanks!

Unfortunately this is not possible, at least not in the way you want to do it. And I also think, you are actually misusing the Python Scripting node in Xpresso. You shouldn't change the scene directly with your Python code. Instead you should only process input parameters of the node and produce resulting output parameters.

What would/ could be negative side effects from directly manipulating the scene with such "hack"? My Python node works like a charm, didn't notice any problems (at least with R16... maybe it will break with newer releases?).

And if you do it in this way (connecting result outputs of the Python node to actual parameters of a tag node for example), you will automatically get the "driven by Xpresso" overlay for free.

Sadly in this case it wouldn't help with that, I think.

Basically I try to update parameters of tags in a relative XPresso setup. Making object nodes/ references in XPresso relative is somewhat easy, but for the tags it seems to be a real headache.

When I just feed an object to a "Tag" node it somehow doesn't update the tag reference properly (I have to reconnect the Tag node with the tag dummy reference to make things update, maybe a shortcoming in R16?). A dummy hierarchy node between the object reference and the "Tag" node seems to workaround this. The next headache is that the targeted tag reference easily can mess up the wrong object, because it acts on its original object rather then not reacting at all when its used "Object" input port is feed with an invalid/empty link (I workaround this by adding dummy Nulls to the scene with dummy tags for the reference nodes, so when the Null object gets messed up it doesn't matter). This can be really confusing. And no "XPresso visual indicator" on the used attributes either. Even just describing this kind of setup is hard, I'll better add an example screenshot:

So compared to the Python hack I need 3 times more nodes per each tag that needs updating, it's more confusing/ bug-phrone and there's no advantage in regards to the missing visual indicators. Tongue

Helper

On 21/08/2017 at 10:34, xxxxxxxx wrote:

Hi

What would/ could be negative side effects from directly manipulating the scene with such "hack"? My Python node works like a charm, didn't notice any problems (at least with R16... maybe it will break with newer releases?).

In general the Xpresso network gets executed like every other tag in Execute(), so during scene evaluation. Here the same rules apply as mentioned under Threading Information. So under all circumstances it is forbidden to change the hierarchy of the scene, otherwise a crash will be the most likely result. While you can change parameters of entities (objects, tags, materials,...) it may not always be wise to do so (and again it is recommended to apply to the same rules and just change the parent object of a tag and tags on this object). For example running into priority issues could be one possible outcome, updating problems as well. The object node is specifically designed to do such changes, taking care of everything needed in background.

Now for your Xpresso setup, I'm not quite sure what you did there (especially not knowing some parameters).
Instead I setup a scene, which may do what you want to achieve, maybe not.
See here:
![]([URL-REMOVED]

And here's the scene file[URL-REMOVED]. Press play and drag different splines into the User Data of the Parent Null object.

There is one culprit though. As I said in my previous post, you get the "driven by Xpresso" overlay for free. Unfortunately this does not work with iterators. So only the first of the Align To Spline tags gets the overlay. I know no workaround (except setting it up for each tag separately), sorry.

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

Helper

On 24/10/2017 at 15:09, xxxxxxxx wrote:

Hi Andreas,

thanks for the reply and example.
(for some reason I didn't get any notification e-mail, so sorry for my late reply )

I did not want to loop over a set of children (like in your example), just look up a single tag from a single object (but the respective object node is in relative state, so not just dragged into the XPresso window, but also configured to look up its position relative to some other object in the hierarchy) and set some attribute(s) to it (getting it from some object higher up in the hierarchy, aka "parent", f.ex.). For some reason that doesn't work directly, but I have to insert this dummy "Hierarchy" node as workaround to make it work, even if I do not want/need to loop over some children)

Somewhat hard to explain, maybe I'll make a video someday. Perhaps it's just the too old version of C4D here.