Set Float Or Double Attr Default Via Python Api

[quad]

Hello.
For a few reasons in our rigging pipeline, I would like to change the default value on a few user created attributes after they have been made.
Am I correct in thinking there is no way to do this in the usual scripting way? I couldn't find anything.
Since you can set these in the API, I started looking at the Python API methods. However, I've hit a roadblock. The code is below.

The problem comes with the line 'numFn.setDefault(dUtil.asDouble())'. I keep getting a RuntimeError, '(kInvalidParameter): The data is not of that type'. Which is funny, since the two print statements above it confirm that it is, in fact, a double on the particular attribute I am trying to change. Just for kicks I've tried asFloat(), asInt(), asEverythingElseICanThinkOf() and nothing seems to work so I think either:

1) My methodology is totally flawed

2) This method is broken

Thanks for your time!

CODE
import maya.OpenMaya as api

def attrSetDefault(name, value):
    attrObj = nameToNode(name)
    numFn = api.MFnNumericAttribute(attrObj)
    numData = api.MFnNumericData()
    dUtil = api.MScriptUtil()
    dUtil.createFromDouble(value)
    print "type: " , api.MFnNumericData.kDouble
    print "type of Attr" , numFn.unitType()
    numFn.setDefault(dUtil.asDouble())

def nameToNode( name ):
    '''Takes a node or attr name and returns a node or attr MObject'''
    name = str(name)
    if "." in name:
        node, attr = name.split(".")
        depNodeFn = api.MFnDependencyNode(nameToNode(node))
        return depNodeFn.attribute(attr)
    else:
        selectionList = api.MSelectionList()
        selectionList.add( name )
        node = api.MObject()
        selectionList.getDependNode( 0, node )
        return node

[joojaa]

QUOTE
Am I correct in thinking there is no way to do this in the usual scripting way?

No.

[visualfx]

You can use the addAttr command to reset your default values, just use the edit flag.

CODE
import maya.cmds as mc
mc.addAttr("yourNode.yourAttr",edit=True,defaultValue=newValue)

QUOTE(Joojaa @ 11/21/08, 11:40 PM) [snapback]295680[/snapback]
No.

why even reply?

[quad]

Cool, thanks visualfx!

[joojaa]

QUOTE(visualfx @ 11/21/08, 07:45 PM) [snapback]295694[/snapback]
why even reply?

So he knows to look elsewhere. Nothing is more problematic than ruling out something that's essentially wrong. Ad i didnt have maya at hand. I mean its not hard to find it in the manual if you look but if you quit looking you can no longer find it. (in essence you have traded your time to find for unlimitted)

And unlike mel which i know by hearth mostly python has some discrepancies so i would need to check. Having, a indication to search for the ansewer is better than nothing. Anyeway i did reserve a slot to return into this. but i got cut off by reality.

---

As for why the api code fails is whati was really after. you are using maya 2009 right. The api for python is a bit reserved to cee in cases.

[quad]

No hard feelings. I've been buried into heavy python development for a while, and it seemed like I was missing the obvious solution, which is why I posted on a board.

When you get out of MEL mode it's easy to forget that you can modify an attribute with "addAttr".

[joojaa]

QUOTE(Quad @ 12/04/08, 02:16 AM) [snapback]296301[/snapback]
When you get out of MEL mode it's easy to forget that you can modify an attribute with "addAttr".

In that case i have tip for thinking. It doesn't matter what you use python, api or mel maya has this wierd take on object orientation. Most other systems don't work thisway but rather the object itself has classes that govern it, but this methodology has a few interesting advantages in strictly typed systems leaving typecasting to minimum.

There's objects and then there's function sets for those objects. So now in scripting this manifests itself in a wierd way. Since scripting for most always only has one way of doing things, its athis: usually the command that you used to create something acts a as that objects functor.

[quad]

It makes sense if you put it that way. I didn't know the creation command acted as the function object.

Warning, getting off topic:

If maya were like every other piece of 3D software with an object model, the scripted interface would be something sort of like:

myAttr = someNode.addAttribute(flags)
myAttr.defaultValue = blah

I wonder if now that we have python, and projects like pymel, if it will move in this direction. It doesn't seem quite right that certain esoteric features of the Maya API manifest as nonstandard behavior in MEL. Nonstandard in the sense that XSI, Houdini, Max etc all do it similar to the other way I mentioned.

If the devs decide to move this way I wouldn't be surprised if pymel became part of the standard Maya package in the future, or if Autodesk rolled their own very similar python interface to abstract the API away even more.

[joojaa]

