PDA

View Full Version : when write a big script...


easyfrog
04-20-2012, 03:36 AM
when write a big script... > 3000 lines . What is the good way to management code? use "include" ? "filein" ?

denisT
04-20-2012, 04:06 AM
when write a big script... > 3000 lines . What is the good way to management code? use "include" ? "filein" ?
i'm just keeping go(grow). i have tools are about 10-15K lines. but they are almost all of my old coding style.
my new way is to use structures defined in stdscripts. they are loading as plugings and are giving me the set of basis functions and data structures. so the base tools is about 3-5 K lines, all other is libraries.
i played with "include" and "filein" and don't like it. so i stay with GLOBAL structures. i see it as more natural way for max scripting ...

muhammadfredo
04-20-2012, 04:09 AM
use "include" instead "filein", because "filein" is like run script whereas "include" is like split your script to separate file.

easyfrog
04-20-2012, 06:20 AM
use "include" instead "filein", because "filein" is like run script whereas "include" is like split your script to separate file.

But when running a including "include" script. Each time it is run. First of all combine all of the include script , and displayed in Maxscript Lisener. Appears very bad. Very slowly

denisT
04-20-2012, 06:39 AM
But when running a including "include" script. Each time it is run. First of all combine all of the include script , and displayed in Maxscript Lisener. Appears very bad. Very slowly
you see why i don't like it

Klunk
04-20-2012, 09:40 AM
i don't think mxs was ever designed for large scripted tools. That was the purpose of plugins and SDK. The trouble with the SDK is it's so bloody obtuse where as mxs is simple, quick and accessible. Definitely the weak spot of mxs , managing large/multi-file projects.

muhammadfredo
04-20-2012, 01:38 PM
But when running a including "include" script. Each time it is run. First of all combine all of the include script , and displayed in Maxscript Lisener. Appears very bad. Very slowly
strange I never have that problem

Klunk
04-20-2012, 01:54 PM
i think the "custom interface" struct for common functions via stdscripts suggested by Denis is the way forward. Gives a kind of "namespacing" to the functions so you can avoid name clashing.

One question, Denis, do you after defining the struct/interface make it accessible by using a global (of struct type) at the end of the script, or use local versions with the tools ?

Gravey
04-20-2012, 02:33 PM
i wrote tool that ended up being around ~20k lines but the whole time i was keeping everything oraginsed into various structs and separated them into roughly 1 file per struct, which became ~100 or so .ms files. This helped me find and navigate code fast. I used include in the 'main' script file which eventually caused a 3 - 5 second startup delay due to the amount of files being included. it was annoying but acceptable for development purposes since I could be sure that all code relating to the tool was updated on each run. For distribution to the the users, I created a script to 'compile' all the includes into a single .ms file, after which startup time was 'instant' again. as a bonus this 'script compiler' as i called it, could filter out unwanted formats, prints, comments or any other wildcard or regex pattern i specified.

regarding the global structs in the stdscripts folder - the only problem i have with this is distribution to users - how can i be sure they always have the latest version of any given struct ??

Klunk
04-20-2012, 02:41 PM
how can i be sure they always have the latest version of any given struct ??

I guess the first fn is GetVersion() and you test against it on tool startup ?

denisT
04-20-2012, 02:52 PM
One question, Denis, do you after defining the struct/interface make it accessible by using a global (of struct type) at the end of the script, or use local versions with the tools ?
i wrote in some thread that nested structures changed my world. so i define GLOBAL structures. but usually they have some another structures inside. GLOBAL structure creates its own instance. If I need any sub structure from the global one, I make its local instance.
it looks like that:

