[Goober5000]

See this thread for context.

As others have mentioned, the Installer should really add OpenAL and wxLauncher if it's going to be a complete solution to users' needs.  Although OpenAL has its own setup program, all that FSO requires is to have the OpenAL DLL in the same directory as the executable.  I've modified the SCP config file to do this.

But wxLauncher looks like it's more complicated -- not only does it also have its own setup program, it resides in Program Files rather than the game directory.  I haven't been following its development closely, so this raises two important questions...

1) Is there any way to build wxLauncher so that it can be a drop-in launcher with no installation, similar to the old Launcher 5.5g?

2) What exactly happens during the wxLauncher installation process?

[Fury]

I really would recommend using OpenAL Soft instead of Creative's. Can't answer to the wxLauncher questions.

[Goober5000]

I really would recommend using OpenAL Soft instead of Creative's. Can't answer to the wxLauncher questions.

1) Why?  2) Can you point me to an OpenAL Soft DLL?

[Fury]

http://www.hard-light.net/forums/index.php?topic=85640.0

[m!m]

The advantage of OpenAL Soft is that it can easily be built and distributed with the FSO builds which would eliminate another failure source in the FSO installation process.

[pecenipicek]

doesnt openalSoft still need creative's openal driver to work on windows?

[Fury]

No unless you have a Creative sound card. Each manufacturer implements support for OpenAL in their own drivers. If you don't have a Creative card, you won't need anything Creative to have OpenAL support on Windows or any other OS. OpenAL is simply an API.

[pecenipicek]

No unless you have a Creative sound card. Each manufacturer implements support for OpenAL in their own drivers. If you don't have a Creative card, you won't need anything Creative to have OpenAL support on Windows or any other OS. OpenAL is simply an API.

ah. gotcha.

*hides his creative card somewhere*

[Tomo]

1) Is there any way to build wxLauncher so that it can be a drop-in launcher with no installation, similar to the old Launcher 5.5g?

No, and it's neither necessary nor desirable.
wxLauncher supports more than just 'proper' FSO (Diaspora etc), and already has an installer and uninstaller, including all dependencies.
(Compiler redistributables, resources etc)

2) What exactly happens during the wxLauncher installation process?

Under Windows it uses an NSIS installer wizard which most users just press "Next...Next....Finish".
(The user can install in a location of their choice if they want)

The FSO installer should simply invoke the native installer, and leave that part of the process to the wxLauncher team.
- It could be invoked with the "/S" switch for a default, silent install though I'd prefer not. There will still be a UAC prompt if applicable.

That said, I do think that the wxLauncher installer needs a commandline flag to define the FSO path for initial profile creation.
The FSO installer will already know and so there's no need for wxLauncher to search (and maybe not find.)

There's one other thing in that the wxWidgets installer still shows the Windows UAC prompt even if wxLauncher is already installed.
I don't know if that's fixable but it'd be great to avoid requesting elevated privileges before checking if it's already installed.

OSX builds provide a DMG file, not sure what you're supposed to do with those as I don't do Apple.

[Fury]

No, and it's neither necessary nor desirable.

Sorry but I disagree strongly there.

[Goober5000]

1) Is there any way to build wxLauncher so that it can be a drop-in launcher with no installation, similar to the old Launcher 5.5g?

No

I'm sure that's not true.  During the wxFRED development process, I discovered that wxFRED could be built to require a wxWidgets installation, or it could be built to contain all the system and resource files it needed.  The same must be true of wxLauncher.

wxLauncher supports more than just 'proper' FSO (Diaspora etc), and already has an installer and uninstaller, including all dependencies.
(Compiler redistributables, resources etc)

And that's not really an explanation.  You don't say what the dependencies are, nor why they need installation as opposed to integration or copying.  Furthermore, the fact that wxLauncher is used for both FSO and Diaspora is completely irrelevant.

2) What exactly happens during the wxLauncher installation process?

