[Closed] Tips of working on a large MaxScript projects

it might be another reason that size to put something in a separate file… usage.

do you know how many times i wrote function “findItemByName”? hundreds!
and every next time i was writing this function again i said “No! not again. i sick of it”
but … did it. why?
because it needs to be a bit different from case to case.
check:
the basic:

fn getItemByName list name =
(
    n = 0
    for k=1 to list.count while n == 0 where list[k] == name do n = k
    n
)

now if you can ignore the case:

fn getItemByName list name =
(
    n = 0
    for k=1 to list.count while n == 0 where stricmp list[k] name == 0 do n = k
    n
)

but if we need to check every item is valid? what if we want to find by pattern? what if we want to find all instead of first? what if we need the item itself instead of its index?

the function that provides all these ‘ifs’ as an option – is a monster! big and heavy

And what if I say I don’t have ANY file except launcher in the max (app data) folders? So how max is able to find my scripts to load them?

see several posts above… user has to manually specify the path to your tools as one of a 3rd party paths.
i can do it automatically with an installation process but prefer to let a user do it himself. user has to know where all my tool’s components are.

never liked (and never use) the “include” and “filein” functionality in max found they cause more issues than they solve especially when there are more elegant solutions out there. Large project management has been mxs Achilles heel since year one and has never been addressed in fact a lot of the interesting additions over the years have made it worse in some ways. Saying that the end user doesn’t give a **** about nuts and bolts of how it’s put together just as long as it works and is easy to install.

Interesting discussion. I suppose I’m guilty of abusing filein then.
Once I discovered the proper use of struct based tools I began using my structs like C# class files. One file per struct, loading them with filein as needed. Just like “using” in C#.

Had no idea this was frowned upon by the more experienced.

If separation of your code into fucntional chunks and loading them via fielin is not a good idea, then what is the ’ more elegant solution’ ?

here is a question… what would you prefer if you have two options?
#1 push a button and easy install whole tool package into your max system. push another button to uninstall it
#2 copy one directory (tool package) in any place and just point to it by specifying a path, and delete this directory any time if you don’t need or like it

My solution is basically #2, although on the previous project I built an installer.

Because of windows user account permission annoyances, and the pain of also maintaining and building an installer, I developed a preference to keep my max script tools in a folder I can control completely, far away from Max’s defaults. I have “Tools” folder in our source control that our art team all utilizes. All my max scripts run therein. I have a single script an artist must run to install our custom menus which creates macroscripts which then all point to .ms files in our Tools folder. This includes a “update me” function for when the menu system itself changes. A tool change is as simple as having the artist sync to perforce, at worst also running “update me”. No max restarts needed.

For inhouse tools I use a system similar to Javascript’s ‘Require’, which lazily loads .ms files, and caches the module in a central location.

Thus, in any file I can use something like

m1 = Require(“module1”)
m2 = Require(“module2”)
m3 = Require(“module3”)

If any of these have been previously loaded, it will fetch the cached version. Otherwise, it will fileIn and cache the result.

The caching system is loaded at max startup.

I can also set a flag on the caching system to use development mode so that it never cache files.

This promotes code reuse and modular programming, and doesn’t create a large delay at startup, because libraries are only loaded when needed.

interesting…such an approach might be useful for me.
is testing for a cached module something like

 if module1 == undefined

or do you have a more explicit set of properties defined?

The following is the function I’m using, part of a larger framework struct which is loaded at startup.

The libraries are cached by name.

libraryCache = #()

fn LoadLibrary libName loadAlways:off &wasCached: path: =
(		
	if loadAlways == undefined do loadAlways = off
	local existingCache = (for c in libraryCache where matchPattern c.v1 pattern:libName collect c)[1]
	if (not loadAlways) and (existingCache != undefined) then
	(
		if (wasCached != unsupplied) do wasCached = true
		existingCache.v2
	)
	else
	(
		if (wasCached != unsupplied) do wasCached = false
		local commonPath = if path == unsupplied then (/*(my default path for library modules*/) else path
		local libPath = commonPath + "\\" + libName + ".ms"
		if doesFileExist libPath then
		(
			local newLib = filein libPath
			if existingCache == undefined then
			(
				append libraryCache (dataPair libName newLib)
			)
			else
			(
				existingCache.v2 = newLib
			)
			newLib
		)
		else
		(
			undefined
		)
	)
)

The caller can pass a byref argument (wasCached) if it’s important for them to know if the library was just loaded or if it was already cached.

This approach allows me to reuse functions across tools with little need to think about their location.
For example I might have a “SkinTools.ms” library, which returns a singleton instance of a struct. In any tool I can then access it by using

local skinTools = MyFramework.LoadLibrary "SkinTools"

If some other tool has already loaded it, this would not trigger another filein.