Zoo Tycoon Community Download Directory

Quote from: JeffI was using man.pal + grizzlym from "global.ztd".  So I thought I was using the original animation - so I'm wondering, if you only installed ZT1, what that did look like - or was the image/bear color messed up in ZT1 for the attack animation? Or was the file replaced somehow later by its expansion packs? (which I generally thought would only "update" files by adding new versions in new folders). With the files you mentioned, it works flawlessly. But I'm still puzzling at the "original" files or how it was done....

When I use man.pal and grizzlym from global.ztd, the bear is brown for me in Zoot. I only get gray in parts of the bear if I try using grizzlym from global.ztd with a newer man.pal (ZUPDATE\global01.ztd or XPACK2\global05.ztd).

QuoteI was already wondering why Zoot also doesn't seem to do anything with the .ani files.

If one clicks on an ".ani" file in Zoot, Zoot will show the contents of the ".ani" file. Other than that, though, Zoot does not do anything with ".ani" files and it does not create ".ani" files.

I'm planning to add some nice little features:

Ready:
- quick access to default color replacements (palettes of 8 colors, palettes of 16 colors). If you are looking at the restaurant, the colors would be replaced right away in the preview image.
- instantly see color information on mousemove over the preview. You'll see the RGB colors and the index in the palette.
- for development purposes, I've also added the index of the color in HEX in the color palette views.

Soon:
- obviously the program should also be capable of writing at least the default format. I might add support for others, but it's definitely not on my current to-do-list.
- for export, you will be able to choose whether it exports the canvas (default 512x512, with the image centered at all times) or cropped versions of every frame.

- batch conversion: This is something I miss a bit in ZOOT.
* ZT1 graphic to PNG: select a folder structure and every ZT1 graphic file will be written out. "N" => "N_0001.png" (the last digits referring to frame index).
* PNG to ZT1 graphic: select a folder structure and every PNG will be converted to a ZT1 graphics file. Multiple PNG's (frames) will be written to 1 ZT1 file.
I'll check with Vondell, who renders graphics in Blender, to see if the default name should be something else.

- rotation fixing.

Regarding the dolphin's shadows: it seems like I'm onto something. Despite it being a detail, I think I have most of the format covered already, in theory. Trying out to figure the details. I might not be able to do it 100% correctly, but I should be close! What I find a bit strange: of the "ssurf"-animations for the dolphin, only some seem to use the compressed format, most stick to the defaults?

Update: seems like I managed to render the graphics in the compressed format, although they might be 1 pixel off. No big deal.

Latest version currently looks like this:

Quote from: Jeff- batch conversion: This is something I miss a bit in ZOOT.
* ZT1 graphic to PNG: select a folder structure and every ZT1 graphic file will be written out. "N" => "N_0001.png" (the last digits referring to frame index).
* PNG to ZT1 graphic: select a folder structure and every PNG will be converted to a ZT1 graphics file. Multiple PNG's (frames) will be written to 1 ZT1 file.
I'll check with Vondell, who renders graphics in Blender, to see if the default name should be something else.

Zoot does allow loading all frames at once for a single ZT image file, but not for multiple ZT image files.

For a default ".png" file name, I would use the various folder names as part of the name. For example, if there is a folder called MySillyPack, some of the ".png" file names that might be created from it:
MySillyPack-animals-FEDCBA98-y-stand-S-0001.png
MySillyPack-animals-FEDCBA98-iczebra-N-0001.png
MySillyPack-animals-FEDCBA98-lsmzebra-N-0001.png
MySillyPack-animals-FEDCBA98-plzebra-N-0001.png
MySillyPack-objects-FEDCBA97-SE-N-0001.png
MySillyPack-objects-FEDCBA97-used-SE-0001.png
MySillyPack-items-myitem-N-0001.png
MySillyPack-fences-FEDCBA96-f-idle30n-SE-0001.png
MySillyPack-fences-FEDCBA96-SE-N-0001.png
MySillyPack-paths-FEDCBA95-icon-N-0001.png
MySillyPack-paths-FEDCBA95-idle-20-0001.png
MySillyPack-freeform-mymap-N-0001.png
MySillyPack-research-myprog-N-0001.png
MySillyPack-scenario-scn98-pic01-N-0001.png
MySillyPack-terrain-myterr-N-0001.png
MySillyPack-awards-myaward-N-0001.png
MySillyPack-guests-man-benzsit1-SE-0001.png
MySillyPack-staff-tour-m-speak3-S-0001.png
MySillyPack-ui-main-devmenub-G-0001.png
MySillyPack-water-freshes-top-N-0001.png
MySillyPack-food-chum-full-SE-0001.png

