-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SurvivalBlockBreakHandler: Take swimming, flying, climbing and effects into account #5581
Conversation
|
||
$effects = $this->player->getEffects(); | ||
if(($miningFatigue = $effects->get(VanillaEffects::MINING_FATIGUE())) !== null){ | ||
$breakTimePerSecond *= $breakTimePerSecond / ($breakTimePerSecond * 0.2 ** $miningFatigue->getEffectLevel()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How confident are you in this? Last time I checked, the values were different for Bedrock, which is why I didn't implement this properly to begin with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$breakTimePerTick = ceil($this->block->getBreakInfo()->getBreakTime($this->player->getInventory()->getItemInHand()) * 20);
$breakTimePerTick *= 1 - (0.3 * $this->player->getEffects()->get(VanillaEffects::MINING_FATIGUE())?->getAmplifier() ?? 0);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know where is your code from but according to the wiki:
The mining speed is reduced to 0.30^level of the normal mining speed. For the in-game default level III, the speed is reduced to 0.33 (0.027×) of normal speed, taking 37 times longer than usual to break a block with the proper tool for that block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The values from the wiki are wrong. The mining animation was too fast and already finished although the block was not broken yet.
$breakTimePerSecond *= $breakTimePerSecond / ($breakTimePerSecond * 0.2 ** $miningFatigue->getEffectLevel()); | ||
} | ||
if(($haste = $effects->get(VanillaEffects::HASTE())) !== null){ | ||
$breakTimePerSecond -= $breakTimePerSecond * 0.2 * min($haste->getEffectLevel(), 5); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same again here - I'm pretty sure the values differ from Java.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$breakTimePerTick = ceil($this->block->getBreakInfo()->getBreakTime($this->player->getInventory()->getItemInHand()) * 20);
$breakTimePerTick *= 1 - (0.2 * $this->player->getEffects()->get(VanillaEffects::HASTE())?->getAmplifier() ?? 0);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why maximize the haste level to 5? This is normally an effect that can theoretically have a level of up to 255. The only limit is haste 3 for arm animation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably because the break time can become negative if the haste level is higher than 5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably because the break time can become negative if the haste level is higher than 5
You're right. But I used the values from the wiki and it seems that they are wrong too. The animation is too fast.
The code I gave is correct I used the values of mcbe but also I tested and it did not create a problem and detected the correct time |
The calculation for the mining fatigue effect is very close to vanilla, but still wrong. |
This PR has been marked as "Waiting on Author", but we haven't seen any activity in 7 days. If there is no further activity, it will be closed in 28 days. Note for maintainers: Adding an assignee to the PR will prevent it from being marked as stale. |
Closing in favour of #6500 |
Introduction
Relevant issues
Changes
API changes
Behavioural changes
Backwards compatibility
Follow-up
Tests