Warp Shrines

[maxheyn]

Project Page: https://github.com/maxheyn/warp_shrines

[oOBoomberOo]

A bounty of $10 has been added to this review. You will be rewarded if you choose to review this datapack.

Keep in mind that I will be expecting a high-quality review with this bounty.

[EstEarth202]

• Request review: If you have, please include every website where your datapack is published. It doesn't have to be just GitHub or Planetminecraft. And if you're on the Minecraft Datapacks discord server, add your Username#0000 as well.
  • Review type: please also specify the type of review you require.
    • Certified Compatibility ✅ Only
    • Certified Compatibility ✅ + Style Guideline Followed 📚 (Optional)

[maxheyn]

Published Websites

• https://www.planetminecraft.com/data-pack/warp-shrines-teleport-between-locations/
• https://github.com/maxheyn/warp_shrines

Discord User

• Maxypoo#4327

Review Type

• Just Certified Compatibility ✅

[EstEarth202]

Certified Compatibility ✅

You can now use the first certified banner for this datapack. The link to your datapack will also be posted on the #certified-datapacks channel.

⚠━━━━━・Important ・━━━━━⚠

Global ignoring tag ✅

Namespace Convention ✅

If you have more than one datapack project, I need to recommend this, I hope it will be useful to you.

Suggest (Optional): Please note: Namespaces are not recommended as datapack names (except standalone), which may cause some issues.

Datapack Advancement

• Cause: use namespaces as datapack names and follow 3. Datapack Advancement the advancement should be inside /data/<namespace>/advancements/<datapack name>.json.
• Issue: /data/<datapack_name>/advancements/<datapack_name>.json

data
 ├ <namespace> <- It doesn't make sense to set it as datapack_name.
 │    └ advancements         
 │        └ <datapack_name>.json
 ├ <global>
 │    └ advancements
 │        ├ <namespace>.json <- "This is creator_head" * That's why
 │        └ root.json

• Solution: fact its creator name.
• Because: you have more than one datapack under the namespace, it will be very helpful when you work on workspace.
• Result: <creator_name>:<datapack_name> prefix is to identify who created it and suffix to tell about datapack. This will be explained further in Directories guideline

Scoreboards and teams: (1.17 and below)

• Shouldn't: use shortened prefix as datapack name.
• Cause: suppose datapack Bounce block uses objective as bb.var.
• Result: if bb is shortened prefix from boomber. It can be an issue.
• Please note: It is difficult to verify this. This makes it inconvenient for the reviewer, and therefore cannot guarantee that certified datapacks will not cause scoreboard conflicts.

Scoreboards and teams: (1.18 and higher) | Tags: (1.13 and higher)

• Should: use a full prefix.

Directories guideline

Guideline Optional

• Multiple datapacks: If possible, I would recommend the following.

Q: If I use creator_name instead of datapack_name. I'm going to have an issue like this

"friendly_beacon:main" -> "boomber:main"
"shulker_mob:main" -> "boomber:main"

A: You can create sub-folders inside functions folder.

boomber/functions/friendly_beacon/
boomber/functions/shulker_mob/

"friendly_beacon:main" -> "boomber:friendly_beacon/main"
"shulker_mob:main" -> "boomber:shulker_mob/main"

If you want an example guideline, I have it.

data
 ├ <your_name>
 │    ├ advancements
 │    │   ├ <datapack_name>
 │    │   │   ├ <event>
 │    │   │   │   └ <player_hurt_entity>.json
 │    │   │   ├ <place>
 │    │   │   │   └ <place_block>.json
 │    │   │   └ <folder advancement groups>
 │    │   └ <datapack_name>.json
 │    ├ functions
 │    │   ├ <datapack_name>
 │    │   │   ├ <folder function groups>
 │    │   │   ├ main.mcfunction or tick.mcfunction
 │    │   │   ├ setup.mcfunction or init.mcfunction
 │    │   │   └ uninstall.function
 │    │   └ <database, random & etc.>
 │    ├ loot_tables
 │    │   └ <datapack_name>
 │    │       └ <loot folder groups item, block>
 │    │           └ <...>.json
 │    ├ predicates
 │    │   └ <datapack_name>
 │    │       ├ <folder predicate groups>
 │    │       └ <...>.json
 │    ├ recipes
 │    │   └ <datapack_name>
 │    │       └ <...>.json
 │    └ tags
 │        └  <items>
 │            └ <datapack_name>
 │                └ <...>.json
 ├ <global>
 │    └ advancements
 │        ├ <your_name>.json
 │        └ root.json
 └ <minecraft>

More facts from the perspective of convention mod

In datapacker circles, there are identical datapacks created by different datapackers, with the same functionality. (with different command's algorithm in different datapacker methods, but with the same result) and may be slightly different, according to the functionality and design features.

Example cool stuff datapack here

• Veinminer by Boomber
• VeinMiner by Gnottero
• Vein Miner Unified by Elemend

For example, the veinminer datapack, if you use a namespace is vm and other datapackers use too, it's an issue. And not explicitly identify under the datapacker's name. Because it was not grouped or class directly under datapacker's name, which lacks flexibility and easy maintenance.

Note: But this is not disallowing you to use namespace as datapack name.

Fictitious directory example:

data veinminer:main
 ├ veinminer
 ├ <global>
 │    └ advancements
 │        └ convention.json

data - villager_magic:main
 ├ villager_magic
 ├ <global>
 │    └ advancements
 │        └ convention.json

data - veinminer_faq:tick
 ├ veinminer_faq
 ├ <global>
 │    └ advancements
 │        └ faq.json

data - vm:tick
 ├ vm (Virtual Magic)
 ├ <global>
 │    └ advancements
 │        └ faq.json

function veinminer:main
function villager_magic:main
function veinminer_faq:tick
function vm:tick

Or

data - convention:veinminer/main
 ├ convention
 │    └ functions
 │        └ veinminer
 ├ <global>
 │    └ advancements
 │        └ convention.json

data - convention:villager_magic/main
 ├ convention
 │    └ functions
 │        └ villager_magic
 ├ <global>
 │    └ advancements
 │        └ convention.json

 data - faq:veinminer/tick
 ├ faq
 │    └ functions
 │        └ veinminer
 ├ <global>
 │    └ advancements
 │        └ faq.json

data - faq:virtual_magic/tick
 ├ faq
 │    └ functions
 │        └ virtual_magic
 ├ <global>
 │    └ advancements
 │        └ faq.json

function convention:veinminer/main
function convention:villager_magic/main
function faq:veinminer/tick
function faq:virtual_magic/tick

But from the above example, which one do you think looks better? Here, I think it's better to let the user see both the creator name and the datapack name when typing the /function command. Instead of just the datapack name. I hope this helpful to you in datapacking.

Note: This is a draft I prepared to bring more detail and comprehension to the conventions, but it isn't complete enough to publish on the conventions' page at this time.

Additional Suggesttion

Try to check data\warp_shrines\functions\shrines\thrown_pearl.mcfunction I see that line 18 contains execute run scoreboard players add $ws_shrineCount ws_linkID 1.