[Closed] What development folder do you use?

mine live in separate folders depending on the project and subprojects at play. Symbolic paths needn’t be a problem per se – you could always set up a global variable that points to your project path which you can then switch to a standard installation path before deployment/distribution.
What’s far more annoying is when you get a script error, and you edit, fix, save, etc. and then next time you try – it’s all broken again; turns out you were editing max’s temp copy of a file in a .MZP or you were editing the macro definition as stored in UI\etc. or usermacros, rather than your source. No way around that one, I’m afraid – just pay close attention to the filename in the titlebar, I guess.

Is there any specific problem you’re facing?

It’s a pre-emptive strike – I’m going through all my old scripts at the mo, so I’m sure I’ll come up with some annoyances in the next day or so!

I think my main beef is with include files, and the fact you can’t use expressions.

Watch this space

I have a script_depot folder on my harddrive that holds all my scripts in subfolders, where most are subversioned. On the server I have production script folder, that’s accesable to eveyone with “foolproofed” tools/script.

I keep my macroscript in .ms format so I can always run the script again from the dev location when I changed anything… I don’t bother with macroscripts in the UI / userscripts folder (really hate that stuff too!)…

Most tools I have are not production specific, If there are some scripts that are then I create a script folder in the project folder on the server and they get placed there.

Long time I’m building searching a way to properly distribute scripts/tools/menu items, but still I haven’t found a fully satisfying way. I notice that with a new install I forget about some old tools, and they get left behind, although sometimes they could be usefull. I would really like to see that max gets some functionallity to handle (macro)scripts and menu items and updating macroscripts… without hacking cui files.

-Johan

I don’t bother with them either – it’s max that places them there. If it were up to me, it certainly wouldn’t be doing any such a thing

What sort of problems have you run into with this?

Although I’d be among the first in line to say that several things there are broken left and right, I’ve at least come to what appears to be a working solution for the most part. Specifically:

• ‘updating macroscripts’
  I’ve never really had to ‘update’ a macroscript. If you redefine a macroscript, as long as you don’t change the name around, it will overwrite the old. The only problem is when you want to get rid of one… which would be easy enough by just not evaluating it, except that max decides to make a copy of the buggers whether you like it or not.

• ‘menu items’
  The biggest hurdle I’ve run into here is localization. Even though there are internal categories and titles for all the menu bits, they’re not used in a way that you could, say, get the light context menu on any locale by a fixed accessor. So you have to code against each language. Poo.
  The other hurdle I’ve run into is that you cannot identify any menu by some form of unique ID. Oh, sure, you can ‘try to’ register a menu with an ID and if that fails it means your menu already exist. Great. So how do you get the menu with that ID? You can’t. This semi-ties into the above… because if there were a unique ID, you could get the menu regardless of localized strings.
  The way I’m working around all of this is just finding the darn things by their label – menuMan has several find options that work quite well for this. After that, once you have a menu, adding sub-menus and menuitems is quite easy.

• ‘hacking cui files’
  I’ve not had to – but I somewhat know what you’re talking about. Specifically, I cannot remove one particular menu without it essentially not being removed, but hidden. The next time it tries to build itself back up it thinks it already exists and bails. Problem is, even though it exists, it’s not shown. And thanks to the thing bailing early, never again will be shown either.
  Wrangling the CUI file -does- allow one to remove the appropriate menu, but then… well, for those who have never looked at a CUI file, go do so now… I will not compensate your mental anguish, however. Also, I said -look- at it… don’t touch it. The slightest change that max disagrees with will make max refuse to start up (of course you can delete the CUI file/etc. but if you have no backups you’ll have to customize all over again. fun?)
  So I’m staying very much far away from the CUI files, myself

What I was trying to do is have a folder structure that should reflect the menu structure in a custum menu. I could build it alright but getting rid of it was a different thing.
I had *.ms files in the directories that weren’t macroscripts, I then build in the menu script macroscripts with a filein clause to the actual scripts… But it seems hard to maintain a meaningfull relation between a ms file a macroscript and a menu entry.

I wanted to update this menu at maxstart since I would like to be able to shuffle directories around and include submenu in submenu’s etc. But I found that’s it’s not easy getting back submenu’s from a menu… since all are menu’s and not special cases. And it has been a while since I looked at it, but there where funny things going on and I ended up with lots of menu entries with the same name…after that I kind of gave up… and manually added the scripts figuring out it took me too much time alreay :shrug:

Still waiting/thinking for a fullproof way to dynamicly create menu’s based on macroscripts or filein actions… maybe dotnet and a xml file… I will again look at it one day

-Johan

I’ve found that one trick with trying to create a menu is that you have to delete it before you create it. For whatever reason, menus don’t update but just keep getting added so that you can end up with hundreds of duplicate entries, and this can really slow down Max when you just try to open the Customize UI window. So here’s a function that you can add to your startup script that will delete the menus (and all duplicates), and then you can safely add it again without making another copy.

	fn removeMenu menuName =
 	(
 		while (menuMan.findMenu menuName) != undefined do
 		(
 			menu = menuMan.findMenu menuName
 			menuMan.unRegisterMenu menu
 		)
 		menuMan.updateMenuBar()
 	)
 
 	removeMenu "Menu Name"
 

I work “currently” in the scripts folder…I’ve a folder in scripts named dev, in that I’ve a few snibbet folders named for the “class” of functions I was starting to write like. “Create Geometry”,“UIs”,“IO”,“UVW mapping” …ect.

When a script gets to a usable state it moves into our script library folder, which is foldered by functionallity. This folder structure and script filenames are consistent with the macroscript definition’s name, Catergory, and Icon set. Each script at this point has a short description and usage added to the top four lines of the code.

I’ve a publishing system, which counts the version # and adds version notes to the top of the script before copying it to two locations.
One is a common share point which gets sycn’d with user boxes each time max starts. This is the current build of the script
The second is the same structure, but each script has a folder, into which I store a version of the script and any extra notes about what changed…

If it’s a “New” script, it makes an html page to add the script to our help .chm file directory. The html has the short description from the top of the script and the icon as a .jpg. Then it’s easy to just add that page in WinCHM, add more detail on usage if needed and recompile the help file… which is also sync’d on max start… I personally really like the help file, I’d recommend it to everyone… WinCHM cost like $80 and almost anyone can make a html page to help with documentation…