Testing new Setting system & UI - Phase 1

[Frooxius]

Hello everyone!

The new settings system & UI has reached a minimum viable product stage, where it is ready for public testing and feedback! If you'd like to help us out and provide feedback at this stage, this is the place to do it!

Please make sure you read this post in full and understand what's being tested before you comment!

Current build version

Beta 2024.4.12.1259

What is the setting rework?

In short, we've completely overhauled how settings work in Resonite - both under the hood and visually. This will not only fix a huge number of outstanding issues, add new cool features, but also make it significantly easier for us to add new settings going forward!

In order to support this, a number of new subsystems were added to Resonite, notably something called "data feeds". This system separates functionality into better self contained modules. While this currently powers just the Settings UI, this system will be used to rebuild majority of other UI's - Inventory, File Browser, Contacts, Messages, World Browser, Inspectors and more!

It's a powerful and dynamic system that allow better sharing of code across different UI's, rather than writing big UI monoliths, which are hard to maintain and expand - giving us bigger bang for the time we invest into developing each thing. It also builds upon the entity interface system, making every visual piece of UI be built by our content team in-game, allowing for much more polish than code-based UI can ever achieve.

And importantly, it also puts the power over how the UI looks and feels to you! Making it significantly more customizable and letting you build your own setting UI's (or modify the default ones) as well.

You can read more about this in this issue here: #584

And general discussion for new settings system here: #614

What is included in this release?

