In other words, I have a global repository for scripts and other assets (hence the "Assets" folder) that all projects share, and then I have subfolders for each individual project.

Now, when I write project-specific scripts, which live in the project subfolders (Project A, Project B, Project C, etc.) I'd like to include the global scripts I've written so each project can leverage them from a single source.

So, I start my scripts with something like:

include "..\Assets\Code\myscript.ms"

This has been working, for the most part. However, I'm finding sometimes that, perhaps after re-opening a file I was working on in a previous session, despite the fact that NOTHING has changed or been moved, maxScript suddenly can't find the file. So, after a lot of trial and error, I might add another "..\", so I now have:

include "..\..\Assets\Code\myscript.ms"

Suddenly, this will work! Wtf? So, I'll just assume that perhaps I did in fact move something (even though I know I didn't), and get back to work. Well, before long I find myself in the same boat. Again, Max can't open the includes. So I'll remove the newly added "..\" and ONCE AGAIN, max can find the files. In other words, I've set and changed the include path THREE times, and each time it worked temporarily, despite the files and folders themselves NEVER moving.

I've read the reference and searched all I can, but I can't find any real info on why this behavior is so erratic and unpredictable. Can someone please elucidate what exactly 3ds max wants from me? All I want is to keep my global scripts in one place, my project-specific scripts in another place, and include them using the proper paths. This has worked in every other programming language/compiler/dev environment/IDE I've ever used, but in max, suddenly it's bizzaro world.

Any help would be GREATLY appreciated. Thanks so much.

Gravey

06-04-2008, 10:21 AM

i have never used or even heard of "..\" before but i did a quick test and it seems to be a reference to the directory 1 level up from the last directory that you opened a file from (eg. a max file) using the open dialog.

i strongly suggest explicitly declairing the path to your assest like "<DriveLetter>:\Projects\Assets\Code\myscript.ms" etc rather than using "..\" especially if they are not likely to be moved.

LoneRobot

06-04-2008, 10:58 AM

a single backslash is used as an escape character in MXS - from the help -

File Path Name Strings

File path name strings use the backslash character to separate a parent directory from its sub-directory. The backslash is used as an escape character, therefore file path names specified in a string should use the escape character sequence for a single "\" character, i.e., "\\".

For strings that are used as file names or paths, the "/" character can be used instead of the "\\". MAXScript internally interprets the "/" character as a "\" character when used in a file path name string.

Keep in mind the ..\ is relative to the CURRENT directory, which can change when you perform File open operations in Max.

The current directory is accessible via
sysInfo.currentdir

Not only can you read it, you can also SET it via that variable! So you might want to try setting the current dir. to whatever the root should be before using relative path names, for example

sysInfo.currentDir = (getDir #maxroot)

amv256

06-04-2008, 03:31 PM

A few things:

1) The scripts won't be moved in a relative sense, but I do sometimes switch between my computer at home and my computer at work. The relative paths are the same, but the absolute paths are not. In other words, I might be "C:\X\Y\Z\Projects\" at home, and "G:\U\V\W\Projects\" at work. So as long as I'm using relative paths in include, everything should be portable from one machine to the next. That's why I'm not actually specifiying a drive letter and so on.

2) Bobo-- I assumed the path for an include script were relative to the location of the script itself, not the currently open file. Shouldn't this be the case? Otherwise relative directories will be constantly changing as files are opened and closed.

Thanks guys.

ZeBoxx2

06-04-2008, 05:06 PM

relative paths are indeed relative to the current working directory; which is not that of the script being evaluated per se.

You could hack it to be so, of course - using getSourceFileName, getFilenamePath and sysInfo.currentDir = ....

But, as the lack of actual code up above might indicate, that's terribly hacky - if a function within such a script file gets executed at a later point in time, currentDir may not be what the script expects it to be.

So, instead, you'll probably want to hardcode your base path and reference that instead (in max9+ish you can define your own symbolic path, say, $myScripts\\etc. but that feels pretty iffy). In the first script you execute you -can- then assign "getFilenamePath (getSourceFilename())" to that variable, and work with that base path from thereon in the other scripts.

CGTalk Moderation

06-04-2008, 05:06 PM

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.

Follow Us On:

The CGSociety

The CGSociety is the most respected and accessible global organization for creative digital artists. The CGS supports artists at every level by offering a range of services to connect, inform, educate and promote digital artists worldwide. More about us on TheArtSociety.com