Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thaumonomicon UI rescale by itself on open/close and windows resizes #10531

Closed
3 tasks done
Tralomine opened this issue Jun 23, 2022 · 12 comments
Closed
3 tasks done

Thaumonomicon UI rescale by itself on open/close and windows resizes #10531

Tralomine opened this issue Jun 23, 2022 · 12 comments

Comments

@Tralomine
Copy link

Your GTNH Discord Username

Tralomine#5809

Your Pack Version

2.1.2.3qf

Your Server

private server

Type of Server

Vanilla Forge

Your Expectation

the thaumonomicon UI is large and doesn't change by itself is no resize action or ui scale is done by the player

The Reality

the UI size change depending on multiple things
by default it starts small, but if you resize the windows to larger than fullscreen then back to fullscreen, it will take the entire screen, or if you change the UI scale to something else then back to the ui scale you had just before the change (so everything should be the same), or if you change some TC4 tweaks render parameters
then, once it take the entire screen, if the UI closes and reopen (if the windows is resized (even by a few pixels), if the thaumonomicon is closed then reopened, or if any research is opened then closed) the ui will slightly shrink, and shrink again, and again, until it goes back to the initial small (and not very useable) resolution.
basically this mean that the size of the previous time the thaumonomicon was opened is saved somewhere and used in the calculations of the new windows size, which shouldn't be the case at all since the user has no way of resizing it

https://youtu.be/J7Di8QSVY_8

this apply with large ui scale at 1920x1080 resolution, for normal ui scale at a resolution slightly smaller (and for small resolutions something even smaller, it probably apply at larger scale on larger screens)

this issue is basically the same but the bug and its causes weren't clearly identified and the reason not to fix doesn't actually apply, ie the calculation should always be the same at the same windows size, and should not depend on the previous size of the ui
#8381

note: this is not quick successions, if I don't open the book for hours it will just shrink one step when I open the book, even if it's just once and don't open it for 5 more hours after that

Your Proposal

make the ui only depend on the screen size and take the maximum amount of space, which is a constant value and do not change when the windows size don't change

Final Checklist

  • I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying the bug still exists will prompt us to investigate and reopen it once we confirm your report.
  • I can reproduce this problem consistently by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
  • I have asked other people and they confirm they also have this problem by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
@Tralomine Tralomine added Status: Triage Tasks awaiting triage. Removed once a dev confirms the issue as valid. Type: bugMinor labels Jun 23, 2022
@Tralomine
Copy link
Author

Okay so I found what the problem is and a fix (that should be in by default), the scaling consider the search area size or position wrongly, so just turning considerSearchArea to false in mod options -> tc4 config -> client side config -> scaling thaumonomicon GUI

@Tralomine Tralomine closed this as not planned Won't fix, can't repro, duplicate, stale Jul 7, 2022
@Tralomine Tralomine reopened this Jul 7, 2022
@mitchej123 mitchej123 closed this as not planned Won't fix, can't repro, duplicate, stale Jul 6, 2023
@mitchej123 mitchej123 added Status: stale Comment to reopen Comment with a good reason to re-open and a Developer will consider it labels Jul 6, 2023
@Tralomine
Copy link
Author

I literally provided a fix that's not "stale" that's "you don't have time for it", please, a bug that isn't updated in a long time isn't stale, or do you want to be spammed every day with a "can confirm it's still there"

@wlhlm
Copy link
Member

wlhlm commented Jul 7, 2023

@Glease Is that a bug with considerSearchArea?

@mitchej123
Copy link
Contributor

I literally provided a fix that's not "stale" that's "you don't have time for it", please, a bug that isn't updated in a long time isn't stale, or do you want to be spammed every day with a "can confirm it's still there"

It's stale as in it hasn't been interacted with, and my script to clean up old tickets flagged it as such. Stale is 100% nobody's looked at it, touched it, or done something about it. If someone is willing to, or has time, to fix it great, we can reopen. But giving attitude about "spamming every day" isn't going to help convince me, or anyone else of that.

@Tralomine
Copy link
Author

what I'm saying is, a script that mark stale issues that weren't interacted with will not fix anything nor remove work, as the bugs are still there but now it's even harder to report them since they are already closed, and also easy fix like this one can't be treated by new people who want to help because they become not searchable

@mitchej123
Copy link
Contributor

Having 800+ "open issues" that nobody touches, is also not useful. There are times tickets are fixed, but not marked as such, and continue to bloat the open issue count. I'm fine having a few false positives that someone can take a few minutes to comment politely and reopen it.

@mitchej123 mitchej123 reopened this Jul 7, 2023
@mitchej123 mitchej123 removed Status: stale Comment to reopen Comment with a good reason to re-open and a Developer will consider it labels Jul 7, 2023
@Tralomine
Copy link
Author

okay, sorry, I used to work on a project where the stale issues couldn't be reoppened easily and it caused massive problems, so I'm quick to jump to throats when that happens, I should have just read and commented on it

@Glease
Copy link
Contributor

Glease commented Jul 22, 2023

It is now clear that when your window size+resolution+scale combo left less than 224px for search result area, browser scale will iterative decrease on each window open until there is enough space or when it hits the browser scale lower bound.

The underlying bug on TC4Tweaks will be addressed by directly go to the end of iteration (in a future release). That means a brower scale of 1.0 will be inferred in your case, i.e. same as vanilla.
If you believe this inferred scale is too low, you can choose to do any one of these three

  1. turn off the considerSearchArea, as you have found out
  2. raise browser scale lower bound
  3. disable the infer feature altogether and set the scale yourself

The scale can be tuned while game is open anyway, so this shouldn't be too much of a hurdle. If you have better idea at how this should be resolved, please comment below.

@Tralomine
Copy link
Author

okay this seems like a more reasonable solution, however I still think the search area is calculated wrong because I can perfectly search with the maximum scale
image

@Glease
Copy link
Contributor

Glease commented Jul 22, 2023

That is because the search area is greatly compressed horizontally and the search result only display 14 character at best. I wouldn't call this enough space for search area.

Should be fixed by 1.5.14 release.

@Glease Glease closed this as completed Jul 22, 2023
@Glease Glease removed the Status: Triage Tasks awaiting triage. Removed once a dev confirms the issue as valid. label Jul 22, 2023
@Tralomine
Copy link
Author

can I suggest something? would it be possible, instead of shrinking on all sides, to just move the main screen a bit to the right? or maybe only shrink it on the left and not all sides? because it literally reduce it by more than 80% of its surface to make it able to show the full search results, making the other, main, part way less useable
image

@Tralomine
Copy link
Author

there should be some kind of middle ground right

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants