4
Tips when making data packsnotes
Sul4ur
As a data packer myself, I've seen a lot of data packs. However, most of them have a lot of issues. Some issues that can be fixed very easily. So I made this forum thread, so almost no one makes these mistakes again. This tips are both for new and easy-coded and hard-coded data packs. Yes, even some of the biggest data packs make these mistakes.
- Use images or videos. "An image is worth a thousand words." - said a wise man. This is an issue even some of my own data packs have. Try to explain using pictures more than words.
- Avoid using long sentences in your descriptions. No one (except for nerds of course) likes to read a lot. Try to use images more instead to explain the data pack.
- Use smithed rules. It is a great wiki for you to make your data packs compatible with more other data packs. In other words, It increases the compatibility chance with other data packs. It also serves some libraries that also help make your data packs compatible with each other.
- Use namespaces in scores, storages, teams, etc. A very often mistake most data packers make. Namespace is a tool to make your files, scores, anythng you say not collide with each other. For example, a mod adds an item called amethyst. but then another mod also adds amethyst itself. Not to mention, even minecraft ends up adding amethysts. But they don't seem to break with each other. why? Because they used namespaces, otherwise known as id of the data pack/mod. They allow data packs/mods to identify which item belongs to the mod. This is unfortunately not used very much in things such as scores. Here is an example of what you should do:
# Instead of
scoreboard objectives add dummy dummy
data merge storage data {foo: "bar"}
# You should use
scoreboard objectives add easier_nametags.dummy dummy
data merge storage easier_nametags:data {foo: "bar"} - Don't ask users to do /reload. 70% of data packers make this mistake. Now it's okay, not using this tip won't bring too many problems, however, the problem is that /reload-ing takes a very long time, when users can just do:
/function #minecraft:loadWhich takes less than a second, and will work still in the same way. Now note that this is only used if you want to run load functions on players, not if you made changes to the data pack or something. And if that's the case, you don't even need to ask them to run any commands. You will just have to setup a loop that detects players and if there is one, run the function:# In load.mcfunction:
execute unless entity @a run schedule function <you_namespace>:load 20t
execute as @a if entity @s at @s run function <your_namespace>:<your_desired_function>Other ways of doing thisThese commands below have not been tested, but from what I can tell, they should work.
If you want to tell it to all players and not just one:# In load.mcfunction:
scoreboard objectives remove <your_namespace>.check_if_loaded
scoreboard objectives add <your_namespace>.check_if_loaded
execute as @a[scores={<your_namespace>.check_if_loaded=0}] at @s run function <your_namespace>:<your_desired_function>
# In your desired function:
<your desired commands go here>
scoreboard players set @s <your_namespace>.check_if_loaded 1
If you want to tell it to all players only once and not during every reload: just remove the "scoreboard objectives remove <your_namespace>.check_if_loaded" commad and you're good to go.
Create an account or sign in to comment.
2
😺
I highly agree with point 4 ^^
That alone should make your datapack compatible with almost any other pack tbh.
That alone should make your datapack compatible with almost any other pack tbh.
