Well, I'll qualify this by saying you're doing stuff I haven't had to do, so I can't really say what categorically is and is not possible, but only what (little) I do know.
The only *specific* and *universal* mapping you can get is between typeName and typeId (which you can do with a DN function set; again, not especially important because I was suggesting creating the map by spitting the output into your source file, whether it's C++ or Python, just using Python to populate it). Since there's not a way to filter an iterator using a typeId, you could look up the type niceName in the mapping and then just test typeId on each item in the iterator when needed. You at least gain *something* from getting the typeId before entering the iterator and then comparing typeId rather than a string when you need to more closely inspect a plugin node (which I would most likely do rather than exclusively examining typeId, so I can still filter at higher levels of abstraction if needed). I don't think there are really any other exceptions. The apiTypes are only special in that they can be interpreted in a way where class hierarchy is known, so that any particular object can be represented by a multitude of apiTypes. To the extent that kPluginDependNode is a child of other classes represented by apiTypes, you can know more about it, but your custom node classes must all inherit from MPxDependencyNode, right? Anything beyond that they API can't really dynamically "learn" about in order to create a new apiType. On Sat, Dec 4, 2010 at 12:27 PM, Chad Dombrova <[email protected]> wrote: > > On Dec 3, 2010, at 4:57 PM, Adam Mechtley wrote: > > > I think part of the problem here is that the "types" recognized in the > command engine (e.g. listConnections) are somewhat arbitrary. I mean those > are just sort of "nice names" for some API type, right? > > yes and no. maybe for animCurve and kAnimCurve, but these API types don't > even exist for custom nodes. and still, is there really no lookup between > these anywhere in the maya API? seems like a useful thing, but maybe it's > just me. > > > One possibility would be to write a script that just creates a node of > each type and uses the nodeType command to populate a "static" dictionary in > some module with niceName:apiType pairs, assuming you want the same types > represented by nice names in the command engine. > > well, luckily pymel has exactly this in interal.factories, but what if i > was working in c++ and didn't have pymel available. > > > In the case of custom node types (e.g., apiType = kPluginDependNode), I > think you'd just need to rely on the MTypeID to distinguish one from > another. > > would certainly be nice if the iterators could just filter on MTypeID. are > there other exceptions that i will have to test manually other than > kPluginDependNode subtypes? > > -- > http://groups.google.com/group/python_inside_maya > -- http://groups.google.com/group/python_inside_maya
