I think I should clarify how Knossos handles mods right now.
It checks the FS2 directory and any subdirectory for mod.json and mod.ini files. The mod.ini is only read if the mod.json is missing and is intended to support already installed mods. Any mod loaded through the mod.ini has an "(ini)" in its title to tell the user that not all functions are available for this mod.
The mod.json file contains everything Knossos needs to know about the mod and is created during installation of any mod/TC/engine/etc.. The idea was that if you delete a mod folder, that mod would just be gone from the mod list without any errors. You can also copy a mod folder from another computer, archive or installer and Knossos will be able to use that mod (and update it) as long as that mod has a mod.json file.
One of the things that are stored in the mod.json file is the type (mod, engine, TC) which in turn allows Knossos to handle it appropriatly (although this part isn't really implemented, yet).
I propose the following:
- I add a new page in the settings window called "Mod folders" which allows the user to add additional folders which are scanned for mod.json files. However, new mods will always be installed in the FS2 directory.
- TCs should bundle a mod.json in their installer, if they want to ensure compatibility with Knossos.
- I extended the FSO launch logic which will allow TCs to live in the FS2 directory without using the retail files.
There might be an interesting discussion to be had here about pushing some of the flags into FSO. e.g. some mods need to have 3dship-select on, others need to have it off, and some don't care. Those sort of settings might best fit into the game_settings.tbl, as in the mod could tune which flags the user can set. Or perhaps Nebula could allow modder to have three settings for flags, on/off/users-choice. Or finally, and maybe simplest, Knossos could use the Nebula flag settings as a default which the user could override (and it'd be cool if "reset to defaults" would go back to the mods defaults rather than e.g. nothing enabled - actually I should play with that in the current version and see what happens).
The latter is the way it's currently implemented but I like the idea of the three settings. Though that would mean that I'll have to implement a proper UI for that instead of a simple text box on Nebula.
I'm running Mint 18 ('buntu 16.04) and it has ldconfig installed. Perhaps the command is quoted such that it's trying to run "ldconfig -p" as the full command, rather than a command with 1x arg? Thanks for linking to the code, I'll have to have a look at it (would really like to contribute but work is slaying me at the moment 
)
I'm sure that ldconfig is called correctly but I think I accidentally cleared the PATH variable which might have caused the bug. I can certainly sympathize with the lack of time (*looks at nearly 2 years of inactivity*
)
Which makes it very difficult for the launcher to figure out which things are Freespace mods, which are TCs and which are independent games. And even if the launcher manages it, you know that people are going to end up trying to run TCs as mods. Which will always be a complete disaster. Then you also have Diaspora and TBP having their own installers which set up a separate install folder and basically this whole idea sounds like a recipe for disaster.
As long as everything (except for FS2 and normal mods) is installed through Knossos or has a mod.json file, Knossos will be able to tell the difference without problem. Folders which only have a mod.ini file and no mod.json file are treated as normal mods and all other folders are ignored.
Knossos could have a mode where the user could point it at an existing FS2/TBP/Diaspora install and Knossos would then copy or move that install to a managed location so that the required directory structure would be maintained.
Moving the files will probably break things (i.e. desktop shortcuts, other launchers) and copying would waste disk space. Unless a complicated problem prevents it, I'd like to support those folders by generating a mod.json file if possible and then add the folder to a list of additional mod locations. The ideal case would obviously be that TCs bundle a mod.json file with their installer.
Maybe I'm in the minority here, but I'd prefer if Knossos could just forget a lot of the past and just be designed for going forward. For one, that means no support for the registry. We assume SDL2+ builds everywhere.
Registry support is already implemented (and has been for a while) but it's only used if the fs2_open.ini is missing AND the registry keys exist. As soon as an SDL2 build is launched the fs2_open.ini is created from the existing registry keys (this is implemented but not yet released).
Mods will have to be updated to work with Knossos to some extent, including total conversions. I think that being able to tell it where your FS2 install from Steam lives is the most it should need. Other TCs should be installed via it or not supported. Since we have full control over the distribution of everything but FS2 I think this is the best way to meet the community's needs for the installer and also keep the logic behind it as simple as possible.
I agree regarding the logic and that the FS2 directory should be the only directory a user has to manually set (maybe I should add some kind of auto detection? Something like "Hey, you apparently installed FS2 with Steam, do you want me to use that?").
Keeping the logic as simple as possible limits the amount of possible errors or edge-cases which in turn makes working on Knossos and maintaining it much easier. That said, the only change neccessary should be to add a mod.json file.
I have an idea regarding TCs: I can build a simple installer using
NSIS which would download and install Knossos if it isn't already installed and then use Knossos to install the most recent version of the TC. The TC authors would be able to customize this installer. This provides several benefits: The installer itself will be very small, fully compatible with Knossos and it will always install the newest version of the TC even if a user downloads an old copy of the installer since the installer itself doesn't contain any of the TC files itself.
Users will probably want to be able to specify where mods/games are installed, in general, as well as where FS2 is located. I would think something like this:
Knossos
Knossos_content
-bin
--3.8\
--nightly_YYYYMMDD\
-FS2_mods
--BPC
--BtA
-Diaspora
--Diaspora_mod1
-TBP
--Zathras
FS2
-core vp files
I'm not too sure about the nested folders. I think you can create them with the current version of Knossos by entering something like "test/my_folder" in the folder field on Nebula.
The one thing I'm not certain about is whether FS2 mods could live outside of the FS2 folder and still be used as the engine is coded today. But I think that being able to have an ecosystem that is completely independent from your Steam/GOG/etc FS2 install could be very beneficial.
I know that it at least used to work. There are two things required for this to work:
- Being able to modify the root directory FSO uses (easy on Linux, PITA on Windows and I think a recent code change changed this on Mac). Would be nice if this could be controlled through a flag or environment variable.
- The -mod parameter allows to specify paths not just directory names (this should be the relevant code).
The root directory is usually the current working directory when starting FSO. However, on Windows FSO chdirs to the exe's directory which means that I have
to copy the exe files to the new root directory. This mechanism is already neccessary to support the nightlies since Knossos installs them into a subdirectory. The same mechanism could be used to start FSO inside a TC's directory which would force FSO to ignore the retail files.
I'd even go so far as to say that maybe it should just copy the core VP files from the GOG/Steam install into the Knossos_content FS2 folder. Probably the only way to ensure a stable environment. We could then notify the user that they can uninstall their Steam/GOG copy if they prefer to let Knossos manage the install from there on out.
If the user gives Knossos a GOG installer, Knossos extracts it with InnoExtract and then moves the *.vp, *.hcf and *.mve files to the selected destination folder and deletes the rest. It would make sense to apply a similar logic to the Steam install (but copying the files instead of moving, obviously).
Knossos itself could live in a typical Program Files location or whatever, or just be installed via a package manager, etc. But then you pick your drive/location for the actual content to live.
This is how it works right now and I want to keep it like that (unless someone offers a valid reason to change it). The only exception would be the portable mode which I want to implement later (not sure when, probably once Knossos is stable).
If you wipe your main drive but had the content on another drive, perhaps a reinstall of Knossos pointed at that folder would even be able to pick up where it left off. At least if you saved your Knossos config written to APPDATA (which all Knossos config data should be written, if not that knossos_content folder, right?).
Knossos only saves settings and the list of available mods to APPDATA, information about installed mods is contained in the mod's mod.json. Which means that in your case you'd still lose your settings (including flags, etc.) but could still play and update the already installed mods.
