Module
Enchanting

Is your feature request related to a problem? Please describe.
Targets players or entities which i dont want it to.
Describe the solution you'd like
Currently homing is an enchantment which targets the least distant mob including player who maybe friendly. It would be better if there was a system in place to determine which mob to target. This currently would need rewriting most of homing enchantment code.

Also there is currently a issue which causes homing to not work in off hand.

Reworked the current system to be more performance friendly by searching for entities in a cone shape from the shooter.

great feature that would be appreciated!

Can the "system" part be elaborated.

How do we determine target detection. Do we do a a cone based field of vision on the arrow? On the player? Or do we stick to a box based (AABB) field of view on the arrow/player? Do we instead pick a target based on the player's reticle? Do we lock onto a target once picked and stay locked on? What happens if the target dies before reached? If doing field of visions on the arrow entity itself do we constantly scan for new targets if available? How big should these areas of detections be? Do we instead take a totally different route and go based on most recent mob hostile to shooter and/or shooter hostile to mob approach?

For targeting other player entities: Do we just ignore all player entities completely? Or do we try to determine hostiles? Scoreboard team systems could be utilized.

How do we determine target detection. Do we do a a cone based field of vision on the arrow? On the player? Or do we stick to a box based (AABB) field of view on the arrow/player? Do we instead pick a target based on the player's reticle?

I haven't really thought out the system for it. I will answer the question which could be the base of the system. For field of vision currently homing enchantment implements a box shaped fov centered around the player it would be better if it based on what player can see. Locking based on player's reticle seems like a better idea.

Do we lock onto a target once picked and stay locked on? What happens if the target dies before reached?

Yes. Arrow can go to last location of the mob.

If doing field of visions on the arrow entity itself do we constantly scan for new targets if available? How big should these areas of detections be?Do we instead take a totally different route and go based on most recent mob hostile to shooter and/or shooter hostile to mob approach?

It should be based on player's field of vision not the arrow as it will much simpler to understand and implement. We shouldn't determine the target based on whether the target attacked or not.

For targeting other player entities: Do we just ignore all player entities completely? Or do we try to determine hostiles? Scoreboard team systems could be utilized.

Determining the hostile player based on scoreboard teams systems would be the best

Been looking into this, there's a major issue without relying on nasty hacks currently.
The Issue:
It's not possible afaik to detect the source of arrows when they spawn into the world, there's no way to know what bow it came from. Currently what's being done to detect this is to check the shooter's main hand every tick for the enchantment level. Obviously this will fail if the bow is moved out from the main hand. This enchantment level can be cached once when the entity is spawned but this still has the issue of other sources and relies on mainhand still. Sure you can look at both main and off but how do you know which it was shot from? Also what about dispensers(Forgot this doesn't work based on bow but rather the arrow item itself so this is perfectly fine)?

For what it's worth, the other bow enchantments also only care about mainhand, do we really need offhand?

public static final Enchantment POWER = register("power", new PowerEnchantment(Enchantment.Rarity.COMMON, EquipmentSlotType.MAINHAND));
public static final Enchantment PUNCH = register("punch", new PunchEnchantment(Enchantment.Rarity.RARE, EquipmentSlotType.MAINHAND));
public static final Enchantment FLAME = register("flame", new FlameEnchantment(Enchantment.Rarity.RARE, EquipmentSlotType.MAINHAND));
public static final Enchantment INFINITY = register("infinity", new InfinityEnchantment(Enchantment.Rarity.VERY_RARE, EquipmentSlotType.MAINHAND));

Cant the bow itemstack be cached so that it can be accessed easily? Also if vanilla enchantments doesn't care about off hand then off hand functionality for VanillaTweaks enchantment is not needed.

I'm more worried about the fact the moment an arrow entity is spawned in the world there's absolutely no way to know what spawned it, we can only make assumptions. And i'm talking about for mod compat. But we can just stick with the scan the shooter's mainhand once and cache it, call it a day.

I'm more worried about the fact the moment an arrow entity is spawned in the world there's absolutely no way to know what spawned it, we can only make assumptions. And i'm talking about for mod compat. But we can just stick with the scan the shooter's mainhand once and cache it, call it a day.

I would say to do as its better what was implemented before just checking the main hand every tick.

I.. seem to have run into a vanilla bug that totally makes this entire thing terrible.
Apparently Arrow's look vectors are correct when facing north or south however when they start to look either west or east the look vector yaw rotation does a 180. An arrow facing east has a look vector facing west and vice versa.
I was gonna do a scan box fov on the arrow mid flight until a target is found as it makes more sense than having the shooter have to target the entity itself but this bug makes it really dumb.
Infact take a look at this...

Scanning the arrow's fov kinda makes the enchantment overpowered like you can shoot the arrow in direction and player can do a 180 turn and it will kinda overpowered thats why i said do a scan for entities in player's fov cone.

I.. seem to have run into a vanilla bug that totally makes this entire thing terrible.
Apparently Arrow's look vectors are correct when facing north or south however when they start to look either west or east the look vector yaw rotation does a 180. An arrow facing east has a look vector facing west and vice versa.

I was gonna do a scan box fov on the arrow mid flight until a target is found as it makes more sense than having the shooter have to target the entity itself but this bug makes it really dumb.

Infact take a look at this...