my first advice is – don’t use “include” method. if you use ‘include’ your project is organized wrong.
I use fileIn and my files are split into logical parts, containing single or a few structs or rollout definitions etc… So all of them are global things. Good to have it confirmed, that I’m doing the right things.
if you don’t want to have some ‘.ms’ file be executed but want to keep them in an auto-executable directory (like ‘startup’) just change these files extension to ‘.mss’ for example
So, I’m guessing I can “fileIn” a file with any extension and it will be executed is if it was a MXS file – is that correct?
correct.
but it’s better to not use ‘filein’ as well as ‘include’. as i understood you use filein just only because you want to a specific loading order. but max already has an order. maybe it will be better just put pieces of your tool in right places.
i’ve stopped using ‘include’ about 10 years ago.
i’m still using ‘filein’ in some situations:
call a complete tool using macroscipt (action)
call a complete tool from another tool
i never use ‘filein’ to load a part of code.
but it’s better to not use ‘filein’ as well as ‘include’. as i understood you use filein just only because you want to a specific loading order. but max already has an order. maybe it will be better just put pieces of your tool in right places.
Are you referring to order described in this article?
http://docs.autodesk.com/3DSMAX/14/ENU/MAXScript%20Help%202012/
Well, what if all my scripts sit in one folder only? Instead of having one 5000+ lines long file, I want to split it into a number of manageable pieces. And since some of the files will rely on globals that need to be declared earlier, I need to specify the order.
Just like you import modules or libraries in other languages.
i think that 5K lines is a OK number for main module. you can have and use some globals that defined outside the main module, but they have to be a common use things (structures, plugins, etc.). if you need some globals that used only by a specific tool, they have to be defined in its main module
(that’s how i do it. so it’s just my own opinion)
does ‘include’ help you to make the code shorter, clearer, easier for reading?
or using ‘include’ you want to say that including part can be a ‘common’ reusable part for many scripts?
Spliting ‘common’ scripts in separate files(libreries) makes my code cleaner and “Include” helps me to include this libraries in to the main script in true order and scope. It could be at startup or at any other execution time.
that’s exactly what i wanted to hear.
now. what does ‘include’ do? it simply merge a piece of text into code. it might not be executable, or not make sense at all without rest of code… but i’m absolutely sure that you put in include something that complete – structure definition, block of useful functions, list of variables, etc.
is it not better to load them once than load and compile with every tool that uses them?
Wait wait, I think I didn’t described my usage of include very well. I use it in the main “Launcher” script which is usally located at startup folder and wil be executed once. This launcher includes all libraries in one structure so i can use it later in my code. I don’t use “include” for every tool.
so my “framework” or “big tool” stucture is:
<the tool directory defined and named by a user>
|
- Bin
- Plugins
- Scripts
- UI
|- Macros
- Icons
- Userstartup
the tool root directory has to be manually added as a 3rd party plugins path by user.
the message text format ate some leading space characters…
ui is a subdir of root. macros, icons, and usestartup are subdirs of ui
But I didn’t get why you are against include. Do you see any problem of using include?
there is no a problem.
but…
let’s say you have two tools in your package and both of them use the same structure. would you like to define and load this structure two times, and every time you load one of these tools?
only if this structure need to be defined in a local scope. but in this case these two tools will talk with each other about different structures.
That’s why if I want to include smth more then once then I just make a global structure and call functions from it as many times as I want
that means you make a globals this way.
now i have to ask you why do not let it do the max itself?
the only a reason is just the specific order of loading you need
personally it’s clearer for me to see all properties of a sub-structure in the main structure.
if it’s a ‘local’ structure it should be in the same file as its ‘global’ structure. if it’s a common used structure it has to be a global.
what is a criteria to leave some in one file or put in a separate? only size? if so, it will be inconsistent.
It’s cool to see all codes in one file, but as my file become bigger and bigger reading the file become harder and harder. At the moment it was really hard to read 24k lines of code. So I decided to split the code to the specific categories: Common scripts, dotnet scripts, geometry scripts, wpf scripts and so on.
you did absolutely the right thing. but again… why not let max do it?
but i see your reason now. in case of a ‘launcher’ that does do only the loading of components it makes sense. you win
i can easily picture a situation that needs the specific order, and i have been in such situations. for example –
i have a low-level WinAPI library.
also i need a higher level WindowsOps library that uses for sure WinAPI but i don’t want to pack them in one file.
so it needs a loading order. but max loads scripts from the same folder in alphabetical order. and check now how i named my scripts.
i’ve seen some packages and scripts:
include "math.ms"
include "controllers.ms"
... (another ten includes)
include "fileops.ms"
where every module was 2-3 functions of 5 lines of code. they were made in advance probably