Skip to content

feat: viewport-relative compass position#37

Open
Panthon13 wants to merge 2 commits into
fitzchivalrik:masterfrom
Panthon13:relative-placement
Open

feat: viewport-relative compass position#37
Panthon13 wants to merge 2 commits into
fitzchivalrik:masterfrom
Panthon13:relative-placement

Conversation

@Panthon13
Copy link
Copy Markdown

Summary

I regularly change between two different monitors while I'm playing. The monitors have different resolutions. When I swap between resolutions, the compass positioning would be incorrect due to absolute positioning.

This changes the compass position setting from an absolute pixel-based screen coordinate to a viewport-relative position stored as normalized center coordinates.

Existing configurations are migrated to the new format, and the config UI now edits the compass position as percentages rather than raw pixel values.

Motivation

Right now the compass position is effectively tied to a specific resolution and monitor setup. If a user changes display resolution, switches between monitors, or moves between setups with different scaling, the saved position can end up far off-screen or otherwise misplaced.

Storing the compass position relative to the current viewport makes the placement resolution-independent, so the compass stays in the same intended part of the screen across different display setups.

Changes

  • store compass position as normalized viewport-relative center coordinates
  • migrate existing saved pixel-based positions to the new format
  • derive the runtime draw position from the current main viewport size
  • update the config UI to edit position as percentages
  • refresh cached draw values when viewport size or font scale changes

Switch compass placement from absolute pixel coordinates to normalized viewport-relative center coordinates. Migrate existing configs to the new format, update the config UI to edit center position as percentages, and rebuild cached draw values when viewport size or font scale changes so the compass stays correctly placed across resolution and monitor changes.
@Panthon13 Panthon13 changed the title Store compass position relative to the viewport feat: store compass position relative to the viewport May 2, 2026
@Panthon13 Panthon13 changed the title feat: store compass position relative to the viewport feat: viewport-relative compass position May 2, 2026
@Panthon13 Panthon13 marked this pull request as ready for review May 2, 2026 14:16
Copy link
Copy Markdown
Owner

@fitzchivalrik fitzchivalrik left a comment

Choose a reason for hiding this comment

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

Hi, thanks for the PR!
I had a quick look at the code & tested it briefly in-game; in general, the feature makes imo sense, but I noticed a few things:

In accordance to Dalamud's AI policy, could you please disclose the level used?

There seem to be changes unrelated to viewport-relative compass feature (e.g. in DalamudPacker.targets, _pluginInterface.UiBuilder.OpenConfigUi += OnOpenConfigUi;, etc.), could you remove those?

The commits are not following the style of the existing commits.

The feature itself seems to not work completely, or I misunderstand its scope:
When using FFXIV in a window (1600x898 is the resolution I used), and moving that window around, I would have expected the compass to move with the main window, but it stays in the same position.
Related, when switching between fullscreen and windowed, the position the window ends up does not seem to be taken into account.
Furthermore, when moving the window to a second monitor, "centre horizontally" does not make the compass appear. IIRC, a second monitor was not really taken into account prior, too, but it would be nice if relative positional would fix that.

@Panthon13
Copy link
Copy Markdown
Author

Panthon13 commented May 7, 2026

@fitzchivalrik Hey! Thanks for the response! This is my first time using a Github project and Codex, so I really appreciate the patience.

So, my intent with this PR was to change the absolute positioning of the compass into a relative positioning based on a percent. In my use case, I have two 'primary' monitors in two different locations, one at 4K resolution, the other at 2K resolution. I swap between these monitors depending on the room I'm in from the same desktop, I don't use them together.

If I'm playing FFXIV with the compass set up on the 4K monitor and switch to the other monitor as the single primary monitor, the position of the compass would be far off screen because it was maintaining the absolute position based on the 4K monitor. I'd have to relocate it every time I swapped monitors, which is usually at least once a day for me. So if I wanted it centered on the screen, I could set the horizontal position to 50%, so when I eventually swapped between monitors, it would always render at the 50% position regardless of resolution.

And, I used Codex in a guided way to specifically implement this.

Let me try and clean up the issues you mentioned and get back to you, if this is all okay?

Edit: Another use case for others would be if they play on Steam Deck and dock to a monitor, the same issue I have would occur. I don't really think the Steam Deck is powerful enough to run the game on any resolution higher than its native screen, but that's an example.

@fitzchivalrik
Copy link
Copy Markdown
Owner

fitzchivalrik commented May 9, 2026

Hi, thanks for your reply!

This is my first time using a Github project and Codex

No worries, we all started somewhere!

And, I used Codex in a guided way to specifically implement this.

Using agents to help develop is totally fine, it just needs proper disclosure based on the level mentioned in the AI policy.
The code etc. itself will be judged the same either way :D.

In my use case, I have two 'primary' monitors in two different locations, one at 4K resolution, the other at 2K resolution.

Yeah, I think this specific part works fine, from my limited testing - I do not have monitors with different resolutions, but when swapping between fullscreen & windowed it seems to work when I keep the window centred. It breaks, as mentioned in my first message, when trying to move it around, with a second monitor complicating things future.
I do not think it makes much sense to add relative positioning but not support the moving window & multiple monitor use-case, too.

I also thought some more about the config changes & migration and I think it would be better to not replace the current absolute positioning with a relative positioning completely, but rather offer the relative positioning as an alternative (via an exclusive toggle, maybe?) and let the user decide what they want to use.
From my experience working on software so far, whenever one removes features, even when replaced by better ones, there will always be user who prefer the old functionality - and often they have valid reasons for that.
So if possible, I try to keep functionality around, and in this case I think the maintenance burden is manageable.

Let me try and clean up the issues you mentioned and get back to you, if this is all okay?

Yes, of course. Thanks for taking the time (and there is of course no rush & no obligation of any kind).

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