Zooberry is a Zoo Tycoon mod repository dedicated to conserving mods once
hosted by Zoomania, Northern Skies, and Artifex. Click here to learn a little more about ZooBerry and why it exists. If you wish to submit your own file for hosting at ZooBerry, please check out the contact page for our file hosting policy.
I released v1 of UFO for ZooTek Phoenix 20th anniversary, but I uploaded an incomplete Pack. That’s why I decided not to upload to ZTP download directory, because v2 will have more animals and items.
UFO v2 will have four divisions. The changelog is this:
Pterosaurs
→ Pterodaustro
→ Tupandactylus
→ Nyctosaurus (Debugged)
→ Quetzalcoatlus (Debugged)
→ Hatzegopteryx (New)
→ Harcpatognathus (New)
I’m releasing Floofy Tyrannos alongside debugged animals this night… New pterosaurs are gonna be a little delayed, but this week vacations go to an end and I’m not sure how long I won’t be able to completely finnish the whole pack
Borsato already made Elephant Birb… I’m thinking on Haast’ Eagle
Tyrannosaurs exp is now released alongside Megaraptor and fixed previous animals… I’m taking a break for a couple of days and then the new pterosaurs are coming to your zoos!
Ok I think I know what happened to graphics. It seems that ZTStudio has an issue when converting .png files to ZT graphics… Every black (#000000) pixel is, because of something, skipped… So, every shadow goes lost when batch conversion feature runs. When I made Tyrannoes I noticed this because they are bigger, but the pterosaurs also have this issue. If you put the animal body inside a square, since it is most colorful, every shadow outside this imaginary square is missing in the final graphic file…
What am I doing then? I’m recolouring aaaaaaaaall of my animals again with a more greyish shadow… If ZTStudio manages to recover the shadow when it’s not whole black, my last version of UFO will have a full rework of animals in addition to the new items… This idea should also fix the issue of tyrannoes being non centered in the icon pannel and their arrow pointing too far (because they were made with Zoot instead)… I’ll post here if this goes well!
EDIT!! This also happens with Peryton… I’ll eventually fix it and upload the new version, which will also like Goosifer’s Atlanean fountain and other user made Atlantean items!
Since ZT Studio does not work on my computer, I cannot say too much about that. But my understanding is that ZT Studio’s batch processing uses the graphics program GIMP. If an image had transparency in GIMP, GIMP remembers what the color used to be in the transparency. But many things in GIMP change that remembered color to black. Also, when transparency is saved as a “.png” in GIMP and probably many other graphics programs, there is an option that says whether the “.png” should remember what the transparent colors used to be. If that option is not set, programs assume transparent colors used to be black. When images are loaded into Zoot, APE, APExp, and probably ZT Studio, those programs do not actually understand the transparency in “.png” files. Instead, those programs look at the top leftmost pixel in the “.png” and change every pixel with that color to be transparent. If the top leftmost pixel in the “.png” is transparent, the remembered color for that pixel is used. If the “.png” file does not remember the color, then black is used. So yes, it is a common problem to have wrong pixels change to transparency, especially when images have shadows.
There are multiple ways to handle the problem. I use GIMP. When I save images from GIMP, right before saving the images as “.png” files, I change the transparency in every frame to magenta (#ff00ff) and then delete the magenta. That way the images show transparency, but GIMP remembers the transparent pixels as magenta. When I save the images as “.png” files in GIMP, I make sure the “.png” options are set to remember the background colors for transparency. This is the technique that many designers use. When Zoot saves “.png” files, it also uses this technique. This might be easier than changing your shadows to grey. And when you say grey, I assume you actually mean a shade of black that is not #000000 pure black.
Thanks Jay! This is a pretty neat answer… Neverthless, it’s like ZTStudio erases the transparency color and also the black, but just from a little area from the frames… I mean, i. e. this is the first frame of Quetzalcoatlus’ flying animation for SE as just as Blender baked it:
However, when converting it for ZT graphic file, the result is like this when loaded in Zoot, ZTStudio and, naturally, in the game (This is Quetzalcoatlus V5 just as is right now available in my signature):
As you can see, all the shadow found outside this “imaginary square” surrounding the animal’s body is missing… I eventually tried to fix this and I achieved neat results… The new version of Quetzalcoatlus looks like this:
I managed to recover the missing pixels of the shadow, but I didn’t keep using ZTStudio batch conversor, because it did work well for Quetzalcoatlus & Nyctosaurus, but not for Titanis & Pterodaustro…
I believe what I said in my previous message is the cause. I will try to explain in pictures. Your first image with the green background has more than 2000 colors in it. So ZT cannot use that image. Each ZT animation may not have more than 255 colors. So your first image has to have the colors reduced. APE and APExp try to reduce the number of colors for images loaded into them. Zoot does not have that ability and will say there are too many colors when attempting to load that image. I believe ZT Studio has the ability, but I do not know if it does so on its own or if it uses GIMP to do so. I used GIMP to reduce the colors to 255 without dithering and keeping the green background. This is the result.
I then loaded that into Zoot. It worked correctly, like your third image. Here is what was shown in Zoot.
I then took your first image with the green background and told GIMP to change the green background to transparency. Even though it shows as transparency, GIMP remembers it used to be green. I then told GIMP to reduce the colors to 255 colors without dithering. That operation causes GIMP to believe the transparency used to be black instead of green. This is what it looks like.
I then loaded that image into Zoot. But since png says the transparency used to be black, Zoot gets confused. This is the result.
Most likely ZT Studio did something similar, possibly with dithering instead of without dithering, and caused your result. If it is easier for you, you can use the green background instead of transparency and that should fix your problem. But it is possible to make it work even with transparency, but you might have to use GIMP or other graphics program instead of ZT Studio. To show the difference, I used GIMP to reduce the colors before I changed the green to transparency. This is the result.
Although this looks the same as the other png with transparency, it is different. This png remembers that the transparency used to be green. So when it is loaded into Zoot, Zoot knows to change any green to transparency. So Zoot again worked correctly, like your third image. Here is the result.
This last example is what I do with images to have them work in Zoot. But instead of using GIMP to set the background to green, reduce the colors, and change the green background to transparency, I use GIMP to set the background to magenta, reduce the colors, and change the magenta background to transparency. Images are less likely to have magenta than green.
Hmm suggestions…what about an elephant bird?
