Skip to content

Add support for newer versions and upgrade to Java 21 - #4348

Closed
intisy wants to merge 534 commits into
Slimefun:experimentalfrom
Slimefun5:experimental
Closed

Add support for newer versions and upgrade to Java 21#4348
intisy wants to merge 534 commits into
Slimefun:experimentalfrom
Slimefun5:experimental

Conversation

@intisy

@intisy intisy commented Mar 3, 2026

Copy link
Copy Markdown

Description

This commit adds support for Minecraft versions up to 1.21.11 and upgrades to Java 21.

Proposed changes

I modified the code to work with newer spigot versions, while still supporting any older versions.

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.

@intisy
intisy requested review from a team as code owners March 3, 2026 22:31
@github-actions

github-actions Bot commented Mar 3, 2026

Copy link
Copy Markdown
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! 👀

@Boomer-1

Boomer-1 commented Mar 3, 2026

Copy link
Copy Markdown

Just a heads up. The program has been officially abandoned for 5 months and no further updates will be done

@intisy
intisy requested a review from TheBusyBiscuit as a code owner March 5, 2026 14:19
@intisy
intisy force-pushed the experimental branch 5 times, most recently from 3c98bfc to b4972d6 Compare May 16, 2026 14:12
intisy added 20 commits July 1, 2026 00:54
…cher config editor (Name (key), framed layout); fill empty wiki slot
…independent so stale sounds.yml still works)
intisy added 27 commits July 22, 2026 07:50
…irely (non-interactive, no free-item exploit)
…ons w/ top-row overflow; default unstyled lore to gray
…port when next cycle started + balance queued-sample count on ticker error
…xtraStorage) compiled against the old package load on the fork
…ding vanilla attributes so real weapon damage shows
…re.yml) so items still on hardcoded lore stay visible
…ork's own bStats project (31272), not upstream; stale comment fixed
…(one-time) + add metrics.disable-addon-metrics flag for consolidated reporting
 - report per-addon untranslated-name and hardcoded-lore counts separately
 - resolve %MOB% families so runtime-generated items aren't false-positived
 - track explicit items.yml name entries vs the authored-English baseline
…he DB backend

 - JdbcStorage: normalized player_research/player_backpack/player_waypoint tables; own connection (embedded H2 allows one connection per file, so player data uses its own slimefun-players file / a separate MySQL connection)
 - playerStorage now follows storage.backend with a shared legacy fallback and is closed on disable
 - MigrationService imports flat Players/ + waypoints/ into the DB on first boot, backing up the dirs
 - round-trip/full-replace/unknown-player tests + config doc update
…displays

 - ItemTextResolver: addon-registered per-viewer name/lore provider for items that can't live in
   static items.yml (per-tier colors, id-derived names, per-instance PDC-based names)
 - consulted by renderForPacket only when no explicit entry/family covers an id, before english/raw fallback
 - renderForPacketWithItem passes the packet's stack so per-instance resolvers (SlimeTinker) work
 - boot audit treats resolver-covered ids as migrated
…on the packet path

So every item is translatable through the one packet path, an item-aware ItemTextResolver can now
override even a static items.yml entry for the specific stacks it claims (e.g. an assembled SlimeTinker
tool whose id also backs a static guide entry). Resolvers return null for stacks they don't handle.
@Boomer-1

Boomer-1 commented Aug 6, 2026

Copy link
Copy Markdown

Just a heads up. The program has been officially abandoned for 5 months and no further updates will be done

I see you are still pushing updates to this PR. while i applaud your dedication you are aware no further updates of slimefun will be released.

@intisy

intisy commented Aug 6, 2026

Copy link
Copy Markdown
Author

I reused the fork for Slimefun5. I honestly thought that this PR was already closed long ago and my fork has since split off into a way different direction. I will just close this because it should have been a long time ago 😅

@intisy intisy closed this Aug 6, 2026
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.

2 participants