How does one create a ".pal" file?

[fern]

  That's what you get for asking a very techical computer programmer a question....... a very technical answer.

Pretty much. Just load up any old thing and you will get a pal file. But whether it will be useful for recolours......Well you would just have to experiment.
Ape cannot handle big buildings and scenery so I have always loaded them manually in zoot. Zoot creates the pal from the 4 view pngs I load. How they work I don't care. That they work is what matters.  

[johnrn1]

  That's all I was asking.  What png to throw in zoot. How many. Where to throw them. And, does the pal file come out the "pal slot".  Oh yes...Where is the pal slot?     Just kidding. I know there's no pal slot.  Is there?

[fern]

I wonder if that is in the "Help" in Zoot. I haven't read it. I learnt to use Zoot before it was written.

I can think of a couple of ways depending on whether you are making a new file or just after the pal for recolouring purposes.

[johnrn1]

I'm just after the pal file right now.

[Jay]

Yes, my previous post is confusing. But it is still a simple example, since it uses the easiest 2 colors, has no color shades, has only 1 row of pixels, and has only 3 pixels total.

I believe fern's idea was to take a ".pal" file from scenery, and possibly scenery that was recolored, and then try that ".pal" file with an animal. But, unless that scenery has a lot of colors, I do not believe that approach will work. A ".pal" file always has 256 colors inside, although they are not always unique. A BF animal might not use the colors that are at the start of the ".pal" file. For example, an animal might use the 96th and 97th colors in the file, but not the 1st color. When we recolor the image of an animal and then load it back in, Zoot and maybe APE will put the used colors at the start of the ".pal" file, instead of putting them as the 96th and 97th colors. So that is why a recolor might look good in a graphics program but not look good when it is put back into a ".ztd". That is why Rick's approach has a better chance of working, because it always has 256 colors. But even then it is an approach that involves trying and seeing, because the preferred shades in those 256 colors might be at a different location than where the animal images look.

I have not given up on understanding this more. I have downloaded a number of programs that allow looking inside ".png" files. That can tell me what reduces the number of colors, what changes the order of colors, and what type of ".png" files that Zoot and APE can handle. I also have an idea for extracting all 256 colors of a BF ".pal" file. Like anything else, though, it is a matter of finding time to experiment.

[Jeff]

Sorry for bumping such an old topic, but Jay, I was wondering if you have found any more information on this.

Basically what I would like to find out, is how it works. Let's work with "N" and "N.pal" for example.

The "easy" part: the .pal file probably only contains the colors, if I understood your explanation correctly.

