SS2 Blue Mod Manager

[67446eefb33c6Marvin]

Pity. Need to test myself then.

Yeah, about that: The smoothest experience, from the user's perspective, would be an auto-save, which is what I first wanted to do, but the problem is that there is then no control whatsoever about what is saved when. Granted, you could not really do that before either, except for killing the manager from the task manager , but at least you could be sure that the manager would not just save before it was closed by either button.

Could have also just renamed the exit button to clarify, which takes 5s, but that felt too lazy... anyways: I'm open to suggestions about what the best strategy would be.

[67446eefb35a6voodoo47]

I'd be fine with leaving it as is, meaning exiting the manager will save the current setup - I kind of still don't see too many people wanting to run the game while leaving the manager open.

[67446eefb3759ZylonBane]

I would think that both Launch SS2 and closing the mod manager would also apply changes. The usual Windows paradigm for settings dialogs is that you'll have an "OK" button that applies changes and closes the window, and an "Apply" button that applies changes but keeps the window open. For example the file properties dialog. So most people will be intuitively familiar with this interaction model. That's why those buttons all just say "OK", not "Apply and Close".

[67446eefb3867Marvin]

Ok, next try: No annying window on exit, apply button only enabled if needed, start button relabelled, Wine-specific folder warning (hopefully?) fixed, proper min window size (for now).

[67446eefb39b4voodoo47]

opens very large now, and cannot shrink at all - as mentioned, just not having unnecessary scroll bars on the right panel would be enough. also, extra warning about an unrecognized mod - there is an extra folder inside that contains a backup folder (xIntrface) in that modfolder that seems to be throwing the manager off, despite the proper folder (Intrface) being there as well.
[im_big.jpg expired]

[67446eefb3af1Marvin]

Well, that's HDPI scaling for you. The whole program is written in absolute pixel sizes. I guess this would be a better one? Lower min size = nice for small screens, needs readjustment for large screens, higher min size = terrible for small screens, correct for large screens. Lower min size it is I guess... in any case, that needs a rewrite. Will delegate to wxWidgets upgrade.

Is the warning new? Where's that mod?

[67446eefb3c0cvoodoo47]

the warning is new, present in all but the first 1.16 release. the minsize is ok now (not allowed to shrink to a size that would make the right panel scroll bars appear), but the first start (the manager cfg not existing) window will still open unnecessarily oversized (1365*1024 pixels).

[67446eefb3d30Marvin]

Initial size: Somewhat intended, again: Most people nowadays don't have tiny monitors anymore, so there is no one-size-fits-all solution (apart from not using absolute pixel sizes ofc). On my monitor (4k, 150% DPI scaling) it looks perfect. Will lower it somewhat.

Can you give me a link to that mod? I cannot reproduce this error simply by adding an unrecognized folder to an otherwise valid mod.

[67446eefb3e36voodoo47]

it's unreleased, so ZB would have to approve. but that shouldn't be necessary - as long as you create empty folders (intrface and xIntrface) in a modfolder, the issue should manifest. funnily enough, renaming xIntrface to backIntrface fixes it, so it might be possible the letter x is special somehow.

[67446eefb3f18Marvin]

Ehm, can still not reproduce.
[test.jpg expired]

[67446eefb4037voodoo47]

attaching mine, but it might be a combo issue - the letter x plus win7 or something along those lines. will check on a win10 machine tomorrow.
[test complain.7z expired]

[67446eefb4124Marvin]

Fixed now.
[ss2bmm.exe expired]

[67446eefb4265voodoo47]

yep, fixed. still think it starts up unnecessarily large (1.16 1066*800 vs 1.15 765*574), but if it's something that's dynamic/can't be helped, then it's not really a big deal.

but now that apply/launch buttons work as they do, and there is no warning when closing the window down, maybe that (using the X button in the upper right corner to close) should discard all unsaved changes. or maybe pop a warning and confirmation only when there are unsaved changes?

[67446eefb44e0ZylonBane]

Typical Windows app behavior when attempting to exit with unsaved changes is a "Save changes? Yes/No/Cancel" modal. The Office apps go even more explicit, with buttons labeled "Save" and "Don't Save". Libre Office does "Save" and "Close without saving". But people using a mod manager probably  don't need that much hand-holding, so I'd think a basic "Apply changes? Yes/No/Cancel" would suffice.

No functional descriptions in the tooltips for Activate/Deactivate, Increase priority, and Decrease priority.

Delete button tooltip text missing space before "(Del)".

Tooltips don't work for disabled buttons.

It would be nice if there was some standard way for mods to specify their display name, so the mod manager isn't stuck just displaying the archive filename.

