SS2 Blue Mod Manager

[67440e11d9dc1Marvin]

I'm fiddling around with the mod manager to see if there are still some minor improvements that the users could benefit from.
Idea #1: A ReadMe button (huzzah). Can some people here try it and give their thoughts?

[67440e11d9f50ZylonBane]

Best low-hanging improvement would be if it could read mod archive files directly instead of requiring users to manually unpack them.

[67440e11da155Kolya]

Readmes tend to be out of date and give obsolete modding advice. If it could link to the according mod thread that would be a lot more useful, also for getting updates. To achieve this without having to place links inside mod archives or having a database flying around (which is both bound to get old and wrong) I suggest linking to a google (I'm feeling lucky) search:  https://www.google.com/search?q=site:systemshock.org+ss2tool&btnI

Just replace "ss2tool" in the example with the "name+of+your+mod". Note that the instant redirection only works if google finds a unique match. Otherwise the search results will be shown, which is also ok.

[67440e11da422Marvin]

@ZB: Wasn't there a discussion about that already and it was decided this was not such a good idea? In any case, there are two important issues with that:
1) What happens to the zip archives? Simply deleting them is not good practice, but moving all to a different folder clutters the hard disk with useless data. In both cases, the archives would be out of sight at first which easily confuses inexperienced users. But let's say the files stay in DMM, then there's another problem.
2) What happens when the user wants to intervene, i.e. by renaming the unpacked folders (some people want to organize their mod list, no shame in that)? How is mod installation handled in general? File handling would look like this:
a) Is a mod with the same name already unpacked/activated? Then leave the zip alone/query. Problem: What about newer versions with identical name?
b) Is the same mod with a different name already unpacked/activated? Then leave the zip alone/query. Or scan each and every file to check for differences. Problem: Similar as above, plus the scanning could lead to performance issues, especially when done after every startup. Implementation itself would be a pita.
c) Is unpacking done automatically or on button prompt? The former is the standard for now but it's not exactly compatible when archives come into play.

@Kolya: You're first sentence is absolutely correct. However, the user should, in general (yes, I know about those horrible mod compilations), have already read each mod thread before downloading a mod. For this and other reasons, the mod thread entry posts where written to be as short and as simple to understand as possible. You can put a lot more information in a readme file, such as changelogs, more in-depth installation advice like mod priority, or team members and contributors. A prime example is SCP, which has a very short and simple "THIS IS HOW YOU DO IT. NO, DON'T TRY TO BE SMART ABOUT THIS. DO EXACTLY LIKE WE TELL YOU!" original post but a very extensive and well written readme.
My suggestion would be to remove bad readmes and/or ask the developers to provide a better one and let the button only link to the Google search if no readme is provided - I'm fairly sure the button name can be changed interactively. Or make two buttons (maybe overkill).
Actually, this would be a good opportunity to brush up the mod archive anyway, could also remove all ss2mod files that way. I'd be willing to sort through and reupload.

[67440e11da639Kolya]

There are mutiple problems with the readme approach.
Generally we don't touch them. They're part of the mod author's work and often contain historically interesting but otherwise obsolete data. Also email-addresses, thanks, credits, etc which should not necessarily become part of a public posting.
Updating these readmes would mean to either get rid of the old content (history loss) or produce a mess. Downloading and reuploading the mods also means that download counters get lost. And of course readmes are bound to become obsolete again, due to changes and new insights outside the mod and the hassle that updating them entails.

In short: It is for good reasons that we have updated mod posts - not readmes - for years now. Generally they're not as short and simple as can be but provide all information that would be interesting to the user. SCP may be an exception here as it is in ongoing development.
The idea that mod users should have read the mod post is nice, but in reality people just download stuff, forget what it said, forget where they even found it. If you lead them back to the source they can get that information and reading the readme is still an option for them.
Maybe there simply should be both options, a link and a readme button. Although I'm not looking forward to the inevitable support posts of the type: "I did exactly as Neospring's readme said but I can't get it to work! HALP! WTF my vanilla game doesn't work anymore!!"

[67440e11da84fMarvin]

I can hardly disagree with that. Did you ever think of creating a mod format FAQ? Sure, we can't travel back in time or redo the whole modification archive, but it would certainly be nice to give new (and active) modders here a set of rules on how your thread should look (structure, adding tags, running a changelog, that sort of thing), what to include in a readme, and so on. There must be Ordnung at all times!

Anway, btt. Here are the sensible options I could think of:
1) Have one button which opens ss.org
2) Have one button which opens the readme but looks up ss.org if no readme is found.
3) Have two buttons, one for the readme, one for ss.org.
4) Have one button which opens an "About" page built either automatically (mod name, ss.org lookup, parse contents of a txt readme/hyperlink for non-parsable formats) or read from a mod.ini file like back in the day.

[67440e11dabc8Kolya]

Did you ever think of creating a mod format FAQ?

Sure did. There was an uploading guide for years, but hardly anyone ever read it. Instead it became the job of the staff to bring new mod posts to shine by suggesting or making subtle changes in support of the author. I think this is for the best as I don't want to scare away someone who has created a new mod or FM with a bunch of rules. Ordnung is nice but it is a secondary virtue after all.

[67440e11daea0Marvin]

Sure did. There was an uploading guide for years, but hardly anyone ever read it. Instead it became the job of the staff to bring new mod posts to shine by suggesting or making subtle changes in support of the author. I think this is for the best as I don't want to scare away someone who has created a new mod or FM with a bunch of rules. Ordnung is nice but it is a secondary virtue after all.

