Skip to content

BME-46 Fix waypoint label position#96

Open
maddie-j wants to merge 2 commits into
LordFokas:mc-1.18.2-v0.8.0-overhaulfrom
maddie-j:BME-46-fix-waypoint-labels
Open

BME-46 Fix waypoint label position#96
maddie-j wants to merge 2 commits into
LordFokas:mc-1.18.2-v0.8.0-overhaulfrom
maddie-j:BME-46-fix-waypoint-labels

Conversation

@maddie-j

@maddie-j maddie-j commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

Just a fix for the positional bugs. Not tackling the aesthetics of the sizing yet, that'll be for a follow up.

A lot of this PR is me indenting all content between pairs of stack.pushPose(); and stack.popPose(); to verify that they were indeed paired up. As such, I suggest clicking the "Hode Whitespace" option before reviewing this to substantially cut down on the noise!

Most of the meaningful changes are in src/main/java/com/eerussianguy/blazemap/feature/waypoints/WaypointRenderer.java, with some additional meaningful changes in src/main/java/com/eerussianguy/blazemap/api/markers/Waypoint.java. I also realise that my refactoring has made the diff a PITA to read, so am happy to walk through it instead if you want. Though granted, I did most of the big refactoring a few months ago, so memory of exactly what changed and why may be foggy 😅


Before

2026-06-05_00 18 29

After

2026-06-04_23 39 43

layer.renderAsChild(stack, hasMouse, mouseX, mouseY);
stack.popPose();
}
stack.popPose();

@maddie-j maddie-j Jun 4, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This was the one non-matching pair of push/pop poses I could find in the codebase. Fixing it didn't fix the issue I was having, but it should hopefully fix other potential issues!

Comment thread build.gradle
compileOnly fg.deobf("curse.maven:$architectury_project_id:$architectury_file_id")
compileOnly fg.deobf("curse.maven:$ftbchunks_project_id:$ftbchunks_file_id")
compileOnly fg.deobf("curse.maven:$ftblib_project_id:$ftblib_file_id")
compileOnly fg.deobf("curse.maven:$ftbteams_project_id:$ftbteams_file_id")

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I don't want these to run normally in the dev server when not working on integration-related code because they just slow everything down. So making them compileOnly, but have the implementation versions below for folks to comment back in if they need them

if(event.getStage() != RenderLevelStageEvent.Stage.AFTER_TRANSLUCENT_BLOCKS) return;

if(!BlazeMapConfig.SERVER.mapItemRequirement.canPlayerAccessMap(Helpers.getPlayer(), ServerConfig.MapAccess.READ_LIVE)) return;
if(!BlazeMapConfig.CLIENT.clientFeatures.renderWaypointsInWorld.get()) return;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Flattened the indentation below by inverting the if statements to fast-fail returns instead. Apologies for how much this messes with the diff 😅

float distScale = 1f/16f;
// float distScale = Mth.clampedMap((float) dist, 0f, 128f * 128f, 0f, 1f);
// distScale = (float) ((-6.92782E-10 * distScale * distScale) + (0.0000172555 * distScale) + 0.0204091);
// distScale *= 4f;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Leaving these lines commented out here as I'll be addressing them in the follow up PR that's focusing more on the scaling. Wanted to save the old code for reference while returning to a constant value for now for the sake of just getting positioning working.

Comment on lines +48 to +51
// Note: Due to a bug somewhere causing weird offsets in Creative but not Spectator mode,
// have to render in the earlier `AFTER_TRANSLUCENT_BLOCKS` stage in 1.18.2.
// Check if can move back to `AFTER_PARTICLES` stage when porting to newer versions.
if(event.getStage() != RenderLevelStageEvent.Stage.AFTER_TRANSLUCENT_BLOCKS) return;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This render stage is what turns out was causing all the extra weird movement of the labels. Or at least, the behaviour stopped when I moved it to the one render stage earlier. It may have some issues with transparency, but I could not for the life of me find anything in our code that could be responsible for the issue!

For anyone reading who wasn't following along in the Discord: The issue only showed up when the GUI showed up. So happened in Creative mode, but not in Spectator mode. And going into F1 mode also stopped the bug from occurring. This is on top of sometimes stopping when the mouse was far enough away, but only for some waypoints, but not for others. Which, absolutely weirdest symptoms. But thankfully, moving that one step back in the render pipeline also fixed it!

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.

1 participant