Add ExperienceOrb attracts lock feature

[ShockedPlot7560]

Introduction

As explained in the issue #4589 , there is a need to allow developers to remove players from the attraction of xp orbs.

Relevant issues

• Fixes ExperienceOrb: no possibility of interfering in search for target entity #4589

Changes

API changes

The following methods have been added to the ExperienceManager :

• isAttractsLocked : Returns true if the Human no longer accepts xp orbs attracts, false otherwise
• setAttractsLocked : The setter to change the acceptance status of xp orbs

Behavioural changes

In ExperienceOrb:

• The getTargetPlayer method will no longer return an instance of Human if isAttractsLocked return true for the instance
• The setTargetPlayer method will no longer choose a Human that returns true to isAttractsLocked
• In entityBaseTick the orb will no longer choose a target that returns true to isAttractsLocked

Follow-up

No specific action is required

Tests

• To test the normal system, mine a block of diamond ore in survival and the orb will indeed follow you.
• To test the locked system, create a plugin that disables orbs by default for any given player and it will look like this:
  

[ColinHDev]

Unexpected, but an interesting-looking solution.

[ColinHDev]

This looks really overcomplicated. This would be much simpler

if($player !== null && !$player->getXpManager()->isAttractsLocked()){
			$this->targetPlayerRuntimeId = $player->getId();
		}else{
			$this->targetPlayerRuntimeId = null;
		}

or

$this->targetPlayerRuntimeId = $player !== null && !$player->getXpManager()->isAttractsLocked() ? $player->getId() : null;

But does this check even belong there? In every case, where pm would set the target player itself, it does the checks alone. So shouldn't plugin devs be required to do their own checks? Possibly someone wants to bypass the lock of another plugin (whyever).

[dktapps]

No, it doesn't belong here. If the player can't be tracked, the orb should try to find a different target.

[dktapps]

This whole change is redundant.

[dktapps]

Code looks OK (as in it will work) but attractsLocked is a really abysmal name.

[ShockedPlot7560]

Wouldn't it be better to call it :

• attractsExperienceOrb
  or
• orbSeverity

It must be made clear in the name that this property must be able to be used to cut the gravitation of the orbs around the player and remove his ability to recover them

I otherwise agree that the changes in setTargetPlayer or getTargetPlayer its rather redundant and deserves to be removed to allow the developers more freedom.

[dktapps]

canAttractXpOrbs and setCanAttractXpOrbs would be better (for consistency with other methods).

[ShockedPlot7560]

Indeed, it makes a little more sense

[dktapps]

Tested and found working.