Could it be that the scripteditor is limited to a certain number of characters?????

if so....:banghead: what stupid kinda stuff is that????

Can I change this? Is it one of those deep nested useless features?????

Or, ... I'm really stunned by this limitation.:eek:

Robert Bateman

11 November 2006, 04:05 PM

yeah, there's a hard limit on how big your scripts can be. At this point, either save your script as a mel file and source it from the script editor; or start breaking out functions into seperate mel scripts (where myFunc gets saved as myFunc.mel).

ljilekor

11 November 2006, 05:13 PM

AAAAAAAAAAARRRRRRRRRGGGGHHHHHHHHHHHHH ! ! ! ! ! ! ! ! WWWHHYYY

Damnation strikes upon me.

AAAAAAAAARRRRGGHHHH (again).
Thx Robert, 4 clearing that up.

azshall

11 November 2006, 10:23 PM

Robert makes a good point.... Making your scripts modular is actually a smarter thing to do. If you have a MEL script that is getting beyond 1000+ lines, it can be cumbersome to modify as you're constantly scrolling up and down the script. At least I do because I try to nest as much as possible to minimize doing multiple applications (like finding the shape/type of an object) when I can write 1 return proc to do this and give it back to me.

You keep your MEL files smaller in length which then makes them easier to modify and if you get an error you get a bit more precise of an output and how to fix it.

Seth

faultymoose

11 November 2006, 10:38 PM

Relatively new to Mel (I once was a flash/actionscript programmer) I find that the biggest changes in my process come in the form of more intelligent script structuring. I am constantly revisiting old scripts and finding new ways to optimise (and minimise) code usage. Sometimes I can eliminate massive blocks of code with better use of procedures. Unfortunately, I don't think this can really be taught, as it's more a mindset than a practice, and I imagine the more scripting I do the better I'll be at it.

I can provide some tips that help me:

1. Look for repetitious blocks of code that can be replaced with a procedure call. For example, a procedure I often use is a custom myGetAttr($object,$attrib) proc that checks if the attribute exists before returning the result, allowing for my own error checking.

2. Group common procedures into their own mel file. I recently coded a lighting toolbox, and the entire code comprises around 6000 lines. But common procedures, such as createLight, createShadowLight, createRigAndAim, etc. are all put in a myScriptCreate.mel file.

3. Decide when to use variables and when to use procedure calls directly, eg:

$temp = `callMyProcedure`;
calculateSomething($temp);

versus

calculateSomething(`callMyProcedure`);

I believe that the second example can result in a slower script as the first example just requires a single call to callMyProcedure, but I'm yet to work with a script big enough to notice a difference.

4. If you're anything like me, you'll constantly find embedded solutions that you were unaware of. Many of my custom procedures have been replaced with a single mel command, and I expect that will continue to happen as I become more familiar with the mel syntax, but learning the long way to do something can be very helpful.

5. There is almost always more than one way to get the result you're after. This goes back to the last point. Examine as many code examples as possible, particularly those that produce similar results to your own script. I've discovered many shortcuts this way, but I've also identified many ways in which my own workflow could improve upon those examples.

Maybe someone else could provide some more tips. I'm not an expert my any means. I'm still waiting for someone to explain search strings for the match command - in english :P haha

P.S. Excuse my post if you're actually quite experienced at mel and only just started using the internal editor :blush:

tbaypaul

11 November 2006, 02:12 AM

Well, typing 900 lines into the script editor is a pain in it self...sorry for that limitation....but don't use the script editor.

I have two buttons on a shelf one is to open up Textpad (what I use to write scripts). It has this command associted with it.

you can write as much as you want there....I have Seth's tippet Rig there and it has 3500 lines of code alone in the editor part...and is a bit*h to read thru...

ljilekor

11 November 2006, 09:49 AM

Though the script is quite optimized, I could still do some more...

I used MaxYa as the external editor. The execute button doesn't work properly. So I copy the source in the native editor to execute it. There's where the problem occurs. The pasted code from MaxYa has all tabs are replaced by single spaces. This dramaticly enhances the number of characters. By replacing the space with tabs again I gained a lot of extra room.

Splitting up the code in different MEL's by creating eg. a Utils.mel with common recurring procs is also a way to go. I'm not a really big fan off this but it's just something I'll have to learn to live with.

Thx 2 everyone 4 the replies.

goleafsgo

11 November 2006, 01:58 PM

I used MaxYa as the external editor. The execute button doesn't work properly. So I copy the source in the native editor to execute it.
Even if the "execute button" in MaxYa doesn't work you still don't need to copy the code into Maya's script editor to execute it. Just save it as a mel file in your scripts folder and call it from Maya.

