_root[input]._visible = false;

This might have been an easier example to start with. It's as simple as telling flash to evaluate the variable input then substitute it in to create a path to an object. Then of course there's the more difficult (but useful) stuff. Say you have an array of movieclip instance names and you want to set the _x of each to a random number.

_root.nameArray = ['Joe','Jenny','Jesse','Jumping-Jude'];

for (var j=0;j<_root.nameArray.length;j++) {
        _root[_root.nameArray[j]]._x = random(200);
}

That's a bit more complicated obviously but this is a crash course so you have to learn fast! Also note that specifically stating _root.nameArray each time isn't necessary; you could simple use nameArray, but I like to keep my paths specific for debugging. Note also that you must include the _root in the dynamic path; Flash needs at least the name of the timeline to look on.

In terms of array notation and dynamic paths, that's about as complex as it gets. You'll learn this best by experience so set yourself a few tasks to do and experiment! Once you're happy with that, we'll move on.

Relative Paths.

This diagram has been stolen from my previous tute on paths. In the Beginner level tutorial we discussed how paths can be associated with a tree structure. The 'trunk' of the tree is _root on which we have movieclips (branches), each of which can contain other clips and objects (sub-branches), each of which can contain variables (leaves). Say we're typing up some code within Clip2 which will call a variable in Clip1. The method taught in the beginner tute would be to use code like this:

_root.clip1.variableName = value;

And that's fine. But what if this SWF is going to be loaded into another SWF post-publishing? When loaded into a movieclip (say we use loadMovie("file.swf","targetMC");) all the paths will change! Clip1 is no longer _root.clip1 but _root.targetMC.clip1. Sure we could go through and rewrite all our paths but that would mean that when not loaded into another SWF, our code wouldn't function. What we're looking for is portability such that regardless of external influences, our code will hop along doing it's thing, oblivious to what's going on around it.

Relative pathing allows us to achieve this. Say we're on a staircase. I say "Walk up 3 steps" and you do. Now I say "Go to step 2". Do you come back down to the bottom and walk up again from step 0? No, you're lazy and you just step back one. That's what we want Flash to do. We don't want it to go all the way to the bottom of the path, because that might change from time to time, we just want it to know where things are in relation to itself. Flash has a few built in bits of code which allow us to access the various timelines relative to the current timeline. The two most important are this and _parent.

this makes reference to the current active object/timeline. For example, if I open up a new Flash file, and add the following code to frame 1 of the main timeline:

this.variable = value;

Flash will produce a new _root level variable with a value. If I am within a movieclip and I type the same code, the variable will be created on the movieclip timeline. "So what?" you say, "You can do that just with the variable name and leave out the this bit". Not quite true. You may leave out the this bit, but Flash needs it. ActionScript is a very user-friendly language: it allows for human laziness and error to some extent. When you leave out the this command, Flash's ActionScript interpreter automatically inserts it at compile time, to make it easier for the Flash player to read. Further, this has some invaluable applications, especially for higher level scripters. It allows you to make your own function prototypes and run functions over objects. It's also useful in with or tellTarget command blocks. For the moment, just remember that it makes reference to the active timeline/object.