Merge novalattasya's Baritone only fork

[Omega172]

No description provided.

[Copilot]

Pull request overview

This PR significantly prunes the addon down to a single remaining module (BetterBaritoneBuild), while also updating the build/tooling and CI workflow to newer versions and a new default Minecraft target.

Changes:

• Removed multiple modules, commands, and a HUD element; the addon now only registers BetterBaritoneBuild.
• Extended BetterBaritoneBuild with additional automation/safety logic (debouncing, retry caps, build origin/schematic capture, revised fetch flow).
• Updated build tooling and release automation (Gradle/Loom bumps, new default target version, new GitHub Actions auto-build workflow, release tag format change).

Reviewed changes

Copilot reviewed 15 out of 18 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/main/java/xyz/omegaware/addon/modules/TSRKitBotModule.java	Removed module (KitBot API functionality).
src/main/java/xyz/omegaware/addon/modules/TPAAutomationModule.java	Removed module (TPA automation).
src/main/java/xyz/omegaware/addon/modules/ItemFrameDupeModule.java	Removed module (item frame dupe automation).
src/main/java/xyz/omegaware/addon/modules/ChatFilterModule.java	Removed module (chat filtering).
src/main/java/xyz/omegaware/addon/modules/BetterStashFinderModule.java	Removed module (stash finding).
src/main/java/xyz/omegaware/addon/modules/BeaconRangeModule.java	Removed module (beacon range rendering).
src/main/java/xyz/omegaware/addon/hud/OnlineTSRMembersHUD.java	Removed HUD element (online TSR members overlay).
src/main/java/xyz/omegaware/addon/commands/ShulkerQueueCommand.java	Removed command (shulker queue management).
src/main/java/xyz/omegaware/addon/commands/LinkCommand.java	Removed command (KitBot auth).
src/main/java/xyz/omegaware/addon/modules/BetterBaritoneBuild.java	Major behavioral changes to storage interaction, item fetching, and build resumption logic.
src/main/java/xyz/omegaware/addon/OmegawareAddons.java	Entry point now only registers BetterBaritoneBuild; repo metadata updated.
gradle/wrapper/gradle-wrapper.properties	Updated Gradle wrapper distribution URL.
gradle.properties	Bumped mod version and added new MC/Yarn/Loader properties for 1.21.10.
build.gradle.kts	Updated Loom plugin version and changed default target_version to 1_21_10.
.github/workflows/release.yml	Release tagging changed; MC version output updated (now potentially mismatched with build default).
.github/workflows/pull_request.yml.disabled	Added disabled PR build workflow file.
.github/workflows/dev_build.yml.disabled	Added disabled dev build workflow file.
.github/workflows/auto_build.yml	Added push-triggered build workflow uploading built jars as artifacts.

Comments suppressed due to low confidence (1)

src/main/java/xyz/omegaware/addon/modules/BetterBaritoneBuild.java:544

