when write a big script...

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  04 April 2012
when write a big script...

when write a big script... > 3000 lines . What is the good way to management code? use "include" ? "filein" ?
 
  04 April 2012
Originally Posted by easyfrog: 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 ...
 
  04 April 2012
use "include" instead "filein", because "filein" is like run script whereas "include" is like split your script to separate file.
 
  04 April 2012
Originally Posted by muhammadfredo: 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
 
  04 April 2012
Originally Posted by easyfrog: 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
 
  04 April 2012
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.
 
  04 April 2012
Quote: 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
 
  04 April 2012
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 ?
 
  04 April 2012
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 ??
 
  04 April 2012
Quote: 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 ?
 
  04 April 2012
Originally Posted by claude666: 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
)
 
  04 April 2012
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

Last edited by denisT : 04 April 2012 at 02:02 PM.
 
  04 April 2012
Originally Posted by claude666: 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
 
  05 May 2012
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.
__________________
Disclaimer:
My opinions are not those of my employer.

Last edited by j83 : 05 May 2012 at 05:56 PM.
 
  05 May 2012
Originally Posted by j83: ....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.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 05:55 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.