Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: portej05 on June 05, 2009, 03:44:06 am
-
Alrighty folks, a quick warning before we begin. Stay on topic, or your posts will get eaten.
With 3.6.10 somewhere round the corner, talk has begun on what to do with the launcher and installer post 3.6.10. A lot of the talk has been on using a cross-platform framework, and we do intend to get a cross-platform launcher going after 3.6.10.
What I'd like to see here is _CONSTRUCTIVE_ ideas for the launcher and _CONSTRUCTIVE_ ideas for the installer. You've probably got something in mind that you've wanted to see in the launcher/installer for a while.
Please explain whatever you suggest well - we're not going to try and decipher anything that doesn't make any sense.
Please also keep in mind that coding this is not going to be an overnight task.
I'll start the bidding.
I'd like to see the launcher check for (official) updates to the engine and to graphics assets.
I'd like to see some versioning of all the assets in the system, and a hash system instead of the current file size technique.
-
Hmm...Having a button to launch FRED from the Launcher would be convenient.
Give the Launcher the ability to set FRED's command line arguments (especially the -mod argument), and other options FRED has. While using shortcuts for FRED isn't that inconvenient, being able to just set the active mod in the Launcher would be greatly appreciated.
Another thought: Let the Launcher check for the presence and integrity of the retail files (or, when using a TC, whatever files it may need to work). Hopefully, this would help avert the dreaded "web cursor bitmap not found" types of errors.
-
Update checker should be optional for TC.
I'd also like to see an INI file replacing registry hack we currently have, skinning option, ability to hide/disable certain flags, that might break gameplay for TC. Maybe a more intuitive layout.
-
Switching the launcher to use .ini files on Windows needs to be done in a backwards compatible manner. It still needs the registry HKLM code for backwards compatibility, especially with stuff like TBP final and retail FS2.
This can probably be accomplished by having the FSO builds report more information back to the launcher when polled by it for things like command line options. It could also mention where it stores its config data. If it's absent it's an old build, or the only other option right now would probably be in the ini file.
-
Having the ability to edit/save optional components for things like hosting that are in the multi.cfg file. Especially the standalone stuff.
Selectable pre-saved configs. Basically set up all the stuff you want to use for a mod and save it. Then when you go back to play that mod again you can just load the config file. Also good for switching between standalones and playing.
And I'll second the FRED thing. The saved configs would be great there as well.
Maybe some way to just bypass the launcher and load a config. Like launcher -FS2_Standalone would pass the info in FS2_standalone.cfg directoly to the FS2_Open version stored in the config file.
-
A total amount completed/remaining bar for the installer, as well as a notification on how much it needs to download.
-
I'm not sure how much demand there might be for this, or if its too much of a headache to add in, but the launcher could get a bit of a coolness factor with optional skins. It could be useful with Total Conversion Mods, say to have customized launcher skin... say a B5 theme for TBP. It could either be tied into the mod.ini to select that skin as long as its selected, dropping back to default or user-choice default if no mod-designated skin is selected.
On the topic of FRED launching support, it could benefit from including a button that allows it to quickly inherit mod parameters from the currently selected FS_Open mod selection. It would also be useful if the FRED support also included similar (to FSO options) lists of command line arguments, rather than relying on the user to memorize them.
This has also been mentioned before, and the usual answer is that it is too difficult to implement. On the subject of command line arguments, there are a number of lighting-based arguments that aren't listed in the standard menus, because they require the user to input a value.. ambient_factor is an example. I'm sure many would like to see these arguments in lists, with their default values and a brief summary of their effect on lighting, listed.
-
savable launch profiles. the current launcher gives you a list of easy setup presets. what id like is the ability to save and load your own sets. for example you may want to save a set of options you use to actually play the game with. you might want other options for mods or for development of mods script and code. of course these configs should contain more than just the command line. should also store things like video settings and custom command line parameters, mods, and so on. new custom presets can be loaded and saved at the launcher level (launcherx.ini/cfg/whatever) but mods could specify additional presets from the mod.ini which would appear in the list when the mod is selected and possibly disable and override the standard defaults as well. this suits both developers and anyone who plays mods.
-
How about a custom title for the task bar. Having 2 or 3 launchers open all named FS2 Open Launcher is a bit of a pain. Maybe something like Launch FS2 which can be changed to Launch TBP or whatever total conversion you are running it for.
-
Bleh... yet again, I find myself forced to fix Nuke's lack of capitalization... And maybe some punctuation while I'm at it....
Savable launch profiles. The current launcher gives you a list of easy setup presets; what I'd like is the ability to save and load your own sets. For example, you may want to save a set of options you use to actually play the game with. You might want other options for mods or for development of mods' script and code. Of course these configs should contain more than just the command line--they should also store things like video settings, custom command line parameters, mods, and so on. New custom presets can be loaded and saved at the launcher level (launcherx.ini/cfg/whatever) but mods could specify additional presets from the mod.ini which would appear in the list when the mod is selected, and possibly disable and override the standard defaults as well. This suits both developers and anyone who plays mods.
Seconded, though. I'm not sure about all of the points, but the general notion of being able to save our own settings is a biggie. The way selecting a preset clears the current features settings is also kind of annoying.
As for skinning, it's been a while since I've seen the retail launcher... I recently installed the FS1 demo and was like "Wow... I remember this launcher... it's so simple-looking." Anyway, if 'skinning' gets done, I'd like to see (at least as a 'standard' skin) something like the original FS2 launcher, I guess. But not quite, since that didn't have enough options.
-
Have a mod match-making system so that if I join a server with a mod, the game'll search my folders for the appropriate checksums and activate the correct files. If I don't have them have the game tell me to go get them.
-
Doesn't that normally require you to restart FS2?
-
That too. Have the game only load files after server connect when using multi (Features Tickbox/Tab)
-
Sounds like a significant change. Not necessarily impossible, though.
-
:bump:
Here's an idea: Add an option to generate a fully recursive directory listing for debugging purposes. No more having to ask people for screenshots of their FS2 directory would be good.
-
Hmm...Having a button to launch FRED from the Launcher would be convenient.
Give the Launcher the ability to set FRED's command line arguments (especially the -mod argument), and other options FRED has. While using shortcuts for FRED isn't that inconvenient, being able to just set the active mod in the Launcher would be greatly appreciated.
That already kind of works, though I think it's more of a bug, anyway. Somehow when you set the mod in the current launcher, FRED seems to know that and gives you the mod in the launcher.
-
That only happens with certain builds and I don't think it's in trunk.
-
FRED has for some time used the same mod that you have FS2 set to use. I don't know how it does it, but it's been working for me for some time. I haven't run FRED from a shortcut in ages.
-
Here's an idea: Add an option to generate a fully recursive directory listing for debugging purposes. No more having to ask people for screenshots of their FS2 directory would be good.
Seconded... perhaps a 'Quick Diagnosis' button that would spit out some of the most useful information, such as build, command line parameters, etc. as well as the debug log. Could be useful for us troubleshooters.
Me, I'd like to add to the checkboxes we have now with sliders and radio buttons for those command-line options that use floats (like lighting) or are mutually exclusive (like FS2/TBP/WCS toggles.)
-
FRED has for some time used the same mod that you have FS2 set to use. I don't know how it does it, but it's been working for me for some time. I haven't run FRED from a shortcut in ages.
Only xt builds do that. The code never made it to trunk.
-
It works for me in latest nightly. (though it was a big surprise, after discovering it for first time, I spent a lot of time checking what's wrong with my shortcut :) )
-
Dragon: Release or Debug edition?
I thought the nightly freds were broken.
-
Release build works flawlessly ,Debug one CTD after I start it with my mod or no mods (standard WinXP error message ) and refuses to start with Blue Planet.
I'm attaching three logs generated after I tried to start debug.
The first one is my mod ,the second is BP (with WiH alpha files) and the third was spawn after try to run without mods.
I had no problems with revision 5342 ,those crashes occurred with 7373.
FRED using the mod selected in launcher worked in all tests.
Error signature (test with my mod):
AppName: fred2_open_3_6_11d-20090625_r5373.exe AppVer: 1.0.0.1 ModName: fred2_open_3_6_11d-20090625_r5373.exe
ModVer: 1.0.0.1 Offset: 00bbc82a
[attachment deleted by MSC
-
yeah, we know where the crash is happening.
We can't for the life of us figure out why :doubt:
-
So I hope you will find out soon ,I will rely on FSO debug build until then.
-
It works for me in latest nightly. (though it was a big surprise, after discovering it for first time, I spent a lot of time checking what's wrong with my shortcut :) )
Agreed, and I'm using an out-of-date nightly, Revision 5063.
-
I have no idea why you'd publicly admit to doing something so stupid but let's hope no one else follows you. :p
-
I have no idea why you'd publicly admit to doing something so stupid but let's hope no one else follows you. :p
Probably because I actually haven't actually used FRED for the past week or so and was too lazy to keep updating every damn night? :P
-
5063 was February. If you're going to use nightly builds, it's imperative you keep them up to date or not expect them to work correctly all the time. Not that you did that just now, just saying, in general. It doesn't hurt to know that it worked that long ago though actually.