10000 Be more lenient with version checks when updating the minor version of the game by DerEchtePilz · Pull Request #594 · CommandAPI/CommandAPI · GitHub
[go: up one dir, main page]

Skip to content

Be more lenient with version checks when updating the minor version of the game #594

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

Merged
merged 10 commits into from
Aug 14, 2024

Conversation

DerEchtePilz
Copy link
Member

Currently, when updating to any new Minecraft version that is not currently supported, we throw an UnsupportedVersionException.
This is not that great since even minor updates require an update to not throw that exception.

This pull request enables, when setting the config option, an update to minor versions of the game:

  • An update from 1.21.1 to 1.21.2 would be allowed
  • An update from 1.21.2 to 1.22 would still result in an UnsupportedVersionException since presumably we still want to double check compatibility for major versions.

So why the new config option when we have the option of just loading the latest NMS version?
Well, the latest NMS version completely breaks support for older versions, this only does something when a server version is used that the main part of CommandAPIVersionHandler#getPlatform() does not handle currently.

Further considerations:
Currently, this does not include a new config option for the plugin version but I think this is something that could and should be done before merging.

That includes an update from, for example, 1.21 -> 1.21.1, but not, for example, 1.21.1 -> 1.22

Also changes build order to first package actual artifacts (shade, plugin) and then runs tests
@willkroboth willkroboth self-requested a review August 12, 2024 21:04
Co-authored-by: willkroboth <46540330+willkroboth@users.noreply.github.com>
@DerEchtePilz DerEchtePilz force-pushed the dev/minor-version-leniency branch from bba5e08 to f063532 Compare August 13, 2024 18:52
@DerEchtePilz DerEchtePilz force-pushed the dev/minor-version-leniency branch from f063532 to e0e73c5 Compare August 14, 2024 10:05
Copy link
Collaborator
@willkroboth willkroboth left a comment

Choose a reason for hiding this comment

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

Just a few comments that don't affect functionality. Could be accepted or not. Otherwise looks good 👍.

Co-authored-by: willkroboth <46540330+willkroboth@users.noreply.github.com>
@DerEchtePilz DerEchtePilz merged commit c3ff409 into dev/dev Aug 14, 2024
3 checks passed
willkroboth added a commit that referenced this pull request Sep 1, 2024
This was a similar issue to what was brought up here: #594 (comment). It seems that having `NMS_1_21_R1::new` as a method reference still loads the `NMS_1_21_R1` class enough that Java gets mad. On 1.19, trying to load the CommandAPI gives `java.lang.VerifyError: Bad type on operand stack - Type 'net/minecraft/commands/CommandBuildContext' (current frame, stack[1]) is not assignable to 'net/minecraft/core/HolderLookup$a'` with the stacktrace going through that line.

Moving all references to the `NMS_1_21_R1` class into the if statements allowed loading on 1.19 as expected. That does mean the slight inconvenience of having to specify and update the latest NMS object in two place.
@DerEchtePilz DerEchtePilz deleted the dev/minor-version-leniency branch March 1, 2025 09:09
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.

5 participants
0