Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Goober5000 on January 31, 2014, 11:19:34 pm
-
See this thread (http://www.hard-light.net/forums/index.php?topic=86614.0) 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?
-
I really would recommend using OpenAL Soft instead of Creative's. Can't answer to the wxLauncher questions.
-
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?
-
http://www.hard-light.net/forums/index.php?topic=85640.0
-
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.
-
doesnt openalSoft still need creative's openal driver to work on windows?
-
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.
-
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*
-
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.
-
No, and it's neither necessary nor desirable.
Sorry but I disagree strongly there.
-
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.
-
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.
-
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 :p
-
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.
-
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.
-
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.
-
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 (http://www.hard-light.net/forums/index.php?topic=86110.0), 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.
-
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.
-
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.
-
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.
-
Fury mentioned a couple of assumptions that are no longer true:
Microsoft's design intent is that Admin permissions should be necessary to install anything on current Windows.
We can expect any remaining loopholes* to be closed, so the UAC prompt will be needed.
I believe that by default Windows 8 does not let you write to the C:/ root without admin permission, so C:/Games will already be 'broken'.
(Unsigned installers can also be painful under Windows 8, but we'll burn that bridge later)
Some installers change the rights during installation (eg Steam**), this is a good workaround for FSO - but obviously the installer needs elevated privileges to do that!
As you said, there has already been discussion about moving Pilot, config and log files into the user's Home folder somewhere. (Be that Documents or AppData/{GUID} or whatever)
At that point, the game itself will no longer require any write access to its binary and mod folders, which will be excellent.
Once that's done, the per-user data can be copied without recourse to grabbing the whole folder, and can even automatically 'roam' between different Windows computers.
Much smaller and easier.
* Windows 8's "Modern"/"TIFKAM" offers a peek into a future where files in the Users/ folder cannot be executed.
** Several Steam games do (try) to store their user data in their own installation folders, and Steam changes the ACLs during installation in an attempt to let them do that.
This is bad practice and doesn't always work, so some games need admin every time they run.
-
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.
In the worst case scenario the directory structure would look like this:
C:\FS2_Open
C:\Diaspora
C:\Freespace2
And if either installer or launcher would ever attempt to automatically parse mod and total conversion locations and versions so that the end-user does not have to, both would then probably end up searching all of C:.
It'd be much safer to have
C:\FS2_Open
C:\FS2_Open\Diaspora
C:\FS2_Open\Freespace2
That way both installer and launcher can safely parse the FS2_Open directory structure and look for mods, total conversions, executables and their versions and whatever else we may need today and in the future. End-user wouldn't even need to manually know or specify any of their locations.
Microsoft's design intent is that Admin permissions should be necessary to install anything on current Windows.
We can expect any remaining loopholes* to be closed, so the UAC prompt will be needed.
The difference being that anything related to FSO would not need install whatsoever, since nothing strictly requires admin rights. You only need to download (and extract) the files. It makes no sense to enforce this kind of behavior where it is not necessary!
I believe that by default Windows 8 does not let you write to the C:/ root without admin permission, so C:/Games will already be 'broken'.
That only applies to files, not directories. You can freely create directories under C:.
And as a general reply to your post. You seem to want installer/launcher to require admin rights even if end-user wants to update their mods or executables. Yeah no, thank you. First of all that would affect modders and fredders who could not longer even do as much as save missions without taking necessary permissions or be prompted by UAC. The whole point of improving this process is not to just make it painless to end-users who do nothing but play, but also fredders and modders. The fact that we'd have all sort of permission issues and UAC prompts kind of defeats that purpose. Yeah sure, the installer could manage the permissions for you during the initial install, but why when it's not even necessary to go that far in the first place. Seems kind of wasted effort.
-
In the worst case scenario the directory structure would look like this:
C:\FS2_Open
C:\Diaspora
C:\Freespace2
And if either installer or launcher would ever attempt to automatically parse mod and total conversion locations and versions so that the end-user does not have to, both would then probably end up searching all of C:.
It'd be much safer to have
C:\FS2_Open
C:\FS2_Open\Diaspora
C:\FS2_Open\Freespace2
That way both installer and launcher can safely parse the FS2_Open directory structure and look for mods, total conversions, executables and their versions and whatever else we may need today and in the future. End-user wouldn't even need to manually know or specify any of their locations.
In an ideal world, that would be great. But I don't know if you noticed my comment about Half-Life. Cause that's the situation we're actually in.
There is no way any Freespace Installer (Especially one which also deals with TCs) can know if the user has already installed FS2 (or an older TC) before the user downloaded the Installer. So then we're left with a problem. What do we do if the user has already installed Freespace to C:\Games\Freespace2 and TBP to C:\Games\TBP?
-
In an ideal world, that would be great. But I don't know if you noticed my comment about Half-Life. Cause that's the situation we're actually in.
There is no way any Freespace Installer (Especially one which also deals with TCs) can know if the user has already installed FS2 (or an older TC) before the user downloaded the Installer. So then we're left with a problem. What do we do if the user has already installed Freespace to C:\Games\Freespace2 and TBP to C:\Games\TBP?
I did notice that and I had answer prepared, but looks like it got lost in copy&paste. Well, let's try again. How does Steam handle pre-Steam retail editions of the games in Steam's portfolio? Short answer, it does not.
I don't think there is any decent and logical way to handle the situation in our situation either. Simply because the situation on any given user's computer could be anything, it would be purely impossible to take into account every possible scenario. Especially because said total conversions have had their own ways to install said total conversions.
But if this is something we have to attempt, then when it comes to retail FreeSpace2 the most the installer could do is to ask location of existing FreeSpace2 directory. Then proceed to merge it into agreed pre-defined directory structure as well as it can. If it notices anything it can't handle, it provides concise information what and why and then provides link to FSWiki article set up for these situations. The article would then contain instructions on how to manually resolve the problem.
But this would not work with total conversions that have used installers of their own, because they could have saved registry information pretty much anywhere. Then you'd also need to take into account uninstall information. In fact, it'd be simpler to merge the total conversion's data directory to agreed pre-defined directory structure, uninstall the total conversion and then have the installer re-install it. Luckily the number of total conversions the installer would need to check for is limited.
Or alternatively, parse only existing FreeSpace2 directory, merge it and don't support existing total conversion installations.
-
You seem to want installer/launcher to require admin rights even if end-user wants to update their mods or executables.
No, I'm saying that Microsoft are slowly changing the enforcement of the rules, and it is inevitable that the Installer will require admin rights, if it doesn't already.
(And given some of the posts in the other FSO Installer thread, it looks like it might.)
Trying to find loopholes to remove that need is only going to cause pain, because sooner or later the loophole chosen will close and we're back where we started.
Best to accept that installation will need admin rights, and make sure that nothing else does.
People don't mind a UAC prompt to install or apply an update, but they will be very annoyed if they get that UAC every time they play the game.
But this would not work with total conversions that have used installers of their own, because they could have saved registry information pretty much anywhere. Then you'd also need to take into account uninstall information. In fact, it'd be simpler to merge the total conversion's data directory to agreed pre-defined directory structure, uninstall the total conversion and then have the installer re-install it. Luckily the number of total conversions the installer would need to check for is limited.
Or alternatively, parse only existing FreeSpace2 directory, merge it and don't support existing total conversion installations.
Good point, I think you're right about that.
-
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?
In short:
1) No.
2) Mostly file extraction and copy. It also registers itself with the windows uninstaller, notes its version information for future installers, and records the location of its command interpreter in the registry.
In long: The design ethos (as already noted in this thread) is for wxLauncher to be bundled with anything and everything just like steam is. And like Steam, an installer that is installing wxLauncher on behalf of the user on Windows is expected to run the most recent version of our installer available from our download site at the time the installer is built for distribution. It is up to the installer if they want to run the wxLauncher installer in silent mode (/S) or not. It is safe to run the wxLauncher installer even if a newer version of wxLauncher is installed, that is, it will not downgrade the existing install.
wxLauncher does expect to be installed globally on the system. So the wxLauncher installer will have to run as an administrator, which it will do automaticly if required.
wxLauncher expects the that an installer that wants to register a new total conversion will call the wxLauncher command interpreter and register it using the publicly committed api listed in the readme for content authors (https://code.google.com/p/wxlauncher/source/browse/ReadMe.ContentAuthors.txt). The full path to the command interpreter is located in the cmdinterpreter value under SOFTWARE\wxLauncher Team\wxLauncher.
For OS X and Linux I am not sure how well tested the command interpreter is, however the process is very similar, and there is no reason it shouldn't work because command interpreter is doing the same thing as the user would from the interface. For OS X, wxLauncher expects the .app to be placed in the global /Applications directory. An installer is expected introspect this .app and find the a file called cmdinterpreter with the execute bit set for the platform that it is running on or a the file wxlauncher with the execute bit set for the platform that it is running on. On linux, it is expected that an installer will search for the file cmdinterpreter with the execute bit set in the /usr/share/wxlauncher directory or the file with wxlauncher with the execute bit set at /usr/bin/wxlauncher. It is expected that the installer would then use the found interpeter the same as it would on windows.
An installer should never attempt to interact with the wxLauncher database stored on disk as the format can and will change.
EDIT: wxLauncher doesn't support win98 mostly because VS2008 doesn't. To my knowledge wxLauncher doesn't do anything in particular that win98 can't support.
-
The thing is, I can copy the wxLauncher setup program to the FS2 directory, same as the other executables. But having to run the wxLauncher setup program is an extra step, whether I launch the setup or the user does. And whoever runs it, the user is going to be faced with a UAC prompt. No other feature or mod of either the Installer or any FSO executable requires UAC.
It would be a much smoother experience if wxLauncher was just a drop-in executable. And aside from "registering itself with the Windows uninstaller", nothing in #2 intrinsically requires a setup program.
-
And that's a problem because...?
-
I don't see why an installer asking for elevated privileges is such an issue.
-
because goober doesnt want any launcher that isnt effectively the 5.5 launcher?
-
I doubt that's the case but if it is, he should have made his objections clear in 2009. :p
-
And that's a problem because...?
To which point are you referring?
I don't see why an installer asking for elevated privileges is such an issue.
Because this particular installer is for the Launcher, which is separate from either the mod downloader or the GOG/FS2 installer. It's a whole extra step, and it detracts from the smooth installation experience.
There's also the point that the credentials are required in the first place. Suppose some kid wants to install wxLauncher. One could conceive of a situation where the parent would consent to entering credentials for FS2 but not for "some unknown third-party program".
And this is aside from the fact that it is possible, in principle, to handle all of the points IssMneur mentioned without elevated privileges.
-
There's also the point that the credentials are required in the first place. Suppose some kid wants to install wxLauncher. One could conceive of a situation where the parent would consent to entering credentials for FS2 but not for "some unknown third-party program".
Having just installed FS2 using the gog.com installer, it also appears in the UAC the same way, because it is not signed either. So said parent would have the same objection to that installer.
And this is aside from the fact that it is possible, in principle, to handle all of the points IssMneur mentioned without elevated privileges.
I have little doubt that we will address doing what we can without elevated privileges, but that is not something that has currently been designed nor tested.
Having said that, it is certainly possible to just copy all of the files that are in the wxLauncher folder with no ill effect on how the launcher runs, which is what Fury apparently does. Though as Fury already noted, wxLauncher will still save the internal data to the users profile. In this mode it will not be detected by the installer and the wxLauncher team doesn't support this installation mode. Read, just copying will work more or less as expected but if it breaks its on you.