Jumping down onto slime from a lower height will sometimes result in a higher bounce than jumping from higher, this feels unintended
Examples include:
+5 px (large amethyst), bounces up 1.33203 blocks
+6 px (daylight sensor), bounce 1.32920 blocks
+7px (campfire), bounce 1.38357 blocks
+7.5px (sideways chain onto trapdoor with slime underneath) bounce 1.34826 blocks
+31px (2 blocks + carpet) bounces 2.63145 blocks
+31.5px (2 blocks + lilypad) bounces 2.55096 blocks
Comments 4
Thank you for your report!
After consideration, the issue is being closed as Won't Fix.
Please note that this is not the same as Working as Intended, as this bug report correctly describes behavior in the game that might not be the intended or desirable behavior, but it will not be fixed right now. Sometimes, this is because the issue reported is minor and/or impossible to change without large architectural changes to the code base.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
@gnembon No, the new slime/bed bounce physics completely forget to take drag into consideration. Why are you asking questions and then resolving the report instantly?
I don’t see any reason to mark this as “won’t fix” instead of, if x% is (distance from slime in last tick)/(velocity), changing the formula from “x% of the way from (current velocity) to (what the velocity would be next tick if the entity kept falling with no drag)” to “x% of the way from (current velocity) to (what the velocity would be next tick if the entity kept falling)”
This is actually very possible. You may end up with different velocitities at the top depending on the quant of time/space the game runs on and total energy should be preserved. The game was loosing that energy before due to tick quant rounding errors, now it compensates for that. Is that the case?