Batch loading could create the various folders as well.

If your program looks for ZT image files, the names to look for are probably: N, n, S, s, E, e, W, w, NE, Ne, ne, NW, Nw, nw, SE, Se, se, SW, Sw, sw, G, g, H, h, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20.

Those are indeed the most common names. But I'd just look for files without an extension.

I think the import/export would just be generated in the same folder as the original image. Shorter filenames, no need to restructure things, and if  you want all the files, there's still plenty of ways to do so. Maybe I'll add the long names as an option, but it's definitely not my preferred way.

This is very exciting! I particularly look forward to Jay's MySillyPack!

Been working on write-capabilities. I've nearly finished that functionality. It will only write the most basic image format, at this point that is.

I've also designed a mock up of what the batch conversion-window would look like (ZT1 <=> png), and I've thought a bit about making  Jay's thing possible too. I'll probably add command line capabilities.

So you would have something among the lines of (only as a potential thing, it  might be different:)
ZTStudio.exe /convert /from:PNG /to:ZT1 /file:"<full path and filename>" /overwrite:yes /cleanup:yes

That would convert 1 ZT1 Graphic file to at least one .PNG-file (remember, one PNG file for each frame). It would overwrite any existing files and it will remove the "source" file.
You could easily generate a whole list of these instructions in an Excel-file. Although I'll recommend to just use the Batch Conversion feature within the program, which will be a lot easier.
I've added both "from" and "to" in case other formats are added at some point (currently not planned, I'm fond of .PNG and think they should replace .JPG ).

QuoteIt is not known what the next 2 bytes represent in the frame entry; Zoot just skips them. So Zoot skips the "01 00".

I only had a look at the "bamboo" file, but... maybe this is the number of the frame? I'll have to check out files with a few frames to see if that's the case.


Not a priority, but nice to have ideas which I might implement:
- try to generate 1 palette for 4 views. (ideally, the user made sure the four views only use 255 colors. Easiest way: put them together in one image file, switch GIMP to 255 colors).
- for shadows: use the compressed shadow format.
- generate the complicated format (+1 frame).
Obviously it doesn't matter much in filesize, but it might have an optimizing effect for the game.

Quote from: JeffI only had a look at the "bamboo" file, but... maybe this is the number of the frame? I'll have to check out files with a few frames to see if that's the case.

Those unknown 2 bytes do not appear to be the frame number, checksum, or length. For all 4 restaurant icons, it is "D8 9A". For all 4 gift shop icons, it is "B0 DE". For the restaurant idle NE view, which has no animation frames, it is "D0 10". For the restaurant idle NW view, which also has no animation frames, it is "D0 2C". For the first frame of the restaurant idle SE view, it is "F0 15". For the first frame of the restaurant idle SW view, it is "00 16". For the first frame of the restaurant used views, they are "40 5A", "D0 36", "10 4A", and "30 42". For the first frame of the gift shop idle views, all of which have animation frames, they match the restaurant idle views: "D0 10", "D0 2C", "F0 15", and "00 16". But the first frame of the gift shop used views are different: "30 73", "D0 4A", "C0 12", and "D0 3E". And the bathroom (which does not have any used views) idle views are all "00 00".

We'll see if we ever figure it out then.

I've greatly improved the rendering for certain animations. I'm now caching the frames, and they're only repainted if there have been changes (e.g. color palette applied).

The datagridview for the color palette is still very slow, still hoping to replace it, but I think I might release an alpha version of the tool anyhow for those who want to look at certain files and easily export them (think restaurant etc).

I was happy yesterday that I managed to create an identical copy  of the  bamboo's SE-view, but it seems like something's wrong in my code at the moment when I try to save images with multiple frames. The hex doesn't match up, mine seems to be a tad longer (too long in fact) compared to the original ZT1 file. Yet, Zoot is able to show it, but it suddenly drops 1 pixel. So I'm thinking something is wrong with the offsets - which would also make sense: my file is 46kb while the original is 43kb, and it seems like I have 8 colors while ZT1 has 7 colors. (the first frame seems to have been rendered properly, identical even; so I think it might have to do with the way width/height and offsets are stored).

