[WIP] Basic implementation of bionics slots system #15937
Conversation
…ved) ... and define some function inputs as const
|
Screenshots of current progress:
|
|
List of bionics and associated bodyparts (+number of slots):
|
|
@Coolthulhu I pushed the latest commit after your assignment but it can be ignored since it's tiny and not critical one. |
|
Seems to be working. Couldn't get it to crash or act incorrectly. The UI is a problem, though. It is really unwieldy without memorized keybinds - too much redundant data. It tries to combine displaying bionic "sizes" (for slot limits) and the activation options and doesn't really work well for either case. It is manageable for a low number of bionics, but many players are currently playing characters that are running out of alphabet letters for bionic keybinds. Activation options need a single instance of each bionic, not more, not less. Passive bionics can be on the same list, but sorted below the active ones. The slot display cares mostly about slot sizes and so should have bionics sorted by size (in the current body part) or per-bionic display with a list of occupied slots (like itemized CBMs). To get it mergeable, I'd bring back the old menu and have TAB switch between them (remembering the last one used). |
That's what we're trying to fight with. I see your points but I disagree with them, your propositions will make this UI even more complex. |
|
Why not have the Body Layout UI in a tab separate from Active and Passive? Having the Active/Passive uniquely listed sounds useful when you don't need to know specifically which body part is needed to activate a bionic, and the Body Layout sounds more useful when adding/comparing/removing parts. |
Sometimes complexity is the lesser evil. For example, Skyrim's simple UI is less usable than Dwarf Fortress' UI after an hour of getting used to each.
That was an extreme example. The new bionic UI is rather unwieldy with just 5 bionics if enough of them are multislot. Consider the following use cases:
Basically, the bionic installation menu and bionic activation menu are two separate entities. Combining them properly would require a different kind of display than just a list. Now that I think about it, the idea of persistent bionic keybinds (for active bionics) is really good. It could work even with old bionic system. |
|
Agreed, activation is irrelevant when installing, and body parts used is
irrelevant when activating, no need to cram both into one menu.
|
|
@Coolthulhu It seems that filtering by bodyparts doesn't play its role to make the menu easier, so maybe the way to solve the stated issues is the replacement of this filter by another one: "body parts observation" (current state of menu), "active cbm list" (similar to "active" tab from previous version) and "passive cbm list" (again, as it was previously). + choosen filter should be stored.
|
illi-kun
changed the title
tab_index is not removed yet (since filtering will be modified later)
|
Why not a UI similar to the equipment adjustment window? |
|
I've added list of affected bodyparts to the CBM description and then I realized that menu becomes really overcomplicated. The latest statement of bionics menu (for this branch) is presented in the snapshot below:
I'll try to design another interface (= create simple third tab for the interface from master branch targeted to demonstration of occupied bodypart slots) and re-apply some small useful things from this branch. |
Sorry for creating new PR, it's continue of #15774 (with resolved merge conflict).
Basic functionality is ready for review, balancing of slots for each CBM and further tweaks of UI will be done as separate PRs (if the current PR will be mainlined soon) or as separate commits (if this PR will not be merged yet).