Animations for items and blocks do not work properly

Tried this and it works as expected, no "missing texture" thing happens when I tested it.

Same here, No "missing texture" for me.

OK, that's strange, it seems to work for some people. I just added the test files to another texturepack to make sure, but the animation does not load. Everything white. My Minecraft is not modded, I tested it with a clean minecraft.jar (Snapshot 13w09a) !

Please add an empty txt file with the animated *.png names and test again?

You mean an empty mobSpawner.txt-file ?
Does not work, besides how should I define the frame durations with an empty file?

C'mon everyone, can anyone cofirm this?
I can't be the only one with this problem! As far as I know, I did nothing wrong with my animations and I used a clean, unmodded minecraft.jar (Snapshot 13w09a!).
If anyone can confirm this, please upvote, we need to get this fixed for the 1.5 pre-release, it seems to be a pretty massive bug!

Added a small test-texturepack to the attachments containing the shown files ...

I also have this problem

Um, animated blocks and items in texture packs now requires the animation definition in snapshot 13w09a (previously it was optional)

@xland44, I quote myself:
"I made sure all animations have their own txt-file (as required in Snapshot 13w09a)." - MC-10355

If you take a look at the attached test pack, there IS a proper txt-file in it, but the in-game result is still white with that silly "missing texture" message.

Come on ... this bug is at least as important as MC-10309, item and block animations DO NOT WORK!
This is one of the main features of the new 1.5 texturepack format and needs to be fixed, so UPVOTE !!!
I tested it on other computers too, it happens evrywhere. Would any mod please officially confirm this and change the confirmation status?

Ok, now it does the same thing. It appears that animations in zip files do not work, but they work fine when in folders. Tested with several packs in both folder and zip form.

thx @Jnrm3, can confirm this. Animations work with folder based texturepacks (but ONLY with folder based packs!). Texturepacks are commonly used as zip-folders, so this bug still affects the majority of all texturepack users.

Still not fixed in 13w09b, please upvote this. Besides, would any mod please officially confirm this and change the confirmation status?

What about 13w09c about animation blocks has been fixed?

have the same problem with my 32x32 pack. animation descriptions are there and the log says that there is a broken aspect ratio. All normal textures are good it only effects the animated ones.

I have the same problem.

@Jayvee D. Enaguas
There is no 13w09c snapshot at this time.

Ok, I tried the folder version of my 32x texture pack & the animations work fine. I'm about to try it with the .zip version of my 32x texture pack, & see what happens.

Ok, I just tried the .zip version of my 32x texture pack & the animations don't work. The only ones that work are the portal, fire, water, & lava animations. None of the other ones work. I have all the .txt definitions for my animations too, so I didn't mess up. This is a bug that I'm experiencing too.

@Mark Cashion That is impossible to 1.5 pre-release yet.

Come on, Mojang. You can't do a pre-release without this bug fixed. You messed up the whole texture animation system!

Everyone else: Please upvote this! Animated blocks/items are one of the main features of the new texturepack format, this has to be fixed BEFORE the 1.5 pre-release!

tried the folder type for my texture pack and my textures work, but now water flow, lava flow, compass and clock are broken.

@Lane Johnson:
Can confirm this for compass, clock, flowing water, portal and fire animations when using folder based packs (but strangely, my flowing lava works).
Updated the main post, thx for that information. Mojang really made a huge mess with everything related to animations, time to fix that !!!

I suspect the problem lies in bji.class. The method "public boolean c(String)" which checks if the texture pack contains a given file does not strip off the leading slash from the path. Adding a .substring(1) before calling ZipFile.getEntry should fix it.

Master Kahr has spoken. Thx. I'll add your comment to the main post. Let's hope they fix it before they pre-release Minecraft 1.5.

Fixed for 1.5!

Thanks a lot for fixing that, Grum 🙂
And thanks to everyone who helped testing and investigating this.

Thanks for reporting; stupid stuff slipping through cracks of manual testing >.>
I've tested the animations with folders only 😞

look on minecraft wiki under texture packs (FROM SOURCE)

Texture Animations in Minecraft 1.5

Snapshot 13w09a note: Starting from this snapshot, in order to have an animated texture, this animation definition text file is mandatory.

Any sheet image can be animated by placing additional frames of animation in the same image in y-axis slots. The default behavior will be that, at 10 updates per second (100 ms per frame), the game will copy the next slot into the active texture. Once the bottom of the sheet image is reached, the game will start over from the topmost slot again. For example, to create a block texture that quickly flips between two 16x16 images, place them above each other in a 16x32 sheet image.

It will be possible to customize the duration and selection of which frames to use. For example you may want to "ping-pong" the animation (using frames 1-2-3-2-1) instead of looping it (1-2-3-1-2-3). This will be done by creating a text file with the same name as the sheet image (such as "dirt.txt" for "dirt.png") and specifying which frame indices the game should pick when it's ticked.

The format of the animation file is simply numbers specifying which frames to pick (indices start from 0), separated by either commas or new lines. For example, if you would want to ping-pong an animation that has 4 frames, the contents of text file would look like this:
0,1,2,3,2,1

... or like this:
0
1
2
3
2
1

To make the animation slower than 10 updates per second, the animation file can be specified to keep the frame for any number of ticks using an asterisk and the number of ticks to keep it. For example, to make the animation above four times slower, the file would look like this:
0*4,1*4,2*4,3*4,2*4,1*4

The water, lava, and lava_flow textures all have default text files which must be overwritten if you have an animation that varies from the default length of 32 frames for water and 16 frames for lava.

@Hkliese:
You should read the content of an issue ticket first before posting anything here. Just read everything above, then you'll see that your comment is a bit out of place here. You can assume that everyone here already knows how animations and the respective text files work, otherwise we wouldn't have found this bug, or not? And Grum fixed it, so everything's OK again.

still not fixed in 13w09c

@Lane Johnson:
False alarm. Everything works fine on my side with 13w09c (tested all animations with zip and folder based texturepacks, no missing textures anymore), please check your txt-files !

Checked, new txt. files! thanks. 🙂

I have still the issue with clock... 😞
@snapshot 13w09c
unziped folder with 64-128px tp
I have made empty clock.txt file
works w/o problems in 13w03a

flowing lava and water have worked weird/broken/incorrect when I had their txt files filled with numbers
the blocks animated, but at some point they stopped, seemed as lag, but it was just the animation frozen, after some time it started over again from 1st animation frame.
(ie. I have animations with 128 frames, but despite that I had written 0-127 frames in txt, it only animated like 30, then it "stopped" until it reached the last 127th and after it the animation repeated from start)
the txt file looked like this:
0
1
2
...
127/255

when I deleted the whole "text" - numbers within the txt the animations started to work properly and all 128, resp. 256 frames got animated.

I can provide the txt and clock png if needed.

See MC-10354.

thx for pointing me at it.

Argh! Still broken for 1.5 pre-release. 😞

EDIT: It seems that the format for the animations changed, so I guess this really isn't a bug in my case. Not sure for everyone else though :\