Fix donated points calculation using stale stored total instead of current block values by Copilot · Pull Request #438 · BentoBoxWorld/Level

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Copilot · 2026-05-15T23:51:27Z

The donated block points were accumulated in the DB at donation-time block config values. When an admin later changes block values, tidyUp() was still using the stale stored total — causing level calculations where the reported total was less than a single block type's current contribution (e.g. total = 49,348 while Iron Block alone = 3,553 × 14 = 49,742).

Changes

IslandLevelCalculator.tidyUp(): Replace the stale getDonatedPoints() DB read with a dynamic recalculation from the donatedBlocks count map × current block config values. Keys are lowercased to match the stored config format.

// BeforelongdonatedPoints = addon.getManager().getDonatedPoints(island);
// After — always reflects current block configMap<String, Integer> donatedBlocksMap = addon.getManager().getDonatedBlocks(island);
longdonatedPoints = donatedBlocksMap.entrySet().stream()
.mapToLong(entry -> {
Integervalue = addon.getBlockConfig().getValue(island.getWorld(),
entry.getKey().toLowerCase(java.util.Locale.ENGLISH));
return (long) Objects.requireNonNullElse(value, 0) * entry.getValue();
})
.sum();

getReport(): Updated the per-block value lookup to use getValue(world, key) (world-specific) instead of the flat getBlockValues() map, making the report consistent with the calculation.

…block config values Instead of reading the stale accumulated donatedPoints value stored in the database (which was calculated at donation-time using then-current block values), dynamically recalculate the donated points from the donatedBlocks map using the current block config values on every level calculation. This fixes incorrect level calculations when block config values change after blocks have been donated. Previously the stored total could be less than a single block type's current contribution, as seen in the issue where Iron Block x 3,553 = 49,742 points but the total donated points reported was only 49,348. Also update the getReport() donated block section to use getValue(world, key) for world-specific block value lookups, consistent with how the calculation works. Fixes #nnn Agent-Logs-Url: https://github.com/BentoBoxWorld/Level/sessions/8d20bea9-7362-4af9-aa27-e0ae175eec2a Co-authored-by: tastybento <4407265+tastybento@users.noreply.github.com>

sonarqubecloud · 2026-05-16T00:19:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The lazy-zero / per-chunk handicap / parallel chunk scan work merged via PRs #435 and #440 (plus follow-up fixes) is not production-ready: admins running CI snapshot builds saw established island levels reset and recalculations that only counted newly placed blocks (#448). That work now continues on the feat/per-chunk-zeroing branch. This commit restores the stable 2.27.0 calculation engine on develop while keeping everything safe that landed since 2.27.0: - Donation fixes: recalc donated points from donatedBlocks (#438), enforce blockconfig donation limits in GUI/prompts (#439), cap donated counts to current block limits (#443) - MockBukkit pinned to Maven Central 4.110.0 - Modrinth MC 26.1.2 game version (#444) - CI publish workflow changes (#445, #446, #447) - Version stays 2.28.0-SNAPSHOT Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6f59pxCkwS8QXtJSe1nq6

Initial plan
caff259

CopilotAI assigned Copilot and tastybento May 15, 2026

Copilotstarted work on behalf of tastybento May 15, 2026 23:51 View session

CopilotAI linked an issue May 15, 2026 that may be closed by this pull request
Not correct level caculation for donation #437
Closed

CopilotAI changed the title ~~[WIP] Fix incorrect level calculation for donation~~Fix donated points calculation using stale stored total instead of current block valuesMay 16, 2026

Copilotfinished work on behalf of tastybento May 16, 2026 00:02

CopilotAI requested a review from tastybento May 16, 2026 00:02

tastybento marked this pull request as ready for review May 16, 2026 00:17

tastybento merged commit ee568ba into developMay 16, 2026
3 checks passed

tastybento deleted the copilot/fix-donation-calculation-issue branch May 16, 2026 00:19