Robken

11 November 2006, 01:57 PM

why not use melStudio? I love that plug-in.

Buexe

11 November 2006, 04:19 PM

why not use melStudio? I love that plug-in.
That was what I was thinking while reading this thread : )
Best money I invested after Mark Wilkin`s MEL book

Robert Bateman

11 November 2006, 05:36 PM

Robken[/b]]why not use melStudio? I love that plug-in.

because it only works on windows.
because it's not as good as other text editors.

Robken

11 November 2006, 08:46 AM

because it's not as good as other text editors.

maybe so, but it still kicks the crap out of the script editor.

Buexe

11 November 2006, 09:35 AM

because it only works on windows.

That is reason #340348 to use a windows computer and why would you want
to use another OS anyway?!! haha, just kidding : )

because it's not as good as other text editors. Now that one I really don`t understand. Can you tell me which text editor lists all my procs
and expressions in a nice list or has an auto complete feature, or takes me directly to the docs of a command or >> insert another 20 reasons in here <<?

sunit

11 November 2006, 10:00 AM

Can you tell me which text editor lists all my procs
and expressions in a nice list or has an auto complete feature, or takes me directly to the docs of a command or >> insert another 20 reasons in here <<?

jedit for one. plus it's cross-platform and very customizable. edit a simple regexp file and you're not just parsing procs, but any kind of structure you can think of (switch/cases, if/else statement, variables, comments, etc).

it might be a bit harder to set up for mel editing than mel studio, but it's much more expandable.

-sunit

brubin

11 November 2006, 12:47 PM

if so....:banghead: what stupid kinda stuff is that????

Or, ... I'm really stunned by this limitation.:eek:

what really stuns me is, how'd you manage to get to line 915 without ever crashing your maya in an endless loop or some other sort of script-failure? i'd be banging my head against a solid concrete wall for the remainder of the day, if i'd loose all my writings by the time i get to line 100.
there's no alternative to a external texteditor, if you ask me, and besides, syntax highlighting and line numbers are not to be sniffed at either...

just my 2 pennies worth...
s.

Buexe

11 November 2006, 12:57 PM

Okay, I`m a Mel Studio fanboy, alright? I took a look at jedit and didn`t
find this proc listing sunit mentioned, but that was probably just my blindness,
anyway did you know Mel studio pro has an auto save feature, in case you get
maya to hang? I think I should get money for all the advertising I`m doing.
may the editor be with you :)

cpan

11 November 2006, 01:10 PM

since this turned in a script editors war hehe, the default script editor is perfect for testing small scripts, verifying sintax, etc (maybe sintax highlighting is the only thing really needed) IMO.

As for "serious" scripts i preffer external script editors any day over MEL studio (and any internal editors) as i mostly allways want a full screen script editing and be able to work with Maya closed so i can play games till i get a better script idea, haha :D
Oh, and to test the 'external' script, just add a "source blabla.mel" shelf and a command executor shelf, so an alt+tab and one click gets you ready to test the script :)

UltraEdit /w MEL Syntax on Win and Jedit on Linux rule! :]

cya,
calin

StephG

11 November 2006, 09:25 AM

Source Edit with MEL syntax is pretty nice. I've had lots of scripts open in its tabs, and sometimes open the huge ascii files I right to debug them (weight lists, key lists for mocap files, etc).

I still like MEL Studio for in-progress stuff. Type a few lines, hit enter, see if there's a problem ;)

Got a big tool suite? 5000 lines, no problem (I've got two suites in that range, and a bunch in the 2000 line range). Trace proc calls with a simple text search. Don't have to trace calls from script to script with a big library. Or if you do have a library, you can combine the procs into a single script for major mods, test it, then break it out again. Also really nice for testing interfaces with just a single punch of the number pad Enter key ;)

I might use the standard script editor periodically for really short tests. Or sometimes to aggregate auto created scripts using scriptEditorInfo -i, but otherwise it's largely unused since I started using MEL Studio earlier in the year. It's sad to hear that MS isn't available on Linux, a major oversight IMO.

I could survive without MEL Studio, but I'd miss it. It certainly isn't my single scripting source, but it's hard to believe that anyone who could use it would reject it out of hand completely.

Incidentally, one of the things I like best about MEL Studio is that I can just highlight a part of a larger script (like say a single proc I'm working on) to update it if I have an interface open with a lot of checkboxes and other data set the way I want them. It's a handy tool to have and use.

Re: the endless loop problem...I always put a stop loop option to error out at about 500,000 loops (usually less in early tests) until I know the script is stable. Saves me lots of headaches ;)

CGTalk Moderation

11 November 2006, 09:25 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.

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