[Maya API] Updating/Rebuilding a node attribute based on a file input

Hi guys,

i’m currently building a Maya node plugin to integrate OpenColorIO into Maya. Therefore i have to read in a YAML filepath on the node to a file that contains options, and based
on these options i would like to update an enum attribute with certain parameters.
For example:
YAML options: Small, Tiny, Heavy <- Enum: “Small” 0, “Tiny” 1, “Heavy” 2 —> Update YAML file
YAML: Big, Large <- Enum: “Big” 0, “Large” 1
I searched the API documentation on Attr. nodes, but i could find any relevant update/setValues methods. (There are addField methods, but they are quite useless without remove counterparts in my case…)
Does anybody here by chance have any idea?

Thanks,
Timm

Do you want an enum attribute there? An enum is supposed to be convertible to and from a numeric value; you’ll have a situation where changes to the yaml file can change the meaning of your existing data should you reassign a number to something else.

Maybe you just want an optionMenu with menuItems instead? You’d probably want to do that in a custom aeTemplate script

Yeah, i thought about an enum. The idea is that changes to the enum directly influence an output by an attributeAffects connection. The node is meant to dynamically react within the graph.
Never worked with AETemplates though. I thought they are just for formatting your attributes, so i would have to go one step deeper and update/rebuild the attribute.
But i will look into that optionMenu idea…

AETemplates are just for formatting - but I think in this case that’s what you want, yes? You’re propagating a number through the attribute system but you want a human readable wrapper on the outside. I’d just use a numeric attribute and then provide the ‘visualization’ in the template.

The main issue is how much you expect the name < > number relationship to change. If it’s fairly stable (and you can promise yourself that you’ll only add on to the end of the numbers, it’s fine to just use the enum attributes). If it is in flux for whatever reason, stick with numeric attributes in the node and use a template (or just a tool window) to make the display human readable.

In the end, enums are just numeric attributes that have display strings attached to a limited set of predefined values. So you can always read in your yaml file, parse out the numbers, and set them as numbers; in that case the enums can be useful as a way of validating inputs or a hindrance because you need to change the enum range if new numbers show up. Enums are good for closed-form problems, not open ended ones.

Yeah, i’m back to using an enum and i am actually using a dynamicaly generated enum variable created in the postConstructor of the plugin.
This enum is than made to affect the output attr. via an overridden setDependentsDirty() method. Each time i update the enum, i actually remove the attribute
with aMDGModifier and re-add it. That actually works fine, and in the channelbox and via the Attributes->Edit Attribute option you can actually see correct values.
Whats bothering me, is that i cannot get the Attribute Editor to update as well. It always remains the same initial values for the enum attr.
The whole AETemplate workflow is a true pain in the ass…a whole lot of wrapping Python into MEL…that was a seriously shitty day, still not working :-/

My fault for not adding the standard “by the way - AETemplates SUCK” disclaimer, sorry. It is a truly crummy system for something so common.

Just in case anybody will come across a situation where he wants to make (dynamic) Attributes refresh in the AE from within a node plugins compute, i’ll post my solution :wink:

Situation:
Within the compute method of a DG node, i was reading some xml files. Based on the contents of these files i (eventually) had to rebuild (dynamic) attributes on the node.
Those would then be used further in the computation.

Solution:
After deletion of the old attribute, and recreation of the new i call a commandOnIdle() with the “setLocalView” MEL script set to empty.
This is in fact the only solution i found that actually works. There is a plethora of MEL cmds, which are suspecious like “refreshAE”, “updateAE” etc… none
of them worked for me. The downside is that “setLocalView” only works from 2013 on, since it uses the relatively new “view” feature i guess.

At last, here the code that worked for me:

//update AE
MGlobal::executeCommandOnIdle(MString("setLocalView \"\" \"\" 1;"));

Edit: If it’s not executed on idle it will crash…was the case for me.