Well thats just because thats how maya was programmed down up (most others are way newer in this respects, especially max that got scripting into the game later then release). The thing i appreciate in maya wis its DOWN UP designed the same way, houdini comes close tho.

Mel is a functional not object oriented so no object orientation there. And in api it is object oriented so yes thats basically how it works trough the api. Functional code just reflects what mel is supposed to do. I often complain that people with programming skill often misunderstand what one should do in maya.

Mayas primary mechanism is NOT to run scripts, but rather use nodes to solve their work. And nodes work just ike any other object orinented language out there. Mainly some problematic perversion happens when poeple do things outside of the nodeal structure, when in all actuality they would want to make a node (they just dont know it). To this end expressions that DO work on the object structure do work like

object.Attribute=object2.Attribute2+sin(time);

So those parts of maya that work on the actual data one should be working on WORK just like any other object oriented language. Its just that any other parts shouldn't actually do any node reading so maya functionality underlines the fact that you are doing something indirectly and that you probably shouldn't be doing so as your primary target.

In fact you never do need any accessor outside of the following getAttr, setAttr, Sets, AddAttr in scripting. Api needs a bit of the other fctions but basically 80% of MFn's are stuff thats there just to help you out not to actually provide you with functionality.

So if you feel your maya code becomes stupid at times its because your not looking at the right tool to do it. As for python, the entire notion of porting mel into python was idiotic it just stopped you form seeing the different parts as just that separate. So yes a whole separate api level different api would have needed to be made.

So yes it exactly works like that as long as you exit the scripting paradigm. Python as it is now just makes it that tiny bit harder for you to see this. I'm not going into the talk wether or not is better to d system that works like users think it should as opposed to how they get the most out of everything, it is not.

(best example of this is the html wild years that broke almost everything, the upside is that it did enlist many users but allmost rendered everything useless. We stilll pay for this)

[quad]

Ah, see I think it would be very possible to have a more 'pythonic' scripting approach AND provide just as much power to the user as MEL, if not more. But that it is so much work for Autodesk that it will probably never happen, because of those architecture design decisions made years ago. There are many advantages to Maya's architecture as you stated but it has made this problem very labor intensive for them. I feel like the current python implementation is a compromise in this regard.
So I understand why it has been done this way, but it is irritating. One of those quirks of the package. Although it handles this particular problem better, XSI has them too.

[joojaa]

QUOTE(Quad @ 12/05/08, 09:44 PM) [snapback]296509[/snapback]
Ah, see I think it would be very possible to have a more 'pythonic' scripting approach AND provide just as much power to the user as MEL, if not more.

Yes and no. Yes in the sense you can be more pythonic sure. more power maybe. More misuse. Its the sort of thing where if i make things easy i also make stupid things easy sort to thing. Easier means lot of stuff gets perverted in way that backfires progress.

But yes thats how it should have been made. But its just people at autodesk who lacked vision here it was the entire industry as whole.

All systems have quirks, either you learn to live with them or die complaining. I mean maya used to be the best designed package i had seen. Now hoewer there's a better thing out there but its not 3d. Problem being its only good as long as there's no wide scale adoption of the sytem. Once it goes mainstream it allways tends to crap up generously.*

So tehncology progresses in a steep step up and a nasty slide down for next 10 years trhen a steep step up and 10 years of sliding doewn because the average picks up. Again the best demo is html wich was well designed for searching and structure but people didnt get it so instead it got screwed up. The base was is and still is great, it just took us 10 years to get even a 5% penetration of the ground idea.

• im not saying it does not help. it does you get a whole nuber of stuff sotound. But only maybe 2% of it is of no use. So what im saying is keep your eyes on the ground idea not on what your boss asks you to do. Youll appreciate things more ad become a more valuable worker and bet more done.

A good other example of this is the new python. That beraks a lot f pythons code. but its good because it has a better idea behind it. Just t takes a lot of time to get the tail behnid good ideas.

So no i don't think it helps per see... it just helps making justifications for problems already solved to be solved again.

[joojaa]

addemdum,

how on earth do you think it gets easier by making a 1000 things

a.1
a.2
.....
a.1000

versus having

1(a)
2(a)
...
1000(a)

the object oriantation only helps whan theres a strict low nuberrof entities in mayas structure each entity has quite many inetms beneth it.

By the way every functional language is capable of duing object code but every object language is not able to do functional code effectively.

anyway neither of the approaches attack the base problem. Which is to teach people to do good code they just leverage same problem in different package. It is just as dangerous to make coding easy as it is to make the sytem hard to understand. On the other hand you make it easy to brute force the hand and other you make it hard to play the hand both are as evil solutions.