[Closed] Scripted material change when objects touch

The script is getting there. So far you can pick a source object, it’s proxy and create a user defined 2d array on the x and y axis. I also have the material and volselect modifiers being applied to the appropriate objects.

Problem I am having at the moment is I can’t seem to add a foat_script controller to the material modifier on the copies of the source object. The modifier is there but I must be getting the syntax wrong for adding the scripted controller.

Here’s kinda what I was trying

$yourObject.material.materalID.controller = float_script()

is that totally off? I can’t seem to find any clear help in the MaxScript Reference on adding controllers beyond your basic position or what have you.

It’s because you are trying to assign the class float_script to the controller, not an instance of the class… I think…

So

  $yourObject.material.materalID.controller = (float_script())

or my prefered way

  fs = float_script()
  $yourObject.material.materalID.controller = fs
  fs.script = "etc"
 

-Johan

woo… this is where bells and whistles should go off

  I've seen this done by scripters before, and I wish the powers that be would be more vocal in discouraging it, but here we go...
  
  [i]Do not access modifiers based on their name by referencing them as a property of the node.[/i]  Your post is a good example of why you shouldn't.
  
  If you have a node with a Bend modifier on top, named "Bend" (you can change the name by right-clicking on the modifier in the stack), you -can- access it as follows:

<node>.bend

  However, imagine what happens if A. you rename it to "myBend".  That code will fail.
  
  Imagine what happens if B. you add another modifier named "Bend".  That code will simply return the first modifier named "Bend" that it finds from the top of the stack down.
  
  Now imagine what happens if C. the modifier's name conflicts with an existing node property. It will use the node's property. That's what you're running into.
  
  This code...

<node>.material

  ...does not refer to the Material modifier on the node, but rather refers to the node's actual material (i.e. a Standard material, Multi/Sub, etc.).
  
  If you do have unique modifier names, then using...

<node>.modifiers["<name>"] -- e.g. <node>.modifiers["material"]

  ...will at least prevent situation C.  It will do nothing for situations A and B, however.

Edit: Bugger keeps changing my “’s into “’s, even though it’s fine in the preview. The above is supposed to read: <node>.modifiers[”<name>”] – e.g. <node>.modifiers[“material”]

  The only way to uniquely identify a modifier is to make sure it has a unique identifier, and then 'searching' for that modifier in the node's stack.  I'll leave that as an excercise :)

I do agree with Zeboxx2, but I do think it depends on who is going to use your tools… If I am the only one using them, I definetly take shortcuts like these, and also skip class testing or whatever I can and will speed up writing the script. If its for general use for your artists or even the whole world, thourough testing is definitly advised.

But I think a distinction can be made for personal (TD only like) use or general use.

-Johan

oh absolutely – but if you do take shortcuts, eventually you’ll hit a problem like this, even if it -is- only for internal use

More importantly, if you don’t -know- that a particular method is a shortcut with caveats, then you’ll be stuck wondering why it’s not working when it has always worked in the past and on similar-but-different tests.

Yeah, and that’s when you whip out the manual, and learn something new

-johan

Thanks for the help. Here’s how I’m doing it now and it seems to work fine.

fs = float_script()
refy.modifiers[“MaterialMod”].materialID.controller = fs
fs.script = “try (
case (volume.selectedFaces.count) of (
0: 1
(volume.numFaces): 3
default: 2
)
)
catch ( 4 )”