Basic

Basic Shapes file editing is via Anvil. Other tools for more advanced work are CLUT Modifier, Shapes Juggler and a suitable data fork editor.

Anvil versions available are:

v1.0
Original release. Buggy as an anthill.

v1.0.2
As bug free as any later version, but color table editing features are a bit basic. Otherwise usable.

v1.0.3f (aka 1.0.3)
Last release version (shipped with Trilogy CD). Rendered virtually useless for Shapes editing due to a screwy integer bug [see notes below]. Shapes editor is otherwise identical to v1.0.3b4 except for addition of "Disable color checking" feature [see notes below], and the modified Views menu in the Sequences editor (adds support for separate One-Animated and One-Non Animated settings; unfortunately it's buggy and doesn't actually work).

For Shapes Editing, therefore, the recommended version is 1.0.3b4. v1.0.2 will serve if you don't plan on doing color table modifications, but there is no advantage in using it over v1.0.3b4 so you might as well upgrade. v1.0.3 is only really of use if you require the "Disable color checking" feature, although it is useful to keep a copy for the purpose of checking sequences with Views set to One to see if they're actually One-Animated or One-Non Animated. Beyond that, however, stick to the recommended version.

Updater/backdater patches are available on the Bungie.org Archives for updating earlier Anvil versions to later ones, and for backdating v1.0.3 to earlier versions (essential for Trilogy CD owners). Again, v1.0.3b4 is the recommended version for all day-to-day Shapes editing. If you don't have it, get it.

Bugs (and work arounds)

Screwy Integer bug (affects v1.0.3f only)
Just in case you missed it last time, v1.0.3f has a bug which causes integer numbers in the Sequences editor to appear in form of e.g. "10.009". The fix: backdate to an earlier version (guess what - v1.0.3b4 is the recommended version to backdate to).

Frame misnumbering bug (affects all versions)
The frame misnumbering bug causes Frames to become misnumbered as you edit them. The end result is that the same frame can end up getting used more than once - you'll generally notice this after a while when you've been been altering frames and then look back to the ones you did earlier and think "hey, that's not what I set it to, it's changed!" If you wish, skip straight to the Solution further down; the next bit describes how the problem arises in the first place.

The Problem:

As you increase or decrease the number of Frames-per-View and/or the number of Views, Anvil has to insert/remove Frames into/from the collection. Unfortunately, it tends to get its maths wrong. Specifically, the problem arises when you reduce the number of Frames-per-View in a sequence when that sequence is set to more than one View. Anvil forgets to renumber the sequence currently being altered, but it does renumber the subsequent collections just as if it had renumbered the first collection correctly.

Here's an example. Sequence #0 is currently set to Eight Views, 4 Frames-per-View (note that I've only shown the first couple of Views in this sequence to save space - it's enough to illustrate the point, however). As you can see, everything is numbering in order:

View#1's Frames are numbered #1-4, View#2's are numbered #5-8, View#3's are numbered #9-12, etc. This is as it should be - i.e. continuous.

Now, I want to set sequence #0 from Eight Views, 4 Frames-per-View to Eight Views, 1 Frame-per-View. So I type '1' in the Frames/View field:

See how Anvil has forgotten to renumber the Frames for Views #2-8 in sequence #0? This sequence would still work OK in itself, mind you - the problems start further down the line, starting in this example with View #3:

As you can see here, View #3 of sequence #0 is still using Frame #9. But look at sequence #1; it also is using Frame #9! Because each Frame has its own unique settings for Bitmap Index, alignment, light value, etc. each Frame should only ever appear once in a collection. Because that frame is now being used twice in two different sequences, you cannot set unique Bitmap Index, alignment, light value, etc. info for each sequence - as soon as you enter the settings correct for one sequence, you're overwriting the settings that were previously correct for the other!

Sometimes you can recover the collection at this point by returning the Frames-per-View setting for the modified sequence to its original value, or greater - this will force Anvil to renumber the Frames, but whether that will be effective in clearing up the problem is another matter entirely. This is usually the sort of stage when the only really sensible solution is to go back to the last saved version and start over from a still-clean version of that collection. And you've still not managed to change that sequence to its desired new settings!

The Solution:

As you can see, reducing the number of Frames in a sequence that has more than One View will always corrupt that collection's settings. You can, very fortunately, work around this bug if you always use the following work around.

