Smithed-MC/Libraries

[Feature]: Add a new tag. "smithed.team"

Closed this issue · 0 comments

Which library (or new library) would this feature fit into
mcfunction

Describe the feature you wish and why you need it
Before you start reading, I would like to clarify that, my post will sound completely offtopic, but its complete relation is towards smithed convention.
Starting the post...

As we know, there are custom mobs which uses smithed.entity tag on them.
But there are 2 types of custom mobs which I have discovered.

  1. Custom Mobs with default behaviour.
  2. Custom Mobs with completely different behaviour than normal.

Most people add custom mobs with default mob behaviour. But people like me create datapacks like this https://www.planetminecraft.com/data-pack/village-guards-1-16-by-sameer-99/ which completely changes the mob behaviour.
It simply adds skeletons with green armor to indicate "Village Guards" where, it adds iron golems, snow golems, green skeletons, villagers, and players to /team join player @s to avoid the green skeletons from attacking iron golems and players.
This was the description of my datapack. Getting back to the point.

Example 1:
Imagine someone creates a custom mob called "Evil Golem". This will be an evil mob and is supposed to attack player. But my village guards datapack is obviously colliding with it bcoz even if its called "Evil Golem", its still a minecraft:iron_golem and it will not attack the player bcoz they are the same teams. Isn't this a problem? Now you would probably say, "cmon man, instead of using /team join player @e[type=iron_golem], just use /team join player @e[type=iron_golem,tag=!smithed.entity], and everything will be fine, wouldn't it be?" Wrong.

Why? Lets consider another case where there is another someone who decided to create custom mob called "Giant Golem" datapack. This datapack is just a default iron golem but better model and buffed, it does not change the original behaviour of that mob. And ofc, that golem is also supposed to be added in team "player" by my village guards datapack. But just bcoz they use smithed.entity, it won't be added to team and "Giant Golem" will attack my village guards.

Now there are 2 mobs. "Evil Golem" and "Giant Golem". We have to add "Giant Golem" to the player team without adding "Evil Golem". This is where smithed.team comes in. "Evil Golem" will use the tag {Tags:["smithed.team"]} but "Giant Golem" won't and I will use /team join player @e[type=iron_golem,tag=!smithed.team]. This way, "Evil Golem" will also attack the player. Problem is fixed.

Example 2:
Imagine someone creates a datapack called "Skeletons friendly fire fix" datapack. It will simply fix the skeletons from accidentally getting into a fight bcoz of wrong target hit. How would this datapack work? Obviously it will add every skeleton to /team join skeletons @e[type=skeleton] which will avoid skeletons from attacking each other bcoz same team. But you see, if someone installs this datapack with my Village Guards datapack, iron golem will kill the green skeletons just bcoz they will be added to other team called skeletons by another datapack. So I will use {Tags:["smithed.team"]} tag for my village guards (green skeletons) and the other datapack will use /team join skeletons @e[type=skeleton,tag=!smithed.team]

Describe alternatives you've considered
What could be an alternative solution for this? I don't see any other solution. Just consider adding smithed.team tag for mobs.

If you need a new library, why won't this feature fit into an existing library
mcfunction is fine. No need of new library.

Do you have any code examples, partial implementations, etc
Description of smithed.team: This tag indicates that a mob's behaviour is completely changed from vanilla and it shouldn't be treated as vanilla mob.

Additional context
No