• onMessageReceive now captures build/stop/cancel commands from any received chat message (not just the local “> …” echo). That means another player saying “build …” or “stop” in chat could overwrite buildCommand / clear queues and affect automation unexpectedly. Restrict this parsing to messages that are known to be the client’s own command echo (e.g., only when the message starts with "> ", or by checking message sender/metadata if available).

        // remove leading chat prompt if present: many clients use "> build ..." or just "build ..."
        String plain = trimmed;
        if (plain.startsWith("> ")) plain = plain.substring(2).trim();

        if (plain.toLowerCase().startsWith("build ") || plain.toLowerCase().startsWith("litematica ") || plain.toLowerCase().startsWith("lbuild ") || plain.toLowerCase().startsWith("schematic ") ) {
            buildCommand = plain;
            // capture origin and schematic name if possible
            if (mc.player != null) {
                buildOrigin = mc.player.getBlockPos();
            } else buildOrigin = null;

            // try to extract schematic name (first token after command)
            String[] tokens = plain.split("\\s+");
            String name = null;
            if (tokens.length >= 2) {
                // e.g. "build test.schematic" -> tokens[1] = "test.schematic"
                name = tokens[1].trim();
                // strip any surrounding quotes
                if ((name.startsWith("\"") && name.endsWith("\"")) || (name.startsWith("'") && name.endsWith("'"))) {
                    name = name.substring(1, name.length() - 1);
                }
            }
            buildSchematicName = name;

            // If user explicitly sent a build, clear stuck pause
            stuckPaused = false;

            if (debugMode.get()) {
                Logger.info("Captured build command: %s, schematic=%s, origin=%s", buildCommand, buildSchematicName, buildOrigin == null ? "null" : String.format("X=%d,Y=%d,Z=%d", buildOrigin.getX(), buildOrigin.getY(), buildOrigin.getZ()));
            }
            return;
        }

        // stop/cancel command handling
        String lowerPlain = plain.toLowerCase();
        if (lowerPlain.startsWith("stop") || lowerPlain.startsWith("cancel")) {
            buildCommand = "";
            eventQueue.clear();
            itemsToFetch.clear();

            Logger.info("Stop received.");
        }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

MeteorExecutor.execute(...) is used to sleep and then eventQueue.add(...) from a background thread. eventQueue is also read/modified on the client tick thread (onTickPre), so this can race and cause ConcurrentModificationException / corrupted queue ordering. Ensure all eventQueue mutations happen on the client thread (e.g., wrap in MinecraftClient.getInstance().execute(...)) or protect the queue with proper synchronization / a thread-safe structure.

Suggested change

	eventQueue.add(new Event(true, () -> {
	performStorageInteractSafely(linkedStorage);
	}));
	MinecraftClient.getInstance().execute(() -> eventQueue.add(new Event(true, () -> {
	performStorageInteractSafely(linkedStorage);
	})));

[Copilot]

moveSlots(...) runs inside MeteorExecutor.execute(...) (background thread) but clears/mutates eventQueue and calls pathToLinkedStorage(...), which schedules pathing/interactions that are also processed on the client tick thread. This cross-thread mutation can lead to race conditions and hard-to-reproduce crashes. Consider moving the post-fetch queue updates onto the client thread (MinecraftClient.execute) and keeping the background thread limited to pure computation/sleep only.

[Copilot]

The workflow hardcodes mc_version=1.21.5, but the build defaults to target_version=1_21_10 in build.gradle.kts (and getRepo() also reports 1.21.10). This can create release tags/names that don’t match the jar that was actually built. Consider deriving mc_version from the same Gradle property used for the build, or pass -Ptarget_version=... explicitly and set mc_version accordingly.

[Copilot]

getRepo() hardcodes the Minecraft tag string ("1.21.10"). Since the build can target different Minecraft versions via Gradle properties, this is easy to forget to update and can drift from what the jar actually targets (similar to the release workflow). Consider generating/injecting this value from build metadata (e.g., via a Gradle resource/property) so it always matches the selected target_version.

[Copilot]

ignoreY is documented as ignoring the Y coordinate during navigation, but in the else branch you build target with the same Y as blockPos, making the setting a no-op. Use the player’s current Y (or otherwise omit Y from the goal) when ignoreY is enabled so behavior matches the setting description.

Suggested change

	BlockPos target = new BlockPos(blockPos.getX(), blockPos.getY(), blockPos.getZ());
	BlockPos target = new BlockPos(blockPos.getX(), mc.player.getBlockPos().getY(), blockPos.getZ());

[Copilot]

Item fetching is scheduled before verifying that a container screen is actually open. Since InventoryEvent can fire even when mc.currentScreen == null, this can run moveSlots(...) against the player handler / no GUI, re-queue the same item, and potentially cause repeated pathing/open attempts. Consider gating the fetch scheduling on mc.currentScreen != null (and/or verifying the screen handler is a container, not the player inventory) before launching the async task.