Workshop UI - Improving the current UI

[Lucasistheman]

With the Creation Kit close to release, this thread allows users to provide opinions about the changes that should be made for the settlement UI. More specifically this thread focuses on these three main aspects: concepts/ideas, methods of implementation and drawbacks/issues. This thread is open to both mod authors and users, in order to improve the settlement UI for every possible user. This discussion is not an active request for a mod to be developed, but an area for features for settlement UI mods to be discussed; neither is this forum making any claims that a settlement UI mod will be developed by myself (currently).

 

Note from Me

 

 

Whilst I would love to develop a very ambitious mod such as this, since I would consider this a great learning exercise and a perfect experience to try new things; I cannot guarantee I will have the time or skills to undertake such a project (at this current time :sad:). If circumstances change however I might undertake this as a project and update this discussion to the main discussion for mod development.

 

 

 

Hopefully this discussion will provide useful information for future mod authors in improving the current settlement UI.

 

Background

 

 

Recently I began discussing the annoyance of the console-based UI for settlements with my colleagues, which led to us investigating how the current UI is implemented and how plausible it would be to modify. After a brief search on these forums I found multiple users who are interested in similar improvements to the settlement UI. However the settlement system is very advanced and the UI very complex, therefore I thought it be wise to create a forum dedicated to discussing the current issues and potential concepts of implementing an improved UI.

 

 

 

To start discussions I'll state some of the major problems that myself and my colleagues have recently discussed; about the most desired function for an improved UI currently: Searching for particular objects.

 

Below is list that will be updated regularly with current thoughts, issues and solutions; separated into multiple categories based on particular functions for the UI. I will edit this main post whenever a user provides a unique thought that discovers new issues, concepts and/or solutions. If you don't see your ideas on the list it will likely be due to the list not being recently updated or that

 

A List of Thoughts: Issues, Concepts & Solutions

 

 

General

• Settlement Menu UI currently does not automatically make changes while open. Possible solution: force close and re-open via script (dependent on Papyrus UI functions).
• Mixing sub-menus and individual objects within a single menu may or may not be possible. Requires confirmation.
• Possible integration/dependency on the updated Settlement Keywords (discussion thread here).
• If using interface file replacer and .esp/.esm combination, disabling plugin with search scripts would not amend replaced interface and crashes could occur from interface search feature. Possible solution dependent on ability to change interface within Creation Kit.
• Quick analysis of decompiled scripts for the workshop, showed a lack of specific functionality to open the settlement UI. Further analysis is required to identify the functions responsible for opening the settlement UI. Dependent on the results produced by further analysis will help determine whether F4SE will be required as well additional F4SE plugins.
• Likely functionality to store additional data within data files (.dat, .bin etc.) could be required for user-configuration storing. Would have to be easily obtainable files as both ActionScript and Papyrus would likely require access.

Design & Structure

• Minecraft-Style: Multi-column, multi-row object selection for settlement UI.
• Same UI-Style: Single row object selection window.
• Grid-based

Searching

• The settlement UI is a single .swf (Flash) file found within the interface folder of the data files (Fallout4 - Interface.ba2). This implies some clear functionality with Papyrus and Flash scripts, however it does not indicate whether Papyrus functions send object data to Flash or if Flash acquires the object data itself. Until we can uncover how the settlement UI retrieves its data, we cannot begin to develop a search feature that obtains object data.
• Currently the workshop menu will (in use) only show a selection of sub-menus or a list of objects; never a hybrid of the two. So would it be possible to search for both sub-menus and objects and receive results for both without additional action?
• Using conditions within Craftable Object forms to allow easy disabling and enabling, is a solution to limit potential objects to those searched for. However depends on existent global condition within all objects that work with mod.

Filtering

• Ability for user to select certain objects to be placed within a quick-find favourites menu to quickly get frequently used objects.
• Ability for users to hide non-favorited objects within specific categories, via filtering.
• Ability for user to select certain objects based off mod that added them. Would require functionality from F4SE to get plugin based information.
• Ability for user to show objects of a particular set (keyword-based sets?).
• Ability for user to select general filters: name, object size, material cost, num. currently craftable.
• Ability to toggle filter results in ascending/descending orders.

Navigation

• Ability to skip a fixed number of objects via a toggle-based/modifier key (Press "Shift" / Hold "Shift").

 

 

 

I know the community will provide some very interesting and unique thoughts about the settlement UI. I look forward any thoughts you may have.

Edited April 26, 2016 by Lucasistheman

[RustyXXL]

This topic is kinda related, and has a little bit of additional information on the structure itself, and what some of the modders envision how the menu should be structured, mainly regarded to settlement keywords etc.

 

some additional points.

While it is possible to give craftable objects a condition, and toggle this condition while the menu is open (in my case I used the hotkey mod to toggle a global that I created, to test if I can turn things on and of) The Menu itself doesn't seem to update dynamically. I had to open and close the menu for the changes to take effect. You can add/remove keywords via papyrus, and modify the Menu Structure this way, but if this would allow the menu to be modified dynamically without reopening it, is unclear for me, and needs further investigation, but all in all the Structure seems to be rather static. Dynamic Menus might help alleviating menu cluttering or simply give the user the option to customize their menu to their liking.

 

Mixing Craftable objects and Submenu is simply a matter of the right keywords being present and shouldn't be a problem. I also think to have seen that somewhere, but I can't guarantee it and have neither explicitly tested it.

[Lucasistheman]

