So, like, I have it set up but my Resource pack here is 32x32, but anyway, sandstone_carved.png is animated yes. But I tried sandstone_carved.png.mcmeta and I for some reason end up with the normal Chiseled Sandstone texture. But the texture isn't the purple black thing though. But I even edited the mc.meta file by typing in the animation thing and what not. Did everything you said here... D:
My first thought is that you are using another texture pack as a template and you have a CTM folder that's overlaying the default sandstone. This is especially likely if you're using Optifine rather than MCPatcher. Optifine is weird like that.
Make sure you don't have a CTM folder anywhere in your texture pack.
If you're 100% sure that you don't, consider uploading it somewhere and sending it to me in a PM. I'll happily take a look at it and help you get it working.
My first thought is that you are using another texture pack as a template and you have a CTM folder that's overlaying the default sandstone. This is especially likely if you're using Optifine rather than MCPatcher. Optifine is weird like that.
Make sure you don't have a CTM folder anywhere in your texture pack.
If you're 100% sure that you don't, consider uploading it somewhere and sending it to me in a PM. I'll happily take a look at it and help you get it working.
I have no CTM folders. Nor do I use MCPatcher or Optifine. Do I need to upload it to like MediaFire? Or could you take a look at it and try to edit it and get it animating?
I have no CTM folders. Nor do I use MCPatcher or Optifine. Do I need to upload it to like MediaFire? Or could you take a look at it and try to edit it and get it animating?
Upload the entire thing to Mediafire if that's all right. In .zip format, preferably.
Chances are you just named something wrong, or some other tiny little mistake that causes Minecraft to overreact, and it'll be just easier for me to examine the pack rather than playing guessing games with it.
so the png and mcmet is named the same and is in the same folder but i still get the checked purple and black texture =(
I have also tried optifine and mcpatcher but non of those work either. WHY.
Same reason I was having the same problem with an animated lava texture -- fencepost error. Remember that the frame index is zero-based. Your mcmeta file should look like this:
The first frame is frame 0, the second is frame 1, the third is frame 2, and the last is frame 3. With my animation, it had 64 frames, and the mcmeta file listed frames 0-64 -- a fencepost error the other way. You didn't start yours at 0, and mine went over to 65 entries for a 64-frame file.
What makes my mistake embarrassing personally is that I looked at the file three times and didn't see it -- and I'm a programmer.
Remember that the two hardest things in computer science are cache invalidation, naming conventions, and off-by-one errors.
How can you change the animation for the endercrystal? I saw it in some other packs like Misa, there's another folder in the assets\Minecraft path, it's called McPatcher. I tried to create the same structure but it won't work to change the endercrystal. It still has the default texture. Please help.
That's an entirely different animation process altogether, and not one that's covered by this tutorial. Check the MCPatcher thread for details on how to do that. You can also look in the Texture Artist's Guide to MCPatcher's Features thread. That would also be a better thread to ask in than this one.
I have a query about the clock. I made a custom texture strip for it, 120 frames, five frames corresponding to each hour. Numerical output with two features:
The "backlight", as it were, tints red between t=13200 and t=22800, which are the nearest multiples of 200 ticks to the actual thresholds. This indicates the time span during which mobs are able to spawn on the surface.
The digits turn red for precisely one minute (six frames) starting from 6pm (t=12000) and ending at t=13200, as a "get to a bed" warning.
...it doesn't seem to want to work, though. After encountering mobs after sleeping despite having gotten to the bed within the warning period, I tested it thoroughly. And it looks like the frames are not evenly distributed. I don't have time at this precise moment to give full details, but where the relationship should be a linear relationship between frames and time, the frames are switching over irregularly (though symmetrically), with a trendline that's reasonably close to straight, but in fact is fitted by a high order polynomial.
Any idea what might be causing this?
EDIT: Okay, I have time to come back and elaborate on this now, so here's a link to my texture file, and my observations on the behaviour are below. [LINK REMOVED -- NO LONGER NEEDED]
Time as displayed on the clock, and tick on which it changes to that frame. N.B. the fractional times are for the mob thresholds; half-ticks are when the frame flickers between two. Obviously, the tick times should all be at intervals of exactly 1000 ticks (fractional hours aside, though obviously they should be exactly 200 from the nearest hour)... but they aren't. And also it all seems to be shifted by an hour on top of that.
I have a query about the clock. I made a custom texture strip for it, 120 frames, five frames corresponding to each hour. Numerical output with two features:
The "backlight", as it were, tints red between t=13200 and t=22800, which are the nearest multiples of 200 ticks to the actual thresholds. This indicates the time span during which mobs are able to spawn on the surface.
The digits turn red for precisely one minute (six frames) starting from 6pm (t=12000) and ending at t=13200, as a "get to a bed" warning.
...it doesn't seem to want to work, though. After encountering mobs after sleeping despite having gotten to the bed within the warning period, I tested it thoroughly. And it looks like the frames are not evenly distributed. I don't have time at this precise moment to give full details, but where the relationship should be a linear relationship between frames and time, the frames are switching over irregularly (though symmetrically), with a trendline something like y = 0.0005x6 - 0.0436x5 + 1.5826x4 - 27.256x3 + 204.05x2 + 653.17x + 228.41 (though with an offset of six hours from that if you want to be technical).
Any idea what might be causing this?
You have a lot of numbers... and that confuses me.
OK, where I think you're having a problem is that you think that the day-night cycle is totally linear. It's not. A minecraft day is 10 minutes. Sunrise and sunset are both 1 1/2 minutes. Night is 7 minutes.
The clock 'starts' at noon which is a 0° rotation. At sunset, the clock has gone through a 90° rotation. Midnight is 180° rotation, and sunrise is at 270°.
What this means is that it takes a little over 11 minutes to go from sunrise to sunset, but just over 8 from sunset back to sunrise. Sunrise and sunset overlap both 'halves' of the clock face, but night doesn't last as long.
For your purposes, it would be more practical to divide the game time (24000 ticks) and use the events listed on This Page of the wiki to determine where your events should begin or end. For example, the 'go to bed' warning must begin and end prior to 13187 ticks. So for 120 frames that should be prior to frame 30 (if my math is correct).
Does that make a lick of sense? Hope that helps you anyway.
For your purposes, it would be more practical to divide the game time (24000 ticks) and use the events listed on This Page of the wiki to determine where your events should begin or end. For example, the 'go to bed' warning must begin and end prior to 13187 ticks. So for 120 frames that should be prior to frame 30 (if my math is correct).
Perhaps I was unclear when explaining (probably).
Dividing up the ticks is precisely what my intention was, and how I designed the texture. It's 120 frames because there are 24 hours, each of which corresponds to five frames and also to 1000 ticks, meaning each frame should last ten seconds/200 ticks. And therefore I placed the thresholds in the animation at the nearest multiples of 200 to the thresholds for mob spawning (and the bed warning simply covers the six preceding frames, since each frame should be exactly 10 seconds).
I'm actually the person who worked those mob thresholds out and put them on the article, btw ; )
I've edited my previous post with my observations and a copy of my texture file.
Dividing up the ticks is precisely what my intention was, and how I designed the texture. It's 120 frames because there are 24 hours, each of which corresponds to five frames and also to 1000 ticks, meaning each frame should last ten seconds/200 ticks. And therefore I placed the thresholds in the animation at the nearest multiples of 200 to the thresholds for mob spawning (and the bed warning simply covers the six preceding frames, since each frame should be exactly 10 seconds).
I'm actually the person who worked those mob thresholds out and put them on the article, btw ; )
I've edited my previous post with my observations and a copy of my texture file.
Sorry then. No clue. My animation seems to be working correctly, and I'm not good enough with the math to figure out exactly why yours isn't.
Hm. Just out of curiosity, I switched to the default resource pack and tested a few values with that.
Noon = 5999.5 (as expected, within that half tick)
Next frame should be 375 (24000/64) ticks on, i.e. 6375, but it's not. It's at 6547 -- off by 172.
t=0 is not the frame it should be. The frame with the dividing line perfectly vertical starts at 23214 -- off by 786 (which is more than the expected length of two frames!)
One might hope that the frame for t=12000, while inevitably wrong, would at least be the correct 12000 away from the t=0 frame. Nope. 12785, which is 785* away from correct, and 1571 away from the "expected wrong value" of 11214.
*You may notice this is almost the same as the 786 for t=0. This is no coincidence. If you put my data from my first post in Excel and work out the differences between tick values, they are all symmetrical like that. But still stupid and inexplicable.
So it looks like however the clock is coded, it's not as simple as "divide the day by the number of frames". Maybe there's something wrong with my specific copy of Minecraft... I suppose the logical next test is to use my unmodified .jar and see if that helps.
EDIT: Nope. Still doing exactly the same even with the vanilla .jar file.
Another edit: Actually, I suspect I know what the issue is. The (default) clock face is exactly half day half night. Which isn't what the cycle is like! I took a look at how many frames long each hour was (now with twice as many frames for greater precision), and broadly speaking, they're fewer frames long closer to midday, and more frames long closer to midnight. Which means it must be, essentially, running different framerates at different times of day -- advancing more frames at night because it has to get through the same number of frames in less time. That's a good thing when your dial is not representative of the true day/night split, but a very bad thing for displays that are totally regular throughout the cycle.
In any case, having now measured it that way around (what frames correspond to the tick times), I'm redoing the texture with the frames based on that. Should work, and should always be accurate within five seconds/100 ticks. Or seven seconds because of the framerate... or something... eh, it's less than ten seconds either way, good enough. I may do even more frames, for even greater accuracy, at some later stage if I can be bothered
I have edited this post far too many times:
If anyone's at all interested, I did a 1200 frame animation, so each frame would correspond to one second if it were linear. And here's what the actual frames per second of the animation looks like over the course of the day:
As I noted, it's higher fps at night, and lower in the day. And this is why a linear animation is doomed to fail.
Hello Alvoria! Can you help me with these animation files? I've changed them many-a-time, and no matter what, I always get the same error.
They all look correct. The only thing I can think of is that the file isn't being saved in the correct format for some reason. Make sure you're saving them using ANSI encoding.
Barring that, please post your image files. The error you're getting is usually associated with having the wrong number of frames in an image... though that makes no sense for the Jack O'Lantern since you don't specify frames. If you can give me some images, I'll see if I can get them to work.
They all look correct. The only thing I can think of is that the file isn't being saved in the correct format for some reason. Make sure you're saving them using ANSI encoding.
I'm using Notepad++ on 'em, which has no encoding option when saving, so I can only assume it was correct.
Barring that, please post your image files. The error you're getting is usually associated with having the wrong number of frames in an image... though that makes no sense for the Jack O'Lantern since you don't specify frames. If you can give me some images, I'll see if I can get them to work.
Alright, I suppose I can do that.
Here is the command block:
the fire:
and the pumpkin:
I do not include the detector rail, because I only just now found that it was only one frame. :/ Making it two frames fixed that.
OK, the only one that I found a problem with was the command block one. You missed a comma in the frame 3 information. I feel like a total derp for not noticing it earlier, actually.
For the other two... they work. At least for me they do. If you're still having problems, try reducing everything to a single line like so:
And i used the simple, one line thing as the mcmeta code. The one that has just the word animation and a few brackets
But when I choose the pack and place the obsidian it will not show up
The image file seems fine. Go through the Troubleshooting steps again. Make sure that you have file extensions shown if you're a Windows user. Make sure the file format is ANSI. Run through all of the trouble shooting steps. If you really can't figure it out, delete the file and start over.
If you really REALLY can't get it, you can also try uploading your .mcmeta file to dropbox and I can take a look at it.
OK, the only one that I found a problem with was the command block one. You missed a comma in the frame 3 information. I feel like a total derp for not noticing it earlier, actually.
For the other two... they work. At least for me they do. If you're still having problems, try reducing everything to a single line like so:
Make sure you don't have a CTM folder anywhere in your texture pack.
If you're 100% sure that you don't, consider uploading it somewhere and sending it to me in a PM. I'll happily take a look at it and help you get it working.
I have no CTM folders. Nor do I use MCPatcher or Optifine. Do I need to upload it to like MediaFire? Or could you take a look at it and try to edit it and get it animating?
"Wake me, when you need me."
Chances are you just named something wrong, or some other tiny little mistake that causes Minecraft to overreact, and it'll be just easier for me to examine the pack rather than playing guessing games with it.
Thanks.
Same reason I was having the same problem with an animated lava texture -- fencepost error. Remember that the frame index is zero-based. Your mcmeta file should look like this:
{
"animation": {
"frametime": 5,
"frames": [
0,
1,
2,
3
]
}
}
The first frame is frame 0, the second is frame 1, the third is frame 2, and the last is frame 3. With my animation, it had 64 frames, and the mcmeta file listed frames 0-64 -- a fencepost error the other way. You didn't start yours at 0, and mine went over to 65 entries for a 64-frame file.
What makes my mistake embarrassing personally is that I looked at the file three times and didn't see it -- and I'm a programmer.
Remember that the two hardest things in computer science are cache invalidation, naming conventions, and off-by-one errors.
Any idea what might be causing this?
EDIT: Okay, I have time to come back and elaborate on this now, so here's a link to my texture file, and my observations on the behaviour are below. [LINK REMOVED -- NO LONGER NEEDED]
Time as displayed on the clock, and tick on which it changes to that frame. N.B. the fractional times are for the mob thresholds; half-ticks are when the frame flickers between two. Obviously, the tick times should all be at intervals of exactly 1000 ticks (fractional hours aside, though obviously they should be exactly 200 from the nearest hour)... but they aren't. And also it all seems to be shifted by an hour on top of that.
OK, where I think you're having a problem is that you think that the day-night cycle is totally linear. It's not. A minecraft day is 10 minutes. Sunrise and sunset are both 1 1/2 minutes. Night is 7 minutes.
The clock 'starts' at noon which is a 0° rotation. At sunset, the clock has gone through a 90° rotation. Midnight is 180° rotation, and sunrise is at 270°.
What this means is that it takes a little over 11 minutes to go from sunrise to sunset, but just over 8 from sunset back to sunrise. Sunrise and sunset overlap both 'halves' of the clock face, but night doesn't last as long.
For your purposes, it would be more practical to divide the game time (24000 ticks) and use the events listed on This Page of the wiki to determine where your events should begin or end. For example, the 'go to bed' warning must begin and end prior to 13187 ticks. So for 120 frames that should be prior to frame 30 (if my math is correct).
Does that make a lick of sense? Hope that helps you anyway.
I live to serve.
Perhaps I was unclear when explaining (probably).
Dividing up the ticks is precisely what my intention was, and how I designed the texture. It's 120 frames because there are 24 hours, each of which corresponds to five frames and also to 1000 ticks, meaning each frame should last ten seconds/200 ticks. And therefore I placed the thresholds in the animation at the nearest multiples of 200 to the thresholds for mob spawning (and the bed warning simply covers the six preceding frames, since each frame should be exactly 10 seconds).
I'm actually the person who worked those mob thresholds out and put them on the article, btw ; )
I've edited my previous post with my observations and a copy of my texture file.
As I said, lots of numbers make my head hurt.
So it looks like however the clock is coded, it's not as simple as "divide the day by the number of frames". Maybe there's something wrong with my specific copy of Minecraft... I suppose the logical next test is to use my unmodified .jar and see if that helps.
EDIT: Nope. Still doing exactly the same even with the vanilla .jar file.
Another edit: Actually, I suspect I know what the issue is. The (default) clock face is exactly half day half night. Which isn't what the cycle is like! I took a look at how many frames long each hour was (now with twice as many frames for greater precision), and broadly speaking, they're fewer frames long closer to midday, and more frames long closer to midnight. Which means it must be, essentially, running different framerates at different times of day -- advancing more frames at night because it has to get through the same number of frames in less time. That's a good thing when your dial is not representative of the true day/night split, but a very bad thing for displays that are totally regular throughout the cycle.
In any case, having now measured it that way around (what frames correspond to the tick times), I'm redoing the texture with the frames based on that. Should work, and should always be accurate within five seconds/100 ticks. Or seven seconds because of the framerate... or something... eh, it's less than ten seconds either way, good enough. I may do even more frames, for even greater accuracy, at some later stage if I can be bothered
I have edited this post far too many times:
If anyone's at all interested, I did a 1200 frame animation, so each frame would correspond to one second if it were linear. And here's what the actual frames per second of the animation looks like over the course of the day:
As I noted, it's higher fps at night, and lower in the day. And this is why a linear animation is doomed to fail.
Thanks for th info!
I have four animations:
(command block)
(upper layer of fire)
(jack o'lantern)
(detector rails)
Those should all work, but they just give me the purple-and-black squares. The launcher console tells me this:
Which hasn't changed at all despite that I have changed the .mcmeta files multiple times. Halp.
No problem. Glad I could help.
Happy to hear it!
They all look correct. The only thing I can think of is that the file isn't being saved in the correct format for some reason. Make sure you're saving them using ANSI encoding.
Barring that, please post your image files. The error you're getting is usually associated with having the wrong number of frames in an image... though that makes no sense for the Jack O'Lantern since you don't specify frames. If you can give me some images, I'll see if I can get them to work.
I'm using Notepad++ on 'em, which has no encoding option when saving, so I can only assume it was correct.
Alright, I suppose I can do that.
Here is the command block:
the fire:
and the pumpkin:
I do not include the detector rail, because I only just now found that it was only one frame. :/ Making it two frames fixed that.
OK, the only one that I found a problem with was the command block one. You missed a comma in the frame 3 information. I feel like a total derp for not noticing it earlier, actually.
For the other two... they work. At least for me they do. If you're still having problems, try reducing everything to a single line like so:
flame_layer_1.png.mcmeta
pumpkin_face_on.png.mcmeta
Sorry I couldn't be of more help, but I can't fix what doesn't appear broken for me.
https://www.dropbox.com/s/2inky8ncpka5de6/obsidian.png
And i used the simple, one line thing as the mcmeta code. The one that has just the word animation and a few brackets
But when I choose the pack and place the obsidian it will not show up
Please help,
Pipster
If you really REALLY can't get it, you can also try uploading your .mcmeta file to dropbox and I can take a look at it.
I figured it was something like that... I think the problem must be to do with the spacing or something. I'll just re-do those files, I suppose.
EDIT: I did what you said, and it pretty much worked entirely. No more errors! Thanks for helping me get that sorted, Alvoria.