Grant's Guide to Working Around MC-227930 Being Resolved as "Works As Intended"
As of Minecraft 1.17, we can't forceload
a chunk, summon an entity into the chunk, and immediately select that entity, all in the same tick. In fact, we can't select any entities in newly loaded chunks until an arbitrary amount of ticks have passed while the chunk fully loads. I've come up with a few ways to work around this, depending on your use case, but none of these solutions are flawless. I may edit this post to include more or make revisions in the future. If you have feedback or suggestions on any of this, feel free to post a comment or message me on Discord @Grant#2604.
- Because chunks now take an arbitrary, unknown amount of ticks to fully load, we can't just schedule a constant time ahead. So there's not really any way to do this other than running a function that tries to select your entity, and schedules itself to run again every tick it doesn't find it. Once it does find it, do whatever you need to do.
- This isn't a viable solution if the information needed to do something with the entity is time-sensitive and may have changed or became unavailable while the chunk was loading. For example, if you need to copy data from a player to an entity in a newly loaded chunk, you can't be certain the player is still online by the time the chunk finishes loading.
2. Summon the entity in a chunk you know is loaded, execute as
it, tp @s
into the newly loaded chunk, and select it with @s
.
- This solution works because
@s
is selectable regardless of whether it's in a fully loaded chunk. - It's not always possible to be sure an area is loaded unless you additionally use solution #1. Spawn chunks can move. Force-loaded chunks require a delay. Even chunks loaded by the player don't load synchronously, and so they can't be guaranteed to be selectable unless you test it. So if you do this, be careful not to assume a chunk is loaded.
- This isn't a viable solution if you can't guarantee any chunks to be loaded, and you can't afford solution #1 to wait for any chunks to be loaded.
- This also isn't a viable solution if you need to select the entity in the ticks immediately following it being summoned, because after the function being run from
execute as
finishes, the context which allows selecting the entity via@s
no longer exists.
- If an entity with a custom UUID is in memory (i.e. if it was
summon
ed or has ever been loaded before during the current session), you can select it directly by its UUID. For example,summon minecraft:marker ~ ~ ~ {UUID:[I;1,2,3,4]}
will create an entity that is immediately selectable via00000001-0000-0002-0000-000300000004
for as long as the entity is in memory. If youforceload
the chunk the entity is in, this guarantees the entity will (almost, see next point) always be selectable by its UUID, starting as soon as it is summoned. - The entity will not be immediately selectable if the server (or singleplayer world) restarts. After a restart, it will only be selectable after a few ticks have passed for the chunk to fully load and the entity to be in memory again. If that's a problem for you, this isn't a viable solution.
- This also isn't a viable solution if you don't have a constant set of known, static entities, and you can't guarantee there to be no UUID conflicts in your pack. Only one entity should have a particular UUID at a time.
- Do not
kill
and re-summon
an entity with the same UUID! Killed entities are not always completely removed from memory, so summoning a new one with the same UUID as a previously killed one may create a UUID conflict.
4. loot spawn
an item into the newly loaded chunk, and replace the item entity with your entity once it is selectable.
- To solve the issue with solution #1 where necessary information may be time-sensitive, use loot table functions (item modifiers) to perform the NBT modifications as soon as the entity is summoned, rather than having a wait a few ticks for the modifications to be performed.
- If you want to use the
data
command to perform your NBT modifications rather than being restricted to any limitations of loot table functions or item modifiers, just perform yourdata
operations in storage beforehand, and then use an item modifier on the loot table to copy the NBT from storage to the item. - This still has the issue of the entity not being immediately selectable, and it requires detecting the item after it is summoned (ideally by running a function that
schedule
s itself with1t append
until it finds the item entity) and replacing the item entity with your desired entity. - For example, if you want to summon a
minecraft:marker
, you will need to wait for yourminecraft:item
to be selectable, and thensummon minecraft:marker
in its place, copying the item'sItem.tag
to the marker'sdata
and killing the item.
@GrantGryczan Ah yes I forgot to put that in my comment, but that is how I've been testing as well. More like this:
execute at @s [player] summon marker ~ ~ ~
execute as @e[type=marker] run function debug:2
execute in the_nether run tp @s ~ ~ ~
execute at @s run function debug:3
execute at @s run forceload add ~ ~
execute at @s run tp @p @s
summon pig or whatever, just testing
Afterwards the marker is in the nether, but the pig is in the overworld, along with the forced chunk, etc.
The use case I'm doing requires transfer of Pos data to the marker as well, but I am leaving it out since the dimension switch is the same issue.
The
forceload
is included so I can determine where the command is executing by querying after, and the as @s is just to be sure haha.This example is heavily simplified for what I'm trying to do, this is just what demonstrates the problem. This is for my Mystcraft Datapack, for a feature similar to homes.
Did you happen to get this technique working in VT Homes? If you did I can just study how it was done there, but I'm not looking to do something as complicated - checks or feedback etc.
Thank you Grant