TextureEnder.jar is not converting some animations .txt files correctly into mcmeta. This isn't necessarily a bug with minecraft, but it is a big and necessary part of the 1.6 snapshots.
It seems that sometimes (notably long delays) timings are converted incorrectly. For example, this:
0*100,1*2was converted into this:
{
"animation": {
"frametime": 2,
"frames": [
{
"index": 0,
"time": 1
},
1
]
}
}Note how "time": 1 when it should be "time": 100. With this it obviously is easy for me to fix, but I have quite a few long and complex timings that get totally messed up.
This happened quite a few times with different textures and it didn't seem to be very consistent with any one timing in the txt file. Although each time I used the converter, the same files would be converted the same way.
Comments 6
I don't see why you marked this as a duplicate. There is no similarity at all between the two issues. The other bug was with mcmeta and commas. This is a bug with the textureEnder converter.
Alright. Reason for duplicating this ticket was the stray comma at the end of "frametime": 2,
Disregard this comment. Was wrong.
What the problem is is that the converter converts the numbers wrong. I edited the report to clarify. Sorry for the confusion.
I keep seeing the "stray comma" as a reason for the error. The mcmeta file is an html type format in the code within the file. the comma has to be there as it is a line seperator used by the program to understand a variable. If it isn't there the texture can break an either become non-animated or a series of purple and black squares.
I've noticed this same issue when I converted my texturepacks and removing this "," from the frametime variable breaks the texture. The TextureEnder.jar, just doesnt know how to handle long time frames. Pretty much any time that was over 10 seemed to convert to a 1.
Duplicate of MC-17936