In 1.16, it was possible to synchronously select an entity in the same tick that the chunk it's in is loaded. In 1.17, this is no longer the case.
This can be reproduced with the following commands in a function or using chain command blocks:
execute positioned 1000000 0 0 run forceload add ~ ~
summon minecraft:armor_stand 1000000 0 0 {Tags:['test']}
say @e[tag=test]The final command no longer will select the entity in 1.17. Scheduling the final command requires a delay of a few ticks (usually between 2-10) or else it will not select the armor stand.
Linked issues
is duplicated by 2
Comments 6
Not sure if this comment is appropriate/worth mentioning here, but this issue breaks several of my data packs (on https://vanillatweaks.net) that depend on selecting newly summoned entities in newly force-loaded chunks.
Edit: For those who are also running into this issue in their data packs, I've written a guide on working around it: https://gist.github.com/GrantGryczan/f0a51fc195f76da570d67826974bf2de#file-guide-to-working-around-mc-227930-md
None of the solutions I've detailed in this guide are a catch-all substitute for the option to synchronously force-load, but I tried to cover as many use cases as possible.
Being able to immediately select entities in chunks means the game is forced to always load chunks synchronously. This has very real implications for performance and isn't a design that we can support. We'd like to implement better support for detecting when a chunk becomes available in the future, but the issue brought up here is working as intended.
Would it be possible to add another variant to /forceload that has this synchronous behavior? As mentioned, a lot of mechanisms rely on this for correctness, even if it causes lag.
We did this ourselves in 1.16 on a Bukkit/Paper server -
/forceload add x1 z1 x2 z2
loads synchronously (vanilla behavior in 1.16), allowing subsequent commands to access everything in that chunk the same tick
/forceload addlazy x1 z1 x2 z2 [namespace:myfunction]
loads chunks asynchronously (sounds like the new behavior in 1.17, possibly taking several ticks) and optionally runs a function when those chunks have all finished loading
Agreed with the suggestion in the previous comment. Currently this issue can't feasibly be worked around in many use cases. In those cases, the performance cost is necessary given the way that data packs work. And generally, that cost is negligible anyway, since they are instances which only run once to load a single chunk, spawn an entity in it, and assign some data to the entity that we only necessarily have access to for one tick, which requires selecting it in the same tick it's summoned. Then it never runs again. It's not really an issue for performance to only run one synchronous chunk load per data pack during the world's entire lifetime.
Another use case this makes less feasible is chunk pre-generation. We can use the `/forceload` command for that in 1.16, but in 1.17, recursively spreading outward with `/forceload` commands throughout a very large area (of variable size) in order to generate chunks would take an extremely long time due to being asynchronous, with each iteration waiting for the previous iterations to finish, and there being tens of thousands of iterations.
The inability to have the option to synchronously load chunks completely breaks destroys tons of datapacks. Async loading would ordinarily be a good idea, but programming languages with async functionality usually have a callback function so you don't have to continuously poll to see if the task completed. What this change does is guarantee the majority of datapack makers' time will be spent ensuring their datapack doesn't run into race conditions every single time they want to interact with the world in any meaningful way. The /forceload command isn't even accurate anymore. It should be called /pleaseloadifyoufeellikeitsometimemaybe.
Might be related to the fix of MC-203745.