At some point, you will come to the realization when you are writing MEL script that you can do anything if you divide and conquer. That was the approach I used with Walkerman, when I needed to do a particular thing, I would just concentrate on that particular issue, not the whole big picture. If possible, I would create the simplest example of what I needed as a starting point, and experiment with possible solutions, and then once I had found what i thought might work, I would then attempt to impliment it with the whole program.

Often I will delete out all of the code that is not pertinent to the coding I am attempting to impliment, just take a CHOPPED, very small part of a procedure, and work with it so all I have to deal with is a small simple piece of code, then when I get it working, plug it in to the regular code.

One of the biggest and most complex issues I ran into with Walkerman was how to identify and re-code each function that needed to be changed, to change a walk to a run with the click of a button. With my first attempt, I just numbered each function, so if I needed to modify, say function 12, I would just do a search for function 12, then modify it.

I ran into problems with that though when I started the quadraped project and needed MORE functions or had to replace any functions, and had to go back to the drawing board. In the end I coded a method to search for the string of code that controlled each individual joint attribute . .. i.e. ls.rotateX = bla bla bla . . . . I would just search for the string "ls.rotateX", and then edit that code. A rather novel and unconventional method, but a very effective way of identifying each function, with no room for error.

Coding is kind of like understanding German in a way, because with the German language, many people are intimidated by it, but if you learn some of it, you eventually come to the realizartion that most of those big words are nothing but a lot of simpler words all strung together . . . .