May be intended. Happens both in regular and deep freezes (maybe stopping them in deep ones but not in regulars, if intended?).

Relates to #398

From #581 (comment):

My view of this:

PROS:

• Functions or apps that rely on actual ticks would always get accurate information
• It seems logical ("makes sense") that processing stops when the Game is frozen
• If shapes expiry time is also paused, would not affect debuggers with shapes, but may even make them better in case they vary based on execution number
• Apps that get data from the environment would not incorrectly update (e.g. app getting info from ticking command blocks)

CONS:

• Functions wouldn't run when the Game is frozen (not really a con in most cases, it's basically the premise of the issue)
• If shapes expiry time is not paused, would make debuggers useless when frozen
• Carpet-less clients wouldn't be sent new particles for shapes in debuggers, including regular particles

Tickrate is synced with clients, so shapes expiry time could be easily paused. Therefore the only con I see would be the last one.

Maybe making it be deep-only to allow compatibility if someone really needs the feature, but that would also make it harder to find, and I personally can't find any use case. Please comment one if you have it.

EDIT: Ok I found one: Actually controlling a freeze, something like temporary freezing the game for x ticks.

In progress PR:

• Stop tick functions from datapacks
• Stop tick events and freeze schedules in Scarpet
• Sync frozen state to the client
  • Make the required packet info
  • Handle that new packet info
  • Find a way to tick the client's TickSpeed in servers (to make tick step and maybe tick superHot render properly)
  • Add 1 to duration of shapes every client tick if frozen

The PR should actually also make freezes look good/better in servers.

hmmm

May break apps that provide shapes if their expiry time is still ticked in the client.

Its something that is not right or wrong here unfortunately. I think I should use deep frozen state in these kinds of situations.

So what's wrong with deep freeze supporting freezing of datapacks and apps?

Oh idk about datapacks, I think those (the minecraft:tick thing) should be frozen too, but not sure where to mix for that. I'd say those should be actually frozen in both types.

Will have to investigate if closing both.

I asked the question in discord just because it's marked as rfc (rfc == request for comments, right?).

Wait. On what freezes should __on_tick() be frozen? Thought it didn't tick when game was frozen. Seems counter-intuitive (for someone who may not know that the game still ticks in a freeze)