ftp://sharedcast.hccs.cc.tx.us/Director/JUST_IN/404UpdatesThe Macintosh version is also available from pangea:
ftp://pangea.stanford.edu/pub/esmedia/programs/Director/4.0.3_to_4.0.4_68K_Updater.sea.hqxAn extended update for the Mac version is also available on CD from Macromedia, priced US$25. This not only allows generation of fat binary projectors, but is itself a fat binary application, allowing Director to run native on PowerPC, for significantly faster running during development (if you develop on PowerMac the $25 will be money very well spent IMHO) For more info contact your usual software dealers or talk to Macromedia direct.
Several bugs, at least one of which is serious, have already been reported in version 4.0.4, so hopefully there'll be yet another incremental release before too many months pass. Updaters are generally released first to the Macromedia fora on CompuServe and AOL, but should be found on the sharedcast ftp site and elsewhere on the Internet within a few days. Look out for 'em.
All updaters are for version 4.0 or above. For information on upgrading earlier versions to version 4.0, contact your usual software dealers.
The cast is a storehouse for all of the elements of your movie, whether graphics, sounds, quicktime/AVIs or text. (In practice, some of these can be stored outside the Director file, but even then getting them into your movie is usually done via the cast.) Items from the cast are shown in the movie, but the cast itself is not. In most cases, the things appearing onstage are "instances" (that is, copies) of the original castmember rather than the actual cast itself. Multiple instances can be onstage at the same time, even with some of their attributes differing (eg, the same picture at different sizes).
The score is a set of instructions describing how the various cast members crop up in your movie and change and interact over time. The score window represents a kind of "map" of the movie's action in which all the different entities that comprise the content are described.
Director's default behaviour is just to do all the things shown in the score straight through, one after another. This doesn't allow for much in the way of interactivity, so Director also includes a scripting language, Lingo, which can modify the movie's behaviour. Most of the instructions represented by the score can be done explicitly in Lingo instead, and Lingo can also do a lot more besides.
As Director develops, the emphasis seems to be shifting away from the score and towards Lingo as the main site of movie control, but at present the "code" aspect of a movie tends to exist in both places, with the score taking the role of a visual overview. However, it is important to note that, since Lingo can take over control from the score, the picture of your movie which appears in the score window may not be complete.
The stage is where the movie actually plays. Castmembers are drawn and played on the stage according the directions in the score & scripts. The stage is what the user of your movie sees and hears, and where s/he addresses input (clicking on buttons, dragging controls, typing text etc).
It's important to note that some sprite properties actually affect the whole channel, and remain in effect even if you jump to some other part of the movie where some other sprite is in that channel. (The puppet and visible properties are the important examples of this.)
Both methods have different advantages. Bitmaps (at least for 1-bit images), are quick to draw to the screen, but they take up more memory and don't scale well. If you want to have them at several different sizes you have to create several different cast members, or else put up with badly pixellated (jagged) sprites.
Tools palette objects, on the other hand, can be slower, because the computer has to work out how to draw them properly each time. But because they are based on an abstract description, they can be scaled easily and always appear smooth (as smooth as possible, anyway). In most cases they also take up much less space in the cast, because only a brief specification needs to be kept, not a pixel-by-pixel copy.
Tools palette objects have the advantage that they can be changed as you go along: you can alter the width of a line or edit a piece of text. Bitmaps have the advantage that you can't do this -- and neither can anyone else. Bitmapped text, for example, doesn't depend on having a particular font installed on the machine your presentation is playing back on. It will always look just as it did when you painted it.
Importing a cast member makes a copy of the file being imported and brings the entire set of data for that castmember into your movie. Your movie becomes correspondingly larger, and any changes made to the original file have no effect on the castmember in your movie.Linking a cast member does not make a copy of the file being linked. All that is brought into your movie is a reference to the file's location on your file system. Your movie does not become significantly larger, and any changes made to the original file are reflected in the castmember in your movie.
Each method has its advantages and disadvantages. Many Director movies benefit from a hybrid approach - some of the cast may be imported, some may be linked. It is not only possible, but probably a very good idea to make the decision on a cast-by-cast basis.
Linked cast members have the advantage of automatic updating. It is conceivable that, with a well-organized computer network, a team of graphic artists could each tweak a folder of castmember graphics while the Lingo programmers worked on the code. Each team member could then focus on his/her assigned tasks independently and all work would be reflected, via links, in the movie. In practice, this lofty goal is difficult to achieve in a hectic production environment. And at some point prior to shipping the movie, it would be necessary to collect all the linked graphics into the local folder and update all the links.
Imported castmembers, because they are completely contained by the host movie, require no organizational mechanism other than the Cast Window itself (and the Cast Window is an excellent organizational mechanism). The Cast Window allows for fairly convenient updating if you do it one cast member at a time. You simply select the desired castmember in the Cast Window, select Clear Cast Members in the Edit Menu, and then select Import... from the File Menu. The newly imported file will replace the prior castmember, not only in the Cast Window, but also everywhere it appears in the Score Window. This is a quick and easy update for a single castmember, but it gets tiresome quickly for more than just a few updates at a whack.
Sound files are always a good candidate for linking, especially when they are quite large. Linked AIFF files spool from the hard disk when played, and therefore it is not necessary to import them, freeing up precious RAM for sprite graphics. Another good reason to link graphics files is for run-time variations. It is conceivable to design a multi-lingual movie which can accept a suite of linked castmember files, each of which is designed for a different language.
To fully-import an external file into the cast, use the importFileInto command:
importFileInto cast whichCast, whichFileThis will place the contents of whichFile into whichCast, regardless of whether there is something in the cast already (assuming the file named in whichFile actually exists).
To add a linked castmember on the fly, use the fileName of cast property:
set the fileName of cast whichCast = newFileNameThis only works if whichCast already contains a linked castmember. Unlinked casts can't have their filenames reassigned because they don't have 'em. However, you can easily add new linked castmembers by doing something like this:
-- keep a small linked castmember in cast "dummyLink"
-- if you've a large cast it's probably more efficient to
-- reference this by its number rather than the name
on createNewLink newFileName
-- locate an empty cast slot to use
put findEmpty(cast 1) into newCast
-- copy our dummy linked cast into it
duplicate cast "dummyLink", cast newCast
-- reset its filename
set the fileName of cast newCast = newFileName
-- return the cast number so we know where it is for future use
return newCast
end createNewLink
When linking external files on the fly, it's important to ensure that the files really are where you expect them. Judicious use of the pathName function can save a lot of grief.
In addition to the above methods, the FileIO XObject provides a method called mReadPict which allows you to import a PICT file on the fly. However, in all cases that I can think of, this has been rendered superfluous by the internal methods described above (as a general rule: if you can do it more efficiently in Lingo, *don't* use an XObject).
So, if you loop over the transition, the cursor flashes on and off (often more off than on since transitions can be slow).
The solution is to place the transition on one frame, with a second otherwise identical frame immediately afterwards. Then, loop back to the second frame rather than the one with the transition.
If you give one of the sprites a script like:
on mouseUp
nothing
end mouseUp
you should get the cursor back.
Note that this problem only manifests if the stage is the only open Director window, or in projectors. With other Director windows open (eg, the control panel) there's always something you may want to click on, so the cursor stays visible.
If you have previously deliberately made the cursor invisible using the cursor command, you may need to reset it with the command:
cursor -1As noted above, the cursor will also vanish during transitions, but these shouldn't usually last long enough for you to lose it altogether.
However, the matte ink can cause undesirable fringing if the graphic has anti-aliased edges. In order to get around this, duplicate the castmember in question, and erase the antialiased edges from the copy, so there's a clean edge for the matte to work with. Then, place this cast on top of the other one on the stage, lining them up carefully. Give the proper castmember whatever ink effect looks right, and use the matte effect on your trimmed one. The trimmed one should be effectively invisible, and you can use it as your button.
(There are more sophisticated methods for defringing antialiased picts using image editing programs such as Adobe Photoshop if the results of this crude approach are unsatisfactory.)
If you want your matte button to be white, create the appropriate shape as a 1-bit bitmap, put it onstage with the matte ink and set the forecolor to 0 (either with Lingo or using the colour chips on the Tools palette). This should make it appear as a white shape with a transparent background.
The Internet Connection at MCLI is
Alan Levine --}
Comments to
levine@maricopa.edu
URL: http://www.mcli.dist.maricopa.edu/director/faq/faq5.html