Under Windows it uses an NSIS installer wizard which most users just press "Next...Next....Finish".
(The user can install in a location of their choice if they want)

I really didn't think I would need to point this out, but I'm asking from the perspective of a developer, not a user.  I want to know what the setup program does under the hood.

The FSO installer should simply invoke the native installer, and leave that part of the process to the wxLauncher team.

That is what I will be forced to do if we can't change the setup process, but that is not an ideal solution.

[MatthTheGeek]

No, and it's neither necessary nor desirable.

Sorry but I disagree strongly there.

Yup. I'm sorry to tell you that Tomo, but you're an idiot.

Portability was a major feature of 5.5g, and until wxLauncher has that feature, it's still in an extremely early and unuseable WIP state as far as I, and most people around here, are concerned.

[niffiwan]

You really need the wxLauncher guys to be commenting here re what can be done / what does happen. Their bugtracker does (pretty much) confirm that it's not currently "portable like 5.5g".
https://code.google.com/p/wxlauncher/issues/detail?id=44&q=portable&colspec=ID%20Type%20Status%20Priority%20Milestone%20OpSys%20Owner%20Summary

Portability was a major feature of 5.5g, and until wxLauncher has that feature, it's still in an extremely early and unuseable WIP state as far as I, and most people around here, are concerned.

I understand that this is a super important feature for you, but I've got to strongly disagree with your assessment. And I'd like to see some evidence to back up the assertion that most people around here agree with your assessment

[karajorma]

Yup. I'm sorry to tell you that Tomo, but you're an idiot.

Seriously? You've been a HLP member for this long and still haven't learnt not to be insulting in this manner?

You're monkeyed for a week.

[zookeeper]

From a user's point of view the launcher is part of FS2O, and it'd be somewhat poor design to bother them with the details of how it's not. As a user I don't want to have to understand that I now have two independent pieces of software installed (FS2O and a launcher) when I set out to install just one; I just want to be able to run and configure the game I just installed, and the launcher actually being a separate app that I can now use to also run and configure other, unrelated TC's or other FS2 installations will mostly serve as a source of confusion.

[Tomo]

For a "Default" and silent install, simply invoke wxLauncher's installer with "/S".

The user may get a UAC prompt, if they do they click "Ok", and it's done and dusted.

That's it! Have a coffee.

That is why I said it's neither necessary nor desirable to replicate the functionality.
It can't be any better than it already is, it can only cause issues when something gets missed.

The FSO installer is for people who are used to Steam. They neither know nor care how all of this works.
They will not be "porting" by copying the folder because that doesn't work to install any modern games onto a different machine (unless you get very lucky).

(Anyway, the dependencies at the moment are a registry_helper app and MSVC90. And the manifest file.)

Compare with Steam - do you know (or even care) where the game files actually are?
I know, but I don't care.

[Fury]

Well, that's your opinion. But consider,

1) Imagine if FSO executables themselves would be contained within an installer and instead of statically linked dependencies, these dependencies would instead be external files in various directories. Likewise the launcher should be contained within a single executable you can simply download and place in the FSO directory. In addition the executables can share any external dependencies such as OpenAL32.dll without any fuss. Which incidentally the old Launcher 5.5g does. Also a matter of consistency, why should install procedure of the launcher differ from install procedures of FSO executables? The old launcher's didn't.

2) Admin or root permissions should not be required at any time. The last two obstacles are installation of retail FS2 and use of registry. The latter will be gone soon and the first one could be bypassed by extracting data without launching actual retail FS2 or GoG installer. This approach can be used cross-platform for both retail FS2 discs as well as GoG.com installer and Hellzed has already made this possible, all it needs is a solution that works on retail FS2 discs, linux, os x and windows alike.

3) Operating system does have per-user profiles and they can obviously store application per-user settings should this approach be desirable to follow in FSO and launcher. Regardless, it should be optionally possible to keep all user data strictly in FSO directory. For one this allows you to copy the FSO directory whenever and wherever you please without having to re-install anything or worry about user data, launcher profiles and whatever else, secondly this allows you to keep local FSO directory in sync between multiple computers, while including per-user data. Or store FSO dir permanently on network drive, including per-user data. None of these scenarios fully work out because of wxLauncher.

