Barotrauma
Barotrauma copied to clipboard
FakeFishGames
Overlapping UI with certain resolutions and multiple elements on screen
Discussed in https://github.com/Regalis11/Barotrauma/discussions/9026
- [x] I have searched the issue tracker to check if the issue has already been reported.
Description UI elements in the game can tend to overlap with one another and cause some to become unusable. This would include linking of multiple devices together getting jank, low resolution causing elements to overlap with one another, and handheld monitors and sonars/beacons when used in both hands.
Steps To Reproduce
For multi-link UI issues, either this sub https://steamcommunity.com/sharedfiles/filedetails/?id=2410124104 or any other that uses something similar, or just recreate it in the editor, and go to the fabricator and click on either fabricators, then click on the storage locker on the bottom that is linked to both. This will cause overlaps to happen, such as this:
For resolution UI issues, start messing around with lower resolutions and full screen and view a Sonar device on a sub, like the sonar in the middle of the Berilla. Each resolution I tried has varying degrees of overlapping, with one of the worse offenders I've found to be 1280x960, where the settings are completely covered by the sonar, and cannot be used for active pinging.
For handheld UI, just hold a monitor or two in your hands, and mix it with handheld sonars, sonar beacons, whatever makes an UI pop UI popup when held alongside.
Version 0.17.15.0
Additional information I've also posted a discussion on my take on a solution to fixing this while also making it a QoL feature in https://github.com/Regalis11/Barotrauma/discussions/9026.
Even the standard configuration of 1 locker to 1 fabricator can bug out for some reason, and will remain this way until the next map change and then it fixes itself.
(Screenshot from modded server, but happens on vanilla too)
Can confirm I am having the same issue, screen resolution is 3440x1440 if that matters.
There really should just be a way to move UI elements and have them save their position.
Can confirm seeing same issue of 1 locker to 1 fabricator overlapping at 1920x1080, with current stable version of the game.
Maybe related to 'repair' UI opening and being a 3rd UI window? Would be nice if we could just drag/drop the title bar of UI windows to fix this as needed/customize UI layout of linked systems as desired.
Yeah it will even tile properly sometimes (read only the very first client side open) .. and when you open it again it .. goes to this.
So I edit ships in Linux, and this happens to me every time other ppl who edit ships on windows apparently don't get these issues.
edit https://youtu.be/QRAXW-ajoKQ
Same issue is happening to me with the Medical Fabricator + Medium Steel Cabinet (only Medium Steel Cabinet is set to display when linked).
Opening the Medical Fabricator is fine but as soon as you open the attached Medium Steel Cabinet, the Medical Fabricator will no longer work and will be overlapped.
A temporary fix is to set both the Medical Fabricator and Medium Steel Cabinet to be display when linked.
One bit of information I can add to @JoneKone's excellent example is that if you enter a connection panel by using a screwdriver on an device such as the fabricator it will temporarily fix the issue.
Tested against in Dev commit https://github.com/Regalis11/Barotrauma-development/commit/af08494ef5d92cc71f3a442efd09c8a412dc563a
seems to work fine (and I tried alternating opening with container, fabricator, multiple linked etc) but I noticed a few things that make it feel odd, but it does fix the issues of overlapping UI's when it occurs by allowing the user to change the window position (And actually feels nice to do so)
As for what I noticed with the new draggable UIs:
-
The order of rendering (If you place one behind the other) is based off which you interact with, perhaps a link order or the one interacted with is always to the fore/back ground of the others. a None issue but an observation.
-
Containers correctly "Remember" their locations on screen after closing the elements, however if a deconstructor and fabricator share the same container - moving the window location for one moves the same window (The shared container) for the other set/group when its not visible (having one link to fab/decon and not to each other as to not display the other), also fine as this implies dragged location is item component specific and not to a set of links.
-
windows cannot be dragged too high/low on the screen (As to pass inventory icons or round-related buttons at the top left) however windows can appear to automatically be placed beyond these limitations (Such as touching the very top of the screen instead of having a gap) - this feels inconsistent.
-
When dragging the window on the screen (IE. a container) the inventory icon elements appear to lag behind the window position, while the texts do not (They do reach the correct location quickly so just a visual quirk).
- It seemed very good at assuming a good position for windows to open in when its two or three elements, couldn't seem to get them to overlap regardless of my combination of links unless I used too many containers which can make a complete mess of the arrangement but they can be dragged and save for that entire round in good spots.
- Finally, it feels odd to allow many containers linked to fabricators (and then link other fabricators to each other as well) but then prevent containers linked to other containers. more as it allows for the following in the mp4 below that best shows it where you can open 3 containers at once (5 with deconstructor/fabricator) then open each container in sequence which does not show the other containers but does show the fabricator/deconstructor their linked to.
https://i.gyazo.com/56c3f0a852564504062a724488978ed8.mp4
windows cannot be dragged too high/low on the screen (As to pass inventory icons or round-related buttons at the top left) however windows can appear to automatically be placed beyond these limitations (Such as touching the very top of the screen instead of having a gap) - this feels inconsistent.
Addressed this in https://github.com/Regalis11/Barotrauma-development/commit/5685ba828465dedc3870edaf388221383dd173a4
Also, something @Rokvach pointed out:
Imo item UI should have a context menu which opens when you right click the area where you can drag it and there's options to reset it to the original position and even lock the UI to the current position so you don't accidentally drag it if it's in a already desired position for the player
I agree the ability to reset or lock the UIs might be useful, but idk if a context menu is the best way to do it for a couple of reasons: we don't use context menus anywhere in these item interfaces so we'd need some way to communicate that's a possibility, and I think it might lead to accidentally deselecting items due to RMB also being used as the default deselect key.
Perhaps just double click or shift+clicking the borders/UI window instead of context menus (so it can reset and rearrange all on screen as long as you can see any part of it).
Also I found a 2-slot container you can completely hide under the chat box (There was one like this in an outpost, it was a super tiny container. looked close visually to the medical ones actually)
Finally it should be added that you can drag a window off-screen and then change resolution, potentially making it exit the screen entirely. an additional issue to this is it didn't seem to recalculate the max drag area when changing resolution. Not sure if these are fixed yet so best to leave the note here.
as for locking the UI's its on a per-object basis (IE. move one connection panel you don't move them all) and containers sharing links between different items are an even worse idea to "Lock" (IE a deconstructor and fabricator share two containers) as they will save positions regardless of the other items position.
IE. rearrange containers for deconstructor where you cant see fabricator, use fabricator instead and you will have rearranged the containers for that too. Locking won't aid these situations but just make it more awkward (And I'm not going out of my way to lock a submarines junction boxes ui's or individual containers every round, saving into the sub causes issues with others resolutions on top? so I wouldn't go with that idea either)
Implemented buttons for locking and refreshing the UIs in https://github.com/Regalis11/Barotrauma-development/commit/fb37746151a53e25c3d66632b05a7cdef56ce0c0
as for locking the UI's its on a per-object basis
Yeah I don't think that's a good idea either, I implemented it on per-panel basis
an additional issue to this is it didn't seem to recalculate the max drag area when changing resolution.
I couldn't repro this
well, in 0.19.0.0 (Without these newer changes mind you, perhaps you have already fixed it?):
https://i.gyazo.com/bc866d9cc52400e66695705d42af0d76.mp4
That is after moving the panel for a container to the very top right, changing resolution down (In my case from 1600x900 -> 1024x768), shame there isn't a window resolution that fits more snug into my 1920x1080 desktop with a taskbar but thats what I typically test on in windowed.
after the resolution change - the limits for the right side of the screen disappear, as well as the bottom clearly confined by the old resolutions limits. - it looks like a lack of updating the restriction on where the window can drag to for me.
just noticed I said you can drag a window offscreen, when I meant to likely write something like "By doing a resolution change"
Fixed UIs getting left outside the window when switching to a smaller resolution in https://github.com/Regalis11/Barotrauma-development/commit/6bd7dfc04d2431705bf2f94e6236793973a9eb78
Also managed to repro the drag area not updating: I was too hasty before, and just checked that the area defined in HUDLayoutSettings gets updated, but didn't realize the area stored in the GUIDragHandle component doesn't. Fixed in https://github.com/Regalis11/Barotrauma-development/commit/8cc22b6f768f2c7eac4413cd2c4e5166a87ea945
Note that both of these fixes rely on https://github.com/Regalis11/Barotrauma/issues/9619 being fixed, and won't work until https://github.com/Regalis11/Barotrauma-development/pull/3488 is merged.
Just a note - there is a new minor bug that has been noticed where hovering one UI over another can make it impossible to drag them (As seen here by dragging the bar over inventory slots of a medical fabricator):
https://cdn.discordapp.com/attachments/668819422919524352/999662318503862382/Barotrauma_2022-07-21_19-59-03.mp4
Referenced an incorrect issue in https://github.com/Regalis11/Barotrauma-development/commit/4abb50973392a22ba934f6036f332f25887e012b, meant to reference https://github.com/Regalis11/Barotrauma/issues/8114
Just couple minor things regarding the UI dragging feature
It would be good to either render the wire on top of the frame or restrict the area where the wire can be dragged to be inside the frame
Due to some recent changes the cursor handle changed to the default cursor instead of a hand, I think it would be good to show that the UI frame is draggable by changing the cursor when your mouse is over it
Addressed in https://github.com/Regalis11/Barotrauma-development/commit/9379a8c4df8fc6529d26a1c045d35a48b1f4cd90 and https://github.com/Regalis11/Barotrauma-development/commit/70ac32f7ef84b6607978cb1313c230e4a8d5e12f
I don't think the wire should reset back to the pin if you try and drag it further than the allowed area, it should just stop there while your cursor leaves the area if you are still holding on to it. Now when it resets to the pin its easy for it to constantly jump from your hand to the pin when moving the wire a round
Same when the wire is unwired it resets to the unwired position, so for example trying to wire the top most pin can get a bit annoying as the wire position resets to the unwired position if you just happen to have the wire slightly off from the pin
I think the above mentioned issue can be fixed later outside of this ticket, the feature itself is working correctly, so I don't see the need to keep this ticket open. Closing.