[karajorma]

Following the meeting today I made a couple of quick mockups for how I see the installer section of the combined launcher/updater/installer working.


Firstly the launcher would be a standalone, cross-platform program. It would not live in the FS2 folder but instead would live in one of its own (if you want you could install FS2 in a subfolder below it of course). The launcher would either be installed as part of a TC download or on its own. Once run the launcher would then look at its ini file. The ini file would contain a list of folders on the users harddrive to search for FS2_Open games.

The Launcher then checks those folders looking for mod.ini files (we can also make it look for launcher6.ini files for compatibility reasons if we want). It uses those to populate its internal list of mods and TCs.  If the user has something installed it goes to the run game tab allowing the user to set up the game.

If the user has nothing installed or the user then clicks on the Install tab, the launcher goes online and checks the website the current installer does (or a new one). It finds the master list of mods and TCs available for download. It then contacts each of them and sees what they have available. It then presents the user with something like this screen.



The master list is a text file which states the name of the mod or TC and the URL of a text file describing where the download for it is located (allowing each mod to remain in charge of updates, etc themselves). Each mod then provides its own text file at that location which has certain data.

1) The version number of the mod
2) The name of any mods or games it requires (so Operations would state TBP (and maybe Zathras) here)
3) The URLs for the downloads plus CRCs, etc for them.
4) CRCs for old files which are no longer part of the mod can be included as an option.




When the user clicks to download the game checks if there are any requirements. It then checks if the required game is already installed (i.e in the internal list it compiled earlier. If the game is present it then checks if the game is up to date (we could supply minimum version numbers if we wanted to so that you don't need to be 100% up to date, merely up to date enough for the mod).

It does this by checking section 2) and then contacting the URL the master list gave for that mod or TC. So in the case of Operations it would check the master list, find the text file for TBP and then check if the CRCs of the .vp files for TBP matched the ones of the files on the HD.

If there are no issues, it starts to download. Otherwise....






If we handled this all correctly we could probably wipe out a huge portion of our support work cause checking that mods are installed properly could all be handled by the launcher. Best of all, none of this should get in the way of a manual install. We'd add a settings tab and simply allow users to manually tell the installer where they have installed mods by hand.


Furthermore instead of maintaining a central .ini file for the launcher by making it save the set up in the folder belonging to the game (or even mod) we allow the user to choose to use the same launcher to run 3.6.11 for WCS, 3.7 for Diaspora and 3.8 for anything else with different settings.

[kkmic]

I'll crunch some ideas with Iss Mneur and get back with a reply soon.

[karajorma]

I've improved on the original post a little by updating the mod list so you can sort it by any of the fields. Which would make it very easy to simply sort by requirements and get all the TBP mods for instance.

[Spicious]

Looks good, but in addition to sorting, how about some filtering? And at least the option to make the pictures much smaller. Maybe only expand the currently selected mod.

Is this going to include mod version requirements and perhaps executable versions?

[karajorma]

Well at this stage it's just a mock up done in a UI design program so it would need to actually be redone in something which understands what code is.

The pictures are simply the ones from the mod.ini files in my FS2 folder for the most part but we could decide on a standard size once we had the program running. Simple filtering wouldn't be hard for something like standalone vs mods. We could probably have it look through the list of standalones so you could filter based on that but I'm having trouble picturing a good, dynamic way of saying "Only find mods dependant on FS1 port"

I think we should definitely make sure that the requirements list include minimum (and maximum) versions for both mods and executables.

[stuart133]

Well I guess that this would sort out problems of not having the right ships to play mods. I remember playing a lot of mods and having to go though and find each ship which I needed to download to make it work.
So yeah this looks like a really good idea, hope to see it soon. 

[castor]

1) The version number of the mod
2) The name of any mods or games it requires (so Operations would state TBP (and maybe Zathras) here)
3) The URLs for the downloads plus CRCs, etc for them.
4) CRCs for old files which are no longer part of the mod can be included as an option.

Is there handling for optional/recommended mods?

[Goober5000]

Ooh, I like this mockup.

What would you have on the other two tabs?

[Nuke]

it should have a developer mode too, so we can maintain settings different from general game playing that can be toggled quickly. i find it annoying when in the middle of modding somone asks me to play multi and i have to spend several minutes changing settings to play multi, and then have to reverse those changes when i want to get back to modding. maybe in the form of a tab which can launch different builds, different fred builds, and maybe other modding tools, and can maintain several saved presets so we can quickly swith over from modding a tc or fredding retail multi missions. maybe also provide quick access to debug log files.

[stuart133]

So how close is this to reality? Are these just mock-ups or is some of the code already in place?

[kkmic]

Sadly, these are just mock-ups. I think Karajorma pointed this somewhere in the previous posts.

[TacOne]

May I suggest a way to launch fred in a similar way, i.e with mods and such.
Think of it like a launcher similar to the current one, just for fred instead of fs2

[karajorma]

I'd just add the option to choose a FRED build to this launcher.