I have no idea how a friendly "Welcome to the forum and thanks for your contribution. BTW, have you read the modding FAQ? It can help you improve the reach of your mod" would scare away someone. We have ZB for that.

[67440e11db016Kolya]

Of course it won't literally scare someone. It's just raising the barrier when I say: Please add screenshots and a short introductory text and tags, btw do you know how tags work, yadda yadda. At that point people - who are often reluctant to release anyway - may turn around and think: Uh oh, maybe it's not quite ready, I could still do this and that... And in the end they never release anything.
But actually we want them to release first and foremost, as early and often as possible. Everything else is secondary and can be added lateron, by others if necessary.

[67440e11db15cMarvin]

Hi,
I'm trying to add the web lookup function right now but the "I'm feeling lucky" operator does not work. For example, this search lists SCP beta 2 as the only result but doesn't open the URL:

https://www.google.de/search?q=site:systemshock.org+"scp_beta2.ss2mod"+OR+"scp_beta2.7z"&btnI

I can't seem to find the reason for this. Kolya?

[67440e11db236Kolya]

Probably intentional by Google to avoid some kind of abuse.

[67440e11db401Marvin]

Alright, here's my latest try, feature's kinda working now.

Unfortunately, I still couldn't resolve the "&btnI" switch ambiguity and the result is wonky if unfriendly characters (hyphen, spaces) are involved because wxWidget is adamant on removing quotation marks from strings if they're passed to the LaunchDefaultBrowser function which forces me to alter the mod name. It only completely failed with SHTUP-ND_beta1 so far.
I'm not too happy with the feature at the moment, but I wanted to hear you out before I scrap it. Maybe someone with better C++ skills than me (i.e. anyone) has some advice.

Moving on to archive support. I'll probably scan the mod folder for archives (and move them to a different folder after installation) and add an install button. Again, if someone has a better idea, please say so.

Edit: Fixed quotation marks.
[ss2bmm_current.exe expired]

[67440e11db8caZylonBane]

@ZB: Wasn't there a discussion about that already and it was decided this was not such a good idea? In any case, there are two important issues with that:
1) What happens to the zip archives? Simply deleting them is not good practice, but moving all to a different folder clutters the hard disk with useless data. In both cases, the archives would be out of sight at first which easily confuses inexperienced users. But let's say the files stay in DMM, then there's another problem.
2) What happens when the user wants to intervene, i.e. by renaming the unpacked folders (some people want to organize their mod list, no shame in that)? How is mod installation handled in general? File handling would look like this:

The Dark engine can read ZIP files directly. There should be no need to unpack anything.

[67440e11dbb8bMarvin]

The Dark engine can read ZIP files directly. There should be no need to unpack anything.

You mean the CRF files? Okay, but how do you go from a .7z mod archive to a mod folder with zipped SS2 folders without unpacking them and what exactly would the benefit be compared to just unpacking everything? I'm not sure I understand.

[67440e11dbca8ZylonBane]

The benefit is that you aren't requiring users to manually unpack things and trusting that they won't fuck it up.

[67440e11dbee0Marvin]

The benefit is that you aren't requiring users to manually unpack things and trusting that they won't fuck it up.

I'm not, I'm letting the mod manager do it, see #252.

[67440e11dbff6Kolya]

The old mod manager by zombe already went this way. It unpacked mods and repacked them in zip files. It was a slow and error prone process. Errors mostly happened because it would only repack file types it recognised.

[67440e11dc233Marvin]

The old mod manager by zombe already went this way. It unpacked mods and repacked them in zip files. It was a slow and error prone process. Errors mostly happened because it would only repack file types it recognised.

No, that's not what I'm going to do. My idea is that the user simply drops all his archives in the DMM folder (or clicks an "Install archive" button and chooses the files) and the BMM will extract them to their folders, move the archives out of sight, and let the user continue as before.

[67440e11dc3b4voodoo47]

yeah, that would be useful.

[67440e11dc498Glaice]

I don't know why this doesn't show that I am in-game when firing up from the Steam installation.

[67440e11dc584voodoo47]

you don't have to run the game via the manager each time, just set the mods up and run it regularly via steam, mods will stay active.

[67440e11dc6c8Marvin]

I had to scrap my first try since the file control dialog is terrible. The new version looks better but is less safe, so please test this thoroughly. If the application crashes during extraction, try the new 7z.dll first.

Only thing left is automatic installation of archives in the DMM folder. As usual, if anything feels off, tell me.

[67440e11dc7e1voodoo47]

seems to work ok, multiple mod import/extraction and all - what's supposed to be up with it being less safe and the extra dll?

[67440e11dc95bMarvin]

Basically I cannot check what the user chooses while the file dialog is open, I can only do it later and reopen the dialog if something bad happened. This gets tedious for the smaller things, so I'm only checking for the biggest mistakes right now which would be choosing archives from the DMM folder as that one already has a file system watcher attached.

The 7z wrapper I'm using is built on the latest 7zip version which has a lot more capabilities than the ancient one (over 6 years old) newdark provides for fmsel. Fmsel would probably crash during extraction of an archive built with those advanced features no matter what DLL it uses as its wrapper is also outdated but at least ss2bmm would be able to deal with it. So, the best course of action would be probably be to let the ss2tool hand out the most recent DLL ss2bmm uses. It's backwards compatible, so it's not like this would make fmsel unstable.