4) Launcher does not need its own installer in any use-case I can imagine. All it does is store a profile(s) containing flags used to launch FSO and hardware setup. In typical FSO scenario the singe-executable launcher would be downloaded either by user or installer into the FSO directory. The installer can even create shortcuts to it if desired. In typical total conversion scenario (like Diaspora), they may either use FSO installer (after (or if) support for total conversions have been implemented) or use their own installer, again placing the single-executable into FSO directory and creating shortcuts if desired. There is NO NEED for launcher to span multiple files and directories or exist outside of FSO directory.

5) Assuming you had two launchers which were on-par feature wise but with one difference. One uses an UAC prompting installer that by default installs to Program Files instead of FSO directory and stores settings in user profile. The other is single executable you can drop into FSO directory and stores settings in FSO directory. Which one would you use?

Obviously you can install wxLauncher into FSO directory into its own directory, but that still doesn't get rid of the UAC install prompt nor storing data in user profile. I actually do install wxLauncher into FSO directory and then create a directory symlink from my AppData\Roaming\wxlauncher to my FreeSpace2\wxLauncher\data directory. It's still something I find annoying and I'd rather not bother with, especially since the old launcher did exactly that and nothing more or less.

[karajorma]

There is NO NEED for launcher to span multiple files and directories or exist outside of FSO directory.

Yes these is. The entire point of the Launcher was to become a Steam style launcher,  installer and updater for any FSO project. Somewhere along the line people got this bassackwards and decided to make the installer handle the last two even though it makes very little sense to do things that way. The installer can't check for updates to itself or the projects it installs unless you run it. Admittedly the launcher can't do that either, but the whole point is that you are supposed to run the launcher every time you play.

Quite frankly having multiple versions of the launcher if you have multiple TCs installed is a ****ing stupid idea which WILL bite us on the arse. The only reason Diaspora installs the launcher to its own folder is because the functionality wasn't in the launcher to support having multiple TCs at the time. It is now and if I was releasing Diaspora for the first time today, setting up the launcher to support both Diaspora and Freespace is exactly what I would do.

[Fury]

Last time I checked, Steam itself and its games reside within same Steam directory. If you want to make this work like Steam, then it would need a directory structure something like this:
C:\Games\FreeSpace2_Open
C:\Games\FreeSpace2_Open\FreeSpace2
C:\Games\FreeSpace2_Open\FreeSpace2\mediavps_3612
C:\Games\FreeSpace2_Open\Diaspora

In which case installer and launcher would reside in the first directory. Retail FS2 and any mods depending on retail would be in \FreeSpace2_Open\FreeSpace2. And total conversions that are independent from retail reside in their own directories under \FreeSpace2_Open. You can't have the launcher, retail FS2, mods and total conversion spill all over the place if you want it to be Steam-like. That is also the most feasible setup for unified launcher to handle mods and total conversions alike. And best of all, it all stays within one directory structure and thus remains portable.

Which by the way, applies to Steam as well. You only need to copy your Steam directory and nearly everything follows. Unfortunately Valve/Steam cannot control where and how individual games save their data, meaning save games and other stuff may be saved into user profile. But surprisingly many games keep their saves within Steam's directory structure or cloud.

[karajorma]

There's no reason we couldn't use that structure for new installs. If we can extract the GOG download on Linux and Mac, why not on Windows too?


But I still don't see much issue with having

C:\Games\FS2_Open (Where the launcher lives)
C:\Games\Diaspora
C:\Games\Freespace2

And people just copying all 3 if they want to move their FS2 install. In the end we're talking about something which most users don't do, and which you can't do with most games anyway.

What does Steam do if you have already installed games like Half-Life etc which pre-date Steam but which it likes to take over and manage though? Cause that's the situation analogous to FS2.