-- as global struct in stdscripts directory:
global My_SkinOps
(
struct My_SkinOps
(
Vert =
(
struct Vert (pos, bones = #(), weights = #())
),
fn getSkin = modpanel.getcurrentobject(),

on create do ()
)
My_SkinOps = My_SkinOps()
ok
)

-- as script in scripts directory:
(
rollout rol "Rollout"
(
local _sk = if _sk != undefined do _sk
label lb "Skin Ops Test"

on rol open do
(
format "skin ops: % %\n" _sk (_sk.Vert())
)
)
rol._sk = My_SkinOps
createdialog rol
)

denisT
04-20-2012, 03:00 PM
here is another way of structure definition:

global My_SkinOps
(
struct Ops
(
Vert =
(
struct Vert (pos, bones = #(), weights = #())
),
fn getSkin = if iskindof (sk = modpanel.getcurrentobject()) Skin do sk,

on create do (My_SkinOps = this)
)
Ops()
ok
)

almost the same but I prefer the second one.

edit: No! I've double checked and see that usually I use version #1. That means it doesn't matter for me what I personally prefer :)

Gravey
04-21-2012, 06:37 AM
I guess the first fn is GetVersion() and you test against it on tool startup ?i think if you need to do this then you may as well just use include or fileIn from a single network location so you can be sure they are always up to date

j83
05-09-2012, 06:51 PM
While I do normally have a "no global data allowed" rule I follow and try to enforce with all scripts we use (as much as possible), I think structs like the examples here are the exception, especially as I recall the painful use of filein and other methods I've used while writing Maxscripts for tools we use.

However, I certainly do cringe when I find scripts with a skyskraper-size set of globals at the beginning of the script. Often you can surround everything in parentheses and change the globals to local, be "global free" and the script will work just the same (just make sure you test it, of course). Unfortunately, global data is often abused cause perhaps the script writer at the time was not familiar with better ways of sharing data in a script.

Furlong
05-10-2012, 05:13 AM
....I do normally have a "no global data allowed" rule...

Could you elaborate on this?
While i haven't been writing tools for very long, i always did find an inexplicable sense of "wrongness" whenever i solved a problem by making something global. I'm curious as to why it's considered bad or lazy.

To contribute to the thread, i've started keeping all my common functions within structs that i keep in the one .ms file that i'll filein at the start of any new tool i write. Like Gravey said, this is to keep users on the network up to date.

denisT
05-10-2012, 05:28 AM
Could you elaborate on this?

i don't like to make a lot of globals with my script but i don't really care about the using of global variables. the thing that i'm avoiding for sure is any using of include and filein. those are probably the worse things in max scripting.
the using of include and filein is the sample of unknowing how to the mxs works.

lanimal
05-10-2012, 09:23 AM
Little question for DenisT in his nested struct example.
I don't understand this line
local _sk = if _sk != undefined do _sk
After rollout definition you set rol._sk as a shortcut to your global struct, right?
So, _sk is never undefined...
I don't get it :surprised

PEN
05-10-2012, 12:40 PM
Great thread.

Glad to know Denis that I basicly follow the same rules as you. I don't like fileIn or Include, avoid Globals as much as possible and use structs to contain every thing.

The one thing that I played with years ago and then just stopped doing was nested structs, don't know why but just stoped using them. I think I will start making that a habit again.

Gravey, I like the idea of the script compiler, never thought of doing that.

DaveWortley
05-10-2012, 01:16 PM
I'm working on a 7000+ line tool at the moment, and I manage it by keeping everything in sections, declare lots of functions and putting ( ) around code sections so I can use the folds to make scrolling down a 7000line bit of code a lot quicker to find bits in. Just annoying maxscript can't record your folds so next time you open the script it's folded how you left it.

How does everyone write their code, in the inbuilt maxscript editor? Or in a different tool?

j83
05-10-2012, 02:19 PM
Could you elaborate on this?
While i haven't been writing tools for very long, i always did find an inexplicable sense of "wrongness" whenever i solved a problem by making something global. I'm curious as to why it's considered bad or lazy.

To contribute to the thread, i've started keeping all my common functions within structs that i keep in the one .ms file that i'll filein at the start of any new tool i write. Like Gravey said, this is to keep users on the network up to date.
Here are a few of my opinions and experiences when working with scripts that used global data,




issues are worse when the global variable names are terse, and common variable names at that, such as "up" or "valid", etc. or other such common words.
at least the script writer should have a callback for when the script closes to mark all globals as undefined,
can hide logic bugs and other type of bugs that are harder to catch, as the global data can hide the poor layout of the flow of the script
I think the main point it, just because someone uses a script or tool you wrote, doesn't mean you should take the liberty of dumping global variables and data all over their scene. :)
There are more, but those are a few of the things I've experienced when dealing with global data. :)


In a studio environment, perhaps where you'll be working with a lot of other scripts, a common global namespace would be valid, but my main annoyance is when users are using a lot of arbitrary scripts from all over the place, which can cause a lot of unusual bugs.

Pjanssen
05-10-2012, 03:16 PM
I'm getting a bit curious about the kind of tools you guys write. 20+ KLOC? That's rather big for a maxscript tool..

Also, I don't really see the issue with using fileIn. For example with the Outliner I use one "init" script file which does a bunch of fileIn's, not a problem I'd think.
https://github.com/Pjanssen/Outliner/blob/master/maxscript/script/init.ms

denisT
05-10-2012, 03:38 PM
Also, I don't really see the issue with using fileIn. For example with the Outliner I use one "init" script file which does a bunch of fileIn's, not a problem I'd think.
https://github.com/Pjanssen/Outliner/blob/master/maxscript/script/init.ms
i do absolutely the same. i have a launcher that sets all my stuff before run the main script. i just don't recommend to use filein and include inside the main script (the real code part)...
but include i don't use at all.

PEN
05-10-2012, 04:05 PM
I have tried to use Include thinking that there should be a way to use it and have just never found one. Good to know that others have found the same thing.

Any one using it in a creative way that I have not thought of?

Pjanssen
05-10-2012, 04:09 PM
i do absolutely the same. i have a launcher that sets all my stuff before run the main script. i just don't recommend to use filein and include inside the main script (the real code part)...
but include i don't use at all.
Aha then I misunderstood your previous post :)
I never use include myself either.