I'll probably leave this project alone for  a few days now, I'm getting a bit tired of looking at hex values and comparing files etc.

Update: I just found the nasty little bug. The file length matches now.

Planned: a short break for now. I've seen enough hex the last few days. I still need to check on the X/Y-offsets compared to the 'center', which seems to be a little different, but I should be able to figure that out too. It's only another minor adjustment. Next: a userfriendly interface to add/delete frames, proper rotation fixing. Once that's right, things should move on fast.

Oh, and I'm not sure whether I mentioned this: currently the PNG's are exported in the canvas size, which is 512x512. You'd think it would make for big file sizes, but it's actually a  very small file due to all the transparency. ( 3KB for a frame of the SE-view of the grizzly bear). I'll probably add two more export options when it comes to canvas size: 'take width/height of the biggest frame', 'crop to relevant pixels').


Potential previews (depending on whether I'll take a break or not.):
Alpha 1: what I've got so far + graphics properly created.
Alpha 2: includes the batch conversion and command line options.
Alpha 3: re-ordering of the color palette. By this version, I also hope to show the color palettes faster.

Beta 1: this would be the hopefully stable version of the tool. I'll listen to feedback, but it's likely this beta - except for some bug fixes - will be very close to the final version.

Version numbering: 1.0.2015.0118 - this will tell you the main version (1.0), and when it was released (18th of January, 2015).


Also, I think I might create new versions of 2 of my previously designed creations.
- umbrella table (I remember I made a fix for it years ago, although I might have a better implementation)
- grand stand with speaker booth. -4 places, but cheaper in upkeep. Maybe animated... Especially if I could work out how to write the complicated format - but I think that could be easier than I thought :)

I've also noticed a few guest animations which should actually be combined with their object (bounce tys, ringtoss, swing...). Maybe I'll make it possible to combine 2 ZT1 Graphic files.

Quote from: Jeff on January 17, 2015, 05:37:35 PMNot a priority, but nice to have ideas which I might implement:
...
- generate the complicated format (+1 frame).
Obviously it doesn't matter much in filesize, but it might have an optimizing effect for the game.

Just for your information... There was a user made animated building where the ".ztd" size was 3.75 MB. I created a program to convert an animation from the simple format (and where the image size and the offsets are the same for all frames) to the extra frame format. Then I ran the program today for the 4 views of that animated building. The resulting ".ztd" size was 2.01 MB. For other animated buildings and scenery, depending on the particular animation frames, the savings percentage might be better or worse than for this animated building. But this shows that savings could be significant for some things. That does not mean your tool needs to have that feature. Most user made buildings and scenery are not animated.

Quote from: Jay on January 20, 2015, 01:41:18 PM
Just for your information... There was a user made animated building where the ".ztd" size was 3.75 MB. I created a program to convert an animation from the simple format (and where the image size and the offsets are the same for all frames) to the extra frame format. Then I ran the program today for the 4 views of that animated building. The resulting ".ztd" size was 2.01 MB. For other animated buildings and scenery, depending on the particular animation frames, the savings percentage might be better or worse than for this animated building. But this shows that savings could be significant for some things. That does not mean your tool needs to have that feature. Most user made buildings and scenery are not animated.

This is indeed a significant gain. But rather than just filesize, I'm curious if we would see performance increasements, and how fast we'd see them, with how many downloads etc. Just one building won't make a difference I guess. So basically you've coded something similar, but for private use?

Performance improvements are difficult to quantify because different computers have different characteristics. If a computer is fast enough and has a lot of memory, then it is unlikely to notice the performance improvement, even when there is one. I believe ZT loads graphics at 4 times: when ZT starts, when a zoo or map is loaded, when an object is unlocked, and when an object is put in a zoo. ZT loads different types of graphics at each of those 4 times. The most is probably when ZT starts, and that can be noticeable. For example, it is noticeable that the original ZT starts much faster than MM or CC. But I suspect the various optimizations mentioned do not affect the graphics that are loaded when ZT starts. I believe ZT loads configuration files (".cfg", ".scn", ".ai", ".uca", ".ucs", ".ucb") at 3 times: when ZT starts, when a zoo or map is loaded, and when an object is unlocked. To find those files, it has to look at all directory entries in all ".ztd" files. So when we use fewer ".pal" files, fewer ".wav" files, and fewer ZT image files, that will speed up looking through the directory entries. I believe that is noticeable when there are lots of files inside lots of ".ztd" files, especially on slower machines with less memory.

