Feature: Add ability to modify/reorganize workshop menus

[brazenvoid]

This can be anything like a final reorder after all the changes other mods do to the menus. If hiding menus is impossible then perhaps reordering will be good enough.

Perhaps we can forego inter-level reorganization and go with same level reorganization.

I guess, making WF specific keywords for menus would help in reorganization in addition to the current ones. I don't know, you will figure out something.

In future, it can be enhanced with profiles for specific settlements or characters.

[ForsakenShell]

The problem is how FormLists work and their specific interaction to the workshop system.

The FormList show-stopping-problems:

You can only remove script added forms from a FormList. The Revert() function will restore a FormList to what the winning override contains and there is no way to remove forms which are specified in the plugin. WSFW would have to start with empty FormLists that it then populates. In order to fully recreate the menus tree, WSFW would need a (very large) pool of empty FormLists which it can use at each level as you cannot dynamically create a FormList from script. Further, some of the FormLists used for the menus have actual in-game text names (those menu category names? Those are the human readable "names" on the FormLists themselves) and there is no way to change the "name" from script.

Another very real issue is time. FormLists aren't particularly fast to access and trying to manage a complex branching tree of them would be anything but fast.

The Workshop not-a-problem:

The engine itself is looking at a specific FormList pointed to by the Default Object Manager as the "root menu". Of all the possible problems, this is simple enough to point to a new FormList and easiest to solve.

[brazenvoid]

I guess an optimal solution will require F4SE.

• To tackle the performance issue, perhaps a caching system could be developed to cache workshop trees once they are built either on every save load or through explicit command through the settings menus.
• Some mods exist which traverse the whole workshop tree to cache it; similar function may then be used to collect it and reorganize it further.

Let me be clear that all of that is what I assume to be so, I am not a well versed in F4SE nor fallout information structure.

[ForsakenShell]

Caching will only help so much (I use it myself a fair bit in some of my mods) however, Papyrus doesn't allow arrays of arrays or records of arrays (structs with array elements). This means that trying to build a tree in Papyrus becomes more difficult, not impossible, just more difficult. So,in the case of FormLists it would only help to cache the original layout of the FormList currently being processed and you still have the problem of a full read/write cycle which is the slow part.

There is another problem which I didn't mention previously - The engine itself pulls most of the information in through Keywords. A lot of the constructible object recipes in the game aren't in the actual FormLists but are referenced by a Keyword which is in the FormList. This allows recipes to use a Keyword and they will be found and pulled into the menu without updating the menu FormList for every recipe/mod adding recipes. The WSFW could sort those Keywords but there is no way for it to sort the results of what it pulled in from those keywords.

eg: A FormList contains two Keywords, "Fences" and "Walls". While one could sort it so "Fences" are shown before "Walls" or "Walls" before "Fences", there is no way to control the sorting of the actual "Walls" and "Fences" themselves.

[cadpnq]

@brazenvoid Which mods have you seen that cache the workshop menu somehow?

[brazenvoid]

I will have to search them again but, one is this: https://www.nexusmods.com/fallout4/mods/35382

[ForsakenShell]

That's a F4SE extension, not an "actual mod" per-say, that is; there is no esm/esp/esl file associated with it just a DLL and json files for MCM pages. I'm pretty sure kinggaths goal is to keep WSFW available on as many platforms as possible. Essentially, unless a solution can be found without any external dependencies...

[brazenvoid]

As kinggath, himself can't work on F4SE, some other will work on it. Perhaps it may prove useful to have such a reference.

[NidusUmbra]

Maybe a bookmark function is more workable with a range of empty form-lists already created that you can dynamically populate as you find items you like in the actual menus. Once you hit the 128-limit it will start populating the next FLIST 'Bookmark 2', or puts formlist 2 as the last item in formlist 1 and so on.