Maxscript, scripted material plugins, and callbacks

Tools 3ds Max
#1

So I’ve been made aware that the scripted material plugin that I’ve done up at work is causing a startup error on some artists’ machines (I’m oddly not getting this error on my machine):

“Extends class must be same superclass as scripted plugin, not: DirectX_9_Shader”

Now, I’ve found what appears to be a solution that involves waiting for the #postSystemStartup callback to fire before filein’ing the material plugin, but I can’t for the life of me get the callback to fire.

I’ve got this in a helperFunctions script in my #userStartupScripts folder:

callbacks.addScript #filePreOpenProcess "MatEditor.Close()" id: #shaderLoadFix
callbacks.addScript #postSystemStartup ("try (fileIn ("<p4 path to max stuff>\\ruUberShader.ms\")) catch ()") id:#loadUberShader

The first callback registers without a hitch, but the #postSystemStartup one never fires (I’ve tried replacing the function call with a print statement, too, just to double check). I’m not sure if it’s an execution order issue, though that doesn’t seem likely, since the #postSystemStartup callback should be around the last to fire on startup.

Any ideas (or alternatives?)

[edit]Crap, thought I was in the Languages forum.[/edit]

#2

This should all be unnecessary.

I know some people (like those at volition) suggest you put stuff in stdplugins/stdscripts but in my strong opinion, just create a single startup script that fileIn’s everything else. Just call it from startup.ms and make sure everything is initialized in the correct order. You shouldn’t have to register anything like this on a callback.

You aren’t hitting a Max bug, you’re hitting a bug with your setup that Max isn’t helping you find at all. Don’t code a workaround.

#3

Rob is right.

Unfortunately Max loads scripts ( and plugins ) based on just how they come from the file system. Thus, on your system something might work perfectly fine, and on another user’s system nothings works as a script tries to use a function which hasn’t been declared yet (thus it’s undefined, even if it will get defined later - this is more of a MaxScript defect exposed to the way 3dsmax starts up).

Thus - DO NOT PUT SCRIPTS INTO A STANDARD LOADED PATH.

Load them explicitly in order, with fileIn just like Rob said.

Put all your scripts into certain folders, and add a single .ms file in the default locations ( stdplugs/stdscipts, plugins, scripts/startup ) depending on in which order things need to be loaded.

Thus, no more random undefined variable problems.

Due to Max being Max, you still always need to restart Max just to be sure you didn’t declare something as global during testing (so you know the stuff really works instead of just working on your machine until the next restart of Max).

The Max beast works in mysterious ways. But you can find out most of the mystery thru documentation and trial-and-error. :slight_smile:

SamiV.

#4

Ahh, ok, I see what you’re saying. That definitely explains a lot, especially the load order bit (I’d occasionally get undeclared vars despite them working just fine in the last couple Max sessions, for example).

Thanks a ton, that’s going to save me some frustration :slight_smile:

The Max beast works in mysterious ways. But you can find out most of the mystery thru documentation and trial-and-error. :slight_smile:

Haha yup, that’s been the story of my last 4 months :stuck_out_tongue: