4
Datapack Block/Entity Removal
SUPERIONtheKnight
Hey fellas!
Lately I've been working on upgrading my Minecraft datapack known as Illumination to 1.16.5, and to the latest snapshot 21w19a. I've had a lot of success so far, and made a lot of improvements! However there is one thing that bugs me still, and I see no easy way around it. To understand my problem, let me first explain a little bit of my datapacks functionality.
Upon installing the datapack and typing /reload, you will be greeted with a message prompting you to add/remove a structure. Upon clicking this option, you will be given a spawn egg. This spawn egg can be placed anywhere in the world to place the structure wherever I want it to go. I even made a visual indicator to show where it will be placed to confirm that there are no special builds here. Once the structure is spawned, the worldspawnpoint is set to that location so I can easily remove the structure, and any entities that the structure contains when I need to uninstall everything. Or at least, that's how it used to work.
You see, any function commands run in a datapack are located at the worldspawnpoint by default, so by doing things this way, it could arguably be a little more difficult to break the datapack. However after giving it a lot of thought, I've decided that using the worldspawnpoint is not a good idea when using datapacks for the following reasons:
When we go to uninstall the datapack, how do we know that we actually removed all of the datapacks entities/blocks/etc from the world? This isn't really possible as far as I know because fill, setblock, kill, teleport, etc, are all limited to only running in loaded chunks. I suppose that we could forceload the location to make the chunks loaded no matter what, however this can get expensive quickly, and IMO seems to be unnecessary. That's also assuming the command works in function files as I haven't tried it. Furthermore it could also be tricky to remove the forceloaded chunk if something goes wrong.
So now the question we've all been waiting for. How do you guys get around this problem? Obviously, I don't think this can be addressed entirely, but I'm curious to hear about how others might have dealt with a similar situation in one of their datapacks. :)
Thanks for reading! Looking forward to reading what you guys have to say! :)
Lately I've been working on upgrading my Minecraft datapack known as Illumination to 1.16.5, and to the latest snapshot 21w19a. I've had a lot of success so far, and made a lot of improvements! However there is one thing that bugs me still, and I see no easy way around it. To understand my problem, let me first explain a little bit of my datapacks functionality.
Upon installing the datapack and typing /reload, you will be greeted with a message prompting you to add/remove a structure. Upon clicking this option, you will be given a spawn egg. This spawn egg can be placed anywhere in the world to place the structure wherever I want it to go. I even made a visual indicator to show where it will be placed to confirm that there are no special builds here. Once the structure is spawned, the worldspawnpoint is set to that location so I can easily remove the structure, and any entities that the structure contains when I need to uninstall everything. Or at least, that's how it used to work.
You see, any function commands run in a datapack are located at the worldspawnpoint by default, so by doing things this way, it could arguably be a little more difficult to break the datapack. However after giving it a lot of thought, I've decided that using the worldspawnpoint is not a good idea when using datapacks for the following reasons:
- There can only be one.
- What if the player is using the worldspawnpoint for some redstone contraption?
- What if there is another datapack, or some command creation that needs the one and only worldspawnpoint?
When we go to uninstall the datapack, how do we know that we actually removed all of the datapacks entities/blocks/etc from the world? This isn't really possible as far as I know because fill, setblock, kill, teleport, etc, are all limited to only running in loaded chunks. I suppose that we could forceload the location to make the chunks loaded no matter what, however this can get expensive quickly, and IMO seems to be unnecessary. That's also assuming the command works in function files as I haven't tried it. Furthermore it could also be tricky to remove the forceloaded chunk if something goes wrong.
So now the question we've all been waiting for. How do you guys get around this problem? Obviously, I don't think this can be addressed entirely, but I'm curious to hear about how others might have dealt with a similar situation in one of their datapacks. :)
Thanks for reading! Looking forward to reading what you guys have to say! :)
Create an account or sign in to comment.
7
2
Ey Superi0n!
Nice seeing you still being active and all... been a long time and I don't recall everything from mind but considering that I seem to be subscribed to you I'm pretty sure you're the guy I think you are 😁
Anyway.. You should look into /forceload. This is a vanilla command which actually allows you to forceload an area and keep it active. Check this link for the wiki page on the command which also has several examples.
Nice seeing you still being active and all... been a long time and I don't recall everything from mind but considering that I seem to be subscribed to you I'm pretty sure you're the guy I think you are 😁
Anyway.. You should look into /forceload. This is a vanilla command which actually allows you to forceload an area and keep it active. Check this link for the wiki page on the command which also has several examples.
1
Hey Shell! Yea it has been a while! Believe it or not, I actually am just making a return somewhat recently. :)
I appreciate the suggestion! I actually already have thought about using the forceload command, but there is a problem. It can in theory cause a lot of lag over time.
Lets say one of my entities are in some random chunk. I forceload the chunk to keep said entity loaded, and use the entity for remembering the chunk location. Now I can remove the chunk when I go to get rid of the entity. Sounds good in theory, but what if the player runs a "/kill @e" command manually(or even "/teleport @e @s")? Now I have no idea where the forceloaded chunk is, and this process could in theory repeat and get out of control over time. My datapack is pretty small, so I don't think it would be that big of an issue for this specific use case. However I do plan to scale things up in the future with a larger datapack, and this could be problematic. I suppose I could use "/forceload remove all", but then what if another datapack/command creation needed some of those chunks?
But yea thanks again for the idea! Hopefully we can bump into each other again sometime soon! Been too long! :)
I appreciate the suggestion! I actually already have thought about using the forceload command, but there is a problem. It can in theory cause a lot of lag over time.
Lets say one of my entities are in some random chunk. I forceload the chunk to keep said entity loaded, and use the entity for remembering the chunk location. Now I can remove the chunk when I go to get rid of the entity. Sounds good in theory, but what if the player runs a "/kill @e" command manually(or even "/teleport @e @s")? Now I have no idea where the forceloaded chunk is, and this process could in theory repeat and get out of control over time. My datapack is pretty small, so I don't think it would be that big of an issue for this specific use case. However I do plan to scale things up in the future with a larger datapack, and this could be problematic. I suppose I could use "/forceload remove all", but then what if another datapack/command creation needed some of those chunks?
But yea thanks again for the idea! Hopefully we can bump into each other again sometime soon! Been too long! :)
2
Nah, I don't mean for the entities; those should eventually despawn themselves, but for the structure you spoke off. Since your routines place the structure it should be doable to check (and store) the location of placement. That information should then be usable to define the "force loaded" region as well as provide enough info to remove said region later.
But speaking of those entities.. I'm not sure from mind but iirc you should be able to use a flag which would prevent them from despawning, however; not sure what effect that would have on the chunk(s), could test that with a fish bucket: every fish you release that way doesn't respawn.
Anyway, I'd focus on the structure and leave the entities as they are. Maybe simply refer to this in the documentation: that unloading / de-installing would remove the structure but would leave the entities.
But speaking of those entities.. I'm not sure from mind but iirc you should be able to use a flag which would prevent them from despawning, however; not sure what effect that would have on the chunk(s), could test that with a fish bucket: every fish you release that way doesn't respawn.
Anyway, I'd focus on the structure and leave the entities as they are. Maybe simply refer to this in the documentation: that unloading / de-installing would remove the structure but would leave the entities.
2
Pretty sure the entities he mentions check and stores locations of placement and then removes it when uninstalled.
As they stated, the command doesnt get to those entities in unloaded chunks 10k blocks away from the player, and more forceloaded chunks = more loaded entities around the chunk = more lag
SUPERIONtheKnight in terms of the /kill @e, for most datapacks they would have some entity used for something important. I dont think you can really do anything in this case
As they stated, the command doesnt get to those entities in unloaded chunks 10k blocks away from the player, and more forceloaded chunks = more loaded entities around the chunk = more lag
SUPERIONtheKnight in terms of the /kill @e, for most datapacks they would have some entity used for something important. I dont think you can really do anything in this case
1
Correct! That's exactly what the datapack does. :)
If I were to go with the forceloaded chunk idea, I'd want to make sure that the entity used to store its location also gets removed. This is simple enough, and should in theory result in no extra entities/forceloaded chunks left behind. However like I said, it's kind of difficult to know when a player moves it, or kills it, and how to deal with the leftover forceloaded chunks as I'd have no idea where they are located if such was done(they could be located 10k blocks away just like you said). So yea I agree, so far I'm not sure if there is a workaround to that or not. I am still open to ideas though. :)
If I were to go with the forceloaded chunk idea, I'd want to make sure that the entity used to store its location also gets removed. This is simple enough, and should in theory result in no extra entities/forceloaded chunks left behind. However like I said, it's kind of difficult to know when a player moves it, or kills it, and how to deal with the leftover forceloaded chunks as I'd have no idea where they are located if such was done(they could be located 10k blocks away just like you said). So yea I agree, so far I'm not sure if there is a workaround to that or not. I am still open to ideas though. :)
1
Ah, fair enough. I didn't realize that's what you meant. In that case, that is a lot easier to do for sure.
Anyways in regards to the structures, how do you suggest knowing where the structure is located? I can always know where a loaded entity is via "/execute at", and use the entity to know where the structure is, but I don't know of that many other options. I actually already have a function that stores the coordinates of the structure into a scoreboard(just like you suggested :)), and it's capable of teleporting the player to that location without the need of an entity being inside of the structure. However I just made this function very recently and I'm not sure how reliable it is just yet. So it does seem like what you are suggesting is possible, just not sure if this solution that I have is the best approach or not yet.
I will look into this some more as it very well could be an improvement. Thanks for the clarification! :)
Anyways in regards to the structures, how do you suggest knowing where the structure is located? I can always know where a loaded entity is via "/execute at", and use the entity to know where the structure is, but I don't know of that many other options. I actually already have a function that stores the coordinates of the structure into a scoreboard(just like you suggested :)), and it's capable of teleporting the player to that location without the need of an entity being inside of the structure. However I just made this function very recently and I'm not sure how reliable it is just yet. So it does seem like what you are suggesting is possible, just not sure if this solution that I have is the best approach or not yet.
I will look into this some more as it very well could be an improvement. Thanks for the clarification! :)
2
I personally dont think theres an actual satisfactory workaround for this.
What im thinking of, is maybe you can activate an uninstall datapack when the main datapack uninstalls. All this does is remove the entities and their structures whenever they load their old chunks. But this is incredibly flawed
You can also ask the command block pros at r/MinecraftCommands' discord server
What im thinking of, is maybe you can activate an uninstall datapack when the main datapack uninstalls. All this does is remove the entities and their structures whenever they load their old chunks. But this is incredibly flawed
You can also ask the command block pros at r/MinecraftCommands' discord server
