[3dsmax] Edit/Editable Poly tool defaults

I was looking into ways of setting the default values of tools like Extrude, Weld, Chamfer. From what I could find there doesn’t seem to be an easy way to do it. I came up with this but I’m not sure if there is a better way to do it. Its based on what Paul Neale does with his Auto Select Modifiers script (http://paulneale.com/scripts/StackTools/)

This is the first time I have messed with callbacks so I’m not sure what the repercussions are.

					
fn callSelChange=
(
	
	if(classof (modPanel.getCurrentObject()) == Editable_Poly) then
		(
			o = selection	
			----------------------------	
				-- Preferences
			----------------------------
				
				--Vertex
				-- o.weldThreshold = 100
				
				--Polygon
				o.extrusionType = 1
				o.faceExtrudeHeight = 0
				o.bevelHeight = 0
				o.bevelOutline = 0
				o.bevelType = 1
				o.outlineAmount = 0
			----------------------------
		)
		else()
		
		if(classof (modPanel.getCurrentObject()) == Edit_Poly) then
			(
			o = modPanel.getCurrentObject()
			----------------------------
			--Vertex
			-- o.weldThreshold = 100
			
			--Polygon
			o.extrudeFaceType = 1
			o.extrudeFaceHeight = 0
			o.bevelHeight = 0
			o.bevelOutline = 0
			o.bevelType = 1
			o.outlineAmount = 0
		----------------------------
			)
			else()
)


callbacks.removeScripts id:#Select_EP
callbacks.addScript #ModPanelSubObjectLevelChanged ("callSelChange()") id:#Select_EP
				

hey nyx702,
This looks good. My biggest caution with callbacks is just to be very careful how you initially create them and as soon as they are no longer relevant make sure to kill them. Also… which it looks like you are doing… making sure to use the callback that is the most precise to your needs. Nothing is worse than having a callback that is constantly checking for a condition that comes up very rarely. Also this callback is nice and simple which is good. Its always good to have checks in place to exit the callback as soon as possible. Much like you are doing, its a good idea to have early and specific “if” statements to exit. Overall, this is simple enough I don’t think you have too much to worry about.

Oh one other note: Any time you can rely on a global variable instead of calling a function in a callback to get data is a good idea… especially in an early if statement. Dont think there is really anything here that fits that description but its good to think about.

Thanks for your feedback/tips. I really appreciate it. I’m kinda learning the quarks of Maxscript as I go.

One other question I had is…
Right now the function is called every time you switch subObject modes. I only need this to run once per object in reality. I can’t think of a way to check if its already ran on the selected object or only run on new editable poly objects. Maybe it doesn’t matter?

[QUOTE=nyx702;30417]Thanks for your feedback/tips. I really appreciate it. I’m kinda learning the quarks of Maxscript as I go.

One other question I had is…
Right now the function is called every time you switch subObject modes. I only need this to run once per object in reality. I can’t think of a way to check if its already ran on the selected object or only run on new editable poly objects. Maybe it doesn’t matter?[/QUOTE]

Probably with how simple your callback is it wont really matter but if you wanted you could make it get called a little less. This can be kind of messy in max but with its pretty limited callbacks its sometimes necessary. You can always make callbacks that start other callbacks. And a callback can always delete itself after running once. In this case there are a couple of more basic callbacks you could use to initialize this callback. I believe there is one that get called every time the modifier panel is invoked? I don’t have max in front of me so its hard to say which one you should use, but I would go through the list and see if there is one that would get called only when either a modifier is applied or an object is converted to editable poly. If you find one that seams suitable just set it so that it creates your current callback and make your current callback delete itself after running once. This is where its easy to run into situation where you arent correctly deleting a callback and they can start to stack up so you have to be very careful. You also need to put in a check to delete the sub callback every time the main callback gets first triggered… to prevent stacking. When testing its a good idea to print out something when a callback gets triggered as many of the callbacks in max trigger more often they they seam like they would… sometime multiple times for one event.