Regarding the button organization on the right, I like their organization into functional groups, but the last few buttons have been left out in the cold. And it seems like Activate/Deactivate and Pause/Resume really belong together. Maybe something like this, with some things shuffled around in order of usage...

Edit
▲ Increase Priority
▼ Decrease Priority
Pause/Resume
Activate/Deactivate
Delete

Info
Open ReadMe file
Lookup mod (WWW)
About Mod Manager

File
Install mod archive(s)...
Open mods folder
Select game folder

Game
Apply changes
Launch SS2

[67446eefb4743Marvin]

I had an exit modal in, see https://www.systemshock.org/index.php?topic=4790.msg134951#msg134951. Took it out because I found it more annoying than helpful. I have the feeling that as a user you don't really expect the mod manager to save a config rather than apply a number of mods to the game, which you would think would be autosaved when quitting the manager - exactly what Launch game already does, without asking. Anyway, I can just revert the commit, it's just two lines of code. If the majority thinks an exit modal is useful, then it is I guess.

Other points:

- Missing description -> will fix
- Del button -> will fix
- Tooltips -> seems fine to me. But sure, why not, I don't think it's difficult to fix.
- Display name: Don't care for that. You'd have to put an extra file in the archive, later parse it, and either have to take care of a bajillion possible errors while doing so or use a proper XML/JSON/YML/whatever parser, which means another dependency. Too much hassle for such a small benefit
- I really like the suggestion about the groups -> will think about it

[67446eefb4850ZylonBane]

Eh, I have no strong opinions on auto-apply vs ask-and-apply. It's just a mod manager, so it's not like people can "lose" work or really mess anything up. So I'd be in favor of automatically applying on exit.

[67446eefb4953Marvin]

Apparently disabled buttons cannot show tooltips. The mouse event is simply not fired. Seems to be an OS property which wxWidgets does not change.

As for the rest, any thoughts about spacers in between categories?
[test.png expired]

[67446eefb4a78ZylonBane]

Spacing seems fine to me.

Are you intentionally keeping the Activate/Deactivate and Pause/Resume buttons separated? (I personally think it's weird and somewhat confusing to have those two almost-identical functions, but eh, too late to get rid of either of them.)

I was debating whether it would be a good idea to have a dedicated "Exit" button now, instead of forcing users to hit the little red X to close the program. There's plenty of room for it.

[67446eefb4b8bMarvin]

Not intentionally, no.

There is space enough for sure, bit I wouldn't want to add an extra button. It's more easy to misclick and it's a duplicate.

Attaching latest test, now with super-fancy UTF-8 icons which hopefully do not break on Unix systems.

[67446eefb4d2cMarvin]

Last thing to consider before actual release: https://www.systemshock.org/index.php?topic=4790.msg116464#msg116464

@voodoo47, would you mind explaining that in detail? What exactly would you want the manager to do, what is the use case?

[67446eefb4e6cvoodoo47]

basically, most mod priorities don't matter, but you'll always want the gamesys mod to have the lowest priority, have the Fixed Objects next, followed by SHTUP - no way around this. as people seem to still not get this right, it would be nice to have the manager gently enforce it in some way, but I have absolutely no idea how to implement it in a proper manner.

and if it can't be done right, it's probably better off left alone.

[67446eefb4f61Marvin]

Gamesys is easy, just move to bottom when activated. The others would need hardcoded custom behaviour, which is easy to implement and just as easily breaks.

[67446eefb506bvoodoo47]

yeah. well, no harm in doing the gamesys part, I suppose - unless someone has a use case where one would NOT want the gamesys to always have the lowest priority.

[67446eefb5196Marvin]

Ok, gameys mods activated last is in, ready for testing.

Current changes:

Code: [Select]

#Version 1.16#
+ Added warning for long file paths (mod folder >=255 chars).
+ Added warning for duplicate folder names (only useful for Wine/Linux).
+ Set min size so as not to squish window too much.
+ Activate gamesys mods in last possible position.
~ Reorganized buttons and prettified labels and tooltips.
~ Added crf archive option and "All files" wildcard (*.*).
~ Changed config save mechanism:
Added specific apply button and relabelled existing "exit and start game" button to clarify what is actually happening.
Added Ctrl+s shortcut for saving config.

Internal:
~ Upgraded build files to VS2019 Community (v142).
Upgraded to WinSDK 10+.
Dropped WinXP support.
~ Upgraded to wxFormBuilder 3.9.0.
~ Updated 7zip-cpp to current version.
~ Upgraded wxWidgets to 3.0.5.