Asset Toggle on Right Side & Dice Tower Movement

[Art Wendorf]

Does everyone else have the Assets toggle/switch with the Wizards theme as a different shape and color than all the other toggles?

Also, when I window and then dewindow, the Dice Tower moves position to the middle-ish of the play area.

Picture attached.

[Moon Wizard]

Assets Button
The Assets button has not been created for all the various themes (in fact, it's only created for CoreRPG right now that I know of). We'll eventually update all the themes we directly support, though community and other third party rulesets in the store will still need to be updated over time.

Dice Tower Placement
I have not seen that behavior, and I'm not able to recreate. Did you unlock and move the Dice Tower at some point? Can you replicate in a new campaign, and if so, provide the steps?

Thanks,
JPG

[pollux]

Also, when I window and then dewindow, the Dice Tower moves position to the middle-ish of the play area.

I reproduce this. Steps are:

1. Load the 5e sample campaign, FGU is full-screen already.
2. The dice tower appears in the lower right corner of the play area as expected. The dice tower is locked.
3. Go windowed via the right-click menu. As expected, the dice tower stays in the lower-left of the play area.
4. Go full-screen with the windows maximize button. The dice-tower stays in the expected position in the lower-right of the play area.
5. Unlock the dice tower.
6. Enter windowed-mode via the right-click menu.
7. Now the dice tower is in an unexpected position outside the play area, mixed in with the buttons on the right-bar.
8. Maximize with the windows button.
9. Dice tower is now in an unexpected position in the middle of the play area.
10. Move the dice tower to its normal position in the lower-right of the play area and re-lock the dice tower position.
11. Go windowed and full-screen, the unexpected behavior continues even though the tower has been locked. When going windowed, the tower leaves the play area when windowed, and moves to the middle of the play area when full-screened... even though we're back to a locked position again.

If there's anything unclear about this I can record it in OBS and generate a gif to illustrate. I think if you follow the repro steps it will be pretty obvious what's going on. To me, the buggy parts are:

1. That the tower leaves the play area and gets mixed up in the right-bar buttons.
2. That relocking the tower doesn't restore the previous locked behavior.

The bit about getting left in the middle when unlocked is not obviously incorrect behavior to me, though maybe there's a less surprising behavior that's possible.

[Moon Wizard]

I was unable to recreate the issue using your steps in the latest build.

One note is that I did not "move" the dice tower after unlocking. If you move the dice tower after unlocking, then the dice tower position is fixed at a given X,Y position from top/left corner. When shrinking the window and any window goes off screen, then it is repositioned such that the center point is in within the current view. This is so that windows are not "lost". This is expected behavior.

Regards,
JPG

[pollux]

One note is that I did not "move" the dice tower after unlocking. If you move the dice tower after unlocking, then the dice tower position is fixed at a given X,Y position from top/left corner. When shrinking the window and any window goes off screen, then it is repositioned such that the center point is in within the current view. This is so that windows are not "lost". This is expected behavior.

I was moving the tower after unlocking. Your explanation makes a certain amount of sense, but I still feel like there are 2 suboptimal experiences going on here...

The first issue is that when the unlocked dice tower is automatically repositioned in "02-unlocked-behavior.gif", it's repositioned down in the corner of the physical window and overlaps with other UI elements. It would look more polished if the candidate area for repositioning only included the play area above the hotbar and to the left of the rightbar, which here is colored with the leather texture and branded with the dragon symbol.

The second issue is that in "03-relocked-behavior.gif", the default behavior isn't restored when re-locking the tower. Based on your explanation I assume this is because the nice default default behavior of tracking the edge of the play area isn't based on the tower being locked... but rather having null values for its X and Y coordinates. Unfortunately if a customer experiments with manual positioning just once, the default behavior seems to be lost in that campaign forever. Now the tower has an X and Y coordinate, which is saved across restarts of FGU. Resizing the FGU window changes the X and Y coordinates of the tower, and saves them across restarts. With the result that your "locked" tower slides around every time you resize your window, and never goes back where you originally put it when the window gets big enough again. The nice default behavior of keeping the dice tower in the lower-right corner is also gone forever.

A middle ground might be that the UI doesn't save coordinates when automatically moving things. FGU would internally store the last coordinates set when a human moved the element, but then compute the display location on the fly... constraining it to fit in the viewport. Or maybe every display element gets a desired-position coordinate which is separate from the actual position and is updated only in response to human repositioning, and not in response to automated repositioning. These approaches would allow FGU to display the element within the viewport even when the desired coordinate is outside the viewport... but would also return the element to its desired coordinate once the window grows large enough to accomdate doing so.

It would make sense to me if this kind of thing doesn't rate on the current list of known issues and goes to the bottom of the list for a good long while... but the behavior displayed in my third gif seems fairly plainly undesirable.

Edit: Gifs were busted when I first posted, but are fixed as of this edit.