Skip to content
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

Fix: solve teleportation time overflow problem. #4163

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

Violet-Nonbloosom
Copy link
Contributor

Description

In TP time calculation, $\rm complexity \times complexity$ may result in int overflow when complexity is higher than $4\times 10^{4}$, not difficult to achieve with several popular addons.

Compared with original solution based on Math function, it is better to avoid overflow directly.

Proposed changes

Use long to storage temporary speed variable, which hardly overflow in TP time calculation.

If $\rm speed > distance$, time cost must be 1 tick, so we can skip calculation.

Otherwise, $\rm \dfrac {distance}{speed} \geq 1$, while speed must be in range of int.

Therefore we can simply convert speed to int variable to calculate ultimate time cost.

Related Issues (if applicable)

Checklist

  • I have fully tested the proposed changes and promise that they will not break everything into chaos.
  • I have also tested the proposed changes in combination with various popular addons and can confirm my changes do not break them.
  • I have made sure that the proposed changes do not break compatibility across the supported Minecraft versions (1.16.* - 1.20.*).
  • I followed the existing code standards and didn't mess up the formatting.
  • I did my best to add documentation to any public classes or methods I added.
  • I have added Nonnull and Nullable annotations to my methods to indicate their behaviour for null values
  • I added sufficient Unit Tests to cover my code.

@Violet-Nonbloosom Violet-Nonbloosom requested a review from a team as a code owner March 22, 2024 03:46
Copy link
Contributor

Pro Tip!
You can help us label your Pull Requests by using the following branch naming convention next time you create a pull request. ❤️

Branch naming convention Label
feature/** 🎈 Feature
fix/** ✨ Fix
chore/** 🧹 Chores
api/** 🔧 API
performance/** 💡 Performance Optimization
compatibility/** 🤝 Compatibility

If your changes do not fall into any of these categories, don't worry. You can just ignore this message in that case! 👀

Copy link
Contributor

github-actions bot commented Mar 22, 2024

Slimefun preview build

A Slimefun preview build is available for testing!
Commit: afc7325

https://preview-builds.walshy.dev/download/Slimefun/4163/afc73256

Note: This is not a supported build and is only here for the purposes of testing.
Do not run this on a live server and do not report bugs anywhere but this PR!

Sfiguz7
Sfiguz7 previously approved these changes Mar 23, 2024
Sfiguz7
Sfiguz7 previously approved these changes Mar 23, 2024
Copy link
Contributor

@JustAHuman-xD JustAHuman-xD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some code style stuff

@J3fftw1
Copy link
Member

J3fftw1 commented Mar 27, 2024

Why are we moving it to a long? Aren’t we delaying the issue then, this isn’t solving the issue.

should limit it to a value instead of moving the problem in my opinion

@Violet-Nonbloosom
Copy link
Contributor Author

Why are we moving it to a long? Aren’t we delaying the issue then, this isn’t solving the issue.

should limit it to a value instead of moving the problem in my opinion

Though it may be more robust, I have no idea what will be happening in future overflow bug.

If long was not enough for complexity², int might not be suitable for complexity as well, which meant a thorough rework would be needed.

Besides, I have another subject to work at present, so my solution ends here.

@Violet-Nonbloosom
Copy link
Contributor Author

Why are we moving it to a long? Aren’t we delaying the issue then, this isn’t solving the issue.

should limit it to a value instead of moving the problem in my opinion

@J3fftw1 As you wish.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants