So far, the only tickets for the scarpet script command “add_chunk_ticket” are portal [level 30] 300 ticks, teleport [level 32] 5 ticks, and unknown [level 33] 1 tick. The feature that I am suggesting is another ticket for the command, which is called a “dummy” ticket. The “dummy” ticket can be set from load levels 22 to 33. Valid load times for this “dummy” ticket are 1 to 300 ticks. Why no 34 to 44? There is no use for load levels 34 to 44 other than generating terrain. May you please add this feature? Thanks.

Valid load times for this “dummy” ticket are 1 to 300 ticks.

Why the 'arbitrary' 300 tick load time limitation? With the way the tick time is stored, you may be able to set a dummy chunk ticket to last 32,767, 65,535, or even 2,147,483,647 ticks depending on the data type. The latter is plenty of time to cover many chunk loader setups that deactivate after a while, as even a real-life week at 20 TPS would be only 12 million ticks, while the former two is also enough to make a chunk ticket last about 1 or 2.5 minecraft days (27 or 54 minutes).

The “dummy” ticket can be set from load levels 22 to 33.

It appears that load levels below 22 are technically valid, but as this is a modded environment, they should be possible if you are willing to load lots of chunks at once (up to 32 chunks radius from a single dummy ticket).

add_chunk_ticket was just a stub function to start with something. At some point I wanted to add a 'custom' ticket that takes any radius, and any duration and leave 'vanilla' tickets to only do what they are meant to do in vanilla (both in terms of range and duration), just never got around of implementing it. I will treat it as a another +1 for this feature.

The 2^31 tick time limit can be used, and the load levels below 22 can also be used. However, the radius variable needs to have a limit depending on the load level or else it could cause Minecraft to run out of RAM.

However, the radius variable needs to have a limit depending on the load level or else it could cause Minecraft to run out of RAM.

Maybe make it so the load level and radius must be such that it wouldn't load more than an effective radius of 32 entity-processing chunks, with a config setting to change or disable the limit?

well, the radius and the level are directly correlated and by design, you can't load more than 32 chunks out (65 diameter), right?

Maybe make it so the load level and radius must be such that it wouldn't load more than an effective radius of 32 entity-processing chunks, with a config setting to change or disable the limit?

Well, if the upper limit is customizable, there needs to be a hard upper limit, and this limit cannot be disabled, or else the game will still run out of RAM. Also, when making this custom ticket, just don’t let the timings get messed up when running /tick freeze or any other /tick command.

A hard upper limit of 32 entity-processing chunks radius per dummy ticket should do fine, no need for a config setting.

+1 to this.

Also, this might just be me but, I used the portal ticket level and it loaded the chunks as redstone processing and not entity processing. Is this a bug? Since the nether portals usually load chunks as entity processing, it strikes me as a possible bug.