MikieK
05-12-2012, 07:09 AM
i wrote tool that ended up being around ~20k lines but the whole time i was keeping everything oraginsed into various structs and separated them into roughly 1 file per struct, which became ~100 or so .ms files. This helped me find and navigate code fast. I used include in the 'main' script file which eventually caused a 3 - 5 second startup delay due to the amount of files being included. it was annoying but acceptable for development purposes since I could be sure that all code relating to the tool was updated on each run. For distribution to the the users, I created a script to 'compile' all the includes into a single .ms file, after which startup time was 'instant' again. as a bonus this 'script compiler' as i called it, could filter out unwanted formats, prints, comments or any other wildcard or regex pattern i specified.

regarding the global structs in the stdscripts folder - the only problem i have with this is distribution to users - how can i be sure they always have the latest version of any given struct ??

After awesome guidance from Gravey, I still use inlcudes to split up my script into multiple files for organisation. Most of these end up in one global struct, and a handful of other bits and pieces which need to exist in a global scope. All in all, there's about 35k lines of maxScript, and 5k lines of C# ish?, which compile to a couple .dlls. I've often wondered if I can setup Visual Studio as my editor for both C# and MxS...

To manage versions, whenever files are saved with my code running, I save a version number in rootnode custom attributes, which can be compared to the currently running version. This was attribute holders, object definitions etc can get updated in old files at load time by the script before they get evaluated. Seems to work pretty well... I've been considering an auto-update feature, but as there are only a handful of users globally, it's easier to just pop out an email with a link :)

Ian31R
05-12-2012, 08:27 AM
How does everyone write their code, in the inbuilt maxscript editor? Or in a different tool?

