BUG: HScript/Python Expressions switch

   4757   4   0
User Avatar
Member
398 posts
Joined: July 2005
Offline
Hi guys,
There is an old bug or rather weird behaviour of this switch. If you write an expression using “opposite” language (I mean if switch is set to Hscript and you trying to write a Python expression and vise versa) that expression won't work even if you set then the switch to proper language.
Try to write frame() or time() in any channel (language should be set to HScript) and then change language to Python. Expression doesn't work. Same if you write $F when language is set to Python. Change language to HScript. Expression still doesn't work.
f = conserve . diffuse . advect . add

fx td @ the mill
User Avatar
Staff
4441 posts
Joined: July 2005
Offline
Are you changing the expression language for that one parameter (controlled from the RMB menu on the parameter label), or are you changing the “default expression language” controlled by the button at the top of the parm dialog? If the latter, what you are doing is changing the default language that will be set on new expressions added to parameters that don't currently have expressions. This setting doesn't change existing expressions because otherwise it would be impossible to mix python and old expressions on the same node.

Mark
User Avatar
Member
398 posts
Joined: July 2005
Offline
Arhhh. Thanks for explanation! Because this is really confusing thing I thought that button is the switch of language for the whole operator not switch of default language. Why do we have two default language switches? One in preferences and one in the operator's menu. Or probably that one in the Preferences changes default language for any project but switch from the operator's menu changes default language for current project only?
f = conserve . diffuse . advect . add

fx td @ the mill
User Avatar
Staff
4441 posts
Joined: July 2005
Offline
It's a three level hierarchy. The Parameter RMB menu changes the type og an existing expression. This is the only way (aside from scripting) to change the type of an existing expression.

The menu on the parm dialog controls the default expression type for net new expressions added to that node only. This value is saved on a per-node basis, and on an existing node, the only way (asidde from scripting) to change this default expression type is from that menu.

The menu in the Preferences dialog controls the setting of the parm dialog menu for net new nodes. Changing this value won't affect existing expressions or the default expression type on existing nodes.

Generally the Main Preferences option will be set once (though it may change on a per-project or per-hip file basis). The node level option will be set when creating a new node that is known to require the other expression type (as when using custom old expressions in a predominantly python file, for example). And then the per-parameter control has to be there to allow for each parm to have its own expression type. We also figured that having the higher level controls change existing nodes or expressions to a different type would be far more destructive than useful, which is why the higher level options act as default values for net new entities only.

Mark
User Avatar
Member
398 posts
Joined: July 2005
Offline
Thanks a lot Mark!
f = conserve . diffuse . advect . add

fx td @ the mill
  • Quick Links