Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Hellzed on September 09, 2009, 11:55:31 am
-
Hi
Sorry for my bad English,I'm french and I stopped learning this language 2 years ago.
I have some ideas about a new linux freespace 2 open launcher.
IMHO, YAL or fs2-open#launcher, even if they are useful for configuring fs2_open, are NOT user friendly: too many buttons and options, while making a simple startup script (or getting it from ubuntu-fr or hard-light) is quick and easy...
In the same time, FSOInstaller is a good idea, but if I'm not wrong, we have to download the new version first, and then update freespace... It is usefull, but it seems a bit complicated too.
My idea is that we could make a single thing with these 2 programs for Linux users, with a very simple user interface.
I'm preparing mockups, but I have to explain how I want it to be (it could look like Edge of Choas launcher for people who played it):
- on the first run, it asks where to install the game (and it could detect older installations and update it)
- a start window, with the image of the currently selected mod, and only four button: Play (Play - Update - Settings - About, or Play(disabled) - Install - Settings - About if the game isn't installed)
- Play instantly launches the game, with the last settings.
- Update only updates currently installed files.
- Settings : exactly like YAL or fs2-open#launcher settings: game folder, use debug build or not, video, graphics, audio, input ... ( we could get some parts of their source code)
- About Hard Light (with a link)...
- In the image of the mod (in a corner, for example), there could be a pop-up list with the installed mods, and a "Add/Remove" option, opening a mod browser, with a list of mods, descriptions, and a checkbox for each, to install or uninstall.
- Perhaps we could install or uninstall two or more mods at the same time ! And while it's installing, play the game, or leave the installer work (just an icon in the systray)...
So, what do you think about it ? Is someone interested ?
ps: I know I am talking about hours of hard work, and I am not a very good C or C++ (or Python) coder. But I'm one of the main contributor to the french fs2_open documentation on Ubuntu-fr wiki, and I think I know what users expect from an installer/launcher.
ps2: I think update system could work with a list of up-to-date files and their url so that url of a mod could change without breaking the update system, downloaded each time the launcher is started (or only when asked, it could be in the settings)... I candidate to be the maintainer of this kind of server !
ps3: the advantage of such a linux-only launcher is that it could detect the architecture (32 or 64) and download only the good binary. I always thinked amd64 support for FS2 had to be increased (official builds for example).
-
I'm kinda surprised this got no responses (presumably because it referred to Linux in the title and everyone assumed it was nothing to do with them if they were on Windows or Mac OS X).
The eventual plan for FS2_Open is to end up with a single cross platform installer/launcher. Portej05 has been pushing for one for a while and I fully agree with the idea (and have suggested it myself in the past). I'd love to see your mock ups. :)
-
Yeah, I'm surprised too that his did not got any attention.
Anyway, Hellzed please check your PM.
It seems that there were some trouble with the board recently, so if you missed my message, tell me.
-
I read your message !
So, as I told you, I've got many ideas, but since I have a little knowledge in programming, I know what can be done and what cannot. But I'm not a very good coder. I'm trying to learn GTK but it's a very slow work-in-progress. For example, I'm trying to do mockups with Glade, but it does not render as i want it to be...
And i really want this to be done, because I created this page : http://doc.ubuntu-fr.org/freespace (a complete install and configure guide for FreeSpace on Ubuntu), but it's still too hard for a beginner.
-
GTK? I'm a KDE user, so I'd go for Qt ;7 (not sure if it's that portable though...)
Anyway, Turey's installer does a pretty neat job ATM, I think you should concentrate in doing a launcher instead of a launcher/installer, as an installer needs work beyond the scope of a simple desktop application.
Looking forward for your mock-ups too.
And for someone to fix the board :wtf:
-
I'd actually like to see a cross-platform Launcher/Manager/Installer where the Installer portion is also capable of applying updates.
Using cfile, cfileextractor and cfilearchiver, it should be possible to write something so that, for instance, future updates to the MediaVP's won't require re-downloading the whole shebang for what little may or may not have updated since the last version. Instead, you get an update package that rebuilds your VP's with the latest changed content.
-
I'd suggest avoiding those files and just doing whatever WMCoolmon did with VPMage except in C++. That would give us the advantage of being able to choose whatever license we wanted for the launcher rather burdening ourselves with the :v: one.
-
what he did was use java and thus avoided the issue entirely.
-
Yeah I know that he used Java which is I why I said we should do the same in C++ :)
Having an installer that can patch VP files would mean we need a hell of a lot less bandwidth for minor updates and it would remove the need to constantly have to manually deal with silly mistake via patches that half the fans forget/never hear about until they have a problem.
-
GTK? I'm a KDE user, so I'd go for Qt ;7 (not sure if it's that portable though...)
QT is indeed portable. My employer uses QT for all their 'new' projects, which are designed to run on both Windows and Mac.
However, Goober has been looking at the wxWidgets framework for FRED, and I think Spicious built a wxWidgets-based Stand-alone multi-server.
So it would make sense to use that framework, given that a fair bit of work has already been done using it.
-
I still believe that there should be two separate applications (launcher and installer). But hey, you're welcome to prove me wrong :)
Being able to download small patches instead of the whole thing is a great idea, as long as someone is wiling to make and keep them available online.
And in this case we need a system to quickly determine what patches need to be downloaded for a certain file (sometimes you might need to download multiple patches to get a file up to date, and this situation should be considered too).
As for the launcher, I think that the only thing it has to do with updates is to quickly determine if there are updates available for your files (all of them? should you be able to select which one to check?) and prompt you to launch the installer. And this brings us back to the chicken or egg problem (since the installer basically should do the same checks as the launcher first before determining the required updates)
-
I still believe that there should be two separate applications (launcher and installer). But hey, you're welcome to prove me wrong :)
Ya they shouldn't be one program, but a suite of programs, which I hope is the plan.
And in this case we need a system to quickly determine what patches need to be downloaded for a certain file (sometimes you might need to download multiple patches to get a file up to date, and this situation should be considered too).
This could be fairly easily setup with a proper version number system and some meta-data for the installer to use.
As for the launcher, I think that the only thing it has to do with updates is to quickly determine if there are updates available for your files (all of them? should you be able to select which one to check?) and prompt you to launch the installer. And this brings us back to the chicken or egg problem (since the installer basically should do the same checks as the launcher first before determining the required updates)
Well just have the launcher call the check_for_updates program or function on the installer and just have the installer do the work and just return "up-to-date" or "needs-updates". If the user wants to know what the updates are the launcher calls the installer show_needed_updates which will result in a URL to display in a web browser (the users default one or in something like a webkit window in the launcher).
Also, I would suggest using wxWidgets over qt, especially it there are other projects around freespace that are or will be in wxWidgets. All in all there does not seem to be much here that difficult because most of the pieces already exist in some form (the existing launchers, Turey's installer) and just need to be tied together in a neat little cross-platform package. That being said "neat little package" takes quite some time, and "cross-platform"....we will be at this a while.
Having stuck my head out like that, I am programmer and while my C/C++ is a bit rusty, I will be able to help in this endeavor starting in October.
-
Okay, speaking from the POV of a support guy, I like having as few programs, with as few dependencies as possible. One Launcher, with an update functionality (however that will be implemented), would be fine by me. And I would prefer a complete, start-from-scratch rewrite to a quick hack job.
-
This could be fairly easily setup with a proper version number system and some meta-data for the installer to use.
Indeed. I did not said that with the meaning "how could we do this", but rather as "there will be a little more work than just downloading one big file if it's different than what you have"
@The E:
Hellzed proposed an installer/launcher for Linux, this spilled over to a new installer proposal. Somehow, if we manage to make a unified and platform-independent launcher/installer, I feel it might be worth building it as an one application.
Me, I'm mostly a designer than a coder, though I wrote code too. Hellzed said he will try some mock ups, and I'm still waiting for them before putting anything on the table.
Iss Mneur, would you like to join this project as a coder, assuming that we manage to truly start it?
Open question:
What the purpose of the "Registry" tab in the launcher? Who uses the registry? The launcher? FS2_Open? Both? If FS2_Open uses it, does it really need to?
I mean, I want to know if we can scrap that tab. I always disliked the registry, and it's not portable.
-
The registry tab shows the current state of all registry keys the selected executable uses. Just like the command-line readout in the features tab, it serves mostly as a quick way to find out if all the settings are correct. Speaking again as a troubleshooting person, I would hate to lose it.
Of course it would have to be adapted for the way this data is stored on MacOS and Linux; but a function like that is still useful, IMHO.
-
I've been evaluating using the RakNet autopatcher system for this, and the Qt framework (I'm more familiar with that than wxWidgets).
FSO uses the registry under windows - it's ugly, but we're working on removing the dependence on that.
-
Yeah, but unfortunately, the registry read/write functionality has to be maintained for older builds to work correctly with the new Launcher.
-
I would rather see it gone (the registry dependence).
I understand that the old builds NEED to read something from the registry, but I'd keep the settings in a file and WRITE them to the registry before launch, if the current OS is Windows and if the build requires it. Otherwise, everything else is passed through to the binary via parameters at launch.
How is the registry dependence handled on OSX? In Linux is a simple config file in ~/.fs2_open if I remember correctly.
-
Umm. The Linux and MacOS builds store their settings in a config file somewhere else. And once you write some values to the registry (which happens when you start the Launcher and click "Run"), those values stay there, unless you delete those settings again when the program exits. The way it is currently handled is the best one available for the circumstances.
-
The other issue is that there's some limit to the length of the command line (IIRC) on windows, and we have _a lot_ of possible command line parameters, which are currently (if I've read the code correctly) passed to the engine through a text file (way to go to mix everything up :P ).
Just passing them to the engine on the command line might not be feasible.
-
This could be fairly easily setup with a proper version number system and some meta-data for the installer to use.
Indeed. I did not said that with the meaning "how could we do this", but rather as "there will be a little more work than just downloading one big file if it's different than what you have"
Of course, I didn't mean for it to sound like I was saying "this was the only way to do it", more a it is doable with some technical specifications/design so that the mods would be able to provide input to the process. Because if this is going to work in an easy and not complicated manner like Hellzed wants we need the whole thing to be supported by a large number of mods. As well I am sure we would not be the first ones to have this problem so there is likely existing solutions for this very problem and it would then be a task of just integrating.
@The E:
Hellzed proposed an installer/launcher for Linux, this spilled over to a new installer proposal. Somehow, if we manage to make a unified and platform-independent launcher/installer, I feel it might be worth building it as an one application.
Yes, I too, I think this would be of most value if it would work on the fs2_open supported platforms because the problems that Hellzed talks about apply to all platforms, though linux being what it is, the problem is likely more acute. Of course, this is probably the reason that this discussion has gone off on this angle to start with.
Me, I'm mostly a designer than a coder, though I wrote code too. Hellzed said he will try some mock ups, and I'm still waiting for them before putting anything on the table.
I too would like to see what Hellzed comes up with.
Iss Mneur, would you like to join this project as a coder, assuming we manage to truly start it?
I would, but as I stated in the my last post I really would not be able to dedicate any time to coding it until after October starts, but would be able to put some input into designing it.
-
Alright, so we have a lot of parameters that we might need to pass to the program. I agree that for the moment, the registry option is the best we have, but I'll keep studying the problem.
Why is bad passing parameters via a text file? (technically speaking)
1. The launcher might not be able to write the file or to rewrite it's contents
2. FS2_Open might not have the right to read the file the launcher wrote
Other posibilities?
I would, but as I stated in the my last post I really would not be able to dedicate any time to coding it until after October starts, but would be able to put some input into designing it.
Good enough. I always said that many project fail because people who code them are not able to see the final shape of the product for one reason or another.
Design is law
-
I think you're misunderstanding what I said. The Launcher needs to read and write to the registry if it is supposed to be compatible to all FSO builds.
Passing parameters via text file is necessary to a) avoid storing said parameters in the registry b) Keep them around in a human-readable format and c) because of the string length limits portej05 mentioned.
Now, the only scenario where the Launcher is not allowed to write this file to a location where FSO can read it (IIRC) is on Windows Vista and later with the Launcher not being in the same directory as the FSO exe. YAL just writes to ~/.fs2_open, and I imagine Soulstorm's Launcher does the same thing.
Design is law
No. Functionality is.
-
I think you're misunderstanding what I said. The Launcher needs to read and write to the registry if it is supposed to be compatible to all FSO builds.
No, I understood just right. The launcher thing.
What I was asking about (sorry if I used the wrong words) is if FS2_Open REALLY needs the registry. Forget compatibility, this is an abstract question.
I'm just collecting data, not proposing designs for the next Space Shuttle. :P
As for the quote, it was the motto of a company who created another landmark game some years ago. But design and functionality go hand in hand. You can't have one without the other and you can't have a good end product without them.
-
In principle, FS2_Open doesn't really need the registry. However, and this is a big however, all windows builds will need it until that dependency is discarded in favour of some sort of .ini file. As a result, IF the new Launcher is to be compatible to all FSO builds (Just as the current Launcher is), it HAS to be able to read and write to the registry.
-
You know, a launcher rewrite is already in progress. It's just taking a long time.
-
I've got a rewrite going too; it's probably going even slower. So far it's just a copy of the existing gui in wx without any functionality.
Would it really be terrible to at some point break backwards compatibility with new launcher and new fs2_open versions?
-
Would it really be terrible to at some point break backwards compatibility with new launcher and new fs2_open versions?
Hmmm... since most of the mods released lately use a recent build, it would probably not be such a big deal. There will be some angry posts on the board though, I can guarantee you that :)
@Goober5000:
The idea was not to just rewrite a platform-independent launcher, but to create a new one, improving on it's current capabilities and adding new ones.
I know we are discussing starting ANOTHER launcher project, but is there anyone CLOSE to finishing one? Making our work redundant...
-
I say unless we can get it set up so FRED2/FS2 will properly launch and start a mission when I double-click (or right click and select Run/Edit in FRED2/whatever), screw the registry.
That's all it'd really be good for, as far as I can tell.
That said, if something like that could be set up, I'd be all for it.
-
I think you're misunderstanding what I said. The Launcher needs to read and write to the registry if it is supposed to be compatible to all FSO builds.
Passing parameters via text file is necessary to a) avoid storing said parameters in the registry b) Keep them around in a human-readable format and c) because of the string length limits portej05 mentioned.
Now, the only scenario where the Launcher is not allowed to write this file to a location where FSO can read it (IIRC) is on Windows Vista and later with the Launcher not being in the same directory as the FSO exe. YAL just writes to ~/.fs2_open, and I imagine Soulstorm's Launcher does the same thing.
Design is law
No. Functionality is.
Both are. It has to work, and it has to be usable and maintainable.
-
Would it really be terrible to at some point break backwards compatibility with new launcher and new fs2_open versions?
Hmmm... since most of the mods released lately use a recent build, it would probably not be such a big deal. There will be some angry posts on the board though, I can guarantee you that :)
Someone correct me if I am wrong but I thought this would be most useful to support most, if not all, mods that are still available (not that it would happen right away, though) so that it very straight forward for new freespace users to get started with the game. Yes, I realize how many completed mods there are just on hard-light, but that would be part of the designing/specing the system so that community can maintain the data that the installer offers.
Not to be presumptuous but it seems to me that Hellzed's primary motivation for this suggestion is to be able to "sell" Ubuntu and a neat shiny game, (freespace), to the francophone computer users. That, IMHO, is something any of the linux distro projects would like.
@Goober5000 and kkmic:
I think the idea was to make the whole thing polished and user friendly, because that seems to be the only thing that does not exist the basic, polished, and shiny launcher. Everything else already exists. We have Turey's installer that already exists and does work, but I am under the impression that the installer as it is now does not do diffing, it just downloads the entire vp that is out of date. In some cursory searching that according to FSOInsaller.com that Goober5000 is rewriting the installer, but the last date on that site was from 2006/2007, so the question for Goober5000 or anyone else that knows, what features does this rewritten installer have/should have and what is its status? I, like quite a few coders, am quite lazy and if someone has done some of the work already, I am not going to re-implement it just because I can.
I know we are discussing starting ANOTHER launcher project, but is there anyone CLOSE to finishing one? Making our work redundant...
I too would like to know. I see there are four launchers that have been released, (again cursory searching), 1 for win32, 2 for linux, and 1 for MacOS X. Seems YAL does both windows and linux, not OSX.
Modifying an existing launcher is not out the question, but this is more of a design type document for a "basic, polished, and shiny" launcher that will integrate a an installer so that it can check for and install updates to the mods, engine, maybe fred and itself.
-
In some cursory searching that according to FSOInsaller.com that Goober5000 is rewriting the installer, but the last date on that site was from 2006/2007, so the question for Goober5000 or anyone else that knows, what features does this rewritten installer have/should have and what is its status? I, like quite a few coders, am quite lazy and if someone has done some of the work already, I am not going to re-implement it just because I can.
The 2006/2007 date is when Turey stopped updating the installer. Recently he delegated the code to the SCP, and I started a general code cleanup about six months ago. It's reasonably close to being done; I just need time to finish it.
I know we are discussing starting ANOTHER launcher project, but is there anyone CLOSE to finishing one? Making our work redundant...
I too would like to know. I see there are four launchers that have been released, (again cursory searching), 1 for win32, 2 for linux, and 1 for MacOS X. Seems YAL does both windows and linux, not OSX.
Indeed. I figured it would be best to start with the most fully-featured launcher and make it cross-platform. This I judged to be the Win32 launcher that was originally created by RandomTiger and is now distributed with FSO. I am also performing a code cleanup on the launcher in parallel with Turey's installer. Once I finish, the plan is to hand it off to portej05 who will oversee conversion of the GUI to wxWidgets.
-
The 2006/2007 date is when Turey stopped updating the installer. Recently he delegated the code to the SCP, and I started a general code cleanup about six months ago. It's reasonably close to being done; I just need time to finish it.
Hmm, interesting. Out of curiosity (no I have not checked to see if I can find the code) are the features that we are discussing here planned/implemented? In particular the diffing of .vp files, the ability to check for updates quickly, and to apply updates only to a specific mod. Is the installer also being ported to C/C++ and wxWidgets or is it staying in java?
I know we are discussing starting ANOTHER launcher project, but is there anyone CLOSE to finishing one? Making our work redundant...
I too would like to know. I see there are four launchers that have been released, (again cursory searching), 1 for win32, 2 for linux, and 1 for MacOS X. Seems YAL does both windows and linux, not OSX.
Indeed. I figured it would be best to start with the most fully-featured launcher and make it cross-platform. This I judged to be the Win32 launcher that was originally created by RandomTiger and is now distributed with FSO. I am also performing a code cleanup on the launcher in parallel with Turey's installer. Once I finish, the plan is to hand it off to portej05 who will oversee conversion of the GUI to wxWidgets.
Interesting. Is the clean up a cross platform conversion? or is more a remove the unclear code and do the cross-platform stuff when converting to wxWidgets? The reason I ask is because wxWidgets, as you probably know, has a large amount of cross platform tools in addition to the GUI stuff itself, in particular file system stuff.
Anyway, the original idea of this thread was to have a very simple and pretty launcher to present to new users and so far this seems to be something that we have will have to do. But the basic launcher would need an advanced settings capability that could be the existing fully featured launcher, which IMHO, would work out quite well. Once we figure out what we want to do for the new shiny launcher, we will come knocking. :)
-
Hmm, interesting. Out of curiosity (no I have not checked to see if I can find the code) are the features that we are discussing here planned/implemented? In particular the diffing of .vp files, the ability to check for updates quickly, and to apply updates only to a specific mod. Is the installer also being ported to C/C++ and wxWidgets or is it staying in java?
The first two of those aren't planned. And no, I'm not rewriting it in C; I'm keeping the Java code but cleaning it up a bit.
I'm also not working on it full time; I'm sort of interleaving it with the launcher and all the other projects I have, which is why it's taken a few months.
Interesting. Is the clean up a cross platform conversion? or is more a remove the unclear code and do the cross-platform stuff when converting to wxWidgets? The reason I ask is because wxWidgets, as you probably know, has a large amount of cross platform tools in addition to the GUI stuff itself, in particular file system stuff.
It's a multi-stage process. Cleanup comes first, then cross-platform compatibility.
-
Well, lately, I had the urge of rewritting the FS2_Launcher for OS X. Since its release, my programming skills improved, but not the code base, and I reached a point to say "what the heck was I thinking when writing this part?". So, when I began rewriting it, I created this thread to ask for feedback (http://www.hard-light.net/forums/index.php?topic=65808.new;topicseen#new) and features request.
So, people pointed me towards creating a cross-platform Launcher. Seems the need is so great for a cross-platform Launcher that I can hardly find any reason to start a new project. For the Launcher on OS X even if I had some cool ideas, like implementing some eye-candy, updating some 3rd party mods, mini-browser for the site for each mod, connection with the Freespace Wiki for explanation for the command line arguments, and stuff like that.
I understand that although a native program for any platform can go deeper into that particular platform's features and use them, and it will have a better look-and-feel with less effort, I also know that a community needs ONE codebase, since everyone must be safe that if someone leaves the project, the rest of the community will have the hardware-software necessary to continue his/her work.
Therefore, I will conform with the rest of the community. I would not like to be the stubborn one that refuses to go with the flow and create platform specific Launchers :)
So, if anyone wants my help for any cross-platform Launcher project, my C++ skills are available :)
-
Excellent Soulstorm. :)
So, people pointed me towards creating a cross-platform Launcher. Seems the need is so great for a cross-platform Launcher that I can hardly find any reason to start a new project. For the Launcher on OS X even if I had some cool ideas, like implementing some eye-candy, updating some 3rd party mods, mini-browser for the site for each mod, connection with the Freespace Wiki for explanation for the command line arguments, and stuff like that.
So we just have to make sure the cross-platform one can do all that too. :D
-
Yeah there's not much preventing that.
-
@Soulstrom: That's great.
@kkmic or @Hellzed: Has there been any progress on this?
It it now October and I now have some free time.
-
I've sent Hellzed a PM. We should wait for his answer.
Also, I'm curious what the SCP Meeting (http://www.hard-light.net/forums/index.php?topic=65891.0) will produce :) Perhaps we should wait for it to take place and conclusions to be drawn. Though his means another month kinda lost...