Is there any hiearachy and priority order in which the scripts are read?
Is any folder overriding another?
Currently, I have managed to find these following script folders.
%localappdata%\Autodesk\3dsMax\2013 – 64bit\ENU\scripts
%localappdata%\Autodesk\3dsMax\2013 – 64bit\ENU\usermacros
»I think those folders can be defined under Configure System Paths.
%programfiles%\Autodesk\3ds Max 2013\scripts
%programfiles%\Autodesk\3ds Max 2013\scripts\Startup
%programfiles%\Autodesk\3ds Max 2013\userscripts [this one was empty other than a MAX.DIR file]
%programfiles%\Autodesk\3ds Max 2013\stdplugs\stdscripts
%programfiles%\Autodesk\3ds Max 2013\MacroScripts
» Different scripts seem to install their files to different folders, and different authors suggest different pathes for their files and I have been in cases where scripts need to be located in other places than what I thought was logical to function, which causes confusions for me.
Examples:
[ul]
[li]centre_caddies.ms script: this one alters the caddies behaviour (centers them) and therefor needs to be started each time max starts. Placed in 3ds Max 2013\scripts\Startup
[/li][li]Activate_best_shading.ms: this one alters the viewport shading settings, called manually by running the script, MAXscript>Run. Placed in [B]3ds Max 2013\scripts[/B].
[/li][li]mb_shortcuts_fn.ms: this one is part of the mb_shortcuts v1.8 pack and had to be placed in 3ds Max 2013\stdplugs\stdscripts to work. 3ds Max 2013\scripts\Startup didn’t work for me…
[/li][li]Meshtools 3 with CSPolyTools: this one puts scripts in 3ds Max 2013\stdplugs\stdscripts, and according to the mzp.run, 3ds Max 2013\MacroScripts as well.
[/li][li]AdverSoftware BatchRenderWizard: Its installer puts files in the %localappdata%…\scripts\AdverSoftware and %localappdata%…\usermacros folders.
[/li][/ul]
» My conclusion is that there isn’t always a very logical pattern for me to understand why I post here and ask.
I get the feeling that scripts that you right click and edit become copies in the %localappdata%\Autodesk\3dsMax\2013 – 64bit\ENU\usermacros folder. I previously asked regarding this and got the tip to point the usermacros folder to be inside 3dsmax-folder to avoid duplicates.
Also, I get the feeling that the idea is that custom scripts are to be placed in %localappdata%\Autodesk\3dsMax\2013 – 64bit\ENU\scripts while scripters not always follows this suggestion and instead put them in the %programfiles%\Autodesk\3ds Max 2013\scripts folder together with the original 3ds max scripts.
» I have understood that there are three extensions
.ms
.mse
.msc
I get the feeling that .ms and .msc are very similar, but that the purpose/idea is that the .msc contains scrips + code that defines category and tooltip name and such, while the .ms is pure code that is been executed only once the script itself is been called/run.
And the .mse seems to be compressed or encrypted.
I also get the impression that not every scripter is following the rule and might name their files .ms while it should be .msc and vice versa.
One of the reasons to understand all this is to try to find out a method where I could put the script files to ease a backup process. I only need to save custom scripts and do want to avoid to backup original scripts and risk overwriting them in the future.
Then, maybe I could move the scripts around, bunch them together and have them easily backuped when needed instead of spread out if they dont have to be spread out like this.
In my opinion scripts should always be installed under the user directory and any temp file it needs to create should be under the user directory as well.
Here:
%localappdata%\Autodesk\3dsMax\2013 - 64bit\ENU\scripts
And here:
%localappdata%\Autodesk\3dsMax\2013 - 64bit\ENU\scripts\startup
Most work environments don’t give the user an administrator status. This means that scripts won’t have write access to certain folders unless 3dsMax is started as an administrator. And not many people do that at work.
Writing your scripts so that they operate within the user directory is the best way to avoid this issue.
Unfortunately there are a lot of scripts out there that need to be installed or operate within the regular scripts folder under the max root folder. Installation of these scripts might fail in such work environments as well as the scripts themselves.
Finally, I don’t think it’s a good practice to put MCR files in your usermacros or macro folder.
Leave it up to 3dsMax to generate the MCR file for you. (I believe there is a more detailed post by BoBo about this.) In order to do this you just need to evaluate a MS file that contains macroScripts within itself.
Maxscripts asking for admin rights, are bad scripts in my mind.
There are ways to load a .ms before anything else, and without admin rights.
But it is better, they don’t know, otherwise…
IMO, mcr should be handled differently, but that’s another topic…
removing the header of these files, is what I do.
mxs help file: Order of evaluation of scripts
You’re right. Writing script without is the best way to keep you far from virus victim
That would mean that if I want to make a system that makes script backup easier for me, I could alter those scripts and make them work under the User Directories. What do you think about that?
But what if the script package comes with MCR files? Scripts from Scriptspot and similar.
Usually, the author instructs one to put them under Max\Scripts folder.
I have encountered such scripts. Whats ther proper way to deal with them; where should I put them so that Max automatically creates MCR (… it does create MCR’s, doesnt it?).
What is different when the file is an .MS instead of directly an .MCR? Or does it mean the script author named the file wrong, MCR while it should’ve been MS?
This is the topic – I’d love to hear your ideas.
Why would you remove the header of those files?
If you want to make a backup system why not backup all the script-related folders, the ones you listed in your first post?
I keep all my scripts in the $userscripts folder and have it synced with Dropbox or Sugarsync. If you want to backup other scripts that are “designed” to only work in “$scripts” folder you’ll have a harder time adapting them to the userscripts folder. You’ll have to do it manually. For more complex scripts that have a mzp installer you’ll have to probably edit the installer script as well.
Maybe you could change the path of the “$scripts” variable to point to the “$userscripts” folder instead, so that scripts that use a the “$scripts” variable will actually be creating or getting files from the “$userscripts” folder.
I think usually the author instruct to put MCR files to the Max\UI\macroscripts folder. Either way it’s bad practice. Macro Scripts should be defined inside a MS file and evaluated once.
3dsMax will go through the MS file and create the MCR files of the multiple macros defined within it, or just the single one. And it will put the MCR files in the $userscripts\UI\usermacros folder where they belong.
Just evalute those files once, drag and drop the file on the 3dsmax viewport if you want.
I would say yes, authors have named it wrong. I don’t see why there would be a reason to distribute MCR files. As I said above, macroscripts should be defined in a MS file and be evaluated once. Let 3dsMax create, name and place the MCR file.
I don’t know about Ruramuq, but what I usually do is create a MS file with the script itself.
And then I define a macro in another script that points to that MS file and just launches it.
This way I can change my MS file and I don’t need to re-evaluate the macroscript every time I want to change something.
I don’t think MS files are really a concern, even with non-admin rights you can really break someones PC if you wanted to through MS files.
For MS files you can atleast look into them, MSE files are a mystery, you can’t know what they are doing.
I agree with this. There is already a “macrotizer” like you call it in maxscript.
Check out “macros.new” here .
I totally agree, what I usually do is I create MZP files, that you just need to drag and drop. They will automatically put the files in the correct place and will even add a button automatically to the Main Toolbar.
I worked on a MaxScript Manager last year that deals with all these problems. It’s a bit rusty and not compatible with 3dsmax 2013 yet. Check it out here.
I haven’t had time to re-write it and improve it though. Don’t have much time these days, but I hope to get back to it one of these days. Got lots of ideas and scriptspot.com integration in the works!
@batigolnguyen,
not only viruses, they may just change something you don’t want, like the registry or some files in ‘program files’, which IMO, should stay unchanged.
@Haider of Sweden,
Removing headers, is necessary to test them. Because a .mcr installs itself in the program. 3dsmax does not ask if I want to install it, or test it*
.mcr files connects your script with the GUI and shortcuts in 3dsmax. IMO it should not be part of any script, because it’s more intimate with 3dsmax than with the script itself.
*I’m thinking that something like a macrotizer and demacrotizer would be useful.
The thing is, telling the user to install .mcr files sound complicated for them. This is something that should(ideally), be simplified.
But the best would be some kind of maxscript management system. Useful to manage your collections and also as an installer/uninstaller | mcr management. ‘All inside of 3dsmax’.
But those are things that should be tested, I haven’t yet.
Because of how 3dsmax work, anybody has different solutions, and that’s a problem(there is no standards), as you can see with the folders order or evaluation, icons, stdfolder, ini/cfg files, #maxdata folder changing every new 3dsmax version, etc…
I remember your script, but I didn’t remember it with the amount of features it really has, those are good ideas.
About the macrotize, I only found one, not really what I had in mind… but anyway, I may review or test/try, once for all, how can I simplify dealing with .mcr/ms files, thanks.
I am afraid I still dont understand this.
Can you give an example of how a file might look like before-after, which part is the header to be stripped so that Max would test it? And what exactly is the test process?
I realize it makes sense. I could just copy everything, and upon an re-install, I copy everything back and choose not to overwrite anything (probably original files). This way I should have everything restored to normal.
Reason why I need to backup the scripts is that I backup my UI settings as well. Often, the buttons are pointing to scripts and when they’re not there it all gets messy.
Any comments on that? Could I break something doing so?
That would mean an MS doesn’t necessarily have macroscripts inside them. They can contain plain code (previously I thought MS was precisely that, only plain code).
The other script you are referring to, that one was an MS as well, but with a macroscript inside it which creates the UI connection and all, right?
Love the concept. Will try it soonest possible
About what you mentioned before, to drag-drop to “install” the scripts, and authors who shouldn’t distribute MCRs.
That would mean the 3ds Max 2013\MacroScripts folder is only for original 3dsMax scripts?
I do have a couple of examples – I do not mean to point anyone out, only refer to real examples – who seem to be copying their files (through MZPs or folder structure in the ZIP file) into the 3ds Max 2013\MacroScripts folder, like:
- http://www.sergepogosyan.com/scripts/scriptspack/
- http://www.paulneale.com/scripts/resetXform/PEN_resetXform.htm
Your opinion was that the scripts – MS and not MSC’s – should’ve been installed by a run command (I guess this is what you refer to when you say evaluate) or drag-drop so that they would end up in the %localappdata% folder. Correct?
What is the consequence of not doing so, meaning copying them to the 3ds Max 2013\MacroScripts folder?
Some sort of a conclusion is that in a perfect maxscript world, I either have an MZP or the only files I need to physically copy under the Max folder are icons and mse. Everything else should be evaluated or drag-dropped into max. Is that correct?
A mcr, or either it’s installed manually, or you evaluate it, and 3dsmax will install it for you.
Manually means, you copy it to some of the folders in the ‘appdata’ or ‘program files’ folders.
If you just evaluate the mcr, and it’s not in some of those expected folders, then what 3dsmax will do, is that it will copy the script to the appdata macroscripts folder (getdir #maxdata)
In any case, it needs to be installed. But most of the time I don’t want that, I just want to see, how the script works(test it). Then the solution is to disable/remove the header of a mcr file:
-- macroScript anyWebMaxscript
-- ButtonText:"press"
-- Tooltip:"does something"
-- category:"any category"
-- internalCategory:""
-- Icon:#(7)
(
-- the rest of the script here..
)
Usually a script has a UI,(a rollout, somewhere inside the script), and because I disabled the header, this script will ‘run’, it’s main rollout will display, but it won’t install.
Otherwise I would need to create a button, or a keyword shortcut, or menu, or quad, and run it, test the script, then delete the butoon, keyword shortcut, menu or quad, then go to the folder where it was copied, and delete it. It’s just too complicated…
When people distributes scripts like this (.mcr), it’s like if he/she, expects everyone to install the script permanently, something that it’s a bit illogical without the possibility of testing it first.