Jay, Who is that handsome new designer from Illinois, who has fascinated many ZT1 fans with his funny quips and perky responses? :giggle Just kidding.
Real question: Is there an instruction anywhere that shows how to actually make my own .pal file for ZT1 UCA's?
Regards,
JohnRN1
The final step in making a new ".pal" file is loading a ".png" file in Zoot or APE, which will then make a ".pal" file from the colors in the ".png" file. The ".png" file would be a graphic image of some sort that is created in a graphics program. Using Devona's approach for creating a new set of colors, one would use the graphics program to change each color shade one by one in an existing graphics image that was extracted from an ingame animal. Using Dr. Rick's approach for creating a new set of colors, one would use the graphics program to create a rectangle filled with color shades ranging from the lightest color shade in one corner to the darkest color shade in the opposite corner. But there currently are no guides describing step by step how to do either of these approaches in a graphics program.
Thanks Jay,
Several designer's of ZT1 animals have made new animals and recolored new animals for their new uca's and I was wondering if any of these designer's had put up an instruction on actually making their own pal files or even instructions on changing the size of ingame animals. :read
I hope that you found the information I sent you helpful JohnRN1 :eggwhistle :faint
Quote from: johnrn1Several designer's of ZT1 animals have made new animals and recolored new animals for their new uca's and I was wondering if any of these designer's had put up an instruction on actually making their own pal files or even instructions on changing the size of ingame animals.
Previously, designers assumed other designers knew how to use graphics programs. So they concentrated on guides that were specific to ZT, such as using APE or Zoot, or how to move ".pal" files, or how to adjust configuration files created by APE, or how to delete unnecessary files created by APE. But a number of us are novices when it comes to graphics programs and realize it would be useful to have guides concerning using graphics programs for ZT work. As you saw, dr rick is trying to help in that direction. What will make those types of guides difficult to create, however, is that different people use different graphics programs and any such guide will be specific to a single graphics program.
hum - good point that Jay. I suppose I am in a somewhat unusual position in that I use Ulead photoexpress to do most things. However I use photoshop at work and also Gimp to do some manipulations, so actually, I could write about how to do things in all three! Trouble is I use whichever program does best whatever it is that I want to do!! :eggcrazy
Same here Rick. I use a very old Paint Shop Pro....No5, I think. I also use Gimp. Occassionally I even use Paint. It all depends on what I am going. Gimp does have a good tutorial that can be found here (http://gimp-savvy.com/BOOK/index.html).
WoW!! :eggroll :egggrin I am on a plane to Graphics school with a stopover at NASA to give them some pointers on their next mission. :rofl
Yes, Dr.R. Your files were very helpful. Also, Fern mentioned about using pal files from objects/scenery. I never thought of that. I didn't know that making a pal file with a graphics program would be so complicated.
I think I will stick to the simple things in life, and go back to watching "Psych" on TV. :egggrin :Kittydance
lol!! I think that I may have made it look more complicated than it actually is! :eggwhistle That's why I need to revisit the tutorial before it gets published. :eggyes
I like complicated :eggcrazy
I suggested you make some scenery to go with your animals. But I do believe genki used some scenery pal files in getting the colours for some of her peacocks.
:sorry I should have said, it gave me an idea of trying out pal files. Unfortunately, I couldn't find the one that I realy wanted. :eggtung :eggcrazy
To a certain extent it really is trial and error and you can get some surprising results. I tend to treat it as a fun game to see what interesting things happen. Which reminds me there is one set I want to try on an animal and keep forgetting.
QuoteJay
Webmaster
Member
Online
Posts: 1516
Re: Ask ZT1 design questions here
« Reply #2 on: August 11, 2010, 10:48:13 PM
The final step in making a new ".pal" file is loading a ".png" file in Zoot or APE, which will then make a ".pal" file from the colors in the ".png" file
This, I don't quite understand. I have been using zoot to show me what a new animal looks like after inserting the new .pal file in the animals file (replacing the original .pal file). But, how does zoot
create a pal file from a png. Or APE for that matter.? :doh
Zoot and APE just look to see what colors are in the ".png" image and save those colors in a ".pal" file.
Here is a simple example. Suppose we have a ".png" image that contains 1 row of 3 pixels: white-black-white. These colors are represented by numbers. White is represented by 16581375 and black is represented by 0. So the ".png" image actually is 3 numbers: 16581375 0 16581375. Zoot and APE see that the numbers 16581375 and 0 are used in the ".png" image and they will save those numbers in the ".pal" file. These numbers in the ".pal" file and in the ".png" file are in computer form rather than human form. So you cannot look at them with a text editor such as WordPad and expect to see the numbers in that format. Humans normally use base 10 for numbers. Base 10 uses digits 0 through 9. Computers use base 2 for numbers. So they only use digits 0 and 1 or, more precisely, "off" and "on". So computers see the base 10 number 16581375 as 111111111111111111111111. Because of how long that is, programmers use base 16, called hexadecimal, which uses digits 0 through 9 and letters A through F. So that number in base 16 is FFFFFF. This becomes especially useful for colors. The reason is that the first 2 letters represent how much red is in the color, the middle 2 letters represent how much green is in the color, and the last 2 letters represent how much blue is in the color. If you look up "List of Colors" at Wikipedia, it will show these hexadecimal numbers for the different colors, and it shows Black is 000000 and White is FFFFFF. Hex editors, such as XVI32, allow seeing these hexacimal numbers inside such files. The start of a ".pal" file is always the same; it starts with: 00 01 00 00. Although I do not know for sure, I believe a ".pal" file has darker colors before lighter colors. So, for example, the next part of the ".pal" file would be for black. The ".pal" file puts the parts of a color in the opposite order than what Wikipedia shows. So the ".pal" shows how much blue first, then how much green, and then how much red. In any case, the next part of the ".pal" file for color black would be: 00 00 00. The ".pal" file always puts FF after each color. After that FF, the ".pal" file would contain the parts for white: FF FF FF, followed by another FF. The size of a ".pal" file is always 1028. So the rest of the ".pal" file can be filled with anything. Therefore, putting it all together, a hex editor would show something like the following for the ".pal" file of our example:
00 01 00 00 00 00 00 FF FF FF FF FF 00 00 00 FF 00 00 00 FF 00 00 00 FF ...
Jay you just made a "simple" example into a confusing example. From your original quote "the final step..." you make it sound like zoot or APE makes a pal file. This is only true, if you are inserting new graphics into ape or zoot.
Obviously, you made it sound like I put any old png into ape or zoot, and poof! out pops a pal file.
:rofl 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.
:clap2 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? :rofl :rofl Just kidding. I know there's no pal slot. Is there? :rofl :rofl :rofl
I wonder if that is in the "Help" in Zoot. I haven't read it. I learnt to use Zoot before it was written. :giggle
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.
I'm just after the pal file right now. :praise2
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.
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.
i'm all in favour of bumping this kind of old topic! i await the answers and resulting questions with interest... :TY
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 *
(http://zootekphoenix.com/forums/uploads/monthly_01_2015/post-105497-0-62239200-1421000765_thumb.png)
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...
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.
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.
The updated APE that is in testing now does not make a mess of the files.
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. :cheers
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".
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.
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.
I'll have to check, I really thought I had Zoot 1.1 from here.
The reading of a palette is easy, that was the first bit of code I wrote, didn't take a lot of time at all.
I currently have the following functionality in three short evenings:
- reading/showing color palette;
- reading/showing basic ZT images (non-FATZ);
- reading/showing FATZ-file with 9th byte 00;
- rendering a frame based on HEX values - which I just used in an experiment where I rendered the background for the drink stand.
On my list:
- figuring out the first part (animations), then add proper rendering
- export to png
- import png, create simple ZT image + .pal-file
- now, the thing which would be new: the user should be able to determine the order of the colors in the palette before they're written out. The user will also be able to create a 8 and/or 16 color palette. This should, after all those years, allow for the color replacement ability.
- batch processing, where a series of PNGs get converted to ZT graphics or the other way around.
wow! i just knew this was going to be exciting! I will have to read it multiple times to make any sense out of it, but if the outcome is an ability to make buildings that can be colour changed, that would be great.
Please remind me (whatever happened inside my head a while back seems to have deleted the relevant information), can we make researchable buildings?
Although we can create researched buildings, they would be hacks and would conflict with other researched buildings of the same type. So we avoid them. Sometimes people want to make researched buildings so that it can show an icon for a program, such as a "Birds of Africa" icon. But instead of creating a researched building just for that purpose, it would be better to show that icon instead of the generic building that is shown in the top left corner of the building info window in ZT.
ok thanks... i don't like hacks...
I'm actually still surprised, with all this information that was available, especially with that last part about the ZTAF-files, that no one simply improved upon ZOOT.
If successful, I hope to be the first to release that type of building. Not sure if it will be something of my own or a co-project. That would make for another "first" after all those years, after the very first custom tank filter for MM for anyone (which was actually much less challenging). Soon after that, I am planning to release my tool, and maybe the source code. Not sure about the code though.
i can understand why you might be reluctant to release the code, but if we had the code for ape and zoot we would have been able to accomplish far more than we have, so my plea would be, please release the code with a very clear instruction that anyone who releases an altered version makes very clear homage to you and your work!
i am very good at graphics so if you would like to work together on a first release i'd be delighted and honoured to help...
jay massively improved zoot in particular ways that the designers of the time (me included) were asking for - zoot 1.1 is brilliant at doing what it does - stable and virtually unlimited in its capabilities within its design parameters.
Credits go to MadScientist for creating ZOOT, which is an amazing program, and Jay for the elaborate explanation on the ZTAF-files
The requirement for color replacement will be: a graphic with 16 clearly colored pixels in the right 'darkness' for replacement (eg pink) and probably another 8 in another color which isn't used in other parts of the graphic. But I'll see.
so is that 16 different brightnesses of pink? or 16 pixels all the same? I am so literal I have to ask for clarification of almost everything :duh I'm really interested in this development as I had been wondering if we knew how to do this as I was working on a couple of new buildings which started out with red roofs and now have sea blue roofs but would have been an obvious candidate for colour changeable roofs
It's a recommendation, but: just 16 pixels of any 'same' color preferably. You will manually need to select the color sets of which the color will be replaced. You could theoretically pick all sorts of colors, but it might be easier to use just shades of pink for example.
It should just be a color which you generally don't use in the image itself if you want to make it easier for yourself.
If your building doesn't contain any blue except for your roofs, you could also just have 16 different types of blue which will be replaced in any color by ZT1.
So in your case: if you manage to limit your buildings to 16 types of blue (maximum, less is not really an issue), it should be fine.
Update: my tool can open and render files like the restaurant, and its palettes.
It will also allow you to just open color palettes.
One complication I didn't think of: for example, the drink stand and restaurant use one main palette for idle and used animations. So you might need to use the same animation for a building in use at this moment. I'm not sure yet where ZT1 checks for the .pal files which are related to the color replacement (color.pal, 1.pal, 2.pal). I'm hoping it just looks in the same directory. Then we can have 4 palettes for "idle", and 4 other ones for "used". This should make it easier for us.
Dr Rick, here's an example of what I mean. I loaded the "used" restaurant, which my tool can render completely. I've also opened up the two separate files (1.pal, 2.pal).
In this example, you can see how Blue Fang used grey and blue as the colors which are replaced.
(http://s28.postimg.org/82s36p3el/20150114_temp.png)
With this tool, I also looked at the guests. Most animations are indeed some sort of reddish shirt and purple pants. Those colors are defined in for example shirts.pal and pants.pal (16 color palettes). These colors are replaced by the colors in the palettes specified in guests.ai . The index for these colors is what triggers the color replacement.
Unsupported at this point: icons. I need to look into the format. It's also similar, but different, and I need to figure out how to detect the differences and some other stuff (blank lines).
wow! :fireworks
OK, seeing that is very helpful. So the range of blue and grey tones (colours not used anywhere else except the colour change regions) are the ones that zt knows it can change to colours defined in other palette files...
so is there one standard zoo tycoon-wide set of colour change pal files to give the range of colours to which you can change it, or is there a set of defining palette files unique to each object?
Quote from: dr rick on January 14, 2015, 04:07:47 AMif we had the code for ape and zoot
...
jay massively improved zoot
We do have the code for Zoot, which is how I was able to improve it. The code is available at DG:
http://www.ztcdd.org/DG/index.php?topic=4773.msg18198#msg18198
As that post says:
QuoteI would like to thank Madscientist for creating Zoot and for making the source code available. Even before the changes I added, to me Zoot is the most important utility to be created for Zoo Tycoon, even more important than APE itself. From my perspective, Madscientist will always be recognized as the creator and most important contributor of Zoot.
Quote from: dr rickso is that 16 different brightnesses of pink?
...
so is there one standard zoo tycoon-wide set of colour change pal files to give the range of colours to which you can change it, or is there a set of defining palette files unique to each object?
As Jeff mentions, he needs some way to say which colors in an object should be put into color slots 232 through 255. So that is why he is saying there would need to be 24 colors that are not used elsewhere in the images. That is just the approach he chose. Whatever 24 colors are used, although those will be the colors shown in Zoot and APE, those might not be the colors that will be shown in ZT. I attached 2 images showing which colors will be used in ZT. The first image, colors16.png, shows the colors that will be used for color slots 232 through 247. If a person clicks on the blue button in the color replacement screen for the first replaceable part, ZT will use the 16 colors shown in the blue16 row for colors 232 through 247. If a person clicks on the yellow button in the color replacement screen for the first replaceable part, ZT will use the 16 colors shown in the yello16 row for colors 232 through 247. The second image, colors8.png, shows the colors that will be used for color slots 248 through 255. If a person clicks on the blue button in the color replacement screen for the second replaceable part, ZT will use the 8 colors shown in the blue8 row for colors 248 through 255. If a person clicks on the yellow button in the color replacement screen for the second replaceable part, ZT will use the 8 colors shown in the yello8 row for colors 248 through 255.
Quote from: JeffI'm not sure yet where ZT1 checks for the .pal files which are related to the color replacement (color.pal, 1.pal, 2.pal).
Concerning the ".pal" files, ZT does not use 1.pal or 2.pal. It also does not need color.pal if the ".ucb" is changed to use the original ".pal" instead of color.pal. I attached a user made "Blue Stage Door" to show this. It is similar to the in-game stage door but is blueish instead of whitish for the concrete. It also defaults to a light blue frame border and a gold curtain and star. It allows color replacement in-game. Of course, since there is no tool yet to allow making the needed ".pal" file, I had to make the ".pal" file manually.
Quote from: JeffUnsupported at this point: icons. I need to look into the format. It's also similar, but different
In-game icons should be the same as the simple FATZ format where the 9th byte is "00". In-game icons do not use transparency. So their i.pal file does not have the transparency color in it. User made icons have to have transparency only because APE and the current Zoot assume the top left pixel represents transparency.
Well... I'll have to check. I was able to read things like the restaurant's graphics, but for the icon, my program got stuck. I'll have to look into it if it's a bug in my rendering or a minor difference in those sort of graphics (which would surprise me).
I'll also have a shot at the shadows you mentioned (are you referring to the 's'(subswi) folders of MM animals?) and what I'm currently missing about guests and color replacement (the colors for animals which attack the guest, look off. If you use Zoot , you should see what I mean if you take a look at the animation of a guest being attacked by a grizzly. It's greyish instead of brown. So some form of color replacement is also applied to the bear in the guest animation, although I missed it yesterday where it's defined.)
Hm, I was assuming that ZT1 knew which parts to replace by reading those palettes.
One feature I'll add (most likely tonight) is to see a preview of color replacements in my tool. I'll change the name of the temporary title "Zoot .NET" to "ZT Studio" or something, to avoid confusion between the programs.
".ucb"? User-created building? I didn't know you already managed to create something like that manually! Great! :)
Update:
- it looks like the issue with icons seems to have been something random.
- ZT Studio can show a preview of color replacement. Steps: select building graphic (eg restaurant), pick one of the color palettes ZT1 used (e.g. blue8.pal, blue16.pal)
- ZT Studio renders the Beluga's shadow perfectly - I'm assuming Jay is referring to another type of shadow?
Also... What exactly are the x/y-coordinates in the .ani file referring to?
Looking at the guests and the grizzly animation. Interesting in guests.ai. grizzlyf = grizzlym (animations).
[BehaviorSet\bCaughtBygrizzlym]
; caught by male grizzly bear
f = fPlayWithSound(grizzlym, bear_roar)
f = fPlay(getupall)
f = fShowPredator()
[BehaviorSet\bCaughtBygrizzlyf]
; caught by female grizzly bear
f = fPlayWithSound(grizzlyf, bear_roar)
f = fPlay(getupall)
f = fShowPredator()
grizzly.ai:
[m\BehaviorSet\bCaughtGuest]
; the time of animation below should match bCaughtBy in guest
f = fPlayTime(stand,4)
The stand animation is not of a bear standing *up*, but just standing there. So no idea why it would need to match "bCaughtBy".
Also, unrelated, it's interesting to see they use quotes here:
[m\BehaviorSet\bChasePrey]
f = fMove(prey,0,"run",68)
Quote from: JeffI'll also have a shot at the shadows you mentioned (are you referring to the 's'(subswi) folders of MM animals?)
...
- ZT Studio renders the Beluga's shadow perfectly - I'm assuming Jay is referring to another type of shadow?
The beluga shadows use the simplest format and are not a problem. The dolphin shadows are an example that causes problems. For the dolphin/m/ssurfswi views, those are supposed to be the shadows when the dolphin swims at the surface in a tank. They cause APE/APExp to crash and Zoot cannot display them. Looking at the bytes for that SE view, the 2 bytes representing the height of the image are "20 80", which reversed are "8020" in hex. When converted to decimal, that would either be 32800 or -32736, neither of which would be good values for the height of an image, which is why it causes problems for APE/APExp and Zoot. I have not looked to see if that highest bit can simply be ignored in Zoot, making it "0020" in hex instead of "8020" in hex. Graagh believed that highest bit being set tells ZT to use a different type of format for the shadows, but he may have just been guessing. It certainly must tell ZT something. But it is currently unknown if that is something we need to take into account.
Quoteand what I'm currently missing about guests and color replacement (the colors for animals which attack the guest, look off. If you use Zoot , you should see what I mean if you take a look at the animation of a guest being attacked by a grizzly. It's greyish instead of brown. So some form of color replacement is also applied to the bear in the guest animation, although I missed it yesterday where it's defined.)
You are using the wrong combination of grizzlym and man.pal. You should use the most current of both. The most current of grizzlym is in ZUPDATE\global01.ztd and the most current of man.pal is in XPACK2\global05.ztd. When more animals were created for the expansion packs, more colors were needed in guests/man/man.pal to have those expansion pack animals attack the male guest. But they were limited to 256 colors total. So they had to redo previous animal attacking male guest animations. The color replacement is only for the man in the animation, which would change the color of the clothes and hair to match those of the man being attacked.
Quote".ucb"? User-created building?
Yes, ".ucb" stands for User Created Building. We no longer use ".ai" files for buildings or anything else that use "bldg....cfg" files. We use ".ucb" files for buildings, vending machines, rides, games, shelters, toys, trash bins, scenery with sounds, and, as shown above, for scenery with color replaceable parts. The ".ucb" has the same contents that the ".ai" would have. The advantage of the ".ucb" is that we do not need a "bldg....cfg" file.
QuoteAlso... What exactly are the x/y-coordinates in the .ani file referring to?
ZT might not use them for typical animations. The reason I believe that is because APE does not set those coordinates when someone loads animations into APE for an existing view. Those coordinates are just a copy of what was used as the base animal or object. ZT did use those coordinates when displaying icons, but the expansion packs changed how those coordinates are used. In the original ZT, before we had Zoot, I changed those coordinates for icons I wanted to display. Although that worked in the original ZT, the icon positions changed in the expansion packs. So now, we use the same coordinate settings for icons that are used for in-game icons, when our icons are the same sizes. When I have to create an ".ani" myself for other graphics and I feel the positioning is critical for what I am creating (such as cliff walls), here are notes I created for setting them: 'The x0,y0 in ".ani" files appears to be the location of the center point touching the ground for the largest image, though with minus signs in front of the numbers. When there is a choice, use the point that you get to first along the bottom edge from the left. x1 = image width + x0. y1 = image height + y0. The image width and height might be for the canvas rather than the actual image.'
QuoteI haven't found a grizzlyf folder yet. Looking for it, although it might simply not exist?
No, there is no grizzlyf folder. All animations where a guest is caught by an animal are only for male guests. They probably felt it was not worth the effort to create more animations for something that should not happen often.
Quotegrizzly.ai:
[m\BehaviorSet\bCaughtGuest]
; the time of animation below should match bCaughtBy in guest
f = fPlayTime(stand,4)
The stand animation is not of a bear standing *up*, but just standing there. So no idea why it would need to match "bCaughtBy".
The animal animation is turned off while the animation from the male guest is turned on, which shows the animal attacking the male. So in that sense, it does not matter what animation is used in the bear ".ai" at the time. It is the time that is important. They want the bear to stay inside its "bCaughtGuest" behavior set until the male guest animation finishes playing. Once the male guest animation finishes, though, the animal animation turns back on. So that is when they want the bear to be doing its "stand" animation.
QuoteAlso, unrelated, it's interesting to see they use quotes here:
[m\BehaviorSet\bChasePrey]
f = fMove(prey,0,"run",68)
Those quotes are not necessary. I remove them in animal configuration I do. There are a number of inefficiencies like that in the configuration. I took care of them in APExp 3.2.
Quote from: Jay on January 15, 2015, 03:40:46 PM
You are using the wrong combination of grizzlym and man.pal. You should use the most current of both. The most current of grizzlym is in ZUPDATE\global01.ztd and the most current of man.pal is in XPACK2\global05.ztd. When more animals were created for the expansion packs, more colors were needed in guests/man/man.pal to have those expansion pack animals attack the male guest. But they were limited to 256 colors total. So they had to redo previous animal attacking male guest animations. The color replacement is only for the man in the animation, which would change the color of the clothes and hair to match those of the man being attacked.
I 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....
Thanks for all your notes Jay! I was already wondering why Zoot also doesn't seem to do anything with the .ani files.
i'm looking forward to having a play with ztstudio, although it might take an awful lot of help to get me to understand how to use it because my brain does not work properly any more (legacy of three weeks on a painkiller that cut off a load of synapses that it was not supposed to).
if you do want me to come up with the graphics for a new building for your first release, just let me know and i'll start thinking about it - this deserves something really special!
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:
(http://s22.postimg.org/s0zybjl75/alpha_20150116.png)
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! :wub2
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!! :praise2 :praise2 :wub2 :blush
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.
Sounds like it is nearly there Jeff! :eggyes :praise2
I've been thinking about what you said about APE... A couple of things initiated my train of thought. The original software (complete collection) is still widely available (at least in the UK) for example in supermarkets and game shops - it is now branded UBISOFT, but all they have added is a new install front page, everything else installs identically (I know this because I have temporarily lost my original disk and I'm currently using the UBISOFT version bought from my local supermarket a year or so ago). I think that we could actually gain community users and downloaders if we could offer them more exciting downloads. If you were to put in the considerable amount of work required to make an improved APE (able to assimilate larger images, cope with the more complex animation formats, configure buildings, shelters, toys and everything that zoo tycoon can offer, plus maybe pal editing facilities), I would undoubtedly use it for years to come to make some really exciting things that are (at the moment) incredibly difficult to make (toys for example).
It takes so long to configure everything that all of my most ambitious animals remain unreleased - I just can't remember what I have done for long enough to actually get them finished. If a new APE meant I could properly configure (for example) my flying cranes and toy-using macaws (which fly into their nest hole in a tree), then these and many more things I and other active designers such as Devona have half finished could be released, reinvigorating the community and giving us something to 'market' to get new users and encourage former users to have another go.
Anyhow, that's my sales pitch done - I'd love you to think about it, and if the answer is 'yes' I shall be forced to change my default text colour to purple ! (sorry Jay!). If the answer is no, I shall still be a happy bunny :bunny7 with the capabilities of zt studio!
Quote from: JeffHave you figured out the two "mystery bytes" yet Jay?
No, I do not know what those mystery bytes represent. But I feel there is no need to know. Whenever graphics are loaded into the official APE, it always sets them to "00 00". You can have the official APE create a new project from something in-game, extract the images, load those same images back in without changes, and those 2 bytes become "00 00". So if the official APE can use "00 00", we can as well.
Quote from: JeffAll are using the "i" (icon.pal?) file.
Yes, any time there is an i.pal file for an in-game object, that file contains the colors for the object's icons.
Quote from: dr rickI would undoubtedly use it for years to come to make some really exciting things that are (at the moment) incredibly difficult to make (toys for example).
It takes so long to configure everything that all of my most ambitious animals remain unreleased - I just can't remember what I have done for long enough to actually get them finished. If a new APE meant I could properly configure (for example) my flying cranes and toy-using macaws (which fly into their nest hole in a tree), then these and many more things I and other active designers such as Devona have half finished could be released
Toy configuration is not much different than shelter configuration. They are easier to configure than most guest buildings. The difficulty is in the graphics of the animal, since all toys have the animal seen using the toy at some point. Even what might seem to be simple animal graphics can be time consuming to work correctly. APE does not do a good job at loading images with the proper offsets. Normally we do not care about that with animals. However, sometimes we do care when it comes to having the animals use toys. For example, Taz's Harp Seal and Ribbon Seal can use 3 toys: a raft and 2 different ice floes. The seals use existing animations when on those objects. But because of APE not loading images with the proper offsets, the seals originally looked like they were mostly off of the objects instead of mostly on the objects. So the positions of those seal animations had to be adjusted. But since those animations were changed and since those animations were used for other purposes as well, that meant the positions of all seal animations had to be adjusted in Zoot, otherwise it would look like the seal was jumping from one animation to another. So it took me a long time to adjust the positions of all animations for those seals. I feel the bigger problem with getting things released is there are not enough people testing things. Animals especially take a long time to test properly. Smarter APE/Zoot/ZT Studio/whatever tools certainly have the potential of helping with that. If tools were smarter at doing the offsets, that might reduce the need to adjust them in most cases. If tools were smarter at pointing out problems, such as pointing out if 1 view of an object or animal has a different number of frames than another view, that would reduce the amount of time checking for those problems. If 1 folder had all of the graphics needed for an animal and the designer just had to click 1 button to load them all in, that could reduce mismatch problems and out of order problems, as well as reduce the amount of time needed to load the animal or object.
Ah Rick you did and had released most of the canids of the world for a start. It was while doing the canids you were experimenting with colours and pal files.
You also did a set of birds - 7 of Dr Rick's birds combined. Dunlin, Eurasian Curlew, Bar Tailed Godwit, Pied Avocet, Scarlet Ibis, Glossy Ibis, Sacred Ibis
Amazon Bush Dog
Arabian Oryx
Arabian Wolf
Asiatic Wolf
Atlas Bear
Australian Kelpie
Australian Terrier
Barbary Jackal
Barbary Lion
Black Backed Jackal
British Wolf
Cascades Mountains Wolves
Caspian Sea Wolf
Dark Colored Dingo
Desert Coyote
Dhole
Dingo
Eastern Wolves
Egyptian Jackal
European Canids
Great Plains Wolf
Himalayan Wolf
Hungarian Reed Wolf
Iberian Wolf by Dr. Rick
Indian Jackal
Indian Wolf
Italian Wolf
Mackenzie Valley Wolf
Marsupial Lions 1 by Dr. Rick
Marsupial Lions 2 by Dr. Rick
New Guinea Singing Dog
Nile Crocodile
Northern Coyote
Queensland Heeler
Red Wolf
Russian Wolf
Senegal Jackal
Side Striped Jackal
Steppe Wolf
Tibetan Wolf
Toto
Transylvanian Wolves
Tundra Wolf
Vancouver Island Wolf
Warrah or Falklands Islands/Malvinas Wolf
ZTUF Dingo
Actually, there only is one main problem in my humble opinion. In the original development, developers overlooked that the game would be so popular. I do have a very concrete plan on how it would allow users to extract an existing item, then give it a proper name of their own [perhaps, if the community c/would agree, check against a list of known used object IDs], better information on each characteristic and all, but currently I don't see the point (anymore) of such a time investment. With ZT Studio, I want to eliminate all possible graphic problems, and as for configuration... with basic knowledge you can just extract and alter the files. I never used APE to create something besides graphics. Also not the "improved" versions.
So for each new toy or nice attraction for an existing animal or guests, you need to update those files.
This could partially have been resolved if the most recent official versions of content were extracted to let's say the dlupdate-folder (not the graphics, just the .AI-files) and mods were applied differently (only adding lines to things). It would also have complicated cleaning up after an install more complicated though.
I currently have a personal expansion pack I'm working on. Don't get too excited. What I've merely done so far, is updated the latest versions of Taz's animals, added some beta stuff etc, and configured everything as it would have been done by Blue Fang. I was also hoping to get more familiar with Blender and create animals from there, but honestly: Vondell (check his posts at Zoo Tek Phoenix) had exactly the same idea, and he was faster and more successful at figuring out everything already. He's quite brilliant at it, and I've been discussing a few things with him.
Jay, you made some good suggestions too. I was already thinking of some sort of validations, mainly when it comes to an individual file, but it might indeed be good to have an easy overview and perhaps validation of number of frames in each graphic.
As for the mystery bytes, I'm not sure. I hope they are unrelated to the frames with an extra animation (but the good thing: the orang utan does not have an extra animation and has values anyhow). I was also thinking they might be just a signature for the graphic artist, but that would make no sense. One would expect it to be on the graphic, and what would the point be....
With some future updates in mind, I can already tell you that the minimum requirement will be .NET Framework 4.5.
I'm willing to provide an early version, but:
* I just implemented rotation fixing and haven't tested it properly yet.
* The batch conversion seems to work from the command line, but the interface still needs to be added.
* still need to add the feature in which you actually have a ZT1 grid (regular and maybe slope) as in ZT1.
i'm looking forward to playing with it... :fireworks
Any idea if the mystery bytes are exclusive to the ZTAF format? (including the ZTAF-format with only 1 frame)
an idle question - will this be able to create anything other than the simplest animation format (like ape and zoot) or will it facilitate the creation of animations with one additional frame containing the common material?
are there any other more complex animation formats (for example for objects containing a non-animated portion, a portion (such as a repeated flashing light) that has only a few animation frames and a portion with many animation frames (for example an aquarium with swimming fishes in it)? or any other animation formats about which I don't yet know?
Quote from: JeffAny idea if the mystery bytes are exclusive to the ZTAF format? (including the ZTAF-format with only 1 frame)
In Reply #23 of this topic, I gave an example of the in-game crocodile. That example shows that it does not use the ZTAF format but has mystery bytes of "01 00".
Quote from: dr rickare there any other more complex animation formats (for example for objects containing a non-animated portion, a portion (such as a repeated flashing light) that has only a few animation frames and a portion with many animation frames (for example an aquarium with swimming fishes in it)? or any other animation formats about which I don't yet know?
No, we do not know of any other animation related formats.
I think 01 00 is actually a sort of default. I'd like to see if other things than 00 00 and 01 00 are found in non-ZTAF files or not.
makes sense...
dumb question time... what is a ZTAF format file?
There are a few variations in the file format. With ZTAF, Jay and me are referring to files which start with the letters 'FATZ'. But a lot of the file's "content" has to be read in reverse, so it becomes ZTAF, and we're just guessing it probably stands for Zoo Tycoon Animation File or something like that.
Current status: nearly fully troubleshooted the output of a graphic file after reading it.
I'm going for the restaurant, which covers some special issues (large image, extra frame)
My output is identical except for 2 things:
- each pair of mystery bytes per frame is 01 00 in my version (I actually contacted a former Blue Fang member but no reply so far, if I'll ever get one);
- a lot of instances of 'F9' are 'ED' in my version - I'll check that out, but I think it will be the same color in the color palette (with ZT Studio taking the first occurrence and the original restaurant taking the last occurrence (not an issue at this point);
Update: fixed some issues, and made sure even the largest ZT graphics are supported. Footprint going up to 18!
A small update. After a few days off, I mostly tweaked the program so it's faster now.
I managed to read and write complicated graphics like the restaurant, but I'm currently stuck with some graphics. I tried to open an old graphic of my own from very long time ago, and found out it didn't work. Next, I tried to open the United States Flag, and it seems to have a similar problem.
I'm currently investing the issue based on the SE view of the US Flag. This is supposedly the end of the first frame, and then you see the width/height and offset for the next frame.
...
01 ff 00 01 ff 00 01 ff 00 01 ff 00 01 ff 00 01
ff 00 01 ff 00 01 ff 00 01 ff 00 01 ff 00 01 ff
00 01 ff 00 01 ff 00 01 ff 00 01 ff 00 01 ff 00
01 ff 00 01 ff 00 01 ff 00 01 ff 00 01 ff 00
Somehow we also end up with these bytes, added to the frame:
02 06 00 98 00 07 00 1a 02 06
Now, this is the next frame, starting with the number of bytes:
1f 10 00 00 ff 00 ff
00 cc 00 7f
...
What's sure: those last 10 bytes are counted for in the number indicating the number of bytes in this frame.
I'm currently assuming that there's a whole bunch of 1 pixel sets per line (01), offset 255 pixels (FF), draw 0 colors (00).
The problem starts here:
02 - two blocks in this line.
06 00 - offset 06, 00 would be very unusual here: no colors. This usually means end of line.
98 00 - again, very unusual, and this would mean that the 07 would refer to 7 blocks in one line.
If I look at the image I can export with Zoot, the 01 FF 00 patterns at the end are just the transparent lines under the flag pole, until the image has a size of 255 x 255 pixels.
So that leaves us with another set of currently mysterious bytes.
If I make sure the program just renders all bytes before those 10 bytes, it renders fine.
This is the case for the US Flag and the personal graphic.
The graphics have nothing in common. One is small, the other is big. One only has 1 frame, the US flag consists of multiple frames (but no "extra" frame).
The only thing my small graphic and the large US Flag have in common, is that they were probably both made by APE.
I'm not sure what they represent. Maybe a date/creation time?
Or maybe, something else those images have in common: neither are cropped, like ZT1 graphics usually are, to a rectangle which only contains relevant pixels.
Both of these graphics have a few border lines which are fully transparent.
If I decide to just skip them, the image seems to render perfectly.
Zoot can also perfectly render the same version of the US Flag.
* 58 00 95 05 3a 00 e4 00 50 is the series of bytes for my graphic (a version of an umbrella table, a couple of years ago).
For this set, I can guarantee that the image is rendered perfectly at first sight. The bottom contains 4 pixels, and it definitely wouldn't widen up to (05) colored pixels again after an offset of (95).
Any clue, am I overlooking something?
intriguing, but I'm afraid I'm not much help... Jay will have some thoughts I'm sure :wub2
I did some quick experimenting, I think it will be related to time.
I fired up APE 1.1, and I used the same .PNG for both SE and NE view. In the same graphic, they're identical (except for referring to a different .PAL file).
When I added a second object (based on something different, but I'm sure that it makes no difference), there were small differences.
* 15 B0 64 00 0D CF 5F 4B 12 B0 ( created close to 18:38 GMT+1 time, 16th of February, 2015)
* 15 B0 63 00 8C CF 5F CA 12 B0 ( created close to 18:38 GMT+1 time, 16th of February, 2015)
And a third one, based just like one of the above on the zoomap:
* 37 FF 5A 00 01 16 FA 1C 30 FF ( created close to 18:52 GMT+1 time, 16th of February, 2015)
Shortly after each other, so only minutes and seconds should be different. I think we're close to finding out the mystery.
Perhaps something which is related: has anyone ever found out whether the 8 character HEX string APE generates, is that random? I mean, I tried 4 objects within 5 minutes, and each object starts with "23......" .
Quote from: Jeff on February 16, 2015, 11:12:11 AMThe only thing my small graphic and the large US Flag have in common, is that they were probably both made by APE.
I'm not sure what they represent. Maybe a date/creation time?
Or maybe, something else those images have in common: neither are cropped, like ZT1 graphics usually are, to a rectangle which only contains relevant pixels.
Both of these graphics have a few border lines which are fully transparent.
If I decide to just skip them, the image seems to render perfectly.
Zoot can also perfectly render the same version of the US Flag.
From madscientist's article on the ZT1 Image File Format:
"This *should* be the end of the frame. However, some ZT1 images have an extra 9 or 10 bytes at the end of them, and I have no idea what they represent. Zoot ignores them with no apparent ill effects."
So it sounds like you just skipping them is the correct approach. I do not know what they represent. They do not look like they are time related to me because your examples look too different for such a short period of time. Maybe they mean something to APE. But it is also possible they are garbage bytes created by APE. We know APE creates garbage inside ".ucs" and ".uca" files (although readable garbage). So it would not surprise me if it creates garbage bytes inside ZT image files.
Quote from: Jeffhas anyone ever found out whether the 8 character HEX string APE generates, is that random? I mean, I tried 4 objects within 5 minutes, and each object starts with "23......" .
We do not know the format of that APE ID. But we know that the start of the APE ID represents number of seconds. I feel their algorithm for APE IDs is not good. The number of seconds wraps around too soon. We have seen a number of times where 2 people create things and they happen to get the same APE ID, which causes a conflict. I just used APE 1.1 to create 3 objects based on the in-game Bighorn Statue. I waited 1 minute before creating the second object and waited 5 minutes between the second and third objects. These are the 3 APE IDs that were created: 24BEF026, 24C2B057, and 24D57026. Based on that, it looks like the first 5 characters represent the number of seconds, since 24BEF and 24C2B in hex are 60 apart, which would be 60 seconds or 1 minute, and 24C2B and 24D57 in hex are 300 apart, which would be 300 seconds or 5 minutes. Based on that, it looks like the first 5 characters would wrap around a little over every 12 days. Although I do not know, the last 3 characters might represent a fraction of a second, maybe the number of microseconds wrapped to fit 3 hex bytes. In theory, it is unlikely for 2 people to create something at the exact microsecond. The problem is that most computers cannot handle that fine of a resolution. So we often see repeats at the end, such as the two "026" ends in my test. Therefore, I would have used a different algorithm for an APE ID. I would have chosen the first character randomly. Then I would have used the last 7 characters for the number of seconds, which would not wrap for 8 years, although I would have reversed those 7 characters so that the APE ID changes more rapidly near the beginning.
I hadn't seen it in the other official ZT1 Graphics I used, and we know the flag is an APE-test, so it's probably the right thing to ignore them.
You're right, Jay. Whatever meaning they might have - it's not significant.
It's curious to see that the flag wasn't cropped to the relevant pixel area though.
Also, there could have been a small level of compression applied if they kept the flag pole in the last frame.
I'll do an experiment soon with the Umbrella table I mentioned, to see if it's easier to make objects with color replacement in-game.
i look forward to hearing how that test goes, and to being able to play with this tool!
This umbrella table is not the one that got canned by Blue Fang.
The design has been recycled from one of my very old designs, but I thought it was a perfect test case.
- rotation fixing: works.
- reordering color palette: works.
- using a ZT1 background image in the preview to make sure it lined up with the regular picnic table: works.
It's also helped me fix another issue one would have had in the rotation fixing process of extremely small images (with width and/or height 1px)
Also, since all views here share the same palette, it made me remember to add a feature to have multiple graphics use one palette file.
I also think that there should be an option to remove all colors from the palette file which are not used in the graphic.
I'm pretty psyched about this new object to use. Just for my own use, I made it so that it can be used by guests properly :)
Here you see the test case in ZT1. Just to be clear, it's one object, NOT 4 objects having different colors.
(http://zootekphoenix.com/forums/uploads/monthly_02_2015/post-105497-0-02353600-1424617659.png)
I'm currently testing the batch conversion feature with some graphics someone provided of a brand new animal.
However, my program is unable to generate an image. Each frame was limited to 256 colors (including 1 transparent), but it seems that frame 1 and frame 2 consist of slightly different palettes - so it's more than 256 colors.
Are there compression methods in place in APE and Zoot to avoid this, or do they just complain as well?
APE has color reduction built in. Sometimes it crashes in the process, but it usually works. I do not know how well it does the color reduction, though. For example, I feel it is best not to use dithering in the color reduction process for ZT animations. But I do not know whether or not APE uses dithering, since I have not looked at it that closely. Zoot does not do color reduction. It gives an error if there are more than 256 colors in a single animation.
There are different approaches to reducing the number of colors for a ZT animation. I use GIMP, which is free and open source. I load the frames of an animation as separate layers in a single image, then have GIMP reduce the number of colors without dithering, then save the individual layers into ".png" files to load in via Zoot. dr rick also uses GIMP to reduce the number of colors for a ZT animation, but he uses different functionality in GIMP. He has GIMP remember the colors in the first frame of an animation as a color palette, and then has GIMP map the rest of the frames of an animation to that color palette. The free and open source programs ImageMagick and GraphicsMagick (which is a fork of ImageMagick) have color reduction functionality, including whether or not to dither. Color reduction is very complicated to implement. ImageMagick has a very long article about the complexities. So rather than trying to implement color reduction, it might be worthwhile if a ".bat" file was created that uses ImageMagick or GraphicsMagick to do the color reduction. Until that is done, if ever done, designers would have to use GIMP, APE (if the animation is not too large), or some other tool to do the color reduction for the animation as a whole.
I use Gimp too for this though in a slightly different way (as Jay explained briefly above, and as originally suggested about a million years ago by Jay). I choose an image from the animation set that appears to have all the colours in it that I want and index this to 256 colours (as Jay said, sometimes the first image in the sequence, but other times I use another image if the first image is missing some key colours that ought to appear). I then save that palette in gimp and give it a name, then index each of the other images in the set using that saved palette so that all the images are indexed to have only the same 256 colours in.
This is slightly more time consuming than Jay's method, but it works for me. I have set up Gimp so that a series of keyboard shortcuts (e.g. ctrl1, ctrl2 etc) do the common operations that I use in sequence so I can just hold down the control key and click 1, 2, 3 etc. to carry out these kind of routines.
I always use APE for small images to avoid the faf of having to do this with GIMP, and it rarely crashes for me. I did quite a lot of work on APE's palette creation a while ago (whilst trying to predict how it would make a palette from a particular raw image, and not entirely succeeding) and I can tell you that the colour reduction involved in the palette creation algorithm for the icons and the animations is not the same because if you insert the same raw image as an icon and as an animation, then the palette file created does not give exactly the same result - there's an article somewhere about that, showing the results of my research. I used the in-game horse to test palette files on, and the palette files from icons and animations had the same sort of range of colours in, but were not the same.http://www.ztcdd.org/DG/index.php?topic=5460.0 (http://www.ztcdd.org/DG/index.php?topic=5460.0) and also http://www.ztcdd.org/DG/index.php?topic=5461.0 (http://www.ztcdd.org/DG/index.php?topic=5461.0)
Thanks. Shortly after my last post, and since I also like GIMP for basic stuff, I thought of exactly the same method Jay describes. I prefer that one in general, since it generates a palette based on *definitely* all colors in the graphic. I'd combine it with the BIMP plugin.
I really dislike APE. In fact, ever since I could use Zoot, I relied on it. APE makes such a mess of everything...
Just fixed a few more offset bugs, tweaked the program a bit more, tested the batch conversion (non-command line version), added the feature APE and Zoot have which consider the top left pixel to be transparent ...
This morning I already posted a brief "how to" on Zoo Tek on how to use ZT Studio to quickly generate a graphic of which the color can be replaced, but it came to my mind that I was lucky with my graphic. Basically it's just a mirror, so I only loaded the first view - to get exactly the same color palette at my disposal, then replaced the frame's image with a mirrored version, and saved it again. I had to use a hex editor to make it use the same .pal-file (currently it still takes the graphic's name and just adds '.pal', similar to APE and Zoot). So I'll probably add another feature, where you can select multiple images and just create one color palette out of them [given that the number of colors does not exceed 256 colors, otherwise I'll just refer to a how-to document which describes how you can do it with GIMP ).
I am really looking forward to playing with this Jeff :eggyes
When a version of it is ready for testing, once you have posted it, please would you be kind enough to put a link to it here (or post a copy of it here!) :praise2 :angel3 :blush :wub2
A private version will be shared with Vondell soon for further, very specific testing. After all, he's been kind enough to share some stuff with me too.
A public version with some brief how-to's should be available sometime soon after that.
The updated ape that is in Testing now does not make a mess of everything.
Quote from: fern on February 27, 2015, 08:33:06 PM
The updated ape that is in Testing now does not make a mess of everything.
I'm really curious about that version. And to see what's actually been changed :)
I think that is the version of APE that I'm using and it is utterly WONDERFUL!!!! :luv :fireworks :praise2 miles better - it has more stuff available in it owing to Jay's clever jiggery-pokery and also there are very few corrections needed to the ucs file which is brilliant (all I do now is delete the excess pal files and then in the ucs, ad any lines like cSwims that I want, check it [no errors found so far] and remove one line of space at the start and end of the file - that is it! - I have not yet tried creating an animal with it so I can't vouch for how well it does that, but if it is anything like the ucs files created, it will no longer have all those idiotic foibles like creating multiples of eververything multiples of everything multiples of ... - you get the picture!)
I do. It's why I always started from the original .AI file, and just copy-pasted and adjusted it, since a lot of characteristics were missing in the original APE. It was far less time consuming to have proper files. Only thing needed was adding the language blocks / changing the ID 19000. Although I generally work with a DLL file. I keep wondering why people kept up with (the original version of) APE, and most of its reincarnations so far.
Quote from: Jeff on February 28, 2015, 06:55:35 AMI always started from the original .AI file, and just copy-pasted and adjusted it, since a lot of characteristics were missing in the original APE. It was far less time consuming to have proper files. Only thing needed was adding the language blocks / changing the ID 19000.
More than that is needed to convert an original ".ai" file to a ".uca", ".ucs", or ".ucb" file.
But not that much. The language bits, replacing the ID, changing extensions.
lol! sometimes i use the APE ucs and uca as my starting point and other times i use text from the AI and paste it into the APE generated file to create the finished ucs, uca or ucb file. For animals I usually change so many items in the uca that it makes no difference what I start with, it is still going to take a LOT of editing!
Quote from: JeffBut not that much. The language bits, replacing the ID, changing extensions.
I also prefer to start with the original ".ai" files. And I encourage other designers to look at original ".ai" files even if they use APE or APExp to make a ".ucs" or ".uca" file. And for some objects it can be simple to convert from an original ".ai" file to a ".ucs". But the reason I am pointing out that it is not always a simple process is because there have been problems in the past. So I do not want others reading these posts to assume the process is always simple. For example, if someone copies a non-zero cEstheticWeight line from an official ".ai" file, either directly or via a version of APExp before version 3.2, and has cNameID set to 19000, the game will crash. Even worse, the game does not crash right away, so it might appear to work when testing the object in-game. Designers should try to understand the configuration in ".ai", ".ucs", ".uca", ".ucb", and ".cfg" files. That way problems can be avoided. Blue Fang has a lot of typos in their files. So understanding the configuration will also help to fix these typos for user made things. For APExp 3.2, I made extensive changes to avoid these various types of problems. At the end of this post, I have a list of the changes I made. This list was just for my benefit as I worked on APExp 3.2, so some of the things might not make sense to others. Some of these things are to make the objects or animals work properly in ZT. Some of these things are to fix typos. Some of these things are for efficiency. Some of these things are to make the things work in APE. Although that might not seem useful if one is creating something new without using APE or APExp, that can be useful later if it is found the internal ID conflicts with something made previously or if someone wants to have an object or animal liked by some other animal and there is not a letter near the beginning of the internal ID.
Here is the list of my notes for when I worked on APExp 3.2:
Add "APEXP" to start of ".ai" file name.
Remove all lines that start with ";" or "//" or ">>".
Remove blank lines within sections.
Except for a space right after =, remove spaces and tabs from end of lines.
Reduce multiple spaces to single spaces.
Have the Type setting match the ".ai" file name.
Upper case to lower in Type, f, m, y, cPlaqueImageName, cListImageName settings.
Upper case to lower for internal name in Icon settings.
Add [f/Characteristics/Integers] section with cPrefIconID line.
Copy cPrefIconID line from adult section to [y/Characteristics/Integers].
If [cCompatibleAnimals] is not right after [m/Characteristics/Mixed], add it.
Set animal's ID in [cCompatibleAnimals] to cGenus ID, or delete both if there.
Remove pairs of lines where 2nd line of pair is "v = 0".
Remove any lines in [cSuitableObjects] section that do not have "=".
To eliminate duplicates, put [m/Animations] lines in order.
Remove any lines in [m/Animations] section that do not have "=".
Copy [m/Animations] section to [f/Animations] and [y/Animations], if none.
Make all action names to left of = match in [m/Animations] and [y/Animations].
Make all animation names to right of = in Animations sections be ones in ztd's.
Change [Sounds] section to link directly to in-game sounds.
For any ".wav" in [Sounds] more than once, change fPlayWithSound lines to use 1.
Remove sound lines in [Sounds] that are not used, possibly matching softness.
Move all [AmbientAnims...] sections to before first BehaviorSet section.
Remove "m\" (or "f\") from all [m\BehaviorSet\b...] and [f\BehaviorSet\b...].
Have all behavior set lines end with ")".
Insert "," between number and "b" in any fPlaySetProb (such as "5b" to "5,b").
Change ", " to "," and remove " in BehaviorSet sections.
Remove any "," that are just before ")".
Change "(Baby1,40,bBaby2,40" to "(bBaby2,80".
Change fPlay(.,..) to fPlayTime(.,..) if .. is number or fPlayWithSound(.,..).
Change fPlayTime(...) without comma to fPlay(...).
Change fPlaySetTerrain(...) without comma to fPlaySet(...).
Change fPlayWithSoud to fPlayWithSound.
Change fTrot(keeper) to fFollow(keeper).
Make sure all behavior actions and sounds are in Animations and Sounds.
Remove all [.\BehaviorSet\b...] sections not in . fPlaySetProb + match adult's.
If all y\BehaviorSet not matching adult are fPlaySetProb, make [y/AmbientAnims.
Split into 2 sections any y fPlaySetProb line with more than 9 commas.
Remove all [y\BehaviorSet\b...] sections that have fEnterBuilding.
Delete land+water y bEscaped1, bChasePrey, bRunFromPredator, bRun if have fTrot.
Change y fTrot(0,0) to fMove(0,0,.,..) with . as action + .. as speed.
Change any y fMoveWithSound(.,..,...,....,.....) to fMove(.,..,...,....).
Change any y fMoveReverse(.,..,...,....) to fPlayReverse(...).
Change any [y\BehaviorSet\bEatenEgg] to [BehaviorSet\bEatenEgg].
Change fPlayStopAtEnd(egg_hatch) in bEatenEgg to fPlayStopAtEnd(egg_break).
If no y\BehaviorSet, add [y\BehaviorSet\bIdleY] with "f = fPlay(idle)" at end.
Fix any warning or error shown by animal configuration checker on uca.
At end of ".ai", add [defaultLCID] section with "LCID = 1033" line.
Remove any "cIsSpecialAnimal = 1" and "AvailableAtStartup=0" lines.
Remove any empty [Global] section.
Have Icon lines go to actual icons and using internal name used in cfg.
Change [Member] of "developer" to "scenery" and remove any "zoogate".
Have [Member] contain animals, foliage, rocks, or scenery.
Remove any [FilterSounds] section.
Remove any cAdultChange, cCapacity, cChildChange, and cEnergyChange lines.
Remove any cAlternatePanelTitle and cHideRegularInfo lines for scenery.
Remove any "cAutoRotate = 0" and "walkable = 0" lines.
Remove any cAvoidEdges line for scenery.
Remove any cCommerce, cDefaultCostIndex, and cIsColorReplaced lines.
Remove any "cDeadOnFlatWater=0" and "cDeadOnLand=0" lines.
Remove any cDecayedHealth, cDecayTime, and cFilterCleanAmount lines.
Remove any cDeletable and cUsedThought lines.
Remove any cDirectEntrance, cDrawUser, cSetUserFacing, and cShow lines.
Remove any cEstheticWeight and cGawkOnlyFromFront lines.
Remove any cExhibitViewer, cIdler, and cReturnBuilding lines.
Remove any cExplosionSound and cExplosionSoundAtten lines.
Remove any cFilterDecayedCleanAmount, cFilterDelay, and cFilterUpkeep lines.
Remove any cFoliage, cRock, cShelter, and cStartingHealth lines.
Remove any cFood, cFoodCategory, cFoodUnits, cKeeperFoodType, + cMaxFoodUnits.
For foliage menu without cHabitat of 9414, set cHabitat=9411 + cLocation= 9618.
For things in rocks menu, set cHabitat to 9411 and cLocation to 9618.
For scenery without "cHabitat = 9414", use "cHabitat = 9411".
If "cUnderwater = 1" and "cHabitat = 9414" for scenery, set cHabitat to 9411.
Remove any cHideUser, cHideBuilding, cHideCostChange, and cTimeInside lines.
Remove any cHoldsOntoUser lines.
Remove any cHungerChange, cThirstChange, and cBathroomChange lines.
Remove any cIsColorReplaced and cIsTransient lines.
Remove any "cLand = 1" line.
If foliage has cHabitat set to 9414 or if scenery, remove any cLocation line.
Remove any cMaxUsePeriod, cMinUsePeriod, and cRandomUse lines.
Remove any "cMoveable = 0" line.
For scenery, each ".ai" must have a different cNameID.
Remove any cNeedsConfirm line.
Remove any "cOnlySwims = 0", "cSwims = 0", and "cUnderwater = 0" lines.
Remove any cPlacementFootprintX and cPlacementFootprintY lines.
Remove any cSelectable line if there is no "cMoveable = 1" line.
Remove any cStink, cStrictBuildingCapacity, and cUserTracker lines.
Remove any "cSurface = 0" line.
Remove any cToySatisfaction, cUserStaysOutside, and cUserUsesExit lines.
Remove any cUseAnimCount, cUserTeleportsInside, and cUsesPlacementCube lines.
Remove any cUserInAnim and cUserUsesEntranceAsEmergencyExit lines.
Remove any "cUseNumbersInName=1" line.
Change any "empty = idle" line to "idle = idle".
Remove any used, half, full, decayed, off, broken, and explode lines.
Change full paths to animation names in [Animations] section.
Set negative esthetic values to 0 for objects converted to scenery.
Remove any [AmbientSound] and [UseSound] sections.
Remove any [Characteristics/Strings] and [Characteristics/Floats] sections.
Remove any [Removes], [Satisfies], and [Sells] sections.
Remove [slots], [slot], [slot0], [slot1], [slot2], [slot3], [slot4] sections.
Remove any [bigslot] [bigslot1], [smallslot11], and [smallslot22] sections.
Remove any [drawslots], [ordern], and [returnslot] sections.
Remove any [ordere], [orders], [orderw], [colorrep], and [cr_color] sections.
Remove any [smallslot1], [smallslot2], [smallslot3], and [smallslot4] sections.
Remove any [smallslot33] and [smallslot44] sections.
For objects, if no [EstheticBonus] section, add one with values of 0.
For things in rocks menu and for benches, add "Decorative" to dll messages.
For exhibit foliage, tables, and buildings, add "Decorative" to dll messages.
For toys, stands, carts, rides, and games, add "Decorative" to dll messages.
For vending machines, shelters, and show toys, add "Decorative" to dll messages.
Remove "stop" from purchase menu tooltips.
For TEXT blocks in dll:
If ..._GENERAL does not exist that matches animal Type in upper case, add it.
Change multiple spaces to single spaces, as well as in String blocks.
If ..._GENERAL has odd number of characters, add blank line at end.
Make each ..._GENERAL have less than 4096 characters.
good gracious!! what can i say but :praise2 :praise2 :praise2 and :TY :hug
That is quite an impressive update!
Just wanted to say I'm still waiting for any feedback. Seems like Vondell's been occupied with other stuff, and honestly, there's a lot of stuff going on in my professional life as well.
I would be very happy to give you feedback but I know not where to find ZT Studio :duh :wub2
There's some very specific testing I'd like to be done. Basically: creating a brand new animal from scratch, solely based on a folder structure including specifically named .PNG files.
There's a bit more to it too, and also proper error handling is being built in to alert that too many colors etc are used. Also looking into optimizing :)
well as soon as you are ready for someone to play with it, I would love to do some testing. obviously there may be others you want to try it first, but i'll wait my turn because i'm still very excited at the possibilities this development raises.
Well, if that particular test case goes well (I've collaborated with Vondell on some stuff, hence the favor), I'll release it publicly. As it is at this moment. The main features are all present ;)
yay!! :fireworks :clap2
I did a test with Vondell's tortoise.
Batch ZT1 Graphic files to PNG: (just created a 'new folder', and unzipped the ztd-file to it, then set the 'new folder' as the root folder. Similar to what you'd do in Zoot). Worked flawlessly except for one error message, which I'll look into, but I think it was because of the text file. The graphics were perfect.
Batch PNG to ZT1 Graphic files: there was one little bug, it's fixed already :)
It might be released soon now!
starts making unintelligible excited noises
eeeeeeeeeeeeeeeeeeeeeeeeeeee!
I've been writing some documentation to go along with the first release. It's mostly a technical document for future reference, but I'm also planning to include some quick pointers on how some of the more complicated things work. Also waiting on one more permission.
I was just thinking that one small feature is missing from the batch conversions from PNG to ZT1, and that is something which technically has nothing to do with it. But I'm considering an option to auto-generate .ani files for folders which either contain only one graphic (think object icon, plaque) or 4 views (NE, SE, NW, SW).
The x0, y0, x1, y1... Any idea what they refer to? I vaguely remember they might be useless; but on the other hand: could this be the coordinate of the most top left pixel; and the most bottom right one?
i don't have any idea, but Jay might know... :praise2 :eggyes
Quote from: Jeff on May 14, 2015, 05:47:45 AM
I was just thinking that one small feature is missing from the batch conversions from PNG to ZT1, and that is something which technically has nothing to do with it. But I'm considering an option to auto-generate .ani files for folders which either contain only one graphic (think object icon, plaque) or 4 views (NE, SE, NW, SW).
The x0, y0, x1, y1... Any idea what they refer to? I vaguely remember they might be useless; but on the other hand: could this be the coordinate of the most top left pixel; and the most bottom right one?
If I remember rightly they have to do with rotation settings but Jay can explain that better. I know that I use them on a certain setting for some things.
Quote from: fernIf I remember rightly they have to do with rotation settings but Jay can explain that better. I know that I use them on a certain setting for some things.
You are probably thinking of ZT image offsets, which are inside ZT image files and Zoot shows.
Quote from: JeffI was just thinking that one small feature is missing from the batch conversions from PNG to ZT1, and that is something which technically has nothing to do with it. But I'm considering an option to auto-generate .ani files for folders which either contain only one graphic (think object icon, plaque) or 4 views (NE, SE, NW, SW).
The x0, y0, x1, y1... Any idea what they refer to? I vaguely remember they might be useless; but on the other hand: could this be the coordinate of the most top left pixel; and the most bottom right one?
ZT image files and ".ani" are used for many purposes: objects in zoos (including animals, guests, staff, paths, fences, and terrain in addition to other objects), icons (purchase menus; sold items; research; programs; animal, guest, and staff lists), plaques, maps, UI elements. So I do not know if they work differently for the different purposes. For sold items, before having Zoot, I would change the y0 and y1 values to get the sold items positioned properly in the building and guest inventories. But then I found that only worked in the original ZT and not the ZT expansions. So those values should always be set to specific values for plaques, maps, paths, and most icons:
plaques: x0 = -89; y0 = -97; x1 = 90; y1 = 97
maps: x0 = -183; y0 = -136; x1 = 184; y1 = 140
paths: x0 = -32; y0 = -25; x1 = 32; y1 = 24
purchase menu icons: x0 = -22; y0 = -16; x1 = 22; y1 = 16
sold item icons: x0 = -17; y0 = -17; x1 = 17; y1 = 17
Research have large icons and small icons, since there are 2 locations they are shown.
large research icons: x0 = -22; y0 = -16; x1 = 22; y1 = 16
small research icons: x0 = -17; y0 = -16; x1 = 17; y1 = 16
The values are probably not used for objects in zoos and possibly not used for the animal/guest/staff lists. When APE creates a new animal or object from a ZT animal or object, it copies the values from the animal or object used as a base. When a designer then loads their images into APE, APE does not adjust the original values. So that leads me to believe the values are not used. When I previously looked at what these values represented, they appeared to be the spot on the ground beneath the object's center of gravity. Here are the notes I previously created:
'The x0,y0 in ".ani" files appears to be the location of the center point touching the ground for the largest image, though with minus signs in front of the numbers. When there is a choice, use the point that you get to first along the bottom edge from the left. x1 = image width + x0. y1 = image height + y0. The image width and height might be for the canvas rather than the actual image.'
Zoot does not create or update ".ani" files.
I was thinking about what you described which is why I said I use certain settings which is why I left it to you to use the correct wording. :tongueout
Thanks, seems my assumption was right.
Although I don't see the point yet of those offsets in the .ani-file, since that could be determined by the graphic. Perhaps it has something to do with the way they created these graphics.
I'll see if I can add a basic feature to generate these files. For a 1 view graphic (e.g. icon), it makes sense. But if you consider that there's 1 .ani file per animation, for 4 views... it doesn't make much sense unless it generates the largest required canvas size to render all views, and still...
For a very first, a bit unpolished but presumably quite stable build: topic at Zoo Tek Phoenix (http://zootekphoenix.com/forums/index.php?showtopic=10178)
I quickly released it as it is, otherwise I'll just keep postponing it, and feedback may be useful. I've also included a very large document, it's definitely not a read-me. It's also a work in progress, but I've tried to write down most information about ZT1 Graphics in basic English. It also contains general instructions on how I've created my Umbrella table with ZT Studio, and what you have to think of when creating such an object.
More polishing to come.
thank you! :hugs1
Working on a small update which will fix some small bugs.
I'm also hoping to introduce the automatic creation of .ani-files, which should be the final step in making sure you never need APE (or Zoot) again for graphic stuff.
I have two questions though. Jay, you listed the types and their image size. I think, for generating the .ani-files, I'll start from the graphics. I'm sort of assuming/hoping users would start from an existing template anyway, rather than completely from scratch.
How many different situations do we have when it comes to a "view" or whatever you want to call it? I've spotted these:
* NE, NW, SE, SW ( most static objects etc )
* NE, N, SE, S, E ( moving, e.g. staff , guests, animals )
* 1, 2, 3, ... 20 ( paths )
* N ( icons, plaques etc )
Are there any other?
Jay, you mentioned that the coordinates don't seem to matter that much, especially for the moving creatures.
Any idea what they would be based on? For the icon cases, it's simple, it's only one "view". But for objects and moving creatures, there are 4/5 views to choose from. Would the coordinates simply be determined by the most relevant offsets and height/width from all these views combined?
For the view names, the ones you listed are certainly the most common ones. Sometimes unique view names are used for a folder with a single view in it. For example, the dust cloud (objects/dustcld/idle in global.ztd) uses the view name "dust". Sometimes an object has more views than are configured in the ".ani". For example, the biplane (animals/biplane/m/idle in animals.ztd) has E, N, NE, NW, S, SE, and SW views, but the idle.ani only lists NE, SE, and SW, and NW. Many of the user interface images (such as those in ui.ztd) use a different set of 4 view names: N, H, S, and G. When a user made object is made that looks the same in all 4 views, sometimes we just create a SE view and list SE 4 times in the ".ani". When a user made object is made that looks the same in the rear views as the front views, sometimes we just create the SE and SW views, and add SE and SW twice in the ".ani". Some user made paths use 01, 02, 03, ... 20 and some user made paths use 0001, 0002, 0003, ... 0020. But those were because they did not have tools like Zoot at the time. Some user made paths use the same image for multiple views. Sometimes in those cases there will be fewer than 20 views and there will be duplicate entries in the ".ani". Of course, APE does not support paths, fences, or user interface elements and it does not look for duplicate images. So we handled these various situations manually in the past.
For the coordinates, I mentioned what the settings should be for icons, paths, plaques, and maps. For other things, they are based on all frames of all views within the folder. So you could look for the widest frame of all views in the folder for the x0/x1 coordinates and the tallest frame of all views in the folder for the y0/y1 coordinates. Technically the coordinates could be slightly more than this, but this would be close enough.
Thanks, this should be quite helpful.
I think I'll only have the tool create the .ani-files in those more default cases. One could consider "dust" or the UI elements, but they're so rare in user created downloads. In those cases, I'd still refer to the manual editing. The seagull seems quite strange. Maybe it was simply one of the very first items, and the .ani-file is a leftover from an editor Blue Fang used or something.
You bring up a good point as well about duplicate views. Obviously, unless you ask for user input for each single item (which might be very annoying in batch conversions), the program currently can't detect identical views (*). So in documentation, I'd advise users to stick to the few defaults I mentioned. If not, they'll simply have to create the .ani-files themselves.
The coordinates will be slightly more difficult than I initially assumed, but it can be done. I'll figure out a way for the best optimization.
* : if it gets further developed, I wanted to add some feature anyhow to combine .pal-files - where possible. For identical views/images, this would result in an identical file content. Once this get spotted, it could also adjust the .ani-file (and clean up unnecessary views). It's way too late, but if this had been implemented from the beginning in let's say APE, I think it would have been ideal: certain downloads would be quite less in file size (not only better for users with slow connections, but also for people hosting content) and most likely it would be better for ZT1 performance as well.
* Still requires Microsoft .NET Framework 4.5
* minor fixes
* new lay-out for the settings window, settings slightly changed (their naming should stay what it is now)
* ZT1 Graphics load lots faster - because I managed to bring down the time it takes to show the color palette on the side bar a lot!
* experimental: creation of .ani file when a ZT1 Graphic is written (if this causes issues, just disable the option. I only did a quick test with "bamboo" so far)
* updated documentation
* ...
thank you! I will try and test this during this week! :wub2
Fixed a small regression when it comes to displaying things like the restaurant.
ZT Studio, build 2015.0625 @ DropBox (https://www.dropbox.com/s/ehampz0sds1y1ok/ZTStudio_20150625.zip?dl=0)
I'm looking forward to testing this! It will have to wait until after Tek's birthday, but then I should have some time to check it out :)
Cool!
I've mostly been toying around with the batch conversions, so I'm mainly thinking if there are any issues, it will be small user interface issues. The build yesterday contains a late fix for the previous/next frame button and label.
A current experimental build hooks up with GIMP (2.8).
First, there's a more general feature which allows you to import/export a .pal file from/to a .png-file (16x16 = 256 colors, the first one being your transparent color).
Next, I had vague plans in the past to allow some quick actions in GIMP which would greatly help to create one single color palette for all your frames for one graphic. That's still far from us, but for the recolor feature, I did try to integrate some basic GIMP-functionality in ZT Studio - rather than write entire graphic manipulation code like that myself.
Now, in this experimental build, I've got sliders to adjust red/blue/green/brightness/contrast and an option to pick the tones (shadows, midtones, highlights). GIMP adjusts the palette; ZT Studio generates a new preview right away :)
wow! :praise2 :praise2 if you can teach me to use that it will be a miracle :blush i use gimp a lot for resizing, indexing etc. and have automated the process only to the extent of using keyboard shortcuts for commonly repeated actions and then learning sequences for commonly repeated actions, forgetting them, relearning them etc. etc. etc... :crazy but it is not the most intuitive piece of software in history...
Keep in mind, it's only the basic color balance ( RGB-values, brightness, contrast ) that is implemented in my current build.
It's mainly meant for recoloring original animals ( you open just one NE file for example, but note that the .pal is shared for all original animals )
Resizing might be a bit more difficult though, since you'd need to do it for each ZT Graphic file (NE, SE...) separately.
As for the indexing: it's like Jay once said. You'd just drop all your .PNG-files or whatever into one GIMP-image, then have it generate an indexed color palette of 256 colors (or better: 255, 1 has to be transparent). All your PNG files would need to be opened and would need to use the colors from that one palette. And then you're close to creating the best possible ZT1 download you could possibly offer. So quite a path which would have to be scripted in GIMP ( the script would take a folder as an input, and go over all .PNG-files and apply all steps mentioned in this paragraph ).
yeah - i can't do Jay's method, so I create a palette for the most widely coloured image in an animation set, save it and use it to index all the rest of the images in the set, not as quick but works ok (Jay taught me how to do that anyway). I always use 255 colours, since i don't understand transparency... so i play it safe that way!
i am (among other things) high functioning autistic so some things that seem easy to other people are simply impossible for me to understand, but other things that other people struggle with (chemistry and pixel-based animation for example) are easy peasy for me (or at least they were before my brain was trashed)...
having a ztd creation tool that could do resizing would be epic and wonderful, BUT, the more complex you make a tool, the fewer people will be able to use it successfully, so if you are ever going to do that, i would strongly advise making a special tool to do that rather than adding the functionality to your existing tool.
I had a quick look at the interface and the documentation of zt studio and it is clear to me both that it looks potentially fabulously powerful, and that it is going to take me some time to get to grips with it!
No worries, the GIMP stuff would be gathered under one single button or something.
ZT Studio should mainly be used to convert entire graphics from one format to the other, or as a way to quickly view graphics. Especially the ones that wouldn't open properly before (think Restaurant, certain dolphin shadows).
As for an easy way to create 1 palette in GIMP based on all your images:
* create a new image in GIMP
* use Explorer to go to your folder with the images, drag and drop those files right onto the canvas of your image
* then let GIMP generate the palette
OK, I have made a start with trying to use zt studio. I suspect I will be a good test of the basics because i was an idiot savant even before i acquired a brain injury and so...
how do i get an item into zt studio? I have tried clicking the open button and selecting an extracted item at various different levels, but all I get is error messages :crazy I tried an unextracted ztd and got a different error message. I also tried the 'open as background' option but it said it didn't like my indexed png image and so it didn't load it....
the support document appears to be very comprehensive except that i can't work out how to open the items. :angry2 :rofl :crazy sorry :blush
Please would you give me some (very) basic instructions. If I can follow them, anyone can, so it will be a useful addition to the support documentation. If it is already there and I have just missed it (entirely possible), please point me at the relevant section and I'll have another go...
Quote from: Jeff on July 12, 2015, 05:47:57 AM
As for an easy way to create 1 palette in GIMP based on all your images:
* create a new image in GIMP
* use Explorer to go to your folder with the images, drag and drop those files right onto the canvas of your image
* then let GIMP generate the palette
I'll try that - I always wondered what it meant by 'drop image files here to open them'...
First, go to the Settings-button.
One of the options is to choose the path. What you need here, is the top folder.
Say you have extracted a .ZTD-file to a workfolder, you'll have something like this:
C:\workfolder\animals\youranimal\...
What you need, is C:\workfolder\.
After this, you can use the first row of buttons to open ZT-files ( N, NE, E, SE, S, NW, SW, .... ).
To import/save .PNG-files, you need the third row of buttons.
Thanks - I will try that when it is not after midnight!
Updated version contains a few improvements when the option to generate/update .ani-files is enabled.
It also contains a few performance improvements.
From now on, I'd like to refer to this post (http://zootekphoenix.com/forums/index.php?showtopic=10178&hl=) for ZT Studio-related announcements.
I have posted all work at GitHub.
It includes the source code as well as file documentation (refer to the uploaded .docx file, I haven't rewritten it to the Wiki pages yet).
Latest download of the program and its source can be found at:
https://github.com/jbostoen/ZTStudio (https://github.com/jbostoen/ZTStudio)
I fixed a few issues in this latest release.
Thank you :praise2 I have been taking a break from designing and most other activities) whilst getting a neurological problem diagnosed and trying to work out if it is possible to design with the resultant coordination deficits and if so how... Which is a long way of apologising for not test driving ZT Studio.
No problem. There's not much left of the ZT1 community - it's kind of surprising in a nice way though that there are still some folks around who enjoy the game or create something. After all, it's been what, 15 years?
I am teaming up with Vondell to work on his Red Panda. Using the most powerful features in ZT Studio (and also spending time on creating fixes), it's kind of a breeze now to do all the importing and rotation fixing. We're both looking into a couple of things to improve upon, and hope to release the Red Panda in the near future. And who knows what might (or might not) be next.
If the game was newer, I'd probably have added a full blown configuration editor as well so people wouldn't have to rely on APE anymore. But back then, I lacked the skills I have today to create such a tool. It's good some people did wonderful work, like Jay and someone who went by the name MadScientist (great work for creating ZOOT!)
I'm looking forward to the red panda... It would be fun to make a red panda tree like the koala blue gum tree I once made - the red pandas i remember most vividly from many zoo visits were those that were 50 feet up in a mahoosive elm tree!
Quote from: dr rick on September 01, 2016, 04:24:59 PM
I'm looking forward to the red panda... It would be fun to make a red panda tree like the koala blue gum tree I once made - the red pandas i remember most vividly from many zoo visits were those that were 50 feet up in a mahoosive elm tree!
The best red panda made for ZT was by WhitePanda and he made statues to go with it. They were based on the ones in Auckland Zoo. If I remember rightly he provided one version that could be changed in Ape. Problem is that before I do that I need to fix a couple of things in the original. Rick let me know if you want the pngs for your tree one.
This would be Vondell's version (we might make it a little bigger, since we're currently discussing what to do with 'young' versions of this animal.)
It looks a little less flat to me. :)
(https://s9.postimg.org/nhaqivz73/standin.png)
they are both very cool! yes, i'd love the pngs. I've always thought the koala blue gum was one of the best things I ever made (up there with the gibbon tualang and a few other things). If I can continue to work out ways to do things, I should be able to animate the red panda like the koala...
They show an interesting range of tree-related behaviours...
the young are very cute!! Could Vondell use the young of one of the wolves with a suitable pal file to reduce the amount of actual image creation? (there are several different wolf cubs across the blue fang wolves - i used one of them as a little adult yorkshire terrier because it has much shorter legs than the wolf young of the other types - can't recall whether it was the gray wolf, the tundra wolf or the mexican wolf, but it was one of them...
I could not find a real wild nest photo, so in the end I took a couple of screen dumps from a documentary about the red panda - if I am able to do the tree, I will put a nest hole in it based on these pictures
Vondell's creating all animals from scratch - no recoloring at all.
He creates the ZT versions from 3D designed animals.
That's how Blue Fang did it, and that's how he manages to imitate the ZT1 style in a superb way.
The only other person to use such a method to my knowledge, was our beloved Tasmanian Tiger (Taz), who passed away way too soon :(
I can only say: both Vondell and I are very fond of animal enrichment, we've discussed several ideas - not just in particular for the red panda; but we both have limited time. So I don't know where things are going. Vondell needs to put his skills to work first, only then can I finish it :)
Ahah, that's the proper way to make animals. Congrats to Vondell. I have never managed to get 3D software to work sensibly except for Sketchup which I use to wrap images around cylindrical shapes...
I miss Taz... She was a very fine artist and designer.
I made and got working two cranes by adding to the blue fang flamingo with in-flight animations and three macaws (including a toy that they would fly into as a nest hole), by painting individual views, but then I became ill before the configuration was complete so they never got released. However, I might have another go at them as although my neurological condition is worsening all the time, my mental health is actually much better than it has been for years (something to do with 6 years of successful therapy for severe PTSD).
At some point I've been playing around with Blender myself, somewhere 1 or 2 years ago, but I didn't have the time to get it fully under control. It was all self-education as well, and I might lack the motivation and (maybe?) the skills to pull it off. Although I was and still am very excited about creating a Dingo and Ocean Sunfish (and some sharks) from scratch.
A bit offtopic on the Red Panda: we're getting close, see Vondell's current projects @ Zoo Tek Phoenix :praise2
In the last few days, I've rewritten major parts of ZT Studio. It's much faster now.
The code looks cleaner and is better documented. Just fixed some really minor issues.
Also documented a few ways ZT Studio can be tested or which *original* graphics are of particular interest to test various features.
Most important new features in these new builds:
* batch rotation fixing. Not limited to a frame anymore, but you can pick a folder and fix all the frames in all the graphics in that one folder at once! (came in handy for me, working with graphics provided by Vondell, where actually everything just needed to be moved up 16 pixels).
* shared color palettes. I added quite some info on how-to on the wiki pages on GitHub. Basically, there's a few things to prepare.
* I listed a very simple method to generate a color palette of 256 colors (including the transparent one), using GIMP. And then applying it to all your graphics at once.
* that GIMP Color Palette can be converted easily into a ZT1 .Pal file
* you'd place either the GIMP color palette or the ZT1 color palette in a particular location with a particular name (right now, the .pal name must be the same as the folder name it's in).
** example: animals/redpanda/m/m.pal => this color palette will be used for all the red panda's male (m) animations.
** example: animals/redpanda/redpanda.pal => this color palette will be used for all the red panda's animations (including the young and [we don't have it though] the female). Exceptions are made if only 1 graphic (icon, plaque) is found in a folder, since these often have colors in their graphics not used anywhere else. Think background green or highland colors in this case.
This feature has quite some potential. I already made the graphics for a (working) Umbrella Table. I still had 4 views, although I actually only used 1 image and mirrored it. That did allow me to easily manipulate the then still 4 individual color palettes (1 per view: NE, NW, SE, SW) so I could put the colors which could be changed ingame, in the right spot. In this particular case, I could use 1 color palette for all those 4 views. And I'd only need to change the order of the colors in this palette once. Which makes it much easier to generate objects/buildings/... of which the color can be changed.
We did a test case for it, since Vondell suggested a lighter version of the red panda as the animation for the young (simply making it even smaller was not much of an option, it would become too small and not very recognizable). I simply made a copy of the male's animations (.PNG files), I batch converted the .PNG graphics to ZT1. Afterwards, the only thing needed, was to export the color palette of the young (animals/redpanda/y/y.pal) to a .PNG color palette (16x16 pixels = 256 colors. We generate this .PNG image since it's easier to manipulate than a GIMP Color Palette). I made a brighter version of it, and replaced the colors in y.pal with the new ones from this .PNG color palette. Et voila: a very simple recolor of the entire animal..
Big kudos to Vondell for teaming up to work on the Red Panda. It's been a long way so far, but our processes are streamlined now.
So the only question which remains unanswered for now (maybe forever?): what is the meaning of those two mystery bytes?
If we ever want to find it out: I think it might be useful if we compiled a list sometime, some day of each frame in graphics and their basic properties (height, width, offsets, amount of colors, amount of bytes in drawing instructions in the frame [after all, they are right in front of them], etc), combined with those two mystery bytes... translated in most likely one number (or are they 2 separate things after all?). Is it some kind of signature? Do they contain a checksum? Do they occur only in frames which start with FATZ/ZATF or not? The mystery continues.
:praise2 :praise2
I like the sound of this
QuoteWe did a test case for it, since Vondell suggested a lighter version of the red panda as the animation for the young (simply making it even smaller was not much of an option, it would become too small and not very recognizable). I simply made a copy of the male's animations (.PNG files), I batch converted the .PNG graphics to ZT1. Afterwards, the only thing needed, was to export the color palette of the young (animals/redpanda/y/y.pal) to a .PNG color palette (16x16 pixels = 256 colors. We generate this .PNG image since it's easier to manipulate than a GIMP Color Palette). I made a brighter version of it, and replaced the colors in y.pal with the new ones from this .PNG color palette. Et voila: a very simple recolor of the entire animal.
Yes, it's quite cool, because previously you'd have to either recolor the actual images to get a proper color palette at the very end or perform some magic similar to the method I described to create such a shared color palette - and then the biggest trick was to make sure you kept the original order of the colors.
Now, for recolors of animations, you could simply:
- open for example animals/tiger/tiger.pal (obviously you'd take animals/ABCD1234/tiger.pal or whatever the ID/shortname of your new animal is) in ZT Studio.
- save the palette as a .PNG-file containing all the colors
- load it in your favorite graphic manipulation program (GIMP, Paint.NET, whatever)
- adjust the color balances like you'd normally do, save the .PNG
- reimport it in ZT Studio
- save as .PAL.
Done. Except for the icons and plaque, you wouldn't even need to mess around with the graphics - if your tiger is the same size obviously.
It's a deliberate choice to NOT include any graphic manipulation (resizing, recoloring etc) in ZT Studio, but only the core: save/view/load the file formats and adjust offsets.