——-> https://scratch.mit.edu/projects/943272790/editor/

Doubt many people would or could know, this is very complicated code you have here. There is a good chance that you have to edit the code as well.

Why would you want to? Unless Santa starts delivering early what would you be tracking?

deck26 wrote:

Why would you want to? Unless Santa starts delivering early what would you be tracking?

because i like Santa/Easter Bunny Trackers

lgrov44 wrote:

Doubt many people would or could know, this is very complicated code you have here. There is a good chance that you have to edit the code as well.

Please respond helpfully. Not saying you aren't but you could definitely provide a bit more support; just saying lol (no offense ofc).

delete this.

So the key is likely to be the ‘days since 2000’ block. That only seems to appear in the Countdown sprite.

Disabling the forever loops one at a time shows the countdown is relying on the ‘!days since 2000’ variable which is set in a loop to the value returned by ‘days since 2000’. So we don't know what the Unix time is used for but for the moment we concentrate on the variable mentioned - seems odd to have a variable to store the value of the block when we could just use the block.

So we need to search through the code again and find where that variable is used.

A useful trick is to rename the variable making its name much longer. It's then easier to spot the scripts that use it. Looks like Main loop is the only sprite that refers to it. Change the name back to the shorter name for easier debugging.

Notice that there are multiple references to the value 10957 being subtracted from a calculation involving the days-since variable. That seems like a likely culprit. A few tests using https://scratch.mit.edu/projects/419289093/ seems to show that that's the value for 31 December 2029. Not sure what that means! Also not sure what the values in the lists so let's look further.

There's also a script where we can see Santa has departed. That seems to rely on item 1 of the Departure time list / 86400000 (number of seconds in 1000 days??). Subtracting 10957 from that gives 9124.4. My project gives 9124.5 for midday on 24 December UTC time which will be approx midnight on Xmas Eve at the international date line. So we start to see something that makes sense.

Now in the first call to the custom block Precise Countdown we can see that changing the value 10957 will adjust the number of days in the actual countdown.

That's about as far as I want to pursue this. What I'd suggest is making a copy of the project so you can't lose what you currently have. Then set a global variable, initially set to 10957. Replace all occurrences of that value in the code with the variable that holds the value. Once you've done that you can try setting it to a different value to see what effect it has. Increasing the value reduces the number of days in the countdown so it's more like 2000 minus the required day number (very roughly) - all seems a bit odd. Using a variable instead of hard-coding a value would make more sense in a project like this anyway - makes it much easier to modify for another date.