• 0

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.
Posted in: Resource Pack Discussion
• 0

Quote from Alvoria
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.
Posted in: Resource Pack Discussion
• 0

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.
```Hour Tick time
------ ---------
07 166
08	 1163
09	 2219
10	 3355
11	 4600
12	 5999.5
13	 7399
14	 8644
15	 9780
16	 10836
17	 11833
18	 12785
19	 13701
19.2 13880
20	 14590
21	 15459
22	 16313
23	 17159
00	 17999.5
01	 18840
02	 19686
03	 20540
04	 21409
04.8 22119
05	 22298
06	 23214```

Posted in: Resource Pack Discussion