Note that Anvil will renumber correctly when you reduce the Frames-per-View setting if the Views for that sequence are set to One. Thus, set Views to One, adjust Frames-per-View to the desired value, and then set Views back to its original value. This is inconvenient as it means you then have to redo the settings for all Views >1 (tip: copy the settings onto paper first so you can just read them back in quickly). However, once Frames become misnumbered it's hell trying to undo the damage again, and even worse to try and work on further with a screwed collection.

The work around is definitely the preferable option to having to rebuild the entire collection from scratch, thus you are strongly advised to follow this simple work around whenever altering Sequence settings this way. It's annoying, but there's nothing that can be done about the bug itself, so you just have to deal with it as best you can.

One-Animated and One-Not-Animated Sequences

Something that pre-1.0.3f version of Anvil never indicates was that there are actually 2 types of "One View". Anvil 1.0.3f adds these options to the Views menu, except that it doesn't actually work (presumably a bug in the menu code).

Earlier versions are 'aware' of these settings and will preserve existing settings as long as they remain unchanged. However, there is no way of selecting between the two in v1.0.3b4 or earlier. Nor does the menu give any visual indication of whether or not a One View setting is Animated or not.

One-Animated is used for sequences where there is One View and several frames that should animate.
One-Non Animated is a little more complex - you can have several frames here also, but instead of animating them the Marathon Infinity engine instead picks one at random and displays that permanently. This is commonly used for scenery objects and corpses as a way of adding some randomness - you can, for example, use it for a 'blood splash' scenery item so that the Marathon Infinity engine will display a selection of different-looking puddles of gore and liquids (much more fun than having the same single boring old blood splash graphic every time:).

Note that Four/Five/Eight Views will always count as Animated (and regardless of the number of frames present - for folks who create multi-sided scenery objects and then wonder why their other animated scenery items no longer animated; well, this is why).

For any version of Anvil, when you create a new sequence it is automatically set at One-Animated. When you alter the Views menu to One, it becomes One-Non Animated. So remember this.

The difference between One-Animated and One-Non Animated is important, and incorrect settings are often the cause of oft reported problems. The three most commonly encountered problems are:

1. Monsters don't die correctly. A dying monster plays through its Dying sequence, then instead of going to its Dead sequence it returns to the first frame of its Dying sequence, where it 'sticks'. This happens because the Dead sequence is set to One-Animated. Dead sequences must be set to One-Non Animated (or Four/Five/Eight Views, but One-Non Animated is normally used for the reasons just covered above).
   
2. Scenery items you want to animate stay stuck at their first frame. This is generally because the sequence is set to One-Non Animated. (Actually, there is sometimes another reason for this happening in-game - the maximum number of scenery items that can animate simultaneously in a level is 20. However, if none of your scenery items are animating, then check the Views setting.)
   
3. The reverse of 2 - scenery items that you wish to remain static animate instead. (There is a barrel in the Sewage set of Marathon Infinity that demonstrates this particular screw-up quite nicely.)

OK, that's the usual symptoms. Now, about cures:

First, this is one of the few occasions where it is useful to keep a copy of Anvil1.0.3f around. Although you cannot set the Views menu correctly, it does at least display the current setting for the sequence. So use v1.0.3f to check to see if the Views are set correctly or not. If it's set correctly then your problem must lie somewhere else (too bad:). Usually, you'll simply confirm that it's set incorrectly.

If your problem is with dying monsters, the solution is very simple: set that sequence to Four/Five/Eight Views and then back to One. As noted earlier, this will cause the sequence to set to One-Non Animated. (If unsure about a sequence, just do this anyway to be sure.)

If you wish to make a non-Animating Sequence Animate there are a couple of work arounds available:

1. Set the sequence to Four Views. You should then replicate all your settings for the first view in the other three which have just been created (this way, as you walk around the object the animation will continue to look smooth even though you are actually seeing it from different views). Having to do more sequence work is a bit of a pain, but it's a simple, reliable method which works.
   
2. The second method is a bit more technical, and requires use of a Data Fork (Hex) editor. I'm not sure who described it first, but I'll set it out here along with a suitable example.

First, work on a COPY of your Shapes file. You do not want to try this on your single existing copy and then find out you've corrupted the file to hell due to a dumb mistake. Data Fork hacking is potentially very dangerous (not just to the file being hacked, but potentially to the entire disk. You have been warned.)