I like to use a similar program to Notepad++, called PSPad. You can use several different syntax highlighters with it,and you can make your own, so I use a decent Maxscript highlighter I found, to make my scripts. Its not perfect, and I often have to add keywords to it, but it gets the job done. However a lot of times, when I'm testing out my scripts, I'll end up tweaking them in the editor.

Screen -
http://imageshack.us/photo/my-images/155/pspadmaxscript.jpg/

Klunk
05-12-2012, 06:19 PM
regarding the global structs in the stdscripts folder - the only problem i have with this is distribution to users - how can i be sure they always have the latest version of any given struct ??

I've just started shifting some common code into a stdplugs/stdscripts/ interface style struct. To make sure the latest version is always used I added a "self" installer to the interface which is called on the interface instance immediately after it's created. The user would then need restart max to utilize any changed scripts. No Idea if this is the best way to approach it or not. Another way I'm toying with is adding the self install to a #preSystemShutdown callback.

DaveWortley
05-14-2012, 09:48 AM
I like to use a similar program to Notepad++, called PSPad. You can use several different syntax highlighters with it,and you can make your own, so I use a decent Maxscript highlighter I found, to make my scripts. Its not perfect, and I often have to add keywords to it, but it gets the job done. However a lot of times, when I'm testing out my scripts, I'll end up tweaking them in the editor.

Screen -
http://imageshack.us/photo/my-images/155/pspadmaxscript.jpg/


I've seen a few people using this approach but I've often wondered how you deal with bug checking? Is there some form of plugin so that max can highlight your problem line in your PSPad?

gazybara
05-14-2012, 02:37 PM
I like to use a similar program to Notepad++, called PSPad. You can use several different syntax highlighters with it,and you can make your own, so I use a decent Maxscript highlighter I found, to make my scripts. Its not perfect, and I often have to add keywords to it, but it gets the job done. However a lot of times, when I'm testing out my scripts, I'll end up tweaking them in the editor.

Screen -
http://imageshack.us/photo/my-images/155/pspadmaxscript.jpg/
I love to see nice colored text editor.
For Notepad++ i use add-on by Ofer Zelichover (www.oferz.com (http://forums.cgsociety.org/www.oferz.com)).
I modify the color to look like this Notpad++ color style (http://i49.tinypic.com/34h71uq.jpg)
Npp_Maxscript_v1.1.rar (http://www.mediafire.com/?xiibt5194xcd1bt)
And for the MaxScript Editor I assume you already know for this solution by spacefrog
http://www.scriptspot.com/3ds-max/scripts/darkscintilla-maxscript-editor-dark-scheme

Ian31R
05-14-2012, 11:45 PM
I've seen a few people using this approach but I've often wondered how you deal with bug checking? Is there some form of plugin so that max can highlight your problem line in your PSPad?

Well, usually I use PSPad for the bulk of the scripting, and use the editor to test and refine the scripts. I try to test all of my functions / scripts anyways, because even if your script is bug free, the script might not be doing exactly what you want. You could probably make a plugin to do bug checking, but I'd rather save the time making more scripts :) I mainly use PSPad because of the syntax highlighting and because it has a lot of tools, such as mass replacing, sorting, general line manipulation, and bookmarking inside of your documents.

The dark Notepad++ style is pretty nice as well. I use a custom windows 7 theme, which makes the rest of the application dark too. - http://googleex.com/desktop/889-windows-7-theme-concave-7-theme.html I customized my color theme for it in max - http://imageshack.us/photo/my-images/833/darkmaxscript.jpg/ So yes, I definitely like to use the dark maxscript editor. I like dark themes for text editors in general, since its better for your eyes spending hours in front of a screen every day. And of course, I love the new dark Photoshop CS6 theme, I just wish you could have colored icons.

If anyone is interested in the color theme for PSPad, let me know.

easyfrog
05-15-2012, 05:53 AM
Maxscript Editor is use SciTE. So can realize a project window management dock left in it ? that will be prety cool! :bounce:

CGTalk Moderation
05-15-2012, 05:53 AM
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.