• A brand new subsystem for handling settings
• All old setting subsystems were completely removed
• All old settings were redesigned and rewritten into the new system
• First public iteration of new setting UI is now used
• Select legacy settings are automatically converted to the new system (see here: Create system to convert old settings to the new system [COMMUNITY FEEDBACK WELCOME] #1554)

What is NOT included in this release?

• We have not added any new substantial settings yet - those will come once we make sure the existing stuff works
• Search functionality is not implemented yet
• Ability to pick settings as facets is not finished yet

What's the goal of this testing?

The goal of this testing phase is to ensure that Resonite is fully usable with this new setting system without any significant loss of functionality and breakage.

If all goes well, these changes will be pushed to public and further Setting UI work will continue on the public builds with quick iteration speed - adding more functionality, lots of new settings (yes including motion blur toggle!) and expanding upon this - we just need to make sure the core things work well first.

What should I test & give feedback on?

• Functionality of new settings - do all the settings work the way they're supposed to? Are your settings saving properly?
• UI of the new settings - visuals, usability, accessibility, clarity...
• Categorization of settings - do you feel some settings should be in different category? Let us know!
• Labels - are the setting labels descriptive and clear enough? We've done a quick pass, but some could probably use better labels
• Ordering of categories & items - do you feel some should be higher and some lower? Let us know
• Conversion of legacy settings - do your old settings convert properly? Please see this for which settings are supposed to convert: Create system to convert old settings to the new system [COMMUNITY FEEDBACK WELCOME] #1554
  -- If you feel strongly that certain legacy settings should auto-convert, leave a comment on the issue with your reasoning for them
• Existing functionality that might have broken - a lot of systems were touched, which might've broken some existing behavior that are not related to settings. If you notice something that works on normal build and not this one, let us know

What should I NOT test and give feedback on?

• General data feed functionality - while this is new mechanism, we are not focusing on this as part of this testing
• New settings or features - these will be added once we make sure that the old ones work correctly first
• Camera category labels - these haven't been made yet

How to test

WARNING: You will be using unfinished experimental builds. If your dash gets saved, it might end up corrupted on the normal build. If this happens, use -ResetDash dash to reset it. Make sure you are comfortable with this before you test.

• On Steam, switch to the prerelease branch and make sure the build updates before you run it
• Make sure your build is the same (or higher) as the Current build version in this post
• To convert your legacy settings (this does NOT happen automatically right now), click the button in Settings -> Misc -> DEBUG - Convert Legacy Settings
• You can reset the settings to defaults by going to Settings -> Misc -> DEBUG - Reset all simple settings and Settings -> Security -> Reset Host Access Entries / Reset User Restrictions
• If you find an issue or have feedback, search this discussion first (you can use Ctrl+F to search in page) and if there's nothing yet, create a new thread

[Frooxius]

Issue - the setting UI elements are too big

Personally I feel that the current version of the UI has the elements a bit too big, so not too many settings can fit on the screen. I think they could be made smaller without sacrificing readability.

Any thoughts on this?

[Zyzyl]

I agree that the highlight is helpful, however I don't think the current width spacing is OK as-is. It really doesn't feel comfortable to me (tested in Desktop & VR) that the label, control, and value display are spaced so widely.

One way to solve this could be by adding a permanent description/info space to the side of the settings e.g. like in the image Prime posted here #1597 (comment) and I posted here #1597 (reply in thread).

This would have the effect of making the UI more compact width-wise and would make room for tooltips. If there's a concern about having empty space on the UI, I've seen significant chunks of empty space in settings UI's of other PC games and it looks fine to me.

[lyoth13]

Very nice design!

[JackTheFoxOtter]

I'm not sure I like the enum input the way it currently is. I'm thinking it might look better to move the enum left / right buttons to the right of the big value preview. This would be in line with the way float values work as well, where the visualisation of the value is the big slider on the left, and the controls to adjust the value on the right. Once we have drop-downs for enums it would also look better to have the dropdown on the left under the value preview instead of on the right. That way the value preview could take up the same space the slider currently takes up, and the two cycle buttons could align nice with the rest of the value fields on the right.

[art0007i]

I think the enum buttons should just be similar to how they are in the inspector, so [<] [Value Name] [>]. Putting them on the right could be good too but I think I prefer how it is in inspectors.

[RyuviTheViali]

Here is what the current enums look like with the buttons on the right of the field. I will state that the enum visuals are temporary until enum data feeds can be seen as a list all at once, at which point they'll be updated to that.

[shiftyscales]

Leap Motion settings show at all times even when the hardware/software is not installed/active.

We used to hide these settings when a user didn't have the hardware installed- should we restore that behaviour, @Frooxius?

I do not see the Vive hand tracking settings while in desktop mode- so I suspect there might be a mechanism for this already and the Leap settings were just overlooked?

[Frooxius]

Ah yes, I wanted to look into this one. I need to actually add a mechanism for this. We can't really "restore" anything here, there needs to be a new mechanism where settings decide to "hide" themselves.

The settings show up if they happened to be registered & saved, so that's probably why you're not setting them.

[Frooxius]

Let's continue here: #1597 (comment)

[ModernBalloonie]

Issue: Dashboard cannot be moved/Freeform Dash doesn't work.

Freeform dash doesn't work in the settings or the facet.

[Frooxius]

This should be resolved! Please let me know if you're still experiencing issues!

[Nytra]

I have found that logging out of my cloud user account in Beta 2024.4.11.484 causes the dash to be immovable in VR and freeform dash toggle does not work.

Log file:

DESKTOP-H976HO2 - 2024.4.11.484 - 2024-04-11 17_14_04.log

[Frooxius]

@epicEaston197 As requested in the initial post, we are not looking for new feature requests as part of this testing, only testing already implemented functionality. That will have to come later.

[cerealbowlsystem]

Preference tier lists are too convoluted.

I understand and agree with the idea of being able to make a tier list of which locomotion settings are preferred in relation to each other, and I can't really think of a major way this could be done better than the way it currently is. However, I still believe that something about this tier list setup makes it very busy on the eyes and blasts the user with info. Maybe it's the size of each element, maybe it's the fact that there's just a bunch of arrows on the right that are always visible, I'm not sure. But I feel like there could be a better way to present the information.

For the Locomotion Preferences list specifically I'd at least add each locomotion mode's icon in front of their text, so that the information is more quickly conveyed. And more importantly, the "Make Preferred" button should definitely not be red when pressed.

[5H4D0W-X]

Somehow adding an animation to the elements, making them visibly swap places, might be enough, but that would also require new components to do entirely without flux

[JackTheFoxOtter]

Yeah the issue is that this is a bit more tricky than it seems at first. The element you grab kind of needs to be moving with your cursor, or it's going to be unintuitive. The issue with that is that you can't actually move the layout out of the list just yet, since that would change the flow and cause the items to collapse. My solution was having a "dummy" element that I write the texts of the actual element I'm moving into, that slides up and down on a separate layer. Then I changed the color of the element I'm moving in the list so you see it's being moved, and then reorder the original element every time I'm crossing the halfway-point of the element. I think I came up with a solution that didn't put any ProtoFlux on the movable elements themselves, only on the container above them, but it required a fair bit of math and that only works out if the size of all elements in the list is actually identical. I think a native solution would be best for this, but there's still a bunch to be considered there.

[JackTheFoxOtter]

Here was how my solution ended up looking, it's a bit broken because I was trying to work on stuff but the reordering still works.

2024-04-04.09-31-33.1.mp4

[Frooxius]

We can look into making this fancier. Allowing the grab re-ordering mechanic and possibly animations there.

However key question here is: Is this a blocker? Should we halt the release of the initial version of settings for this?

This is non-trivial to implement properly and it will take some time, so it might be better to tackle this as post-release improvement.

[JackTheFoxOtter]

Agreed. I think this would be a pretty decent improvement to the UX, but it's not necessary for the first release.

[Frooxius]

This has been fixed! Thanks!

[KierDran]

Resonite completely froze on me. I was just having a conversation with someone over messages.
MINK - 2024.4.3.1385 - 2024-04-03 17_44_41.log.zip

[shiftyscales]

Please include the log files for that session, @KierDran. https://wiki.resonite.com/Log_Files

Do you know what specifically you were doing when it happened? Can you replicate that issue?

[BlueCyro]

DESKTOP-6C2UJFB - 2024.4.3.1385 - 2024-04-03 19_16_52.log

2024-04-03.19-20-26.mp4

At times, the UI elements appear to not be able to decide which one I'm hovering over, and end up flickering.

[decoybird]

I am also getting this constantly, on many of my selections.

Resonite_e9lLU21ing.mp4

URAGAAN - 2024.4.3.1385 - 2024-04-04 02_21_32.log

[shiftyscales]

Does the issue persist if you hover over a different container, @BlueCyro? Or does it only last as long as you stay within the bounds of that particular setting grouping? (What happened past the end of the clip you submitted?)

[BlueCyro]

@shiftyscales The issue seems to come and go as I hover and click between the containers. Specifically changing the container after it's happened and switching back doesn't appear to resolve the issue.

[Frooxius]

I think this is actually a long-standing UIX bug that I've been meaning to tackle a while back. I'm going to tackle this one.

[Frooxius]

This is now fixed in 2024.4.9.1426, thanks!

[ohzee00]

#1597 (comment) Possible this is the same as what Cyro reported?

[shiftyscales]

As Ohzee noted, this appears to be a duplicate of #1597 (comment)

Please continue your report there, @akiRAM3.

[Frooxius]

I made the swap, thank you! Hiding this as resolved now.

[epicEaston197]

Move photo capture to camera category

[Frooxius]

We could move these there, but it might be a bit too cluttered there.

The "Camera" has specifically the interactive camera settings, while this one concerns the finger photo gesture and the desktop capture.

[JackTheFoxOtter]

I think putting it into the interactive camera settings would be more confusing, as it doesn't have anything to do with it. But maybe "Camera" as a category label is a bit too general and could be "Interactive Camera" or "User Camera"?

[orange3134]

@shiftyscales Yes, this always occurs after launch.
I do not know of any other users experiencing this.

[shiftyscales]

Could you try disabling your audio devices one by one and see if the issue can be linked to a particular audio device, @orange3134?

[Frooxius]

I have fixed this now as part of another issue. Thanks for report!

[ProbablePrime]

Confusing Category Heading UI.

I'm a little confused by the UI design of the heading of each category:

Its heading resembles a tab:

But it is not actually a tab, there are "tabs"(categories) but those are controlled through the top menu, or the left menu instead.

So with all 3 of these combined we have 3 controls that look like they're do to do with categorization. While only 2 actually are:

1. Side menu
2. Top menu/breadcrumbs
3. The "Tabs"

From a purely graphical/UI design point of view, I'd recommend re-styling the heading to not look like a tab.

[RyuviTheViali]

Here is what standalone-text group headers look like:

[lxw404]

Very clean tbh, I really kinda like that it implicitly separates the groups now by the space around them.

[ProbablePrime]

I really like this!

[JackTheFoxOtter]

Yeah this is a lot better. I like it a lot. It makes the entire menu feel way less cluttered.

[ShrikeAlvaron]

As I mentioned elsewhere I didn't like the headers being background-less, but I can see what Jack says about it helping things feel less cluttered, especially compared to the full-width background on them instead of the tabs. Having them highlighted along with the entire group helps ensure that the groups stand out as being connected too.

[Frooxius]

This has been fixed, thank you for the report!

[shiftyscales]

I believe I ran into this once before a while ago after I had reset my UI. It fixed instantly after changing status, and is probably an issue with the facet itself, and is not related to this settings UI update in particular.

Can you please create a separate GitHub issue to report this, @mpmxyz?

[mpmxyz]

I believe I ran into this once before a while ago after I had reset my UI. It fixed instantly after changing status, and is probably an issue with the facet itself, and is not related to this settings UI update in particular.

Can you please create a separate GitHub issue to report this, @mpmxyz?

OK, but I can only report it on the prerelease version. Is there a way to reset the UI on the normal version? (-ResetUI or -ResetDash don't trigger the behaviour on the normal version.)

And the reason I created another comment to this discussion:
Shouldn't the selection persist? It always resets to "Invisible" for me after a restart of Resonite.

[shiftyscales]

I started Resonite without -Invisible in my command line arguments, and my online status facet shows Online as expected. So I can't replicate the behaviour you've observed.

[shiftyscales]

Regarding the original issue, I also looked into the facet and found that the purple bar with no text is how the facet looks when the UserOnlineStatusSync component is set to Offline, which is a status that doesn't seem to be represented by the existing facet version.

Either way- please make a separate content issue about that and it can be looked into further, @mpmxyz.

[mpmxyz]

Where is the information taken from?
Are there any files I could edit/rename to switch the selection?
PS: No, I've not used the option -Invisible.

[shiftyscales]

Which information, the command line arguments?

If you are launching from Steam, you would find them under Resonite's properties in Steam, otherwise, if you are launching from a shortcut, they could be specified in a shortcut.

I tested against the current live build- and the behaviour is the same on both- whatever status you last had is restored when you restart, e.g. if it is set to away, it stays away, if set to invisible it stays invisible, etc.

So as far as I can tell everything is working as expected there.

[mpmxyz]

I was asking about the old and new config files since I assumed that the persistence of the UserOnlineStatus is managed through the settings system.
(timeskip)
After checking around I found the settings key "Profile.OnlineStatus" in the class EngineStatusSource.
This is no longer used with the prerelease but was used in the old/normal version.
It is quite possible that this is intended behaviour since the OnlineStatus makes more sense as a cloud-only setting.
In that case it is simply a content-issue where the previously unused state "Offline" is not displayed correctly with the facet.
PS: You are probably already logged-in when starting Resonite. I don't use the "remember me" feature. This is why I observed the "Offline" state.

[RyuviTheViali]

I've added x/y/z indicators for composite value types (int2, float2, float3). Does this indication work well, or if not, what should be tweaked?

[Dusty-Sprinkles]

could maybe add a little splash of a slightly darker (or lighter) shade/put them outside of the input box for clarity/readability

[RyuviTheViali]

I've highlighted the component indicator text:

[JackTheFoxOtter]

This looks really pretty. I like it.

[Frooxius]

There's already issue for this: #1597 (comment)

[ohzee00]

A very minor visual thing I'm noticing in the settings UI, if you navigate to a page that has disabled toggles the animation seems to start as enabled then go to disabled like so:

Resonite_wAhzr9QZ9H.mp4

It is a bit distracting when there is a lot of disabled options but not a blocker.

Tried searching up different terms for this, my bad if I somehow missed a duplicate.

[RyuviTheViali]

Okay, this was addressed - there isn't an easy way to fix this, so I instead "inverted" it - bools set to off don't move, while, bools set to on do animate on. To me that makes more sense as you'd want to notice the settings set to on.

[ohzee00]

Sweet thank you! That does make more sense to visually show enabled than disabled toggles

[Frooxius]

This has been fixed, thank you!

[Frooxius]

@art0007i Those should be reported, so we can add type validation to them.

[ModernBalloonie]

For reference this is what it looks like in the release build (old settings).

[ModernBalloonie]

It seems like the intro tutorial has the old audio settings too, as well as language selection.

These screenshots are in the prerelease build.

[Frooxius]

Yes, see this issue here: #1626

[Frooxius]

This was now done

[Frooxius]

Good catch, thank you!

[Frooxius]

This has been fixed, thank you!

[epicEaston197]

"Use system default" is on by default hopefully that can mitigate this issue
but yeah I agree

[Frooxius]

I've made this change, thanks!

[shiftyscales]

Arbitrarily adding extra screens to the dash is not a supported feature- if custom facets have issues, that is an issue that should be taken up with the facet creator. If you have issues with your dash you can launch Resonite with the -ResetDash command line argument. But your comment here doesn't seem applicable to the prerelease build.

[troyBORG]

Arbitrarily adding extra screens to the dash is not a supported feature- if custom facets have issues, that is an issue that should be taken up with the facet creator. If you have issues with your dash you can launch Resonite with the -ResetDash command line argument. But your comment here doesn't seem applicable to the prerelease build.

I don't want to loose my old dash home screen so I'm not doing the reset dash.
It is applicable though as it works in the old thing but because the old settings and new settings tabs got swapped I think it changed how it was seen and mades it show the wrong icon and stuff.

But as I said if I just remove it and import a new blank tab facet it will probably fix it..
So it's mostly only effects us users who migrated stuff from the old platform.

[JackTheFoxOtter]

I have a simple template for custom screens you can use that works reliably in my public folder, but this is definitely off-topic for the settings rework.
'resrec:///U-JackTheFoxOtter/R-c79b181e-bacc-4d63-8bc2-b8ffa87aa415'

[shiftyscales]

What do you mean by "old settings and new settings tabs got swapped", @troyBORG? Can you attach a screenshot to show the issue you are reporting?

[troyBORG]

This isn't the perfect screenshot, but imagine one of the settings tab has a Purple Outline and the other was just Grey like this. But they were both the same settings tab...

This is the log from the first time I logged in last night. I think I booted directly into the Pre-Release branch.
DESKTOP-H0FLKOJ - 2024.4.12.1259 - 2024-04-15 00_19_47.log

This might be the log when I did the dash reset?
DESKTOP-H0FLKOJ - 2024.4.12.1259 - 2024-04-15 01_02_04.log

I did end up just making a new Blank Dash and moving all my stuff from "Old Home" into that, so I could save it, and then do the -ResetDash option. Which got rid of the Duplicate Settings tabs.

Yes I know "Desktop" tab is missing in my screenshot. I had deleted that a long time ago back in NeosVR with a Local Inspector as I accidently clicked on a game one time on the desktop and it kicked me from the game to launch the other.

[epicEaston197]

Looked at the default audio volume noticed that the master volume default was 50% resulting in a lot of things being quiet by default it would be nice if it was bumped up to 100% and if not we would have to re audio balance all of our creations around the new default

[Frooxius]

This is intentional change. 100 % can be too loud for some users - it's very user dependent. It's better to start the volume at lower value, because users can always bring it back if things are too quiet.

If things are too loud and the user is new, it can be uncomfortable to them, because they might not know how to adjust volume quickly just yet.

You should not be doing any re-balancing to compensate for this - you will make your experience louder than others. Let the users adjust their own audio volume to a comfortable level.

[shininghero]

Definitely sensible logic. But out of curiosity on your choice, why the master volume slider? This could also be accomplished by tweaking the other sliders as well.

At the same time, it's possible my audio levels are wacky (master at 100%, with the rest turned to 50% or lower). I would need to ask around to get baseline numbers.

[Frooxius]

That would require users to tweak other sliders to change volume, which can also be more confusing to new users.

E.g. they tweak one, it does nothing, so they need to tweak another. With master they can just turn that one up.

I'll see if I can re-balance things a bit too though, because we did lower the others too, to give them a bit more headroom, but we might end up going the other way and support going over 100 % instead.

[Frooxius]

I've tweaked the defaults to 75 % master and left rest at 100 %

[ProbablePrime]

See: #614