File size is often important for some of us. Some people, including fern, are on dial-up. Also, web site administrators have to worry about how much disk space is used on the servers, how much bandwidth is used, how long backups take, and how much space a backup takes up. So we often are concerned about making large files smaller. We might change things to use in-game sounds or graphics directly instead of via copies. If 2 objects use the same user supplied sound or use the same unlock file, we might combine them in the same ".ztd". If an object has 2 or 4 views that are the same, or if we want foliage or a rock to have decorative, exhibit, and dead versions, we might have the configuration refer to the same graphics instead of copies of the graphics. For the animated building I mentioned in my previous post, it was the designer that was concerned about the size. It actually started at 7.37 MB, with idle and used graphics. The designer decided that the difference between the idle and used graphics was not that great and decided on their own to move the used graphics to idle and remove the used graphics. That reduced its size to 3.75 MB. Since there was still concern of the size, I wrote that program so that I could convert the animated building to the extra frame format.

Yes, I coded something that creates a ZT image file in the extra frame format. But it is difficult to say whether it is something similar. It is also difficult to say if it is for private use. I often code things for specific projects. I do not mind sharing my programs or source code with others. If I feel others can benefit from it, I release my programs and source code. That is why the Animal Configuration Checker, Zoo Object List program, and Zoot 1.1 are available. They were all things I wanted for myself, but I felt others could also benefit from them. But it is often difficult to determine what others might find useful. Although I continued to use Java for Zoot 1.1 (and for a slightly enhanced version), I prefer using either C or sh for coding. For C, I use the gcc compiler, which has versions for MS Windows, Linux, and Macs. gcc is free and open source. In the case of MS Windows, I use a MinGW version. Although I also have a MinGW version that allows creating executables that work in both 64-bit and 32-bit versions of MS Windows, I usually use a MinGW version that creates executables that works only in 32-bit versions of MS Windows, just because that happens to be the way I initially set up my computer. So the program that creates the extra frame format probably only works in 32-bit versions of MS Windows. It also only works for animations where all frames have the same size and offsets. The program does not have a graphical interface. Although the program could be run from right-clicking on a ZT image file, I run the program in Command Prompt. Because of all of this and because not many designers create animated buildings and scenery, I am not sure yet how useful it would be to others. If I feel others want it, even in its current form, I will release it. A number of years ago, I created another program that looked at ZT image files. Its purpose was to help give names to recolored files. It looked at the first frame of a ZT image file, listed all of the colors (in hex format) used by the image file along with how many times each color was used, and looked at a file that had color names in it (from the List Of Colors article in Wikipedia) to see which color name was the closest to the most used color. Others seemed to prefer coming up with names on their own rather than use the program since people often use names that might not be technically correct but are recognizable by others. For example, a lot of people often say the background used for ZT graphics is "pink" or "hot pink", even though technically it is "magenta". So I never released that program, although I still sometimes use it (or a similar program where I get the color value for a specific pixel in an image). I also mentioned I have a slightly enhanced version of Zoot 1.1. For a specific project, I needed to get ".png" files from a lot of ZT image files. So I added a command line option to Zoot 1.1 that would extract a ".png" file for a specified ZT image file. Then I used a ".bat" file that ran that version of Zoot for all of the image files I wanted. Again, I did not know how useful that would be for others, so I have not released it, at least not yet.

Well, I have a webhost with unlimited band width and nearly 5 GB of data. For a very cheap price. So even with hundreds of downloads, I didn't assume that would make the big difference in hosting.

It seems similar, especially when you add support for .bat-options, like I mentioned. Although I'll also include it in the program's user interface.

How are you getting on Jeff? I am still ridiculously excited about this! The idea of an extended repertoire of tools that we can use to create zt items is so far above my expectations of the development of our capabilities that, following on from Jay's (unexpected) expansion of the capabilities of zoot and APExp, this (also unexpected) is just epic!!

I'm thinking Jay could actually be ready to release the updated Zoot-version already?