And for most part, MadScientist (Zoot's creator - is he still around actually?) has obviously found out most of the stuff which is in the files. I haven't taken a look at the source code yet (no experience with Java at all, only with JavaScript which is something else, and a few other actual programming languages).

It also seems that the first few bytes of the "N" file are often different. I've also noticed that one of the first bytes is the length of the path which is only just a bit further (eg animals/12345678/idle/idle.pal ). I assume all other values are in some way mentioning the width and height of the image (which we should easily find out if we have an image with different width/height and just one color and which we then rotate  90 degrees), and that there's probably a reference to an index number (in the pal file) for each color. But how the image is then composed, and if/how breaks are defined...    

Lastly, there's also two complicated aspects I'm assuming.
- multiple frames + animation speed + likely some form of alignment ("rotation fix")
- what about color replacements... are they defined in the "N" file? Or just by a separate .pal file?

----

Slightly off-topic, but maybe interesting: I replaced the "swimming with dolphins" guest animation with an elephant's animation. Some colors were still replaced. So either the color must have matched (highly unlikely) or some index number of a palette file...

----

Taking a look at the Restaurant's AI-file:


[colorrep]

; cr_color is listed below
color = cr_color

; cr_part1 is listed in building.ai
replace = cr_part1
title = 2300
defaultpal = scenery/building/pals/brwn16.pal

; cr_part2 is listed in building.ai
replace = cr_part2
title = 2301
defaultpal = scenery/building/pals/gold8.pal

[cr_color]
ncolors = 232
fullpal = objects/restrant/restrant.pal
colorpal = objects/restrant/color.pal

I'm assuming "ncolors" is just "number of colors"?

Most of it reccurs in other objects of which we can replace the color, e.g. Bathroom :

[colorrep]

; cr_color is listed below
color = cr_color

; cr_part1 is listed in building.ai
replace = cr_part1
title = 2302
defaultpal = scenery/building/pals/gold16.pal

[cr_color]
ncolors = 232
fullpal = objects/bathroom/bathroom.pal
colorpal = objects/bathroom/color.pal


In buildings.ai, we find this, which confirms my idea on "ncolors":


[cr_part1]
; Shared 16-color replacement palettes for buildings
; The name of this block is contained in the colorrep block
; of the ai files for each building
ncolors = 16

pal = scenery/building/pals/blue16.pal
ui_info= blueButton

pal = scenery/building/pals/green16.pal
ui_info= greenButton

pal = scenery/building/pals/teal16.pal
ui_info= tealButton

pal = scenery/building/pals/gold16.pal
ui_info= goldButton

pal = scenery/building/pals/gray16.pal
ui_info= grayButton

pal = scenery/building/pals/grayb16.pal
ui_info= graybButton

pal = scenery/building/pals/lime16.pal
ui_info= limeButton

pal = scenery/building/pals/orang16.pal
ui_info= orangButton

pal = scenery/building/pals/purp16.pal
ui_info= purpButton

pal = scenery/building/pals/rose16.pal
ui_info= roseButton

pal = scenery/building/pals/steel16.pal
ui_info= steelButton

pal = scenery/building/pals/tan16.pal
ui_info= tanButton

pal = scenery/building/pals/yello16.pal
ui_info= yelloButton

pal = scenery/building/pals/red16.pal
ui_info= redButton

pal = scenery/building/pals/brwn16.pal
ui_info= brwnButton

pal = scenery/building/pals/palyel16.pal
ui_info= palyelButton

pal = scenery/building/pals/fucia16.pal
ui_info= fuciaButton

pal = scenery/building/pals/watmel16.pal
ui_info= watmelButton

pal = scenery/building/pals/burg16.pal
ui_info= burgButton

pal = scenery/building/pals/choc16.pal
ui_info= chocButton

pal = scenery/building/pals/ulmar16.pal
ui_info= ulmarButton

pal = scenery/building/pals/pink16.pal
ui_info= pinkButton

pal = scenery/building/pals/sky16.pal
ui_info= skyButton

pal = scenery/building/pals/bone16.pal
ui_info= boneButton

[cr_part2]
; Shared 8-color replacement palettes for buildings
; The name of this block is contained in the colorrep block
; of the ai files for each building
ncolors = 8

pal = scenery/building/pals/blue8.pal
ui_info= blueButton

pal = scenery/building/pals/green8.pal
ui_info= greenButton

pal = scenery/building/pals/teal8.pal
ui_info= tealButton

pal = scenery/building/pals/gold8.pal
ui_info= goldButton

pal = scenery/building/pals/gray8.pal
ui_info= grayButton

pal = scenery/building/pals/grayb8.pal
ui_info= graybButton

pal = scenery/building/pals/lime8.pal
ui_info= limeButton

pal = scenery/building/pals/orang8.pal
ui_info= orangButton

pal = scenery/building/pals/purp8.pal
ui_info= purpButton

pal = scenery/building/pals/rose8.pal
ui_info= roseButton

pal = scenery/building/pals/steel8.pal
ui_info= steelButton

pal = scenery/building/pals/tan8.pal
ui_info= tanButton

pal = scenery/building/pals/yello8.pal
ui_info= yelloButton

pal = scenery/building/pals/red8.pal
ui_info= redButton

pal = scenery/building/pals/brwn8.pal
ui_info= brwnButton

pal = scenery/building/pals/palyel8.pal
ui_info= palyelButton

pal = scenery/building/pals/fucia8.pal
ui_info= fuciaButton

pal = scenery/building/pals/watmel8.pal
ui_info= watmelButton

pal = scenery/building/pals/burg8.pal
ui_info= burgButton

pal = scenery/building/pals/choc8.pal
ui_info= chocButton

pal = scenery/building/pals/ulmar8.pal
ui_info= ulmarButton

pal = scenery/building/pals/pink8.pal
ui_info= pinkButton

pal = scenery/building/pals/sky8.pal
ui_info= skyButton

pal = scenery/building/pals/bone8.pal
ui_info= boneButton

(ui_info just refers to INI-sections which have the same name, and then it just defines the color values for those buttons which are shown ingame)


If I take a look at blue16.pal, the first byte is '11' (HEX), so 17 (DEC). The next three bytes are 00.
There's 4 bytes of which I don't know what they mean (00 FF 00 FF). They might be some sort of filler bytes. And then there's 16x 4 bytes which I assume represent blue colors.

Blue8.pal: first byte is '09', next three bytes are 00. Then there's the block of 4 mysterious bytes. And then we have our 8x 4 bytes for the colors.

[dr rick]

i'm all in favour of bumping this kind of old topic! i await the answers and resulting questions with interest...

[Jeff]

What would you like to accomplish, dr Rick?

I actually have two goals. Although, we should face this is an old game, and there's not that much interest in it any longer - although if you consider how long it's been around, it is still quite impressive.

My two goals:
- I want to find out if (most likely: yes) and how it is possible to create buildings of our own where we can replace colors.

- I would also like for a new tool at some point to create new items. That could go several ways. Either it's a full-blown tool: for instance, it would not mess up the UCA/UCS-files that much and it should give a lot more information on what certain characteristics mean. Perhaps there would also be some basic wizards. But if we would just get the graphics part working... we could an improved version of a tool like ZOOT.

I think we have quite some technical people around, perhaps we could co-develop this if we could agree on a programming language etc. I have to admit, I'm only used to VB.Net when it comes to software. It's just a very easy thing to master, and I come from exploring VB6 years ago. But I do "understand" some C# too. I'm more familiar with web development.

Update:
I was actually in the mood to experiment with some stuff. Using ZOOT and a Hex editor, and using a few  basic images, I managed to find out a lot of stuff already. I think I understand how a single frame is drawn, how it copes with transparent pixels, with width/height, with offsets, with animation speeds,  how it refers to the .PAL-file. I mostly documented the stuff in a Word file, with some examples. I'll see when I find the time and when I'm the mood to try to piece something together that reads/writes those files. Once I figure that out, it should be a small step to the animated versions.

The only part of programming I've actually done, is a .NET program which reads a palette file and displays all colors inside.

With that little program, I checked some files of the restaurant:
- restrant.pal: contains 256 colors.
- color.pal: contains 232 colors. They are identically the same as all the first colors in restrant.pal, except for color index 0: black in restrant.pal, pink in color.pal (the kind of pink you'd use for transparency, although it might be a coïncidence).
- 1.pal: pink + 16 colors (the ones which were NOT in color.pal ) = the ones we can replace? (mostly black, blue)
- 2.pal: pink + 8 colors (the ones which were NOT in color.pal ) = the other ones we can replace? (shades of grey)

Possible conclusion: the colors which can be replaced, are better placed at the end of the original object palette file - although this might not be a requirement.
cr_color = color.pal = colors which are to be left untouched.
cr_part1 = 1.pal = colors for a first color replacement option
cr_part2 = 2.pal = colors for a second color replacement option

So basically, with this information, all we need is a tool which makes it easy for us to determine which colors may be replaced.
One thing we will have to keep in mind (just a stream of thoughts right now): the 1.pal with 16 colors would most likely need to refer to a palette like "blue16.pal", the second one with 8 colors would need to refer to "blue8.pal". I'm assuming the color replacement happens in the same order. E.g. color #0 in 1.pal is replaced by color #0 in blue16.pal.

This would also mean that you can use a maximum of 16 colors + another maximum of 16 colors (assuming you have to chose between 8 or 16 at this point) which can be recolored!


I hope this is a useful contribution. * Hoping to get credit for things of which you could replace the color, eventually, be it by this basic summary or by developing a little program himself *


From left to right: restrant.pal, color.pal, 1.pal, 2.pal

Another update: I'm extending the tool so it will be able to render graphics. If I succeed, it should help me to create a program which is able to create graphics as well. Consider it a ZOOT-clone. But with maybe some new features ahead...

[Jay]

Some time in the 2003-2005 time frame, MadScientist created an article at Zoo Admin describing a good portion of the ZT1 image file format, at least for the format that Zoot understands. In 2011, Graagh created posts at Zoo Tek Phoenix that slightly expanded MadScientist's file format information. As far as I know, neither MadScientist nor Graagh have been in the ZT community for years.

".pal" files are just colors. Using a hex editor, this is what is shown for scenery/building/pals/blue8.pal:
09 00 00 00 FF 00 FF 00 1B 20 40 FF 1F 25 4A FF
25 2C 59 FF 2C 34 6A FF 33 3D 7C FF 3B 46 8E FF
41 4E 9E FF 50 5D B3 FF

The first 4 bytes say how many colors are in the file. These first 4 bytes have to be reversed, though. So "09 00 00 00" in the above example becomes "00 00 00 09" or "00000009". That shows there are 9 colors in the file. Each color uses 4 bytes. The first byte of each color is how much red is in the color. The second byte of each color is how much green is in the color. The third byte of each color is how much blue is in the color. The fourth byte of each color is either 00 or FF: 00 means that is the color used for transparency and FF means the color is an actual color. So in blue8.pal, the first color entry is "FF 00 FF 00". The "00" at the end means this is the color to use for transparency. The "FF 00 FF" happens to be the magenta color we are used to seeing when we extract images in Zoot. Whenever there is a transparency color in the ".pal" file, it will always be the 5th through 8th bytes in the ".pal" file, with the 8th byte being "00". As it turns out, though, ZT does not care about transparency colors. When it is in the ".pal" file, it is just for reference. The remaining 8 colors are 8 different shades of blue. When Zoot and APE create a ".pal" file, it seems the colors are ordered from darkest to lightest. That is not always the case for the ".pal" files that come with ZT.

The ZT image files themselves are more complicated. There are a number of formats for them. Zoot can handle the 2 simplest formats. APE tries to handle more, but often will crash rather than handle them correctly. animals/swcroc/y/stand/N is an example using the simplest format. Using a hex editor, the following is shown. A hex editor would not format the lines in this way, but I did so to make it easier to find the individual parts.
7D 00 00 00
1A 00 00 00
61 6E 69 6D 61 6C 73 2F 73 77 63 72 6F 63 2F 73 77 63 72 6F 63 2E 70 61 6C 00
01 00 00 00
21 01 00 00
17 00
11 00
0D 00
08 00
01 00
02   07 02 15 13   08 00
02   06 03 16 15 17   08 00
02   05 05 22 17 15 2A 34   07 00
02   05 05 22 2A 16 15 34   07 00
02   05 06 11 13 0D 0D 14 17   06 00
02   05 08 13 17 15 15 15 2A 17 22   04 00
02   04 0A 01 17 17 15 15 0F 17 17 2B 37   03 00
01   04 0D 03 2A 17 17 15 15 2A 2A 0D 15 2C 46 34
03   04 09 0D 13 0F 0D 0F 15 39 44 08   01 01 15   02 00
02   03 0A 2A 17 17 15 15 2B 2B 37 44 0F   04 00
02   01 0C 3F 17 17 11 17 15 2A 2D 2D 37 26 08   04 00
03   01 01 13   01 0A 17 16 15 2A 3D 2B 17 34 11 01   04 00
02   00 0D 26 26 15 17 15 15 34 37 15 0D 17 14 01   04 00
02   03 09 0D 0F 17 3A 28 0D 15 26 06   05 00
02   03 07 14 0F 13 2A 11 0D 26   07 00
02   03 07 0D 13 17 0D 01 08 28   07 00
03   03 05 0D 17 26 0B 01   01 02 2A 34   06 00
02   03 04 08 35 15 0D   0A 00
02   03 04 01 16 15 13   0A 00
02   03 05 01 01 14 17 15   09 00
02   04 04 01 01 0F 26   09 00
02   05 03 01 26 0F   09 00
02   06 02 26 02   09 00

The first 4 bytes are the animation speed, but these 4 bytes have to reversed. So "7D 00 00 00" in the above example becomes "0000007D", which is 125 in decimal. That is the amount of milliseconds ZT will wait before showing the next frame of the animation. With 125 milliseconds, ZT will show 8 frames per second, since 1 second has 1000 milliseconds. The next 4 bytes contain the length of the ".pal" file name, but these 4 bytes have to be reversed. So "1A 00 00 00" in the above example becomes "0000001A", which is 26 in decimal. Since that is 26, the next 26 bytes are the name of the ".pal" file to use. The next 26 bytes are "61 6E 69 6D 61 6C 73 2F 73 77 63 72 6F 63 2F 73 77 63 72 6F 63 2E 70 61 6C 00". Those are the ASCII characters for animals/swcroc/swcroc.pal, followed by a nul character. The ".pal" file names always end with a nul character in ZT image files. The next 4 bytes are the number of frames in the animation, but these 4 bytes have to be reversed. So "01 00 00 00" in the above example becomes "00000001", which means this animation only has 1 frame. After this, there is an entry for each frame of the animation. Since there is only 1 frame for this animation, that means the rest of the image file contains that 1 frame entry.

The first 4 bytes of a frame entry contains the length for the rest of the frame entry, but these 4 bytes have to be reversed. So "21 01 00 00" in the above example becomes "00000121", which is 289 in decimal. If you count the number of bytes after "21 01 00 00" in the above example, you will see there are 289 bytes. The next 2 bytes of the frame entry contains the image's height, but these 2 bytes have to be reversed. So "17 00" in the above example becomes "0017", which is 23 in decimal. So the image is 23 pixels tall. The next 2 bytes of the frame entry contains the image's width, but these 2 bytes have to be reversed. So "11 00" in the above example becomes "0011", which is 17 in decimal. So the image is 17 pixels wide. The next 2 bytes of the frame entry is how many pixels the image has to be moved vertically when displayed, but these 2 bytes have to be reversed. So "0D 00" in the above example becomes "000D", which is 13 in decimal. Therefore, ZT and Zoot will shift this image 13 pixels vertically when this image is displayed. The next 2 bytes of the frame entry is how many pixels the image has to be moved horizontally when displayed, but these 2 bytes have to be reversed. So "08 00" in the above example becomes "0008". Therefore, ZT and Zoot will shift this image 8 pixels horizontally when this image is displayed. Those last 4 bytes are what Zoot changes when Zoot is used to adjust an image's position. It is not known what the next 2 bytes represent in the frame entry; Zoot just skips them. So Zoot skips the "01 00". The rest of the frame entry contains the individual lines of pixels, which I arranged into the 23 lines of pixels for this image.

A line of pixels is divided into pixel sets. The first byte for the line says how many pixel sets there are for the line. Each pixel set has at least 2 bytes. The first byte says how many consecutive pixels are transparent. The second byte says how many consecutive pixels are not transparent. If that second byte is greater than 0, then there will be that many bytes following it, each byte being an index into the ".pal" file. The above example shows that the first line of pixels is represented by "02   07 02 15 13   08 00". The first byte of "02" says there are 2 pixel sets for this line. "07 02 15 13" is the first pixel set and "08 00" is the second pixel set. The first pixel set says there are 7 transparent colors, followed by 2 non-transparent colors, and the index numbers are "15" and "13" into the ".pal" file. Converting these index numbers from hex to decimal and adding 1, that means "15" is the 22nd color in the ".pal" file and "13" is the 20th color in the ".pal" file. The second pixel set says there are 8 transparent colors followed by no non-transparent colors. So the first line of pixels looks like this:
7 transparent colors - color number 22 - color number 20 - 8 transparent pixels.

Note that is 17 pixels, which happens to match the width of the image. This approach is used for the rest of the lines of pixels.

As mentioned above, there are other types of ZT image formats. All of the other ZT formats add 9 bytes at the start of the image file. The first 4 bytes for these other formats will always be "46 41 54 5A", which is "FATZ" when converted to ASCII. If those 4 bytes are reversed, they spell "ZTAF", which probably stands for "Zoo Tycoon Animation File". If the 5th through 9th bytes are all "00", then the rest of the image file is like the simpler format described above. Zoot can read this format, but it does not write those 9 bytes back out when it creates or updates a ZT image file. As another format, the 9th byte is set to "01" instead of "00". This says that the image file has an extra frame at the end. That frame contains the non-moving parts of an animation. The current Zoot does not handle that format. That is why when Zoot is used to look at some in-game buildings you can see the animated parts but not the non-moving parts of the building. APE tries to handle this format, but it makes an incorrect assumption that can cause it to crash. It assumes that no animated frame is wider than the non-moving frame. Another format is used for shadows that are used in a tank. Since shadows are a single color, a format was used to compress the image more. Neither Zoot nor APE understand that format.

Color replacement is not inside ZT image files. Those are done via the ".ai" files. Neither Zoot nor APE understand color replacement. There are different types of color replacement. One type is where we can change the color of some buildings and some other objects inside ZT. The other type is the color replacement used by guests and staff, where their clothes or hair are different colors. For color replacement of buildings, it is usually 232 colors (including transparency) that are not replaced. These are the first 232 colors in the building's main ".pal" file, and are also the 232 colors that are in the building's color.pal file. I do not know if ZT gets those 232 colors from color.pal or if it just gets them from the building's main ".pal" file. Usually there will be 2 parts of the buildings where colors can be changed. One part will have up to 16 shades of 1 color and the second part wil have up to 8 shades of a second color. For the first part, the 16 shades of color are the 233rd color through 248th color in the building's main ".pal" file and are the 16 shades of color that are in 1.pal. For the second part, the 8 shades of color are the 249th through 256th color in the building's main ".pal" file and are the 8 shades of color that are in 2.pal. For these color replacements, though, ZT probably does not use 1.pal, 2.pal, or the building's main ".pal" file. Instead, it would use the ".ai" file to see which ".pal" files should be used from scenery/building/pals.

Although it is theoretically possible to have a user made building with color replaceable parts, it would not be an easy thing to do because of the current lack of tools. We cannot force Zoot or APE to put certain colors from a ".png" file into color positions 233 through 256. Since Zoot and APE appear to sort colors from darkest to lightest, it might be possible to create a building with 256 colors and use the 24 lightest colors for the color replaceable parts. It is also theoretically possible to update Zoot or create some other tool to allow this, but that is not something I want to spend my time doing.

I do not know what type of new tool is being sought. The first part of that item in the post sounds like it is talking about configuration, while the second part of that item in the post sounds like it is talking about graphics. Graagh wanted to work on a tool, possibly a Zoot update, that allowed recoloring things without needing a graphics program. But that tool never came about. As for configuration, I did a massive update to APExp, called APExp 3.2, that avoids a lot, but not all, of the configuration problems caused by APE and previous versions of APExp. It also allows basing something on any in-game animal or object (things that are in ZT's objects folder, which also includes buildings, toys, and other things, although the default configuration would be scenery). I had made APExp 3.2 available to a few people to test it.

As for the comment about "animals/12345678/idle/idle.pal", it is not likely to have an idle folder for an animal and it is not likely to have an idle.pal file for anything.

[Jeff]

Thanks, your explanation lines up with what I had uncovered so far.

I'm writing a VB.Net program which will at least be able to draw the regular format.

I'm also keen on looking into supporting the more complex file as well. I remembered some information from MadScientist, but with your explanation I understand a lot better what he meant. The shadows - that part I'm not really interested in, although I might look into it some day.

My tool would be able to create palette files, and order the colors. That would be the improvement over ZOOT.

I got to figuring out how everything works for basic files yesterday, and I wrote some code already, I was just getting started on the reading/rendering of images.

In the ideal world, but I don't think it will happen, the tool would be expanded and you'd be able to pick any animal or object as well. Characteristics would be properly documented, and the file would not become the mess APE makes of it now.

[fern]

The updated APE that is in testing now does not make a mess of the files.

[Jeff]

Good to know :)

So how did this "update" work? Someone decompiled APE and used the original source or ...?

Update: my tool is currently able to read/render at least some basic ZT1 graphic files. 

[Jay]

APExp 3.2 is still the same program as it was previously. The changes were done via a massive amount of configuration. All animals and objects ".ai" files were updated to avoid triggering APE to cause its mess. Animations in a ZT image format that would cause APE to have problems were extracted and reloaded in a ZT image format it does understand. Animals resources were reordered in APExp to avoid some of the inefficiencies it created. Their limits were changed to be ranges that make sense. APExp 3.2 files were renamed to avoid conflicts with ZT, APE, and previous versions of APExp. In addition, ".ai" files were created for a number of ZT objects that do not have ".ai" files. Since the program is still the same as it was previously, there are still some inefficiencies. The biggest inefficiency is that it still unnecessarily copies animal sound files into the ".ztd". But it is easy for people to delete the ".wav" files from a ".ztd".

[Jeff]

I'm looking at the "FATZ"/ZTAF files.

I found something interesting, maybe it holds clues to. The drinkstand contains a "bg" folder, which contains - most likely - unused graphics. It's also present in the beta version.
There's a minor difference at the beginning of the file:
45 41 54 5A  00 00 00 00 00 7D ("bg")
vs
45 41 54 5A  00 00 00 00 01 7D (both "idle" and "used")

If I get it to work, I'm assuming this might more or less confirm Jay's explanation: the final version has an additional frame at the end. It's a great explanation you have here, Jay, although I wonder why no-one did anything with the "FATZ"-files. Also, if I look at the bathroom with Zoot, I don't see anything. For the restaurant, I only see the sign (idle) or the sign and smoke and a border (used). It should also be noted that it moves up and down a bit in Zoot. As if offsets are wrong.

Update: the "bg" graphics are those of the drink stand, as it appeared in the beta version. Colors are a bit screwed up though, since it uses the palette of the new version of the drink stand. So I can confirm: "00" as 9th byte = basic file format.

[Jay]

Yes, the 9th byte of "00" in the "FATZ" format means it uses the basic file format and the 9th byte of "01" in the "FATZ" format means it has an extra frame at the end of the file containing the non-changing parts of an animation. For the bathroom, all of the graphics are non-changing and are in the extra frame, which is why you do not see anything in Zoot for it. Similarly, you are seeing the animated portions for the restaurant in Zoot, while the non-changing parts are in an extra frame. I suspect the restaurant sign was also planned to be animated, but then they changed their minds. As for it moving up and down in Zoot, it sounds like you are using an older version of Zoot. That does not happen in Zoot 1.1:
http://www.ztcdd.org/DG/index.php?topic=4773.msg18197#msg18197

As for not doing anything with "FATZ" files, MadScientist did not understand that format. Graagh understood the part about an extra frame and he started changing Zoot to handle it when loading an animation. But that version was never finished and he did not make any source code available. That version also had the ability to show all of the colors in a ".pal" file when a ".pal" file was clicked. I have not added loading that extra frame into Zoot because that would just be a 1-time use, which I feel is not worth the effort. APExp 3.2 is able to show the restroom, the used graphics of the drink stand, the idle graphics of the restaurant, and either the idle or used graphics of all other in-game buildings, which means such changes are not needed in Zoot. The more important functionality would be to add the ability to save that extra frame, since that would make new animated things smaller. That would be a major effort, though, and I feel there are more interesting things to be doing.