GroupMembers' hardcoded VolumePage behavior
 

This may be a silly question... but is there any way at all to get rid of this? It's driving me crazy and I can't figure out why it even exists considering VolumePages actually exist without hardcoding.

Simply I want to create a group window arranged in a 3x2 grid. Which of course means I am moving the player's stuff into it. Forget for the moment I don't have the cure indicators working past being grey boxes...

So I create my pages in the layout that I want which works fine in UIBuilder... but put it into the game and my 3x2 grid turns into:
F1 | F2 | F3
__ | F4 | F5
__ | F6

I'm not even sure what kind of grid to call that. Obviously it's taking into account F2's position and arranging F3-6 based on that. Which is sort of crazy because I'm using pack sizes so the page children always fit and will never want to go to the next row.

I read a thread from like 4 years ago regarding this complaint and ran across the idea of programatically setting each member's page location. So I made it so when ever a group member was shown, it would relocate all of the pages. I honestly thought that would work. But what I didn't know is that not only does it relocate all of the pages with hardcode every time it resizes, but there's a million other invisible events that cause it. Just standing in a group might not be bad, but if you're in combat you'll get it repositioned so often that if you use a hotkey macro to trigger the 3x2 layout, it might be in that messed up grid faster than the next frame is rendered.

Considering this issue is so old, you guys can probably tell me right now if it's hopeless and I can avoid spending another two days on it.

With the dynamic data available for groups, can you not just make your own volume page that doesn't use the same name/structure as the default?

Haven't checked out the group window in a bit, so I may be a bit out of mind of the code.

It'd work extremely easily except for the one thing I mentioned about moving the player's info.

Unless I'm crazy, there is still some hardcoding going on with the icon cure effects. I suppose I could be doing it wrong... but if you create an icon with /GameData.Group.Group_0.Effect1 and put it in a random window. When you get a trauma effect the icon's visibility will be updated but nothing else. It'll look like a grey box and won't tell you if the effect is non-curable or if there is more than one trauma effect.

If you put that same element in the correct XML tree structure, some hardcoding takes place and makes the icons work correctly.

Yeah you can't make a DD based window or I'd have done it ages ago. The size hardcoding has probably gotten worse with the addition of pet health which I think automatically resizes each group member in the default UI.

Ah ok, missed that on a first quick glance at your post. That is a bummer.

I'd like to see this changed.

I'd like to see it changed too. I'm not sure why the window was originally created this way, but it has to be one of the oldest windows in the game, so no telling what the thought process was.

Since this isn't something that's currently broken in the game, its pretty low priority and will mostly likely have to be another one of my "pet" projects.

OK fine! here is my group window I use for profitUI. It auto fills center out. It can easily be made to fill top-down, button-up, left-right, right-left..

Oh yea I didn't bother to fix the click to cast buttons as I never use them.. I did fix the click to cures though.