Open the file in your Data Fork editor (making sure you're looking at the Data fork, not the Resource fork). I use the Disk Editor bundled with Norton Utilities (see screen shot below). The easiest way to find the sequence in question is to use a Find command to track down that sequence's title (note case sensitivity). In the example below, I'd already renamed the collection "Sculpture Block anim" to make it easy to find (Find commands can have the funny habit of searching your entire drive, so watch out). Once you've found it, look at the hex data following the sequence name, searching for the first '0A' (that's 'ten' in decimal). Change this to '01' to set the sequence to One-Animated. Don't change anything else, and don't try to change the value from anything other than '0A' to anything other than '01' (ie. or you'll totally screw your file). Save your change and close (note that hitting Return in Norton Disk Editor means 'Don't Save' - even Disk Editors think this disk editing lark a Bad Idea). You should probably then use Anvil1.0.3f just to check you did set the right value, and not some other '0A' value (e.g. note how there are two '0A's in this example screen shot).

My own advice: changing the number of Views to Four is much safer, if a little slower. Nuff said.

A couple related footnotes on Animating sequences:

A monster may have an Animated sequence (i.e. One-Animated/Four/Five/Eight, with >1 Frame-per-View) for its Stationary sequence if you wish. However, a 'sleeping' monster (one that has not yet been activated) will not show any animation. Once a monster is awake, however, it will show animation in its Stationary sequence. This may be useful, for example, for a flying monster which you want to keep animating as long as it is airborne (i.e. a flying monster moving vertically-only will display its Stationary sequence while doing so). In such a case, you may simply use the same Animated sequence for both Stationary and Moving (preferably designing the sequence so that the first frame also looks suitable for when the monster is initially inactive).

Weapons-in-Hand sequences can only animate for certain functions; i.e. Idle and Charging functions do not support animating, regardless of whether the sequence used is set to One-Animated or One-Non Animated.

Items (e.g. weapons and ammo items) can't animate.

Importing/Exporting Photoshop color tables

There are some problems with importing/exporting Photoshop color tables, depending partly on which version of Anvil you use. This is one of those Anvil features that just implemented as well or as sensibly as it should have been.

When exporting PS color tables, Anvil (rather sloppily) writes out as many colors as it can find in a collection, until the PS color table is full or it runs out of colors. With collections that contain only one CLUT, this is not really a problem, but for those that contain more than one, Anvil will simply tack the contents of subsequent CLUTs onto the end of the first one (it really shouldn't do this), which makes the exported PS CLUT not terribly useful for indexing artwork since it contains a lot of unwanted colors (admittedly, these can be edited out manually, but there are other reasons why Anvil-generated PS CLUTs aren't really suitable for indexing work). Note that Anvil starts exporting from the currently selected CLUT.

When importing PS color tables, there are two main problems that may be encountered:

In v1.0.2, Anvil replaces all entries in a CLUT with the contents of the PS color table, including the first 3 transparency colors. This is fine if the CLUT you're importing already has the 3 transparency colors at the start. However, if your CLUT is PS-generated then this won't be the case, which will have unwanted results. The most likely problem is when importing a PS-generated CLUT into the Custom Weapons-in-Hand collection and you discover that bits of your weapons graphics (most likely the lightest bits, since PS orders CLUTs with lightest colors first) are transparent when they shouldn't be. For this reason, Anvil was modified after v1.0.2 so that the first 3 colors weren't overwritten, but...

In v1.0.3b4 (or v1.0.3 if you're reckless enough to be using it), if you import an Anvil-generated CLUT you'll find that the original 3 transparency colors remain in place OK, but that the 3 transparency color entries in the Anvil-generated CLUT appear directly after these (albeit remapped to their closest 'Mi-safe' equivalents) - Anvil isn't smart enough to skip these 3 entries as it imports the CLUT, unfortunately. This behavior is more appropriate when it comes to importing PS-generated CLUTs (for custom Landscapes anyway...). Bear in mind that when you index the artwork to be inserted, you should index it to 253 colors, not 256.

At any rate, there are more flexible and less irritating ways of handling CLUTs than using the Import/Export feature.

[See the color Editing section for more information on handling colors, CLUTs, etc.] (coming soon)