As for ZT Studio, the core is finished, but I haven't worked on it much the last few days. Needed a small break from the project.

Yesterday, I wrote the basic "convert ZT1 file into .PNG-files" feature. I did that first, because now I know how I'll implement the conversion from a series of .PNG-files (based on filenames) to a ZT1 Graphic.
"SE" would be split into "SE_0000.png", "SE_0001.png", ... "SE_0010.png". => Basic graphics.

For the ones where we mentioned that it might use an extra frame, e.g. the restaurant, there are two options:
- you can either have the option above - and the last frame would be rendered as SE_extra.png,
- or choose to render all frames with that extra frame as background.

There's also support for loading a ZT1 graphic as background - and also rendering that in each frame.
The use? You can combine the "used" object animation (rope swing) and the animal's toy animation (orang utan swinging rope) and see the complete animation.

I also want to add support for "rotation fixing".
You will be able to apply the offset from one frame to all other frames, and from one frame to all frames in another graphic.

And as for exporting .PNG-files: I'm also planning to add the few options I mentioned ("export to canvas size" (currently 512x512), "export to relevant pixel area of frame" (top left/bottom right pixel determine height/width), "export to relevant pixel area of graphic" (similar, but takes all frames into account).


Ultimately, ZT Studio should be a replacement for ZOOT and definitely speed up the graphic parts.
If the game was more recent, I'll probably aimed for it to replace APE - allowing all kinds of configurations.

I actually have a question: for the case where you just let ZT Studio create the ZT1 Graphic based on a series of files - would the ideal scenario involve the rotation fixing and setting of the animation speed in the tool, or would you prefer to set it in an .INI-file for each graphic?

Have you figured out the two "mystery bytes" yet Jay?
It's the only thing which is unknown to me.

At this stage, I can load any file - including the compressed format, and write any ZT1 file - except for the compressed format.
It's identical, safe from the mystery bytes.

I'm currently taking a few looks, trying a few calculations, but I don't get it yet.
Assumption: it's *frame* related? Yet, for the *few* examples I picked so far, it seems to be the same for every single frame in a ZT1 Graphic.

- Orang utan: m, f, y : all animations (?): " C8 74 ".  Number of bytes for each frame is different. Number of bytes for each graphic file is different. They all share the same palette.
- Orang utan: icforngu: " 88 BB "
- Orang utan, icorngut: " 80 A5 " > .ani file has same x0, x1, y0, y1 as icforngu. So the bytes are not related to that either.
- Orang utan, lsorng: " 80 A5 " > same as above.
- Orang utan, lsorngut: " 80 A5 > same as above.
- Orang utan, plorngutan: " 10 FD  "

Not sure if this actually refers to 1 single thing or 2 things.
- Restaurant, icon SE: "D8 9A"


SE-views:
- guests, boy, bounce: all 00 00.
- guests, girl, aqbounce: all F4 C6
- guests, girl, ringtoss: all F4 C6
- guests, girl, ringwin: all F4 C6 - these 3 files all have their palette in common
- guests, male, grizzlym: all 00 00 ?
- objects, asibars,  idle & used: 01 00
- objects, asirope, idle & used: 01 00
- objects, bamboo, idle: 01 00
- objects, bathroom, idle: 00 00
- objects, burgstnd, idle, 10 4A
- objects, burgstnd, used,
* 0: 00 89 + all frames not listed:
* 1: 30 89
* 13: A0 89
* 14, 15: 40 89
* 16: C0 E4
* 17: 40 E4
* 18: A0 E3
* 19: 10 E3
* 20: 80 E2
** 21: 70 E2 = "extra" frame
- objects, asirope, icon, NE & NW & SE : B0 E8. But SW: 10 F4.  All are using the "i" (icon.pal?) file.

I'll see if I can somehow get some statistics on the graphic's specifications, on width, on height, on offsets, on total bytes, on number of colors in frame, on number of colors in graphics, in number of pixels; the actual value of the mystery bytes...

It also looks like it's got nothing to do with the place it needs in game.

Water fountain: the animation has "01 00" for each frame.
Restaurant used: has some different variations for the mystery byte. Some changes are minor and I thought I spotted what one byte might mean, but I'm wrong. Others are bigger: 10 (hex) vs 30 (hex). Color replacement seems also excluded.