it should have a developer mode too, so we can maintain settings different from general game playing that can be toggled quickly. i find it annoying when in the middle of modding somone asks me to play multi and i have to spend several minutes changing settings to play multi, and then have to reverse those changes when i want to get back to modding. maybe in the form of a tab which can launch different builds, different fred builds, and maybe other modding tools, and can maintain several saved presets so we can quickly swith over from modding a tc or fredding retail multi missions. maybe also provide quick access to debug log files.

The idea was that the settings (i.e the equivalent of launcher6.ini) would be saved in the same folder as the game or mod itself rather than the one belonging to the launcher. In that way every single mod could have different settings.

The current issue I'm pondering is how to make that work so that we can set a default for all games run through the launcher. The problem is that if I set a global default for Diaspora which was running on 3.7 that command line option might not work on FS2 running on 3.6.11. That said even if I we only set the defaults at the game level (i.e you have to set up Diaspora's defaults and then have to do it again for TBP, Starfox or FS2) that's still what you have to do now anyway, so it simply means we couldn't improve on that.

1) The version number of the mod
2) The name of any mods or games it requires (so Operations would state TBP (and maybe Zathras) here)
3) The URLs for the downloads plus CRCs, etc for them.
4) CRCs for old files which are no longer part of the mod can be included as an option.

Is there handling for optional/recommended mods?

I didn't remember to include it but it would be very simple to add it to this design. You'd add it in between 2 and 3 and then check it in a separate pass using the same functions used to check the requirements.

Ooh, I like this mockup.

What would you have on the other two tabs?

I'll design them today. The update tab would be very similar to the one you see except it would display a list of the mods and games you have already have installed. Clicking on them would simply check the version you have against the one that is available. Personally I think we should make checking for updates something the launcher does automatically (although we'd allow the user to switch that off and do it manually if they wanted to).

[Tolwyn]

Hmm... As far as I am concerned, wouldn't it be better to store all settings in an ini file instead of using registry (or rather virtual registry on Vista / Win 7)?

This would make the game really portable and I could, for example, run different resolutions with different mods. For instance, when debugging a mission, I prefer to run the game in 1280*1024 in window mode, when playing just for fun, I run it in 1920*1080. Currently the resolution setting (as well as language setting) is stored in the registry. Which reminds me: German version of Saga poses another problem - language string has to be set to German which leads to all kinds of issues with the HUD in international version.

[FUBAR-BDHR]

Removing all registry dependencies was one thing everyone was in agreement on at the meeting.

[karajorma]

Yeah. It was so obvious we'd be giving the registry the boot that I didn't even think to mention it.

[chief1983]

Does that include eliminating the launcher's backwards compatibility with retail through 3.6.10 builds?  I was suggesting a while back that future builds should somehow tell the launcher they use a new storage method for configuration, similar to how they report their supported flags when polled.  Then a launcher could work with old and new builds.

[portej05]

I actually thought about this a while ago.
Define a very clear XML file format which contains the capabilities of the engine and the defaults that will be used.
Define a very clear XML file format which contains the settings to be used for the game.
Readers are simple and cross-platform.

This allows for very simple launcher development in whatever design people wish.

[karajorma]

Moving on, here are my mock ups for the run game section.

Starting with Mod/Game selection. This simply displays a list of the available mods and games. I've not bothered showing the text from the mod.ini here but we might as well show it.



Once you have selected a mod you'll be taken to the easy setup screen.



This makes heavy use of the mod.ini (or its replacement) that was downloaded with the mod. First thing the launcher does is use the skinning settings in the mod.ini to alter itself to look the way the mod team wanted.

Then it checks if you have specified an executable for this mod (or globally). If not it looks in the .ini file to see if one is specified there and selects that one if it finds it in the correct folder.

It then populates the easy setup combo box with all the versions it can find. Some of these are hard coded (as they are now) but mod teams can also specify their own set of default settings in the ini file which will then be presented to the user as an option.

The Other tab could be used to have general settings (Don't check for updates, continue even if required mods are out of date, etc) perhaps we could just call it preferences or something. The About This Game tab also uses the mod.ini to give a description of the game/mod and any information it thinks the user might need. The About FS2_Open tab has information about the SCP etc on it. The other tabs should be fairly self explanatory.

[Tomo]

Kara said I should repost this here:

I would definitely agree with a combined Launcher/Installer-Updater, as that immediately minimises support.
However, I would suggest that it *doesn't* expect to deal with all TCs, but instead the same executable should be 'skinnable' to meet the needs of each TC.
- So a TC distributes the same Launcher app, but with a different skin and config file suited to their particular needs.

Thus TCs have the option to have associated 'mods', handled in the same way as FS2O handles mods to FS2.

This removes the problem of 'Where do you put the Launcher?' and the issues of having the Launcher find the appropriate executables, because it simply lives in the same folder as the associated TC or FreeSpace2Open itself.

It also prevents future updates to the Launcher from possibly breaking older 'no longer supported' TCs, as they will simply keep their old one.