This topic is kinda related, and has a little bit of additional information on the structure itself, and what some of the modders envision how the menu should be structured, mainly regarded to settlement keywords etc.

Settlement Keywords is a great mod that and the work those modders in that topic are doing is amazing. The framework currently could be very useful in achieving a better user interface; as an optimized menu system with a known structure could assist in performance and searching in general.

 

some additional points.

While it is possible to give craftable objects a condition, and toggle this condition while the menu is open (in my case I used the hotkey mod to toggle a global that I created, to test if I can turn things on and of) The Menu itself doesn't seem to update dynamically. I had to open and close the menu for the changes to take effect. You can add/remove keywords via papyrus, and modify the Menu Structure this way, but if this would allow the menu to be modified dynamically without reopening it, is unclear for me, and needs further investigation, but all in all the Structure seems to be rather static. Dynamic Menus might help alleviating menu cluttering or simply give the user the option to customize their menu to their liking.

This a reasonable issue that does affect the overall functionality of the settlement UI. The problem however then with using conditions for craftable objects is it enforces a requirement for mod authors to make it compatible or patches to enforce compatibility. However considering the varied use of both FormLists, Keywords and Craftable Objects used for settlement objects, a method that doesn't rely on modder assistance is plausible as long as Bethesda provides some functionality to link them. Some brief research suggests HasKeyword works with practically any Form and therefore means a framework without modder assistance could be potentially possible; but until the Creation Kit releases we won't know if we can easily navigate/manage them via a script.

 

The issue regarding non-automatic menu updating is interesting but a simple solution (depending what functions are available in Papyrus) would be to when a search occurs; the menu is forced closed, search disables the objects not searched for and the menu re-opened.

 

Mixing Craftable objects and Submenu is simply a matter of the right keywords being present and shouldn't be a problem. I also think to have seen that somewhere, but I can't guarantee it and have neither explicitly tested it.

If this is possible it could open the door for other useful functions such as allowing shortcut menus or favourites for the user to easily re-create objects that are a nuisance: A) to find or B) to type/search for.

 

Thanks for your thoughts I'll add them to the list :smile:

 

Edit: Didn't think it was worth creating a new post for so just putting here instead.

 

Thought of an issue that would occur if both a replacer interface .swf file and .esp/.esm file are used for the mod. Simply disabling the .esp/.esm would not revert the interface to the vanilla interface. If the .esp/.esm had scripts that controlled the searching functions, then the interface could potentially cause crashes if the search was unused on the interface without the script present. Hopeful solution would be that the CK will allow replacing flash files for interface components just like an item and then it would cause less issue. Added to list.

Edited April 21, 2016 by Lucasistheman

[RustyXXL]

Well, the test I did was a quick test to see if you can dynamicly alter the menu, mainly out of interest, not with a particular use in mind, and the way with the condition and the global via hotkeys mod was simply the easiest way for me to test it. I only brought it up to demonstrate how I tested it, in case that the engine handles other ways of altering the structure differently.

One additional issue with conditions on craftable objects I should mention is that you can't directly modify the submenus this way. you'd have to disable all craftable objects in a submenu for the submenu to disappear. From what I have read empty categories should be ignored and not show up. This of course is a problem when another mod adds additional items to the category you want to hide. So altering the keywords via papyrus is clearly the better way to hide complete categories/submenus.

[HoneyBearSquish]

if we could have a minecraft style workshop UI that would be awesome xD i really like the side menu with tons of rows and columns lolz

 

http://i0.wp.com/www.minecraftdl.com/wp-content/uploads/2013/12/Utilization-Resource-Pack.jpg?resize=640%2C332

[Lucasistheman]

if we could have a minecraft style workshop UI that would be awesome xD i really like the side menu with tons of rows and columns lolz

 

http://i0.wp.com/www.minecraftdl.com/wp-content/uploads/2013/12/Utilization-Resource-Pack.jpg?resize=640%2C332

I can see how some people would like a multi-row/multi-column interface for object selection and I can see it being very plausible. Downside of that would be how much screen space would it take; after all most of the screen space is already dedicated to viewing the object you intend to build. I'll add it to the list.

[HoneyBearSquish]

^^ Thanks for adding it, i figured the Multi- row/column would make up for the lost screen space, and it could have smaller or less rows maybe.

[Lucasistheman]

^^ Thanks for adding it, i figured the Multi- row/column would make up for the lost screen space, and it could have smaller or less rows maybe.

 

There is a fair amount of wasted screen space true, but too many extra columns and rows could over-clutter the space. Not sure because I run my game on fullscreen at 1920x1080, but I'd assume on lower resolutions trying to add more content to the UI could make text difficult to read or certain objects difficult to see. Though at higher resolutions the current object viewer could be scaled down and more columns/rows added without bumping into these issues. Multi-rows/columns would be very useful so the issue would be finding the balance of screen space usage and empty space.

[eldiabs]

The only two things I can think of that would be nice are a search function (tied to the keywords or cobj somehow?) and shift - arrow keys to skip through larger menus more quickly...for example hit shift - arrow right and you move ten items to the right. I like the current layout. It makes sense and there is plenty of room to see where you are building.

[Lucasistheman]

The only two things I can think of that would be nice are a search function (tied to the keywords or cobj somehow?) and shift - arrow keys to skip through larger menus more quickly...for example hit shift - arrow right and you move ten items to the right. I like the current layout. It makes sense and there is plenty of room to see where you are building.

 

Quick navigation would be very great and if the controls used to toggle skipping could be rebound by the user adds far more usability than the current UI. Added to list.