Please post any issues, comments, or questions in this thread. All known issues can be found on the wxLauncher bug tracker (http://code.google.com/p/wxlauncher/issues/list), but a brief list is below. Please keep in mind that this is not feature complete and there are outstanding glitches (which is why we want feedback).

Important Known Issues

Launcher does not read your current command line, so you will have to re-setup your command line before you launch FSO with wxLauncher.

wxL currently does not properly handle cases where the default font/font size is unusually large. Some text may be cut off in such cases.

There was an issue with the Wings of Dawn mod image's alpha channel that causes it not to appear.

[Windows] wxLauncher does not display AA or AF controls because FSO on windows does not support the feature

[Windows] wxLauncher does not set the correct screen resolutions. This is fixed by 0.10.1, please upgrade.

[OS X] Right after you change profiles or select an FSO executable to use, the flag checkboxes on the Advanced Settings tab will not appear until you interact with the tab somehow, such as by clicking or scrolling on the list.

[OS X] The Activate and Info buttons don't always appear when you click on a mod. However, they are present and will work if you click on the space where they should be.

[OS X] On Lion, wxL's list of resolutions may include reasonable-sounding resolutions that do not appear in System Preferences >> Displays (such as 640x480), as well as unusual/odd resolutions, such as 840x524.

[OS X] With a debug build, you get a wxWidgets Debug Alert that says among other things can't set default encoding to wxFONTENCODING_DEFAULT

Downloads (https://github.com/wxLauncher/wxlauncher/releases)Windows users can download the installer from the downloads page (https://github.com/wxLauncher/wxlauncher/releases/tag/release-0.10.1) of the wxLauncher website. A debug installer can be found here (https://app.box.com/s/nsh9a4l2kh0l2foi7m9gnmh4s92at80c) if you are having trouble. Windows users can also download the source code from the downloads page.

Debian Linux users can find us as freespace2-launcher-wxlauncher on Wheezy and Jesse. Please be aware of the version that is packaged is may be different than the currently released version.

Arch Linux users can find us as wxLauncher in the AUR. Please be aware of the version that is packaged is may be different than the currently released version.

Linux users can download a the source from the downloads page (https://github.com/wxLauncher/wxlauncher/releases/tag/release-0.10.0). At this time, most Linux users must build wxLauncher from source. The ReadMe (https://github.com/wxLauncher/wxlauncher/blob/release-0.10.0/ReadMe.md) has the build instructions. The ReadMe is also included in the source archive and will be for the version that you download.

OS X users can download a .dmg disk image from the releases page (https://github.com/wxLauncher/wxlauncher/releases/tag/release-0.10.0) of the wxLauncher website. There is a debug disk image also on the releases page if you are having trouble. OS X users may also wish to build wxLauncher from source; the ReadMe (https://github.com/wxLauncher/wxlauncher/blob/release-0.10.0/ReadMe.md) has the build instructions. A source tarball is available from the releases page.

If you have Diaspora R1 Patch 4 and below (1.0.4 and below). Why haven't you updated it yet? See the release thread (http://www.hard-light.net/forums/index.php?topic=81859.0) for the patches, download this .zip file (http://www.mediafire.com/?l1i1bcb6bogzlez) of updated launcher resources and unzip it into your Diaspora folder. But really you should just update Diaspora, see the release thread

Many thanks to @onlyjob (https://github.com/onlyjob) for help with getting wxLauncher packaged on Debian Jessie and for improving our support for wxWidgets 3.0 with GCC (#117 (https://github.com/wxLauncher/wxlauncher/issues/117)) and OpenALSoft (#118 (https://github.com/wxLauncher/wxlauncher/issues/118))

Details are available here (https://github.com/wxLauncher/wxlauncher/compare/release-0.9.5...release-0.9.6)

0.9.5 fixes:

Support for wxWidgets 2.8, wxWidgets 2.8 STL, and wxWidgets 3.0

wxLauncher should deal better with OpenAL Soft

Various fixes for issues with CMake and plaform

Details are available here (https://github.com/wxLauncher/wxlauncher/compare/release-0.9.4...release-0.9.5)

0.9.4 fixes:

Extended mod.ini support, including skin system

Toggle FRED launching with F3!

Details are in the 0.9.4 post (http://www.hard-light.net/forums/index.php?topic=67950.msg1693392#msg1693392).

0.9.3 and 0.9.2 fixes

Special Limited editions for Diaspora

0.9.1 fixes:

Support for the new sound code!

Details are in the 0.9.1 post (http://www.hard-light.net/forums/index.php?topic=67950.msg1622567#msg1622567).

0.9.0 fixes:

All platforms now use the same code base

Major changes to the layout

Profile cloning

FRED launching

Lighting presets

Multiplayer on Windows works!

Details are in the 0.9.0 post (http://www.hard-light.net/forums/index.php?topic=67950.msg1612710#msg1612710).

The official commit log can be viewed here (http://code.google.com/p/wxlauncher/source/list).

Troubleshooting

For Windows and OS X users, if you run into problems getting wxLauncher to run, download and install the launcher built in debug mode ("Downloads", above). Post or PM the log (which is located in %AppData%\wxLauncher\wxlauncher.log (Windows), ~/.wxlauncher/wxlauncher.log (Linux), or ~/Library/Application Support/wxlauncher (OS X; note the space in Application Support)).

For Linux users, to build a debug version of wxLauncher, follow the build instructions as above, but when running CMake, ensure that CMAKE_BUILD_TYPE is set to Debug (cmake -DCMAKE_BUILD_TYPE=Debug).[/list]

There are several things going wrong here. Why is the feature list using a different (extremely ugly) font, and not the system default one? Why is the preset selector not rendered correctly? Why doesn't the current commandline text field show the entire current commandline, including the -mod arguments?

(http://i659.photobucket.com/albums/uu320/FabianW/bassettings.png)

The design here is very messed up, and needs to get cleaner. Controls and boxes rendered over one another are :ick:

On a more general note, the artwork, especially the big W M A B strip, is ugly. I would prefer a cleaner, slicker design like the one featured here: http://www.hard-light.net/forums/index.php?topic=65239.0

Oh, and the links on the Welcome page should probably be to the Hard-Light Wiki and the Hard-Light Forums. There are a few different FS2 forums out there, and even though HLP is the biggest, we are not the only ones :)While we're on the subject of links, please provide one to the Troubleshooting FAQ.

BUGS FOUND:

(http://s659.photobucket.com/albums/uu320/FabianW/modsettings.png)

The image retrieval code does not seem to be able to handle a nested mod folder structure. In this case, both "Blue Planet" and "Blue Planet 2" should show images, they don't.The folder structure looks like this:blueplanetsvn\---blueplanet -> For AoA---blueplanet2 -> For Wih

When using the mod.ini for one of the mod folders, the Launcher mangles the -mod argument beyond recognition:

Using extension "GL_EXT_fog_coord". Using extension "GL_ARB_multitexture". Using extension "GL_ARB_texture_env_add". Using extension "GL_ARB_texture_compression". Using extension "GL_EXT_texture_compression_s3tc". Using extension "GL_EXT_texture_filter_anisotropic". Using extension "GL_ARB_texture_env_combine". Using extension "GL_EXT_compiled_vertex_array". Using extension "GL_EXT_draw_range_elements". Using extension "GL_ARB_texture_mirrored_repeat". Using extension "GL_ARB_texture_non_power_of_two". Using extension "GL_ARB_vertex_buffer_object". Using extension "GL_ARB_pixel_buffer_object". Using extension "GL_SGIS_generate_mipmap". Using extension "GL_EXT_framebuffer_object". Using extension "GL_ARB_texture_rectangle". Using extension "GL_EXT_bgra". Using extension "GL_ARB_texture_cube_map". Using extension "GL_EXT_texture_lod_bias". Using extension "GL_ARB_point_sprite". Using extension "GL_ARB_shading_language_100". Using extension "GL_ARB_shader_objects". Using extension "GL_ARB_vertex_shader". Using extension "GL_ARB_fragment_shader". Unable to find extension "GL_ATI_shader_texture_lod". Found special extension function "wglSwapIntervalEXT".

Looking through the code package, I have a few suggestions. They might be annoying and you might not like re-doing a lot of stuff, but:

Organization. Separate the code files for each of the distinctive tabs/etc into sub-folders with a defined folder for anything global and another for any includes. Just having it all sitting in the root of /code/ can make it interesting to situate which file does what, often despite the fact that they have fairly clarifying names to them.

This way, expansion on existing features can take place with additional files with sub-folders or the primary Global folder. It will also make for situating various "project" environment files easier.

A way to group and filter the list of mods would be nice too. Like a textbox, for example, where I can type in "BL" and then the list would only show mods that contain "BL" (with different priorities: name starting > name contains > description starting > description contains).

Another idea would be a Multiplayer page which would let people see who's waiting for a game and/or is logged in. At the very least a 2.0 (if not 3.0 lol) idea but might as well dream big.

There are several things going wrong here. Why is the feature list using a different (extremely ugly) font, and not the system default one? Why is the preset selector not rendered correctly? Why doesn't the current commandline text field show the entire current commandline, including the -mod arguments?

The font is because it was reverted so that it is working, but it will have a much better presentation when finished.

Oh, and the links on the Welcome page should probably be to the Hard-Light Wiki and the Hard-Light Forums. There are a few different FS2 forums out there, and even though HLP is the biggest, we are not the only ones :)While we're on the subject of links, please provide one to the Troubleshooting FAQ.

The URL of the Troubleshooting FAQ is? I was only aware of gamewarden as being the only other active FS2 site, though at that this launcher is specific to the SCP's FS2Open.

The image retrieval code does not seem to be able to handle a nested mod folder structure. In this case, both "Blue Planet" and "Blue Planet 2" should show images, they don't.The folder structure looks like this:blueplanetsvn\---blueplanet -> For AoA---blueplanet2 -> For Wih

When using the mod.ini for one of the mod folders, the Launcher mangles the -mod argument beyond recognition:

Looking through the code package, I have a few suggestions. They might be annoying and you might not like re-doing a lot of stuff, but:

Organization. Separate the code files for each of the distinctive tabs/etc into sub-folders with a defined folder for anything global and another for any includes. Just having it all sitting in the root of /code/ can make it interesting to situate which file does what, often despite the fact that they have fairly clarifying names to them.

This way, expansion on existing features can take place with additional files with sub-folders or the primary Global folder. It will also make for situating various "project" environment files easier.

Reorgainzing the code layout has been considered, but at this time I do not see the benefit especially with the names of the files.

A way to group and filter the list of mods would be nice too. Like a textbox, for example, where I can type in "BL" and then the list would only show mods that contain "BL" (with different priorities: name starting > name contains > description starting > description contains).

I have not looked at the source but from what I see in the executable you need to use sizers, it will make your interface a lot cleaner and dynamic.

also make the play button a lot bigger and prominent.

We are using sizers (everywhere actually) , which is why some of the elements are so flattened against each other as the sizers do not have any boarders set. What specifically were you thinking was not done with sizers?

How exactly is skinning supposed to work? Create a resources directory in the game's folder?

The mod.ini and the tc's mod.ini ( a mod.ini in the root of the TC folder) are supposed to configure the launcher's skin (mostly just the icons, fonts and colours), but this support is not implemented so, currently the only way to reskin is to change the resources in the launchers resource folder and/or making changes to the defaults in SkinSystem.cpp.

The URL of the Troubleshooting FAQ is? I was only aware of gamewarden as being the only other active FS2 site, though at that this launcher is specific to the SCP's FS2Open.

I think I just lost a bit of my will to live. If even reasonable people who are actively working on the project don't know this........

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

As for other site, well, there's sectorgame and freespace.pl, for example.

Quote

I was not aware that FSO even supported paths in the -mod line.

Surprised me as well. However, for projects in development, like the mediavps or Blue Planet, this ability is essential. On that note, a conversion to the different path signifier formats (/ on *nix, \ on Win) is necessary.

Got these errors when trying to launch it:http://img31.imageshack.us/img31/1803/error2s.pnghttp://img211.imageshack.us/img211/3221/error1i.png

Seems the problem is that the Startup Folder is set to "C:\Program Files (x86)\wxLauncher" instead of "C:\Program Files (x86)\wxLauncher\bin"

Incidentally, I've noticed that FSO looked different with this launcher and it was because the previous launcher had put "-ambient_factor 35 -ogl_spec 20 -spec_exp 15 -spec_point 1.2 -spec_static 1.5 -spec_tube 1.5" automatically into the extra command line arguments. Is this an actual recommended default? Is there an recommended default?

They work fine, but since (I've found out from Zacam on IRC) these are "recommended" by the Wiki based on commentary by the folks who best set the engine defaults, I'm thinking they could be included somehow in the new launcher.

I have not looked at the source but from what I see in the executable you need to use sizers, it will make your interface a lot cleaner and dynamic.

also make the play button a lot bigger and prominent.

We are using sizers (everywhere actually) , which is why some of the elements are so flattened against each other as the sizers do not have any boarders set. What specifically were you thinking was not done with sizers?

well the layout seems static, for one thing the border isn't resizeable, for another thing the controls aren't distributed evenly. I supposed this could just be because it's an early build, but that's normally the first thing I fix with interface code, before I even make the interface functional. but I suppose that's just the way I do it.

Windows does not allow having the context help question mark and a minimize/maximize box on the title bar at one time. That being said we are going to have to do something so that there is a context help button on linux and OSX as they do not provide those as options.

I have not looked at the source but from what I see in the executable you need to use sizers, it will make your interface a lot cleaner and dynamic.

also make the play button a lot bigger and prominent.

We are using sizers (everywhere actually) , which is why some of the elements are so flattened against each other as the sizers do not have any boarders set. What specifically were you thinking was not done with sizers?

well the layout seems static, for one thing the border isn't resizeable, for another thing the controls aren't distributed evenly. I supposed this could just be because it's an early build, but that's normally the first thing I fix with interface code, before I even make the interface functional. but I suppose that's just the way I do it.

So far we have not had any reason to make the interface move controls around that is why they are "static". As for the window not being re-sizable, it is consciously that way because as with moving the controls we have not seen the point. That is, all of the controls and the layout are designed to be more or less the same size no matter the resolution.

As for the controls not being spaced correctly, that is more to do with that we have not finalized what controls and there respective sizes well be (actually we have yet to move some controls to a different tab all together). Because of this, I have not spent the time to fiddle to make the controls look decently spaced.

That being said, this is the time to get your 2 cents in about the layout of the launcher, like Karajorma, The_E and Zacam have already. So if there is some design pattern that you think would work better we would be happy to hear it.

having a resizeable frame and have all the controls inside adjust properly should be trivial to implement if your using sizers. resizeable dialogs are generally preferred in most of the HCI guidelines I recall reading, though I can't think up a specific pattern off the top of my head.

similarly with the location, sizers don't usually lend themselves to some of the odd uneven distributions, like what you see in the basic settings tab for example. I would have expected all those high level group boxes to have been even with each other, and filled the available horizontal space.

Glad you asked, to steal the explanation directly from the (incomplete) wxLauncher help manual:

Quote from: Help > wxLauncher Overview > Profiles

Profiles are one of the biggest features introduced by wxLauncher. It allows you to save various "snapshots" of the launcher settings, for ease of access. Think of them like the "save" feature in the modern games. You can save your current settings and restore them later.

Just like each user on a computer has it's own settings, files, etc., a wxLauncher profile stores the state of each game option available. That means that you can save the settings required for a particular MOD/TC in a profile, and later, when you want to play that MOD again with the same settings, you need just to select your previously saved profile, and voila!, everything is set for that MOD. You just need to hit "Play" afterward.

In my opinion, those things should be treated like mod.inis. What if a user wants to edit the recommended profile? I am not feeling comfortable with the idea of editing files in a vp. If they are not in the vp, you can edit them easily, and you don't need to bother with any override checks (as in, checking to see if there is a copy of the file outside of the vp that supercedes the one packed away).

A recommended profile isn't supposed to be edited, it's what's _recommended_ by the mod. The mod.ini serves a completely different purpose. However, if this is specific to this particular launcher I don't think keeping it with the mod is a good idea either, unless this is some sort of standard format of generic settings that could be utilized by any launcher down the road.

Set a "Profile" group in said mod.ini (or whatever) that suggests recommended settings for the mod that they can play with, or they can select their own profile.

Problems: solved.

This is our kkmic's and my preferred solution as we outlined in our proposed Mod.ini, though we call them flagsets. They are to work more or less the same way the easy flags that FSO provides do right now. They are going to appear above the easy flag sets in the same list in the launcher. [flagsetideal] will be the set that causes the "recommended" image to appear in the flag list (currently it appears for all).

See http://code.google.com/p/wxlauncher/wiki/ModIniOptions#%5Bflagsetideal%5D (http://code.google.com/p/wxlauncher/wiki/ModIniOptions#%5Bflagsetideal%5D)

Do you think it's possible to implement a "multi mode" button? I have a number of things for testing inside my data folder (because I use them with other mods) and thus have a separate folder that I rename to "data" whenever I try multiplayer in order to get it clean. Something like that would be nice.

Do you think it's possible to implement a "multi mode" button? I have a number of things for testing inside my data folder (because I use them with other mods) and thus have a separate folder that I rename to "data" whenever I try multiplayer in order to get it clean. Something like that would be nice.

Anyone with ideas about how that ought to work?

There are certainly a number of things that we can do as wxLauncher learns more about the structure of FSO data files (so it can patch them for example), so there are very few things that we would not be able to do.

That being said, what you are wanting to do would be a good use of the mod system. You put your testing data into a folder called foo, for example. Put a mod.ini file in that folder, which is just a text file (or just copy the whole thing). In the mod.ini copy the entire [multimod] section of the mod that you are using, placing the name of the mod that you want to test the updated files on (ie. the one that you just copied the mod.ini file of) at the beginning of the secondarylist (if you copied the entire file make sure that you change the modname value as well so that you can tell them apart more easily in wxLauncher).

The installer automatically picks Program Files as install location. This is not advisable on Vista/Win7 as writing to Program Files requires admin privileges. By default install location should be C:\Games\FreeSpace2 as this is default in the FS2 installation. Total Conversions on the other hand either will package this with their downloads or have clear installation instructions.

In the mod selection list, it is a bit annoying that infotext disappears when you select mod. For some reason wxLauncher does not detect OpenAL and detect is grayed out. Another issue is that the launcher seems to think Windows reports 1 joystick with 3 or 4 plugged in. Old launcher only displays one. Calibrate button doesn't work for any of the four joysticks and they're all named as "Microsoft PC joystick driver", making it a wee bit harder to find the one that is actually my joystick.

And finally, profiles still doesn't seem to work. No matter what settings I tick, once I press "Play" the launcher uses default settings. None of the settings in mods, basic settings or advanced settings are used.

Launcher doesn't seem to detect uniquely named fs2 open executables, only those that follow certain naming scheme. Didn't find a way to select differently named exes manually either.

As I couldn't get the launcher to use any settings beyond very defaults, I'll let you know more feedback once these have been sorted out.

It seems that with this launcher I can no longer use fs2_open exe directly to fire up my games. I only used the old launcher when I needed to change mod folder or change a setting, other than that I always used fs2 open exe directly. Oh well, I'll adapt I think. :p

The installer automatically picks Program Files as install location. This is not advisable on Vista/Win7 as writing to Program Files requires admin privileges. By default install location should be C:\Games\FreeSpace2 as this is default in the FS2 installation. Total Conversions on the other hand either will package this with their downloads or have clear installation instructions.

This launcher is not intended or designed to be installed directly in the FS2 (or any other TC's) folder. This launcher is designed to be completely independent of the mod of FSO installed.

Another issue is that the launcher seems to think Windows reports 1 joystick with 3 or 4 plugged in. Old launcher only displays one. Calibrate button doesn't work for any of the four joysticks and they're all named as "Microsoft PC joystick driver", making it a wee bit harder to find the one that is actually my joystick.

Hmm, do you have any other controllers installed, like a game pad? In any case, as above I would need to see a log from a debug build.

And finally, profiles still doesn't seem to work. No matter what settings I tick, once I press "Play" the launcher uses default settings. None of the settings in mods, basic settings or advanced settings are used.

Hmm, can you also include the profile files. They are in the same folder as the log and are name pro*.ini.

Launcher doesn't seem to detect uniquely named fs2 open executables, only those that follow certain naming scheme. Didn't find a way to select differently named exes manually either.

Currently it will only enumerate executables that start with fs2_open. I was not aware of exes that are FSO that do not have that naming scheme. I will talk to kkmic about adding a way to add exes separately.

At that, I am aware that an executable named fs2_open_includes.exe, for example, would be shown as just FreeSpace Open Release. I need to adjust the filename parser so that any extra text in the file name would be shown in the list.

It seems that with this launcher I can no longer use fs2_open exe directly to fire up my games. I only used the old launcher when I needed to change mod folder or change a setting, other than that I always used fs2 open exe directly. Oh well, I'll adapt I think. :p

Hmm, I will have to look into this because it is not supposed change anything in that regard.

If you're installing a program, installing to program files shouldn't be a big deal. Needing admin privs for that shouldn't be a problem. Subsequently writing data to that directory, however, is.

The only time the launcher should be have its folder written to is when it is being upgraded. Everything that this launcher writes is done to its folder in the users profile or to the TC's folder (fso_cmdline.cfg).

I wouldn't get too heavy into file name parsing, we don't exactly have a standard. Filenames have traditionally started with fs2_open though, but having a 'show all exes' option would be helpful. Does this launcher include FRED launching support by the way?

I wouldn't get too heavy into file name parsing, we don't exactly have a standard. Filenames have traditionally started with fs2_open though, but having a 'show all exes' option would be helpful. Does this launcher include FRED launching support by the way?

Not currently but it is planned, the button for it even is still in the code, but it is currently commented out.

I think the WMBAI thing is kinda corny. Would prefer something a little sharper.When a TC/Retail folder isn't set yet, just take me to Basic Settings or something, don't tell me I have to go there. Or ask me directly for the info needed (where the TC is, etc).First time setup wizard (ie point launcher to game data root folders) for getting this info would be nice.Like I said before, not a huge fan of the filename parsing. It's not going to stay consistent probably, as much as I'd like. Either just showing filenames, having an 'all' option to actually pick the exe from a popup window, or polling the exes for the version data directly when that is finished would be preferred.Do AA/AF and texture filtering settings do anything yet? Didn't think they did.Audio says: Unknown version; Download OpenAL and Detect are disabled (greyed out).Old launcher had a 'no sound' option, where did it go?Joystick device is listed twice, old launcher only lists it once.Port/IP should somehow indicate that they are optional overrides. Also Port defaults to 0 instead of empty string, seems misleading.

Activate button is not disabled for the active mod.Mod image looks horrible stretched to fit current size. Will it handle an image that doesn't need scaling at least?

Need way to go to wiki entry for a command line option from the Advanced Settings tab.

That's all the nitpicks I have so far. Might be some that are just uncompleted features, but figured I'd include everything now.

Like I said before, not a huge fan of the filename parsing. It's not going to stay consistent probably, as much as I'd like. Either just showing filenames, having an 'all' option to actually pick the exe from a popup window, or polling the exes for the version data directly when that is finished would be preferred.

We thought that all/most exes include the "fs2_open" string. A "show all executables" option would be nice, but then we rely on the user that he knows which exe he selects. Not good for non-technical users.

Activate button is not disabled for the active mod.Mod image looks horrible stretched to fit current size. Will it handle an image that doesn't need scaling at least?

Keeping the images' original size for the mod list will result in a big entry for each item from that list. We'll look into a smooth scaling method. As for the activate button, we'll keep it active as long as the old launcher is around.

Like I said before, not a huge fan of the filename parsing. It's not going to stay consistent probably, as much as I'd like. Either just showing filenames, having an 'all' option to actually pick the exe from a popup window, or polling the exes for the version data directly when that is finished would be preferred.

We thought that all/most exes include the "fs2_open" string. A "show all executables" option would be nice, but then we rely on the user that he knows which exe he selects. Not good for non-technical users.

Well, if we can get to some sort of standardized naming scheme, including everything after the fs2_open, that'd be great. We just don't have one currently so it's not telling enough info a lot of the time. Sometimes we even rename builds ourselves because the coders who released them don't give them any extra designation, those would probably not follow any scheme at all (mine still all start with fs2_open though).

Activate button is not disabled for the active mod.Mod image looks horrible stretched to fit current size. Will it handle an image that doesn't need scaling at least?

Keeping the images' original size for the mod list will result in a big entry for each item from that list. We'll look into a smooth scaling method. As for the activate button, we'll keep it active as long as the old launcher is around.

The only reason the activate button doesn't disable for the currently active mod, is because of the old launcher? That sounds silly as it doesn't make much sense there either. Not even quite sure what you're talking about actually. There's no functionality exactly like that in the old launcher.

Like I said before, not a huge fan of the filename parsing. It's not going to stay consistent probably, as much as I'd like. Either just showing filenames, having an 'all' option to actually pick the exe from a popup window, or polling the exes for the version data directly when that is finished would be preferred.

We thought that all/most exes include the "fs2_open" string. A "show all executables" option would be nice, but then we rely on the user that he knows which exe he selects. Not good for non-technical users.

Well, if we can get to some sort of standardized naming scheme, including everything after the fs2_open, that'd be great. We just don't have one currently so it's not telling enough info a lot of the time. Sometimes we even rename builds ourselves because the coders who released them don't give them any extra designation, those would probably not follow any scheme at all (mine still all start with fs2_open though).

As I mentioned above, kkmic and I are discussing our options and where we are going to put the button and/or options.

Activate button is not disabled for the active mod.Mod image looks horrible stretched to fit current size. Will it handle an image that doesn't need scaling at least?

Keeping the images' original size for the mod list will result in a big entry for each item from that list. We'll look into a smooth scaling method. As for the activate button, we'll keep it active as long as the old launcher is around.

The only reason the activate button doesn't disable for the currently active mod, is because of the old launcher? That sounds silly as it doesn't make much sense there either. Not even quite sure what you're talking about actually. There's no functionality exactly like that in the old launcher.

What kkmic is referring to is that the current launcher (or any other launcher for that matter) can change the current mod that is represented in the cmdline_fso.cfg file, but wxLauncher does not read the contents of the environment after its first run. wxLauncher gets its settings from its profiles and pushes them into the places that FSO looks for them, so actually it does not matter if the mod is changed outside of wxLauncher as it will erase any changes that are made outside of wxLauncher.

The real reason is that I forgot, though it also allows the user to reset the Advance Settings Page when it messes up without having to restart the launcher. I filed a bug report as I don't plan on fixing this right now. https://code.google.com/p/wxlauncher/issues/detail?id=43

Just to put these here so that they exist outside of IRC conversation:

Having a manifest file (probably a .txt though the extension doesn't matter to me) that contains a Version and Release Date lines. Additionally to contain some form of hashing (SHA-1 + file size was suggested. I'm okay with that or MD5, but definitely anything other than CRC especially not FSO's CRC. Don't get me wrong, it's nice, but it is outdated now and inaccurate to other CRC shemas, nevermind that it takes ages for a full file read). This file would be present at the root of each VP, so the hashing would be for the files in the VP itself. Additionally to potentially contain the -spew out put for tables/missions to assist in validation. (And if/when an installer/updater is added, the same style of manifest file can be included in the root of the archive that will give the hashing data for the VP it contains (or VP's in the case of a package like Total which has all the individual VPs in it)).

Other additional: (And probably the most work to implement) As the MediaVPs contain quite a few components that may be desirable to turn off or on as the situation warrants, have in (say, MV_Core since it will always be on) a list file that will allow for optionals (like MV_Advanced, MV_AnimatedMaps or any other additional optional component) to be selectable as on or off when the MediaVPs are chosen as a mod. This can also be expanded to other mods or TC's that may have "Option Plus" content.

However, the debug launcher works better than standard one for some odd reason. Except that cloning settings from one profile to another doesn't work. But at least debug saves settings, which standard didn't.

However, the debug launcher works better than standard one for some odd reason. Except that cloning settings from one profile to another doesn't work. But at least debug saves settings, which standard didn't.

For the record, Fury and I have done some further troubleshooting on IRC and most of his problems that he was having with the launcher disappeared with after installing and running the debug wxLauncher once.

Also, wxLauncher 0.7.4 Alpha has now been released. You can get it from the usual place (http://code.google.com/p/wxlauncher/downloads/list) or see the first post (http://www.hard-light.net/forums/index.php?topic=67950.0), which also contains the change log highlights.

1) Download this zip: http://www.box.net/shared/bmuicdkxba2) Unzip the contents into the bin directory of your wxLauncher install (overwrite the wxlauncher.exe and registry_helper.exe).3) Find global.ini in %AppData%/wxlauncher. Open this file in a text editor and add to the end of the .ini:

You will now see a button to the left of the Play button labelled "Fred" which is, as you can probably guess, launch FRED using the currently configured mod options. You can select the FRED binary on the Basic Settings page.

Well, it took 13 months, but we finally have a Mac OS X version of wxLauncher. Many thanks to jg18 and his tireless work over the last 2 months on getting wxLauncher working on OS X. Download information is in the OP.

Special thanks to our pre-alpha testers (Androgeos Exeunt, chief1983, Echelon9, and swashmebuckle) and others who gave suggestions and feedback (The E, Valathil, and Zacam).

Hi guys,It sucks to admit that I'm a noob :D , but I really am.. I downloaded FS2 from GOG, what's next to get the updates for the game? Can anyone show me how to apply the new material or at least show me a noob friendly thread?Much thanx..

(1) I highly recommend building from trunk rather than the 0.8.0 source tarball. Instructions for checking out a copy of the source are in the readme (http://code.google.com/p/wxlauncher/source/browse/ReadMe.txt).

(2) Are you sure that you have the markdown module for Python (called Markdown in Python (http://freewisdom.org/projects/python-markdown)) installed? One way to check is to start up the python interpreter at the command line (that is, type python at the shell prompt) and then type

So let's say a certain soon-to-release total conversion wanted to use this, have the launcher pre-configured with a set of command-line flags and settings so that it's immediately ready to go, and not mention FS2 at all. Listing TC-specific mods would be a definite bonus.

How much of this is possible right now without changing the source? What would I need to do this?

What are the barriers preventing me from using wxlauncher as part of a TC release?

So let's say a certain soon-to-release total conversion wanted to use this, have the launcher pre-configured with a set of command-line flags and settings so that it's immediately ready to go, and not mention FS2 at all. Listing TC-specific mods would be a definite bonus.

How much of this is possible right now without changing the source? What would I need to do this?

Removing mention of FS2 will require (some) modification of the source code (change some strings basically).

Having the launcher pre-configured with a set of command-line flags and settings would be doable with some modification to the installer (that is, change some of the profile information that the launcher has by default, though at this time, it would have to be specific to the user that installed it. To allow these defaults to affect all users on a system some modification to the source code would be required (to change the default profile and have the launcher look somewhere else by default for the TC [it currently defaults to nothing]).

I am not really sure what you mean by "Listing TC-specific mods", but I think it does that already without modification.

I seem stuck with 16-bit color depth, no matter what I set the "color depth" option to.

Assuming you are using the version that is this thread, because there have been so many bug fixes to the trunk version I would suggest that you try compiling it first. If you can't compile wxLauncher I can build one tonight.

If it is a trunk version that you are using, I would need a debug log from wxLauncher and the platform you are trying this on. See the instructions in the OP for where to find it.

wxLauncher 0.9.0 alpha has been released. You can download it from the release post (http://www.hard-light.net/forums/index.php?topic=67950.msg1341695#msg1341695).

Summary of changes since 0.8.0 affecting all platforms:

New look! * Replaced big blue icons along the left side with plain tabs along the top * Removed components that don't (yet) work or were otherwise unnecessary * Removed components from platforms that currently don't support them * Reformatted whatever components were left * Added spacing and padding around and between components * Components that were previously cut off the edge of the launcher window are no longer cut off * Launcher is now minimizable * Removed status bar fields that are currently unused

Profile changes: * Profile cloning is now supported * On a profile switch, the newly loaded profile's settings and flags are loaded correctly * On profile switch, on profile creation, and on launcher exit, if the current profile has unsaved changes and the "Automatically save profiles" box is unchecked, you'll be asked whether you want to save the changes * Global profile (which includes things like last profile used, whether profile autosaving is on, most recently retrieved HLP highlights) is now always saved on launcher exit * Default values in the launcher are automatically written to new, uninitialized profiles * New profiles are automatically saved to disk right after they are initialized

Welcome page changes: * "Automatically save profiles" checkbox now works correctly. If the checkbox is checked, then profiles are automatically saved before a profile switch and on launcher exit, as well as right after you check the checkbox.

Basic Settings page changes: * After OpenAL is detected, default sound device is the first device on the list * Default video settings are now maximum supported screen resolution and 32-bit color depth * List of screen resolutions is now sorted by aspect ratio, then by size, both in descending order, with a header for each aspect ratio category * "Force local port:" box no longer displays 0 if no value is entered * Refresh buttons for the list of FSO executables (and on Windows, for the list of FRED executables as well) * If there is no valid root folder and FSO executable selected, the settings other than root folder/executable selection disappear * Various improvements and corrections to FSO filename parsing * Better descriptions for "Connection type" and "Connection speed" options (special thanks to KyadCK for help with coming up with them)

Advanced Settings page changes: * Lighting presets box added * Double-clicking on a flag brings up its online documentation, if available * Text in "Current command line" box now wraps properly * If the flag list box has an error (invalid root folder, etc.), the other components on the page disappear, and the error text is centered in the flag list box

Other changes: * Fix for launcher window expanding if the launcher is started with a profile that doesn't have a valid FS2/TC root folder selected. * Some revisions to help system content, although it needs a lot more work * Numerous formatting adjustments and text revisions * Assorted bug fixes * ReadMe.txt updated with improved build instructions for all platforms

Changes affecting Windows only:- Icon added- FRED launching!

To enable it, open the file global.ini in the directory %AppData%\wxlauncher in a text editor and then add the following text to the end of the file:

Be sure to make this change while wxLauncher is not running.(well, GUI support for FRED launching is available on all platforms, but FRED is currently only available on Windows)- Improved presentation of the flag list (special thanks to The E for formatting advice)- Multiplayer now works! (special thanks to KyadCK for help with testing)- Checkboxes for speech settings now work correctly- Text-to-speech is now turned off by default

We want to replace the old Launcher as the default option because a) it only works on one platform, b) it's not that friendly for developers, c) it is built for expert FSO users, d) it is not really extendable.

wxLauncher, on the other hand, is much easier for newcomers to learn, and can be easily extended to interface with the next installer version, and is cross-platform of course.

This is great. How far would you say are we from recommending this as the official Launcher over 5.5g?

Thanks. Glad you like the new version. :)

As for your question, Iss Mneur and I have been discussing it, and we're not entirely sure.

There are several things that we feel are must-haves before we would consider it suitable for wide release: (1) support for the new sound code (currently in progress), (2) automatic self-update (Windows and OS X, plus maybe one or two Linux distros) or automatic update notification (all other Linux distros), possibly (3) a portable version on Windows, and of course (4) more testing.

As someone who spends a lot of time on FSO support, what features would you like to see included before you think it could replace 5.5g?

1. This app can't works. If I click to "play" I get error messages: "Unable to write FSO2 settings to registry (0x2)EDIT: See log, created with debug version.If run this app with admin rights, this app is working, "play" is executed.

3. If I click to play, game is started, but language settings in registry is lost. This is mean: If I set language to German is registry, with wxLauncher game language is english. With launcher 5.5g, language is equal with registry settings.

3. If I click to play, game is started, but language settings in registry is lost. This is mean: If I set language to German is registry, with wxLauncher game language is english. With launcher 5.5g, language is equal with registry settings.

Thanks.

Win7 x64 FSO2 3.6.12, wxLauncher version is 0.9.0

Please install the debug version of wxLauncher as linked in the post at the top of this thread. And reproduce the problems indicated and attach the wxlauncher.log as described in the original post.

I am able to reproduce the calibrate button not working. I will look into why it doesn't work. Has been assigned issue 81 (https://code.google.com/p/wxlauncher/issues/detail?id=81).

We should not be setting language whatsoever. The log will probably help here though. I have assigned issue 82 (https://code.google.com/p/wxlauncher/issues/detail?id=82) to this problem.

(...)We should not be setting language whatsoever. The log will probably help here though. I have assigned issue 82 (https://code.google.com/p/wxlauncher/issues/detail?id=82) to this problem.

Hi!

This report is wrong, bcause launcher 5.5g can't set language.I wrote this:I set FS2 language (in registry).I see this (languages settings) in launcher 5.5g registry tab.If I click run in launcher 5.5g, game is run with language in registry.But with wxLauncher, this registry settings is lost.

Well, I think wxLauncher uses wrong registry path of this game, and first and third problem is equal.Correct registry path on my system (Win7 x64) is: [HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Volition\Freespace2]

How FSO interacts with the registry has many flaws and manifests various issues, however, considering that wxLauncher is reported to work for many testers (though I don't think any of them use a non-English install of Freespace 2), I don't see how wxLauncher can be getting the registry path incorrect, however, please get me the wxLauncher.log from a debug install of wxLauncher so that I can see what the problem is and then I can actually help you.

How FSO interacts with the registry has many flaws and manifests various issues, however, considering that wxLauncher is reported to work for many testers (though I don't think any of them use a non-English install of Freespace 2), I don't see how wxLauncher can be getting the registry path incorrect, however, please get me the wxLauncher.log from a debug install of wxLauncher so that I can see what the problem is and then I can actually help you.

Hi

See log file in my first post.My FS2 install is english, but my OS is not english.

Why I think this app uses wrong registry path? Simple.

Without admin rights, this app is crashed, with admin rights, not.Vista and Win7 limit the registry uses for applications. See my previous post, and registry key :"VirtualStore"VirtualStore mean, OS is denided to registry use of applications, and place to under VirtualStore key.If this app is crashed, then this app can't handle this situation (OS is denided access to required registry key).With admin rights, I see, wxLauncher created registry path this: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Volition\Freespace2]This is different from original registry path, therefore can't use original language registry key (third problem).

Huh? So then what is the problem? If your FS2 install is English then it doesn't matter what language is set in the registry for FSO (at least as far as I know, being an English speaker, running an English FS2, on an English Windows 7 x64, but being a wxLauncher dev and a SCP dev, I am fairly familiar with the code that FSO has to deal with languages)?

Without admin rights, this app is crashed, with admin rights, not.Vista and Win7 limit the registry uses for applications. See my previous post, and registry key :"VirtualStore"VirtualStore mean, OS is denided to registry use of applications, and place to under VirtualStore key.If this app is crashed, then this app can't handle this situation (OS is denided access to required registry key).With admin rights, I see, wxLauncher created registry path this: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Volition\Freespace2]This is different from original registry path, therefore can't use original language registry key (third problem).

Indeed. I know this all too well. That is why I am confused, wxLauncher goes to extensive lengths to get this just right becuase of how messed up FS2/FSO and the windows registry virtualization and 32-bit registry virtualization is. wxLauncher includes a registry_helper.exe whose job it is to make all of the magic happen, so I suppose the real question is, why do you have to run wxLauncher as admin, when everyone else is able to run wxLauncher as a normal user. registry_helper cannot do its job if wxLauncher has been run as admin.

The log that you attached to the post above does not show the registry helper being invoked, which means either you didn't try to start FSO during that run or you ran wxLauncher as admin. The log also does not show wxLauncher's shutdown, so please rerun the debug wxLauncher as a regular user, run FSO, and then after it fails exit wxLauncher so that the log gets flushed.

Huh? So then what is the problem? If your FS2 install is English then it doesn't matter what language is set in the registry for FSO (at least as far as I know, being an English speaker, running an English FS2, on an English Windows 7 x64, but being a wxLauncher dev and a SCP dev, I am fairly familiar with the code that FSO has to deal with languages)?

I have translation (mod).... new version needs change language registry key from default.

(...)The log that you attached to the post above does not show the registry helper being invoked, which means either you didn't try to start FSO during that run or you ran wxLauncher as admin. The log also does not show wxLauncher's shutdown, so please rerun the debug wxLauncher as a regular user, run FSO, and then after it fails exit wxLauncher so that the log gets flushed.

Previous log show: wxLauncher run with normal user (not admin), click to play, this app show error window, ask: "do you want stop the program?" I click to yes. After wxLauncher is freeze.

Now this attached log show: wxLauncher run with normal user (not admin), click to play, this app show error window, ask: "do you want stop the program?" I click to No. I get "unable to write registry" messages. After I close this app.

Previous log show: wxLauncher run with normal user (not admin), click to play, this app show error window, ask: "do you want stop the program?" I click to yes. After wxLauncher is freeze.

Now this attached log show: wxLauncher run with normal user (not admin), click to play, this app show error window, ask: "do you want stop the program?" I click to No. I get "unable to write registry" messages. After I close this app.

Okay.

Can you please take screenshots of these dialog that pop up?

I have reviewed the log and it is telling me that the access denied error comes from being unable to create a temporary directory, which wxLauncher uses to communicate with the registry_helper. Because this file cannot be created, it then fails to open the non-existent file for writing, obviously this doesn't work so well.

Please generate a wxLauncher.log the same as you did this time, with this new build (https://www.box.com/s/8c81e86cbd08420e7f74) so we can try and figure out how we are failing to create a temporary directory.

Also, please post or attach the output of the set command when you run it in a command prompt.

I have reviewed the log and it is telling me that the access denied error comes from being unable to create a temporary directory, which wxLauncher uses to communicate with the registry_helper. Because this file cannot be created, it then fails to open the non-existent file for writing, obviously this doesn't work so well.

Please generate a wxLauncher.log the same as you did this time, with this new build (https://www.box.com/s/8c81e86cbd08420e7f74) so we can try and figure out how we are failing to create a temporary directory.

Also, please post or attach the output of the set command when you run it in a command prompt.

I see C:\TMP driectory rights, and I see, I have full access to this directory.

Okay. So after some more research.

1) Try running wxLauncher as a normal user with you antivirus disabled. What antivirus software are you running?2) Microsfot KB 892613 (http://support.microsoft.com/kb/982613) sounds like it may apply to this situation, please try the hotfix in the KB if you feel safe to do so.

I see C:\TMP driectory rights, and I see, I have full access to this directory.

Okay. So after some more research.

1) Try running wxLauncher as a normal user with you antivirus disabled. What antivirus software are you running?2) Microsfot KB 892613 (http://support.microsoft.com/kb/982613) sounds like it may apply to this situation, please try the hotfix in the KB if you feel safe to do so.

Hi!

My system is working correctly. Problem with only this application. Why do you think this is problem with my computer and not with wxLauncher? All other applications working correctly.I try turn off already my antiviurs and other defense software, but nothing change. Antivir Avira & Comodo firewall my defense systems.

I see this hotfix, but this is old date,Kernelbase.dll patch version is: 6.1.7600.20693Kernelbase.dll on my system: 6.1.7601.17651, 6.1.7601.21772 etc... this is newer than patch date.

But if I run this patch, patcher is say (translated): This patch is invalid for this computer. I try x86, x64 patch too (not ia64). This is old patch, and outdated I think, and I see.

My system is working correctly. Problem with only this application. Why do you think this is problem with my computer and not with wxLauncher? All other applications working correctly.I try turn off already my antiviurs and other defense software, but nothing change. Antivir Avira & Comodo firewall my defense systems.

I see this hotfix, but this is old date,Kernelbase.dll patch version is: 6.1.7600.20693Kernelbase.dll on my system: 6.1.7601.17651, 6.1.7601.21772 etc... this is newer than patch date.

But if I run this patch, patcher is say (translated): This patch is invalid for this computer. I try x86, x64 patch too (not ia64). This is old patch, and outdated I think, and I see.

Hello

I think the problem may be with your system because you are the first (or at least the first to report this problem) of almost 10,000 downloads of wxLauncher for Windows. More specifically I think it might by a problem with your system because the code that is failing, I did not write, it comes from the wxWidgets (http://www.wxwidgets.org/) project which has been in existence for over 10 years. Of course, that doesn't mean wxWidgets doesn't have a problem as well, but it is unlikely. In addition the specific function that is failing with the access denied error, is GetTempFileName (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%28v=vs.85%29.aspx) which is a windows system call; this is why I suggested the hotfix.

I had noticed that the hotfix was older, but it didn't call out what service pack it was for so I figured may as well try it. However the hotfix is the first result in google for "GetTempFileName Access Denied", which is the problem that you are having. This made the hotfix seem like a good idea to try, especially after reading the description it could very well have been the cause of the problem.

Either way, please don't take offence to the solutions that I am proposing. Its not personal, am not attacking you, its just tech support. That is, I am trying out ideas in the hope that something works because as noted above most people do not have this problem. Yes, I am just guessing at this point. Sometimes it happens in tech support. If you have further ideas, they are more than welcome, however keep in mind what I noted above, most people have not had a problem with this, so either your system is causing wxLauncher (and/or wxWidgets, and/or GetTempFileName) to hit an edge case. The question right now is, which one is it.

I have reviewed what you have written previously and I have some more questions (read, shots in the dark):1) Why does TMP need to be a short path?2) What is the output of:

cacls %TMP%cacls %TEMP%cacls %LOCALAPPDATA%\Temp3) Try running wxLauncher after defining TMPDIR to be C:\Users\totya\AppData\Local\Temp4) I have googled both of you Anti Virus products (why 2?) and they don't appear to have a specific reputation for interfering with temporary file creation (not really a surprise, but some Anti Virus can be really bad about interfering with a system).5) The fix for the joystick calibration issue is in trunk and will be in the next release of wxLauncher. Thank you for pointing it out.

I'm am sorry wxLauncher currently isn't working for you and I appreciate your being willing to try ideas out to figure out what the problem is.

...I had noticed that the hotfix was older, but it didn't call out what service pack it was for so I figured may as well try it. However the hotfix is the first result in google for "GetTempFileName Access Denied", which is the problem that you are having. This made the hotfix seem like a good idea to try, especially after reading the description it could very well have been the cause of the problem.

cacls %TMP%cacls %TEMP%cacls %LOCALAPPDATA%\Temp3) Try running wxLauncher after defining TMPDIR to be C:\Users\totya\AppData\Local\Temp4) I have googled both of you Anti Virus products (why 2?) and they don't appear to have a specific reputation for interfering with temporary file creation (not really a surprise, but some Anti Virus can be really bad about interfering with a system).5) The fix for the joystick calibration issue is in trunk and will be in the next release of wxLauncher. Thank you for pointing it out.

Answer for your questions:

1. Different temp path is very popular, see google. Short path is need, if I don't want use cleaner applications. Delete temp files is recommended, example before install application, and I see easy this directory, contain, size...

1. Different temp path is very popular, see google. Short path is need, if I don't want use cleaner applications. Delete temp files is recommended, example before install application, and I see easy this directory, contain, size...

However, given that there's an easy tool for just this purpose that comes with Windows, this, to me, seems like one of those cargo-cult type things people keep doing because they've been doing them for a long time (like messing with Windows' pagefile settings for no reason).

For me don't need this app, I try is, because I want look it, and I want help for developer, because I'm a good tester.

Okay. Thank you. And thanks to your perseverance, I have now been able to reproduce your issue and because I could run the debugger on the code, I was able to quickly come up with a fix.

The problem wasn't that wxLauncher couldn't handle paths that were different than default, but it couldn't handle paths that did not have their immediate parent directory writable by wxLauncher. So in the case of C:\TMP, we were actually trying to use C:\ as the directory and TMP as the prefix of the temp filename. And now because, a normal user cannot write to C:\ (or at least CreateTempFileName refuses to create a temp file in C:\) resulting the Access Denied.

Please try this new build (https://www.box.com/s/67f1db2bdeb19a95ff5b). It contains both the fix for the temp dir issue and for calibrate not working. Please test and see if it is actually fixed.

The problem wasn't that wxLauncher couldn't handle paths that were different than default, but it couldn't handle paths that did not have their immediate parent directory writable by wxLauncher. So in the case of C:\TMP, we were actually trying to use C:\ as the directory...

Hi!

Okay, this is clean now, this is wxLauncher code error, because this app not uses Temp directory, this app uses parent of Temp directory.

New build is working correctly, and joystick calibrate window dialog is opened now. Thanks, good job.

If I try quick compare launcher 5.5g and wxLauncher, I look these differents, these missings from wxLauncher:

I removed "all features on" because it didn't make sense to me -- what would it mean for all features to be on? I was concerned that that option would confuse people. The "flag sets" box needs some more work, since it should change after you apply a flag set and then change the flag list yourself.

- video/aniso/AA settings (In game I don't see AA working with this settings)

The anisotropic filtering and AA settings for FSO currently don't work in Windows. They do, however, work in Linux and OS X, so those settings appear in wxL on those platforms. Once they're working on Windows, the settings will be added to the Windows version of wxL.

Adjusting the general settings in 5.5g didn't seem to have an effect the last time I tried, but as I remember, they change the in-game detail settings and correspond to the detail presets available in the in-game options. The "highest" option is deceptive in that it doesn't really max out all detail settings, which is the main reason I decided to leave the general settings out.

"Use large textures" and "Fix font distortion problem" are from when FSO used Direct3D. Now that FSO only uses OpenGL, those options aren't needed.

It would take significant work to make something like this on all platforms in wxL, and my opinion is that this functionality is really for advanced users. If people need to check the registry (or fs2_open.ini on OS X/Linux), they can use regedit on Windows (or a text editor on OS X/Linux). Also note that wxL doesn't make any changes to your registry until you press the Play button.

Just compiled and started wxLauncher on Lubuntu. The readme is well-written, allowing a linux noob like me to build an actual program :yes:

Encountered an issue with the program itself though. In the Basic Settings tab, FS2 or TC root folder selector: the pop-up window won't allow me to choose a directory, I only get ' cancel' and 'open' buttons.Then a couple cosmetic things:- w/o root folder selected, the Mods and Advanced Settings tabs both tell me that I should select a root folder; however they do so in different ways. The Mods tab has a nice panel with an info icon and message (word wrap is a little screwed up here), the Advanced Settings tab has a fairly cheapo-looking black-on-white message (also with bad word wrap).- The 'Check out these links' window is sized a little poorly, see screenshot.

It would take significant work to make something like this on all platforms in wxL, and my opinion is that this functionality is really for advanced users. If people need to check the registry (or fs2_open.ini on OS X/Linux), they can use regedit on Windows (or a text editor on OS X/Linux). Also note that wxL doesn't make any changes to your registry until you press the Play button.

Truthfully, consolidating it would make a lot of sense. And is something that I have thought about implementing (though is a more generic way, probably using wxLauncher's internal representation of the data that is stored in the registry). This would probably implemented as part of the "I have a technical problem that I cannot solve" button or as a special support ninja menu (maybe accessible only via a keyboard combo) that has various debugging tools that the ninja's can ask people to use. It definitely does not need to be visible by default though.

Seems silly to implement a registry tab if we're going to go over to using .ini files eventually anyway.

True, but wxLauncher still builds a representation of the settings internally that we could make available, and once reading the existing settings works (which would require implementation for every system anyway) we would always have that feature covered.

Encountered an issue with the program itself though. In the Basic Settings tab, FS2 or TC root folder selector: the pop-up window won't allow me to choose a directory, I only get ' cancel' and 'open' buttons.

You should only get a cancel and an open button. You don't get a file tree to pick from? Can you please screenshot this?

Then a couple cosmetic things:- w/o root folder selected, the Mods and Advanced Settings tabs both tell me that I should select a root folder; however they do so in different ways. The Mods tab has a nice panel with an info icon and message (word wrap is a little screwed up here), the Advanced Settings tab has a fairly cheapo-looking black-on-white message (also with bad word wrap).

Thanks. That is something we had forgotten about in the 'excitement' of the issues we have had with that tab. We will definitely make sure that it gets the same treatment that the Mods tab gets.

You should only get a cancel and an open button. You don't get a file tree to pick from? Can you please screenshot this?

It's the regular file selection window, just with all files greyed out and only directories selectable. But I can't find a way to actually return a folder: the "Open" button will just go into the directory and display its contents, instead of returning to the launcher.

Quote

Is that the default font size for your system? It seems to be absurdly large. The wxLauncher window is the same height (in pixels) as what I have here but the font is much larger all around. Hmm....

It appears to be the default font size, yeah. Now that you mention it, it is kinda large compared to my Windows boot. It's a fresh install of Lubuntu 12.04 though, can't remember to have fiddled with the font sizes.

"all features on" this is mean for me: all-features-on. :) All new features turned on, example all graphics enhanced options, all 3D HUD options, all gameplay options etc. It's not really important, but short way.

Then a couple cosmetic things:- w/o root folder selected, the Mods and Advanced Settings tabs both tell me that I should select a root folder; however they do so in different ways. The Mods tab has a nice panel with an info icon and message (word wrap is a little screwed up here), the Advanced Settings tab has a fairly cheapo-looking black-on-white message (also with bad word wrap).

Thanks. That is something we had forgotten about in the 'excitement' of the issues we have had with that tab. We will definitely make sure that it gets the same treatment that the Mods tab gets.

Yeah, we'll work on coming up with something better, although a start might be wrapping the text to suit whatever font size is in use. Currently, the newlines are hardcoded into the messages.

You should only get a cancel and an open button. You don't get a file tree to pick from? Can you please screenshot this?

It's the regular file selection window, just with all files greyed out and only directories selectable. But I can't find a way to actually return a folder: the "Open" button will just go into the directory and display its contents, instead of returning to the launcher.

Hmm, interesting. Iss or I should probably get Lubuntu and see if we can reproduce this.

Is that the default font size for your system? It seems to be absurdly large. The wxLauncher window is the same height (in pixels) as what I have here but the font is much larger all around. Hmm....

It appears to be the default font size, yeah. Now that you mention it, it is kinda large compared to my Windows boot. It's a fresh install of Lubuntu 12.04 though, can't remember to have fiddled with the font sizes.

What's the default font size for your system? In GNOME, you can check it from the menu using System >> Preferences >> Appearance and then selecting the Fonts tab, but I don't know offhand how to check it in LXDE, which is what Lubuntu uses. I'm using Ubuntu Lucid (10.04) and the default font size is 10, and all of the text fits fine. We'll see what we can do to make that text area scrollable and/or perhaps enforce a specific font size in that text area.

"all features on" this is mean for me: all-features-on. :) All new features turned on, example all graphics enhanced options, all 3D HUD options, all gameplay options etc. It's not really important, but short way.

Hm, ok, but your definition of "all features on" doesn't seem to fit the FSO team's definition (see here (https://svn.icculus.org/fs2open/branches/fs2_open_3_6_14/code/cmdline/cmdline.cpp?view=markup), starting at the line

This setting used to be in the wiki until Zacam changed it (http://www.hard-light.net/wiki/index.php?title=Sample_Lighting_Settings&diff=35477&oldid=30682) last July, which led me to believe that that setting was no longer the FSU team's recommended setting, which is why it's not in the launcher.

Hmm, interesting. Iss or I should probably get Lubuntu and see if we can reproduce this.

Perhaps niffiwan might be able to help, he seems (http://www.hard-light.net/forums/index.php?topic=80711.msg1604610#msg1604610) to be running Lubuntu as well.

Quote

What's the default font size for your system? In GNOME, you can check it from the menu using System >> Preferences >> Appearance and then selecting the Fonts tab, but I don't know offhand how to check it in LXDE, which is what Lubuntu uses. I'm using Ubuntu Lucid (10.04) and the default font size is 10, and all of the text fits fine. We'll see what we can do to make that text area scrollable and/or perhaps enforce a specific font size in that text area.

I'm happy to help - "technically" I'm not running Lubuntu, rather Ubuntu 12.04 with Unity & XFCE installed - I *think* I can just install the relevant LXDE stuff (I think lubuntu-desktop is the package) and just login with a different session to get Lubuntu.

Anyway - it's probably best to start with a screenshot as requested by Iss Mneur :)

Ehm, this is kind of embarassing. The folder selection works now :nervous:

However! Since I had troubles executing FSO from a mounted partition, I copied the FSO directory to my /home/user. But now I cannot change the location of the root folder in wxLauncher. The Browse button is gone, and I can't type in the box either.

If you could paste the contents of the profile you're using in code tags, that would also help. The profiles are located in /home/<YourUsername>/.wxlauncher/ and are of the form pro#####.ini. The default profile is stored in pro00000.ini. If you're using a profile other than the default one, you'll need to search through the folder and look at the files in a text editor to find the one you're using.

Thanks!

EDIT: Also, did you use make install to install wxL to /usr/local/, or did you use development mode to avoid having to do that? If the latter, then I'm not sure that you can just copy and paste the folder and have it work, since the paths might be baked in. You might need to rebuild wxL in that case.

This setting used to be in the wiki until Zacam changed it (http://www.hard-light.net/wiki/index.php?title=Sample_Lighting_Settings&diff=35477&oldid=30682) last July, which led me to believe that that setting was no longer the FSU team's recommended setting, which is why it's not in the launcher.

Hi!

Official MediaVP thread install instruction show "old" preset. If user can't see this mediawiki (I dont see this never before you show), then user type "old" preset, if want use MediaVP.This is clean logic. If you know this information: recommended preset is "old" in MediaVP thread, then show this; example:

Now visible preset name in wxLauncher:

"Baseline recommended" - this is wrong name.

"Baseline recommended (with MediaVP too, 7 July 2011)" - this is correct name. Please do not hide any important information from wxLauncher users :)

This setting used to be in the wiki until Zacam changed it (http://www.hard-light.net/wiki/index.php?title=Sample_Lighting_Settings&diff=35477&oldid=30682) last July, which led me to believe that that setting was no longer the FSU team's recommended setting, which is why it's not in the launcher.

Hi!

Official MediaVP thread install instruction show "old" preset. If user can't see this mediawiki (I dont see this never before you show), then user type "old" preset, if want use MediaVP.This is clean logic. If you know this information: recommended preset is "old" in MediaVP thread, then show this; example:

Now visible preset name in wxLauncher:

"Baseline recommended" - this is wrong name.

"Baseline recommended (with MediaVP too, 7 July 2011)" - this is correct name. Please do not hide any important information from wxLauncher users :)

I went digging through my IRC logs and couldn't find the conversation I was looking for, but as I remember, Zacam once told me that the lighting settings you quoted are now deprecated and that the settings now listed in the wiki as recommended are the official recommended settings. If the MediaVPs 3.6.12 release thread still lists the old settings, then the issue is with the thread and not with wxLauncher. Hope that explains things.

If the MediaVPs 3.6.12 release thread still lists the old settings, then the issue is with the thread and not with wxLauncher. Hope that explains things.

This is clean for me, but I think will not come to the end of the world, if you show your application, baseline settings is recommended MedaiVP settings too. Do you understand this? :)

I'm sorry, but I don't understand what you mean by "if you show your application, baseline settings is recommended MedaiVP settings too." Are you saying that the "Baseline recommended" settings should be taken from the MediaVPs 3.6.12 release thread and not from the wiki, even though the wiki is (more or less) the official location for standard lighting settings? If so, then Iss Mneur and I will need to talk about it, and thanks for the suggestion.

Also, did you use make install to install wxL to /usr/local/, or did you use development mode to avoid having to do that? If the latter, then I'm not sure that you can just copy and paste the folder and have it work, since the paths might be baked in. You might need to rebuild wxL in that case.

I didn't use the dev mode flag to compile, but did do a make install (those go together? didn't see it mentioned anywhere in the readme). I'm now running wxlauncher from terminal.

Anyhow, it appears that the MSVC .map and .pdb files in my Windows FSO folder are fooling the launcher, see screenshot 1. It's skipping the .exes alright, but not the debugging files. Hence, that directory is recognized as a valid FSO root folder, even though there's no valid linux binary in there anymore. And thus I'm not allowed to change the location, see screen 2.

Quote

If you could paste the contents of the profile you're using in code tags, that would also help. The profiles are located in /home/<YourUsername>/.wxlauncher/ and are of the form pro#####.ini. The default profile is stored in pro00000.ini. If you're using a profile other than the default one, you'll need to search through the folder and look at the files in a text editor to find the one you're using.

Anyway, if I unmount the partition with the Windows FSO folder, it cannot find the root directory anymore (as it should), and I am allowed to change it (get the Browse button back).

Nice work on the mods list! :yes:

The Advanced Settings tab I'm thinking could use some work, from a user perspective... (screen 3) YMMV, of course, this is just my first impression. The layout doesn't reflect the relation between different elements very well IMHO. The Lighting Presets and Custom Flags box belong together, as do the Flag Sets selector and the list of checkboxes. The 'Copy selected preset to custom flags' button is also not a great way to do it IMHO, if you're a first-time user who doesn't really know what it does.

How I would do it - Instead of the 'Lighting Presets' pane (on the right) put a 'Setting presets' box, with radio buttons ordered by computing power, e.g. 'Default FS2' (all features off), 'Basic features on' (for older computers, with glowmaps and other basic things only), 'Recommended' (for most computers, only some high-performance features off) , 'Full option' (for real good computers, with full-on visuals), 'Custom' (gets auto-selected if the user changes a setting himself). Then have a selection list for the custom lighting settings, positioned directly above the Custom Flags list (where the Flag Sets selector list is now).

Anyway, take it or leave it, I know it's quite an overhaul of the tab I'm suggesting.

One more thing, the 'Default FS2' preset should probably turn things like glowmaps and normals off, right? I'm guessing it's meant for those who wanna play vanilla?

I didn't use the dev mode flag to compile, but did do a make install (those go together? didn't see it mentioned anywhere in the readme). I'm now running wxlauncher from terminal.

Development mode is for when you don't want to use make install and instead want to run wxL within the development directory. As mentioned in the ReadMe, you enable it by including -DDEVELOPMENT_MODE=1 when you run CMake. Otherwise, you use make install. And yeah, I run wxL from the terminal, too.

Anyhow, it appears that the MSVC .map and .pdb files in my Windows FSO folder are fooling the launcher, see screenshot 1. It's skipping the .exes alright, but not the debugging files. Hence, that directory is recognized as a valid FSO root folder, even though there's no valid linux binary in there anymore. And thus I'm not allowed to change the location, see screen 2.

Fixed in revision 98a09dcace9d (http://code.google.com/p/wxlauncher/source/detail?r=98a09dcace9d595f6cde68a78c061fe98680056d). Thanks for reporting this issue.

The Advanced Settings tab I'm thinking could use some work, from a user perspective... (screen 3) YMMV, of course, this is just my first impression. The layout doesn't reflect the relation between different elements very well IMHO. The Lighting Presets and Custom Flags box belong together, as do the Flag Sets selector and the list of checkboxes. The 'Copy selected preset to custom flags' button is also not a great way to do it IMHO, if you're a first-time user who doesn't really know what it does.

You're right, the layout is a bit jumbled. I think flag sets used to be under the flag list until I added the "Double-click on a flag etc." text. As for the copy preset button, it was intended as a limited way of making the lighting presets more useful, in case someone liked a preset but wanted to tweak it to their own tastes. I think it's easy enough to figure out what it does once you try it, and reversing the effects of pressing it is simple enough (just remove the text added to custom flags and select the preset again), but you're right, it's not great.

Speaking of which, the issue of large text font sizes is something the wxL Team will have to deal with, especially in cases of text like the "Double-click on a flag", which isn't in a scrollable window. :blah: The advanced settings page on my machine looks like this (http://wiki.wxlauncher.googlecode.com/hg/images/wxLLinuxAdvancedPage.png), by comparison, using the Ubuntu Lucid (10.04?) default font size of 10.

How I would do it - Instead of the 'Lighting Presets' pane (on the right) put a 'Setting presets' box, with radio buttons ordered by computing power, e.g. 'Default FS2' (all features off), 'Basic features on' (for older computers, with glowmaps and other basic things only), 'Recommended' (for most computers, only some high-performance features off) , 'Full option' (for real good computers, with full-on visuals), 'Custom' (gets auto-selected if the user changes a setting himself). Then have a selection list for the custom lighting settings, positioned directly above the Custom Flags list (where the Flag Sets selector list is now).

Anyway, take it or leave it, I know it's quite an overhaul of the tab I'm suggesting.

Interesting, although it'd require close collaboration with the FSO team, since we wouldn't want to have to keep track of what are considered to be resource-intensive options and which aren't, especially since the definition of resource-intensive changes over time as new features are added (and old ones sometimes removed) and as the average computer gets more powerful. Much better to leave those decisions to the engine, whose authors know how resource-intensive the various options are in the context of the average computer at that particular point in the engine's development. In fact, something like this would probably require at least a partial rewrite of FSO's cmdline.cpp. In any case, since we're currently focusing on fixing bugs and adding support for the new sound code (a feature that we must have), we're probably not making major changes in the very near future. Thanks for pointing these things out and for your suggestion, though.

One more thing, the 'Default FS2' preset should probably turn things like glowmaps and normals off, right? I'm guessing it's meant for those who wanna play vanilla?

That's what it did in the past, although now that trunk has the various maps enabled by default rather than disabled (https://svn.icculus.org/fs2open?view=rev&revision=8587), meaning that the corresponding flags now say "Disable X" instead of "Enable X", I'm not sure how things are going to work. Well, I just tried out a trunk build, and it looks like the various flag sets haven't been adjusted to match the changes in the flags, meaning the FS2 Default flag set has the new flags turned off instead of on. Also, High memory usage features off flag set has them turned off, but maybe they should actually be turned on? I have no idea what qualifies as "high memory usage", though.

EDIT: Clarification.

EDIT 2: As for the currently crappy formatting in the error message text in the advanced settings page, would allowing the text to wrap properly be a step in the right direction? We can work on coming up with a better version of those messages in the meantime. Thanks.

This setting used to be in the wiki until Zacam changed it (http://www.hard-light.net/wiki/index.php?title=Sample_Lighting_Settings&diff=35477&oldid=30682) last July, which led me to believe that that setting was no longer the FSU team's recommended setting, which is why it's not in the launcher.

Hi!

Official MediaVP thread install instruction show "old" preset. If user can't see this mediawiki (I dont see this never before you show), then user type "old" preset, if want use MediaVP.This is clean logic. If you know this information: recommended preset is "old" in MediaVP thread, then show this; example:

Now visible preset name in wxLauncher:

"Baseline recommended" - this is wrong name.

"Baseline recommended (with MediaVP too, 7 July 2011)" - this is correct name. Please do not hide any important information from wxLauncher users :)

Hi. Wrong. Not hidden, obsolete. Not important, irrelevant.

FSU -used- to recommend settings. Parts are still hanging around. You start with "Baseline recommended" (this IS the right one) and go from there or you use "Defaults"

You're right, the layout is a bit jumbled. I think flag sets used to be under the flag list until I added the "Double-click on a flag etc." text. As for the copy preset button, it was intended as a limited way of making the lighting presets more useful, in case someone liked a preset but wanted to tweak it to their own tastes. I think it's easy enough to figure out what it does once you try it, and reversing the effects of pressing it is simple enough (just remove the text added to custom flags and select the preset again), but you're right, it's not great.

Yeah... It's easy for a newbie to just be adding flags this way, instead of replacing them. (Wonder what FSO would do when the same flag is set multiple times, with different values - I guess just take the last value?) Of course, you can't just clear the entire custom flags list, there might be more in it than just lighting settings. Hum... Perhaps two different custom-flag text boxes, one for the (selection/tweaking of) lighting settings and one for misc flags? So basically you'd have a text box instead of the "copy to flags" button, which gets cleared and re-set every time the user picks different lighting settings. Would probably fit best at the bottom of the flag list, with a "Custom:" radio button autoselected when the user changes something in the field.

Anyway, just tossing ideas around here.

Quote

Speaking of which, the issue of large text font sizes is something the wxL Team will have to deal with, especially in cases of text like the "Double-click on a flag", which isn't in a scrollable window. :blah: The advanced settings page on my machine looks like this (http://wiki.wxlauncher.googlecode.com/hg/images/wxLLinuxAdvancedPage.png), by comparison, using the Ubuntu Lucid (10.04?) default font size of 10.

Yeah, with font size 10 it all fits nicely... Though I guess, with ever-increasing screen DPI, bumping the font size up every once in a while may not be a bad idea. Does wxWidgets have some way of auto-scaling the window?

Quote

As for the currently crappy formatting in the error message text in the advanced settings page, would allowing the text to wrap properly be a step in the right direction? We can work on coming up with a better version of those messages in the meantime. Thanks.

Oh, definitely. The error message on the Mods tab already looks nice and native, with an "info" icon and everything - removing hard-coded newlines and copying it to Advanced Settings should do the trick.

You're right, the layout is a bit jumbled. I think flag sets used to be under the flag list until I added the "Double-click on a flag etc." text. As for the copy preset button, it was intended as a limited way of making the lighting presets more useful, in case someone liked a preset but wanted to tweak it to their own tastes. I think it's easy enough to figure out what it does once you try it, and reversing the effects of pressing it is simple enough (just remove the text added to custom flags and select the preset again), but you're right, it's not great.

Yeah... It's easy for a newbie to just be adding flags this way, instead of replacing them. (Wonder what FSO would do when the same flag is set multiple times, with different values - I guess just take the last value?) Of course, you can't just clear the entire custom flags list, there might be more in it than just lighting settings. Hum... Perhaps two different custom-flag text boxes, one for the (selection/tweaking of) lighting settings and one for misc flags? So basically you'd have a text box instead of the "copy to flags" button, which gets cleared and re-set every time the user picks different lighting settings. Would probably fit best at the bottom of the flag list, with a "Custom:" radio button autoselected when the user changes something in the field.

Anyway, just tossing ideas around here.

Interesting, although people might have the impression that lighting settings flags will only work if in the "lighting settings" text box, which I guess isn't a huge problem. More problematic, though, would be if someone tweaks the settings in the lighting settings text box and then selects a different preset. If I understand you right, their settings would then be overwritten, and destroying user data (especially without their consent) is generally a big no-no. (Aren't GUIs fun? :D) We could ask them "are you sure you want to switch presets?", but pop-ups are annoying.

A quick experiment shows that if lighting settings are repeated in the custom flags, FSO uses the last value.

Of course, another option is to remove the "copy preset" button, but that would reduce the value of the lighting presets somewhat.

Other ideas... I guess the UI can indicate with a warning somehow (custom flags box border becomes red, maybe?) that there are repeated flags in the custom flags, maybe with a message like "Repeated flag: -ambient_factor". I don't know of any situations where having repeated custom flags is desirable. Admittedly, that doesn't help that much with the problem you mentioned.

Yeah, with font size 10 it all fits nicely... Though I guess, with ever-increasing screen DPI, bumping the font size up every once in a while may not be a bad idea. Does wxWidgets have some way of auto-scaling the window?

Well, the font sizes are in points (http://en.wikipedia.org/wiki/Point_%28typography%29) rather than pixels, so text of a given font size should be the same size in any resolution. You can test this out by lowering your screen resolution and seeing if the text is still the same size. I'll try testing it out later. That said, the error text on the mods page seem to be quite different sizes across the three platforms, even though it's 12-point font in all cases. So I dunno.

Oh, definitely. The error message on the Mods tab already looks nice and native, with an "info" icon and everything - removing hard-coded newlines and copying it to Advanced Settings should do the trick.

If only it were that simple. :blah: The advanced settings page is technically very different from the mods page, so achieving the same look might not be easy. We've already committed a change that makes the background the window color instead of white and that removes the bold from the text, since it looks better that way (the text on the mods page is not bold), so there's already an improvement. The advanced settings page also has a wider range of errors, since it covers all the ways in which flag file processing can go wrong.

As for the newlines, well, it might be nice to have newlines separating sentences, so that you don't end up with a monolithic block of text, although we try to make the messages short. And also, no matter what we do, there'll always be some combinations of font and font sizes where a word at the end of a sentence will end up stuck on its own line, likethis.

In short, we'll need to think about what to do with the newlines. If nothing else, there will be fewer of them. Lowering the font size might help (currently 16 in advanced settings vs. 12 in mods page). We might just have to try to ensure that bad wrapping doesn't happen with common combinations of fonts and font sizes. Originally, I was hoping that the line breaks would be at logical places (which is what the current line breaks are trying to do), such as keeping prepositional phrases intact, but that's probably too much to ask for.

wxLauncher 0.9.1 alpha has been released. You can download it from the release post (http://www.hard-light.net/forums/index.php?topic=67950.msg1341695#msg1341695).

Summary of changes since 0.9.0:

All platforms:- Support for configuring the new sound code (http://www.hard-light.net/forums/index.php?topic=68146.0)-- If the Enable EFX checkbox is missing, then your OpenAL setup doesn't support EFX- Improved formatting of error messages on mods page and advanced settings page- List of executables on basic settings page is now sorted alphabetically- Assorted bug fixes and text revisions

Windows only:- "Calibrate" button in joystick settings box now works :nervous:- "data" folder is automatically created if it doesn't already exist- Improvements to installer, such as checking for installed versions

Linux only:- Taskbar icon added- Expanded range of files to be ignored when looking for FSO binaries, such as files ending in .map, .pdb, or .gz

What a fantastic program! As a linux user, thank you very much for working on this. I can't believe how beautiful it looks on my system.

Just one question: Is it possible to compile the launcher so that it looks for the resources directory by relative pathing, rather than absolute? It's a pain having to recompile it if I just want to change where I'm storing it...

What a fantastic program! As a linux user, thank you very much for working on this. I can't believe how beautiful it looks on my system.

Just one question: Is it possible to compile the launcher so that it looks for the resources directory by relative pathing, rather than absolute? It's a pain having to recompile it if I just want to change where I'm storing it...

Thank you.

The short answer is no. There is no way to do that at this time, however I don't really understand the reason for the question. How/why does the resources directory need to be changed from the directory in /usr?

What a fantastic program! As a linux user, thank you very much for working on this. I can't believe how beautiful it looks on my system.

Just one question: Is it possible to compile the launcher so that it looks for the resources directory by relative pathing, rather than absolute? It's a pain having to recompile it if I just want to change where I'm storing it...

Thank you.

The short answer is no. There is no way to do that at this time, however I don't really understand the reason for the question. How/why does the resources directory need to be changed from the directory in /usr?

some of us really dont want to install it on the system and would much rather keep it in the user directories :p

(i'd be fine with simple guideline on how to compile it into a certain folder, if nothing else)

As I read it, these past few questions boiled down to "This is very nice but could you <change some arcane detail a user shouldn't think about> to <cater to my highly specific interests>?"

Is there a .deb package? no.

Until there is a .deb package i will continue not installing it on the system and i'll keep using it from a folder in my home directory. i also find the separation of logs and actually useful **** for debugging from the main executable's location.

i also find the separation of logs and actually useful **** for debugging from the main executable's location.

This does not parse. Please elaborate.

derp. i meant to say that i dislike the fact that fso stores stuff like pilots, logs and such into .fs2_open instead of in the directory where the executable and the rest of the important stuff is.Yes, that does make sense if the game is installed into /usr/games or whatever, which isnt user-writeable. I havent seen anyone say that they installed the game like that on linux so far, and if memory serves, the proper "tutorial" on the wiki is basically "save into whichever folder you want(which, for most people is /home/<username>/whatever ), plonk the exec there, have fun with launching the game"

also, i do not know if its been requested already, but a box for manual resolution entry in the launcher would be swell :)

i might investigate into ways of installing it like that (other than the manual file-nudgery) and see how fso behaves. but that comes later.

i also find the separation of logs and actually useful **** for debugging from the main executable's location.

This does not parse. Please elaborate.

derp. i meant to say that i dislike the fact that fso stores stuff like pilots, logs and such into .fs2_open instead of in the directory where the executable and the rest of the important stuff is.Yes, that does make sense if the game is installed into /usr/games or whatever, which isnt user-writeable. I havent seen anyone say that they installed the game like that on linux so far, and if memory serves, the proper "tutorial" on the wiki is basically "save into whichever folder you want(which, for most people is /home/<username>/whatever ), plonk the exec there, have fun with launching the game"

Not that what FSO does has any bearing on what FSO does, but nevertheless we will (at some point) be doing a "portable" mode for wxLauncher because it has been requested by several people.

I should note however, where you install FSO has no bearing on where wxLauncher should be installed. We don't suggest installing wxLauncher in the same directory as FSO. Instead wxLauncher should be installed as a separate application.

also, i do not know if its been requested already, but a box for manual resolution entry in the launcher would be swell :)

No it has not been requested. But I don't see us adding that feature either because the resolutions that we list are requested from the video hardware/software. If a resolution is not in the list then it is probably not a resolution that you want to use anyway.

Having said that, you can probably edit profile or set your resolution manually on the custom flags. The flag is -res <width>x<height> IIRC and it will override the resolution set by wxLauncher via the other mechanism.

also, i do not know if its been requested already, but a box for manual resolution entry in the launcher would be swell :)

No it has not been requested. But I don't see us adding that feature either because the resolutions that we list are requested from the video hardware/software. If a resolution is not in the list then it is probably not a resolution that you want to use anyway.

At least one boneheaded version of the nVidia Linux drivers has a very minimal set of supported resolutions (i.e. 7) which doesn't include my standard res for a 16:10 window (1440x900) - in fact the only widescreen res was fullscreen :nono:

Having said that, you can probably edit profile or set your resolution manually on the custom flags. The flag is -res <width>x<height> IIRC and it will override the resolution set by wxLauncher via the other mechanism.

If you manually edit the profile file will the next change you make to the profile overwrite your change?

i also find the separation of logs and actually useful **** for debugging from the main executable's location.

This does not parse. Please elaborate.

derp. i meant to say that i dislike the fact that fso stores stuff like pilots, logs and such into .fs2_open instead of in the directory where the executable and the rest of the important stuff is.Yes, that does make sense if the game is installed into /usr/games or whatever, which isnt user-writeable. I havent seen anyone say that they installed the game like that on linux so far, and if memory serves, the proper "tutorial" on the wiki is basically "save into whichever folder you want(which, for most people is /home/<username>/whatever ), plonk the exec there, have fun with launching the game"

Not that what FSO does has any bearing on what FSO does, but nevertheless we will (at some point) be doing a "portable" mode for wxLauncher because it has been requested by several people.

I should note however, where you install FSO has no bearing on where wxLauncher should be installed. We don't suggest installing wxLauncher in the same directory as FSO. Instead wxLauncher should be installed as a separate application.

of course, i wasnt implying i installed it in the same folder as FSO, just a wish to keep it all contained within a single folder. no worries there as i know nothing will change there on the FSO side.

also, i do not know if its been requested already, but a box for manual resolution entry in the launcher would be swell :)

No it has not been requested. But I don't see us adding that feature either because the resolutions that we list are requested from the video hardware/software. If a resolution is not in the list then it is probably not a resolution that you want to use anyway.

At least one boneheaded version of the nVidia Linux drivers has a very minimal set of supported resolutions (i.e. 7) which doesn't include my standard res for a 16:10 window (1440x900) - in fact the only widescreen res was fullscreen :nono:

oh its even better on my end. i'm running a dual-screen setup. twinview of course, you know how many resolutions i have? One., 3200x1080, because 1920x1080 + 1280x1024I had to define an additional metamode just to keep applications from fullscreening to both monitors, and then i always lose the secondary monitor for the time the fullscreen app is running, due to the way the metamode is set up. I havent found a solution yet, but i also havent searched that much for it either.

Having said that, you can probably edit profile or set your resolution manually on the custom flags. The flag is -res <width>x<height> IIRC and it will override the resolution set by wxLauncher via the other mechanism.

If you manually edit the profile file will the next change you make to the profile overwrite your change?

Thanks for the tip about the -res flag, I'll have to try it out.

thank you for that. i always forget about that flag -.- (mighty useful when trying to run windowed)

If you manually edit the profile file will the next change you make to the profile overwrite your change?

The launcher only reads from the profile files on startup. It won't notice any changes you make to the files while the launcher is running. It only looks for profile changes made in the launcher through the controls, and the only points where it would save those changes to the file is on profile switch, profile creation, and launcher exit. If the "Automatically save profiles" checkbox is checked, then any changes will be automatically saved; if it's not checked, then a pop-up dialog will appear asking if you want to save changes, if there are any.

The global profile (global.ini) which includes things like the most recently retrieved highlights (if any), the last used profile, etc. is always saved on launcher exit. Thus, any changes to global.ini while the launcher is running will be overwritten when the launcher exits.

What a fantastic program! As a linux user, thank you very much for working on this. I can't believe how beautiful it looks on my system.

Just one question: Is it possible to compile the launcher so that it looks for the resources directory by relative pathing, rather than absolute? It's a pain having to recompile it if I just want to change where I'm storing it...

Thank you.

The short answer is no. There is no way to do that at this time, however I don't really understand the reason for the question. How/why does the resources directory need to be changed from the directory in /usr?

Mostly because I'd like to install the program in my home directory, where it will be preserved if I reformat the operating system. If I compile it to be in /usr, I have to reinstall the launcher every time I upgrade my OS. I was able to change the install directory, but now the launcher fails if I try to give it to someone else with a different username, and they have to recompile it.

It's really a very small issue, and nothing that a quick recompile can't solve. Thanks again for writing this awesome program.

Any ideas?I've got the required dependancies installed and the sources cmake without errors.

To my fellow Archers out there, I found a solution to this problem. If you're like me you have both python and python2 installed. As stated the build will only work with python2, but the cmake files are looking for python 3. Edit CMakeCache.txt and replace /usr/bin/python with /usr/bin/python2. After that the build worked great

Noted a possible bug, but it could just be my side. When using text-to-speech on the Windows-only launchers, the drop-down list shows the correct order. However, when I use the wxLauncher's text-to-speech drop-down list and select the one I want, it plays another voice instead. I believe the drop-down list's voice name is shifted down, but it may in fact be random.

To my fellow Archers out there, I found a solution to this problem. If you're like me you have both python and python2 installed. As stated the build will only work with python2, but the cmake files are looking for python 3. Edit CMakeCache.txt and replace /usr/bin/python with /usr/bin/python2. After that the build worked great

Noted a possible bug, but it could just be my side. When using text-to-speech on the Windows-only launchers, the drop-down list shows the correct order. However, when I use the wxLauncher's text-to-speech drop-down list and select the one I want, it plays another voice instead. I believe the drop-down list's voice name is shifted down, but it may in fact be random.

I'll need to look into this and get back to you. Thanks for reporting it.

EDIT: This issue has been confirmed and fixed in trunk. Thanks again for reporting it.

[main]name=Diasporafilename=pro00099.iniinitialized=1[lighting]preset=BaselineRecommended[network]ip=port=0speed=Nonetype=None[speech]inbriefings=0ingame=0inmulti=0intechroom=0voice=0volume=100[tc]currentbinary=fs2_open_Diaspora_R1.execurrentmod=(No mod)currentmodline=flags=-post_process -soft_particles -fxaa -cache_bitmaps -snd_preload -ship_choice_3d -weapon_choice_3d -warp_flashfolder=C:\\Games\\Diaspora[video]depth=32height=768texturefilter=Trilinearwidth=10242) I have the installer alter the profile's "folder" option to reflect where the user has chosen to install to. 3) I call the launcher twice to install the profile and to make the profile the default.

wxLauncher\bin\wxlauncher.exe --add-profile --profile=Diaspora --file=[profile filename]wxLauncher\bin\wxlauncher.exe --select-profile --profile=Diaspora (you set that name in the profile itself)To do all that requires that you have the latest version of wxLauncher (0.9.2), which is the version Diaspora uses and isn't publicly released as yet. But if you chat with Iss or jg18 I'm sure they'll help you.

One recommendation about the profile Karajorma posted: I'd recommend leaving the "height" and "width" entries out, so that the launcher will auto-detect the player's native resolution, which is assumed to be the highest resolution that their display supports.

Beyond that, I'll need to look at this more carefully after I've had some more sleep. :)

To do all that requires that you have the latest version of wxLauncher (0.9.2), which is the version Diaspora uses and isn't publicly released as yet. But if you chat with Iss or jg18 I'm sure they'll help you.

To do all that requires that you have the latest version of wxLauncher (0.9.2), which is the version Diaspora uses and isn't publicly released as yet. But if you chat with Iss or jg18 I'm sure they'll help you.

Yes, we will have lots of questions.

I'll contine working on this on the weekend ... I'll send a PM your way once I'm back on it...

Q: Should joystick calibration work on Linux? I can't seem to find the button. (Diaspora launcher)

No. It is intentionally disabled on Linux and OS X because as far (as I can tell) there is no way to calibrate joysticks with SDL. Now, I honestly doubt this is the actual case, but I have yet to find any documentation on how to do it.

@0rph3u5: Sounds like a plan. I should be around on #scp most of the weekend and am on in the evenings Mountain Time.

2) I have the installer alter the profile's "folder" option to reflect where the user has chosen to install to.

How?

That was the tricky part. Fortunately the installer I used (Inno setup) had a feature built in allowing it to alter ini files. I had to set up a tiny bit of pascal code to alter things to the format that the profile uses but it wasn't too hard in the end.

I think the change from underscores to periods was made in the .14 branch some time ago and only recently synched over to trunk, we may have to change it to something that wxLauncher can handle better if it can't be made to work with this format easily. Using fs2_open_3_6_15 should probably work too.

I can't reproduce this bug on Ubuntu 10.04 (Lucid), although I admit I was lazy and just renamed an existing executable called fs2_open_3.6.14 to fs2_open_3.6.15.

FSO executable names on OS X have included periods/full stops since 3.6.12 at least, and wxL has just one FSO filename parsing scheme for all platforms. FWIW, the filename parsing is necessarily brittle: since there are no official naming conventions for FSO executables, the parsing has to be a "best guess" interpretation.

What do you mean by "is not recognized as a valid executable"? Could you post a log (~/.wxlauncher/wxLauncher.log)?

What do you mean by "is not recognized as a valid executable"? Could you post a log (~/.wxlauncher/wxLauncher.log)?

Exactly that, I'm unable to select the game root folder because "No supported executables in folder". Log attached, generated by renaming the execs to the bad name again (I couldn't un-select the previously selected game folder, hence why it says "The current game root folder is /home/downwash/FSO").

I have limited time to stare at this at the moment :sigh: but could you try these things and see what happens, to help narrow down the problem?

renaming the executable to fs2_open_3.6.14

renaming the executable to fs2_open_3.6.16

renaming the executable to fs2_open_3_6_15, as chief suggested

renaming the executable to fs2_open_3_6_16

renaming the executable to fs2_open.asdftrq4-56dd87 (works on my machine)

moving that executable out of the FSO folder, taking an old executable that's known to work, copying it into the FSO folder, and renaming it to fs2_open_3.6.15

changing the new executable name back to fs2_open_3.6.15, moving it back into the folder and all other FSO executables out of the folder, going to your profiles folder (~./wxlauncher/), finding the pro#####.ini file corresponding to the profile that loads at wxL startup (check the line that starts with name=), backing up that file, and adjusting the line that starts with currentbinary= to point to /home/downwash/FSO/fs2_open_3.6.15

Hmm, the funny thing is wxL does recognize it as a valid binary if the game root folder was selected previously; it's really just the folder selector that's affected. Are you using different filename patterns for those two?

1. Not recognized by folder selector2. Not recognized by folder selector3. Not recognized by folder selector4. Not recognized by folder selector5. Still not recognized by folder selector6. The 3.6.15 exec is recognized if I rename it to just fs2_open; if I rename it back to fs2_open_3.6.15 it's not anymore. Again, this is for the game root folder selector.7. It plays alright, but the folder selector still doesn't recognize it. Status bar says "Folder does not have any supported executables".

BtA DemodataFS2.bmpFS2OGGcutscenepack.vpfs2_openfs2_open_debugmediavps_3612mod.iniroot_fs2.vpsmarty_fs2.vpsparky_fs2.vpsparky_hi_fs2.vpstu_fs2.vptango1_fs2.vptango2_fs2.vptango3_fs2.vptrunk (note: that's a mod folder, SVN named it this way)warble_fs2.vpwxlauncher (note: I copied the binary to here, to have everything in one place. )

Thanks for the tests. Filename patterns should be the same in both cases.

Nothing jumps out as a potential cause, and I might not have time to seriously look into this for a few weeks :blah: since I'm in the middle of finishing the semester and coordinating a 1,500-mile (2400 km) move of all of my stuff. Hopefully Iss can look into it sooner than that.

Could you check if this issue occurs with 0.9.0 or 0.9.1? You can get the source tarballs from the downloads page (http://code.google.com/p/wxlauncher/downloads/list?can=1).

... ehh. *headdesk* It appears I've been doing something horribly wrong. I actually went into the root folder and then clicked "Open", which means the select-folder dialog might actually have been looking in the first subdirectory, instead of the (intended selection) folder I was in. Because if I open the folder selector, go to /home/downwash, select (but don't open) the FSO directory and press the "Open" button, it is recognized correctly, even with the _3.6.15 extensions.

In my defence, there is no clue whatsoever to this behaviour, I only accidentally discovered it by random button-klicking. But nonetheless, apologies for reporting a false positive. Turns out wxL is more stable than its users by now :)

Ah yes, that issue. Well, the same button is called "Choose" on OS X and "OK" on Windows, although the dir picker dialog on Windows has a more intuitive directory tree layout (well, it's as intuitive as the notion of a dir tree is in the first place, anyway). Since these are all native MFC/Cocoa/GTK+ widgets, we can't change the button label without rolling our own dir picker AFAIK, an unappealing option that also goes against the wx philosophy of native widgets on each platform.

So not sure offhand what a good solution would be. One easy thing to do would be to include the complete folder path in the error message "No supported executables in folder", so at least it'd be clear which folder was being examined. Still doesn't fully explain to the player what they're doing wrong or how to fix it, but it's a start.

Ah yes, that issue. Well, the same button is called "Choose" on OS X and "OK" on Windows, although the dir picker dialog on Windows has a more intuitive directory tree layout (well, it's as intuitive as the notion of a dir tree is in the first place, anyway). Since these are all native MFC/Cocoa/GTK+ widgets, we can't change the button label without rolling our own dir picker AFAIK, an unappealing option that also goes against the wx philosophy of native widgets on each platform.

I couldn't agree more, that would be way more work than it's worth, and kinda defeat the purpose of using wx indeed.

Quote

So not sure offhand what a good solution would be. One easy thing to do would be to include the complete folder path in the error message "No supported executables in folder", so at least it'd be clear which folder was being examined. Still doesn't fully explain to the player what they're doing wrong or how to fix it, but it's a start.

That would be good :yes: Perhaps only the folder name (as opposed to the full path) would do, to prevent text overflows on longer paths/larger fonts.

Come to think of it: is a scalable window planned for the future? (As in, drag the corners to adjust window size.)

Come to think of it: is a scalable window planned for the future? (As in, drag the corners to adjust window size.)

Possibly, but not in the short term. It is far too much work to make it look good on all platforms (which is why it is hardcoded as it is now), when writing the UI the originally there were countless bugs (primarily with the mod list and the flag list) when the window resized. It is something we will need to address (if only for DPI reasons) though.

My input: great work so far, way better than the v.0.8.0a, more organized, good clean looks, I haven't played in about a year, I'm starting again and using this latest version from the start; I don't see why is it in alpha stage still, for me looks like a beta at least.

Suggestion for the lighting presets: maybe you could add a image or a small 3D model to cast the lighting on so we can see how the different presets modify the lighting at gameplay.

Antipodes builds, Trunk builds, BP builds, RC builds... all with different flags and requirements. It's a good thing wxL is super awesome with profiles and stuff. What was that old launcher? 5.5dontuseitanymore I think it was.

With the new 3.6.16RC1 the launcher does not differentiate between the regular and debug version in the selection screen for the FS exe. or the fred exe. It shows up correctly in the command line but not in the selection screen.

With the Windows launcher, any mods and command-line switches set for the game are also used when FRED is launched. This isn't the case with wxLauncher, so anyone who wants to use FRED but can't use the Windows launcher has to enter the switches manually in a shortcut or at the command line. Is it possible to fix this?

With the Windows launcher, any mods and command-line switches set for the game are also used when FRED is launched. This isn't the case with wxLauncher, so anyone who wants to use FRED but can't use the Windows launcher has to enter the switches manually in a shortcut or at the command line. Is it possible to fix this?

Hmm? With wxL you can launch FRED from the launcher. It definitely keeps the command lines that way.

With the Windows launcher, any mods and command-line switches set for the game are also used when FRED is launched. This isn't the case with wxLauncher, so anyone who wants to use FRED but can't use the Windows launcher has to enter the switches manually in a shortcut or at the command line. Is it possible to fix this?

Hmm? With wxL you can launch FRED from the launcher. It definitely keeps the command lines that way.

WxLauncher didn't have a field for FRED, so I assumed that it didn't support launching FRED. I searched the manual a few minutes ago and found out how to make it launch FRED.

That's news to me.. but if that is the case it should definitely be changed. What a great way to encourage people not to FRED.. :(

Mostly because it was a ninja feature by me (at the request of a particular FREDer) and it just never was promoted to a proper feature. However, the current thought process is that in a effort to reduce clutter and confusion in the interface (which we do get complaints about) the FRED launch button along with other future modding tools are hidden by default. The current method of editing a config file to enable it however will go once I have time to write a proper interface for it.

It doesn't. Each tab has the correct amount of information without it being crammed like the old one (which *was* crammed). Also I don't get this criticism at all. The last adjective I'd remember to call wxlauncher was "BIG".

Given that I can't even get wxLauncher to be fully visible on my netbook (which can run FS2_Open), it's too big. When bits of the UI are not even visible in a resolution FS2_Open can actually run, then it's way too big.

The windows box is 655x715 pixels. I'd guess your netbook screen is a 1024x600 pixels (which is a crime in itself). Well, if considering netbooks is a thing that should be done, then I see your point. I also see where one could cull 150 pixels (counting with the bar pixels...), although that would be detrimental to everyone else that would experience an app that is way smaller than it could be given their screens with 1024 pixel height (and usually with nineteen hundred pixels in horizontal). A funny thing about wxlauncher is that it has a resize corner, but then it doesn't resize at all :D.

I'm thinking a landscape layout would solve the issue without further compressing the launcher's contents. I doubt that anyone plays FS on a portrait resolution - and then still, they can at least drag the window left-to-right to see everything.

Alternatively, an extra tab. Redistributing advanced settings. The other three tabs could probably shrink a little without becoming cramped.

Or (third option), from Advanced Settings, remove the Flag Sets (unless anyone would miss it?) and shrink the checkbox list. This would probably be the easiest option, if also the least desirable from a design/functionality point of view.

My input: great work so far, way better than the v.0.8.0a, more organized, good clean looks, I haven't played in about a year, I'm starting again and using this latest version from the start; I don't see why is it in alpha stage still, for me looks like a beta at least.

To address the "why alpha?" question, we were originally thinking of keeping wxL as alpha until it had auto self-update and maybe also a portable mode on Windows. At this point, though, I'd say it's likely that the next version will be called a beta, even though it won't have those things.

Suggestion for the lighting presets: maybe you could add a image or a small 3D model to cast the lighting on so we can see how the different presets modify the lighting at gameplay.

Thanks for the idea. We thought about using the screenshots from the wiki, but they're of various sizes and aspect ratios and of different scenes, and we don't have permission to use them with the launcher (GNU GPL v2) besides.

Now, if a FREDder with artistic sensibilities and a decent rig could create a mission with a fixed scene suitable for showing off lighting of all types and then take screenshots using the various lighting settings, we could use that. :)

Alternatively, the lighting settings may eventually become configurable in-game (http://www.hard-light.net/forums/index.php?topic=79283.0), in which case this would be less of an issue.

With the new 3.6.16RC1 the launcher does not differentiate between the regular and debug version in the selection screen for the FS exe. or the fred exe. It shows up correctly in the command line but not in the selection screen.

This should be fixed in future 3.6.16 builds. Thanks for reporting it.

That's news to me.. but if that is the case it should definitely be changed. What a great way to encourage people not to FRED.. :(

Mostly because it was a ninja feature by me (at the request of a particular FREDer) and it just never was promoted to a proper feature. However, the current thought process is that in a effort to reduce clutter and confusion in the interface (which we do get complaints about) the FRED launch button along with other future modding tools are hidden by default. The current method of editing a config file to enable it however will go once I have time to write a proper interface for it.

Pretty much this.

Quote from: headdie and others

<wxLauncher is/is not too big>

At this point, I can't tell whether the concern is that the launcher is too big or that it has too much information in each tab (usability issue?) or that people are just unhappy with the layout. Whatever the case may be, could whoever feels strongly about it please create a ticket in our bug tracker (http://code.google.com/p/wxlauncher/issues/list) and please be precise about the problem?

We're also well aware that while the current UI could definitely use some work, there's no one UI that will make everyone happy, so no matter what we do, someone is gonna be at least a little disappointed. That's life. (And no, we will not provide options for different UIs. It's not worth the added code complexity.)

If the launcher can't fit in a netbook-size screen, then yes, that's a problem, but not something that can be fixed anytime soon. UI changes, especially non-trivial ones, are always a dicey proposition code-wise -- remember that "UI" means on all three platforms -- and we're currently working on getting the skin system up and running so we can get the next version out the door (ETA is SoonTM). Including this issue in our bug tracker ensures that it won't get lost.

At this point, I can't tell whether the concern is that the launcher is too big or that it has too much information in each tab (usability issue?) or that people are just unhappy with the layout.

It's not "or", it's "and" - they're not three issues, but three facets of the same problem :P The root problem is that the window is too big. It can't be "just shrunk" because the information density is already very high, especially in the "Advanced" tab. So the amount of information per tab may need to be reduced, in order to shrink the window. And this will obviously affect the layout.

Come to think of it, if the lighting screenshots idea goes ahead, "Lighting" would make a logical fifth tab, unloading the advanced settings...

Completely unrelated, thank you guys for the user profiles. I didn't see the need for it at first, but now that Diaspora and BP both came with their own binaries and lighting settings it's a godsend :yes:

At this point, I can't tell whether the concern is that the launcher is too big or that it has too much information in each tab (usability issue?) or that people are just unhappy with the layout.

It's not "or", it's "and" - they're not three issues, but three facets of the same problem :P The root problem is that the window is too big. It can't be "just shrunk" because the information density is already very high, especially in the "Advanced" tab. So the amount of information per tab may need to be reduced, in order to shrink the window. And this will obviously affect the layout.

Come to think of it, if the lighting screenshots idea goes ahead, "Lighting" would make a logical fifth tab, unloading the advanced settings...

So it seems specifically the the window is too tall, not a simple too big. How many pixels too tall is it again?

Completely unrelated, thank you guys for the user profiles. I didn't see the need for it at first, but now that Diaspora and BP both came with their own binaries and lighting settings it's a godsend :yes:

Thanks. For something that seems so simple, it has proven to be a very hard feature to implement as intended.

So it seems specifically the the window is too tall, not a simple too big. How many pixels too tall is it again?

Yes, sorry for not being more specific. Like I said earlier, a panorama-oriented box (using widescreen resolutions more efficiently) might solve the problem - keeping the content per tab the same, but rearranging pretty much the entire UI.

First, could some Linux wxLauncher users try out the patch on this wxL bug ticket (http://code.google.com/p/wxlauncher/issues/detail?id=93#c6)? Once it's committed, it will allow (or at least pave the way for allowing) for building Linux binary packages for wxLauncher (according to niffiwan (http://www.hard-light.net/forums/index.php?topic=83240.msg1662802#msg1662802)), so that people won't have to build from source anymore. Thanks! :)

At this point, I can't tell whether the concern is that the launcher is too big or that it has too much information in each tab (usability issue?) or that people are just unhappy with the layout.

It's not "or", it's "and" - they're not three issues, but three facets of the same problem :P The root problem is that the window is too big. It can't be "just shrunk" because the information density is already very high, especially in the "Advanced" tab. So the amount of information per tab may need to be reduced, in order to shrink the window. And this will obviously affect the layout.

Come to think of it, if the lighting screenshots idea goes ahead, "Lighting" would make a logical fifth tab, unloading the advanced settings...

Thanks for the thoughts, but it looks like part of my quote is missing. :P

At this point, I can't tell whether the concern is that the launcher is too big or that it has too much information in each tab (usability issue?) or that people are just unhappy with the layout. Whatever the case may be, could whoever feels strongly about it please create a ticket in our bug tracker (http://code.google.com/p/wxlauncher/issues/list) and please be precise about the problem?

Iss Mneur may feel differently, but I figure that since there's nothing we can do about this issue in the short term (UI changes are messy), much better to discuss it on the bug tracker, where it can be saved and organized with the other listed issues, than here, where it'll likely get forgotten or mixed in with whatever other things may come up.

Completely unrelated, thank you guys for the user profiles. I didn't see the need for it at first, but now that Diaspora and BP both came with their own binaries and lighting settings it's a godsend :yes:

Thanks. One of kkmic's brilliant ideas IIRC, along with the mod list and undoubtedly many other wxL features, to give credit where it's due. And as Iss Mneur said, it proved to be quite hard to get right.

In regards to this: http://code.google.com/p/wxlauncher/issues/detail?id=44&colspec=ID%20Type%20Status%20Priority%20Milestone%20OpSys%20Owner%20Summary

Portable mode is where I expect I can open an archive (not an installer), drop the necessary files to either right under FS2 dir or in their own folder under FS2 dir. And then be able to move or copy the entire FS2 dir to portable drive, or network and have it work on another computer right away with launcher settings as they were before copy or move.

The old launcher has the definite advantage that is it only a single executable that works entirely from FS2 dir as-is, and only writes to two (IIRC) files under FS2 dir.

Of course, when used in portable mode, it is not possible to have per-user profile settings as any writable files will have to reside under FS2 dir.

I think asking that the settings themselves still have to be in that folder is a bit much. What about just having a way to specify where the USERDATA folder is, and that could just be a separate folder on the portable device that could still live outside of the FS2 directory, or I suppose it could be right inside of it. But having it outside of it could allow other portable apps to still use a common USERDATA folder on one device, something I believe is fairly common, but I could be wrong.

The "All features on" flag set; this is defined in the EXE and should not be hidden.

Fine, I can add it back. I think the flag sets are generally not as useful as they look (except for maybe "all off"), "all features on" doesn't strike me as well-defined (does that include 3D radar? preloading sound? info next to target? etc etc) and SCP doesn't maintain the flag sets besides (or at least hasn't in my time here). I've made Mantis 2790 (http://scp.indiegames.us/mantis/view.php?id=2790) as a reminder about it, but it'll be the FSO Team's job after that to ensure they're in sync.

To start, make sure the speech checkboxes in Basic Settings are checked. They are checked by default in 5.5g but unchecked by default in wxL based on this poll (http://www.hard-light.net/forums/index.php?topic=80799.0).

In the plans (http://code.google.com/p/wxlauncher/issues/detail?id=78), ETA unknown.

As for portable mode, I don't have anything definitive to say offhand, so either Iss can post something or we'll talk about it first. I for one would really like discussion of complicated topics like this one to stay in the bug tracker and not get fragmented between here and there, especially since the release thread is an interwoven mix of whatever comes up. :sigh:

As for portable mode, I don't have anything definitive to say offhand, so either Iss can post something or we'll talk about it first. I for one would really like discussion of complicated topics like this one to stay in the bug tracker and not get fragmented between here and there, especially since the release thread is an interwoven mix of whatever comes up. :sigh:

I don't have anything to add other than a reminder that the wxLauncher is considered an FS2 Open Tool (http://www.hard-light.net/forums/index.php?board=193.0) and is a valid topic to discuss on the tools board.

Yeah, if we had our own board (as was proposed a while back (http://www.hard-light.net/forums/index.php?topic=79887.0)) then it'd be a lot easier to discuss complicated topics; they could just each have their own thread.

Not so much a bug, this, more of a gripe. I was in the advanced settings tab, and while hovering over the Flag Sets menu accidentally hit the scroll wheel. BAM! My precious carefully crafted game setup, all gone - reduced to "All features off". Expected behaviour of course, but still it made me go through the entire checkbox list to set up my preferences again. Cost me a full two minutes of my life! :P

jg18 asked me to bring this up here. FRED launching should be available by default. Assuming that wxL continues to basically be the new standard launcher, then it's an opportunity to remove as many barriers as possible to get new people FREDing as well as playing. FREDing, regardless of mod, universe, or storyline, is the backbone of what we do at HLP. You can create all the pretties you want, but we need missions to put them in.

jg18 told me the reason it's not on by default is to keep the launcher simplified in it's UI. I'm not arguing against UI simplification by any means. But realistically, we are talking about 1 extra dropdown menu and 1 extra launch button, both already clearly labelled! Currently, someone has to go find their %appdata%, open a file, add some text, and save... to get FRED launching ability in wxL. That's WAY too much. Even if it is in the help docs (which I didn't even know existed until jg18 told me it was in there.) jg18 also mentioned that you guys are thinking about adding a menu checkbox 'allow FRED' or something. That's a fine compromise, I suppose. But it seems like overkill if you are going for UI simplification. Add a menu & box to toggle a menu and a button?

Given how much FRED is used by a large portion of the community, FRED launching should be available out of the box. Everything is clearly labelled... even the builds that SCP provides! It's a minimal addition to the UI, especially since it uses space that is otherwise unoccupied. FRED is just too important to HLP to be left hidden in the background.

Me too. If necessary stick FRED on its own tab so that it doesn't confuse anyone. But it should be available by default.

This brings me to my other suggestion. An error reporting tab. At the simplest this would be a tab which provides an interface to access the log files. At the very least fs2_open.log but access to the FRED log, multi.log and mission.log would all be useful.

A more complex version would be a tab with text at the top explaining how the tab will help you run the debug version (Simply check if a debug version of the currently selected exe exists) and explain which data would be useful to people on HLP when it comes to troubleshooting your problem.

A good, working error reporting tab could basically end the "I have problem X", "Get us a debug log", "Here's my debug log" start we have to almost any major problem.

Right now I'm feeling too lazy to read posts from where this was last discussed, so pardon me if these have already been discussed about.

I'm strong supporter of not requiring system wide installs of anything past retail FS2. And even that is optional if you don't plan to play with retail executables, ever. With new installer on its way, I imagine process of installing FS2 and **** goes like this:1. Install FS2 from retail discs, GoG.com or something.2. Run installer which installs everything for you.3. ????4. Profit!

Or alternatively.1. Copy existing installation from another computer, disk, stick, network, whatever. No installation or admin privileges required.2. Run installer which installs or updates everything for you.3. ????4. Profit!

FSO has only one base requirement to function, OpenAL. The choices here are either Creative's or Soft. But whichever is chosen, both have a dll file that can be named as OpenAL32.dll and dropped into FS2 dir without any system-wide installation. For user convenience, launcher is also needed but not required by FSO. As we have discussed before, the old launcher was single executable which was just happy to be dropped into FS2 dir and work right out of the box.

But enter wxLauncher which requires system wide install and even defaults to Program Files. As such, wxLauncher remains the odd one out in the whole process. Where everything else is downloaded and put right into FS2 dir, wxLauncher isn't and requires even admin privs to install.

Now, I understand that this choice was made to allow multiple users to have multiple profiles. But in reality, do we really need anything but multiple profiles on single user? It's nice to have the option for multiple users, but does it need to be default? Right, so what I would propose is following:- By default wxLauncher is installed to FS2 dir, which hopefully is not in Program Files.- By default wxLauncher is in single-user mode set to use global profiles. Global profiles are stored in wxLauncher dir.- wxLauncher has an option to enable multi-user mode, where user profiles are stored in %appdata% instead. Both global and user profiles would be available to you, they are not mutually exclusive and you can choose which one each profile is.- wxLauncher has an option to install start menu or desktop shortcut for all users, not just the user under which wxLauncher was installed.- wxLauncher does not write to windows registry and does not care where it is installed, it follows nicely without complaints wherever FS2 dir goes. If FS2 dir is copied to another computer, wxLauncher and global profiles (if any exists) would follow with it. If on this new computer there are any pre-existing wxlauncher profiles in %appdata%, they are automatically displayed in wxLauncher.

So with these changes, retail FS2 would hopefully remain the only thing where user needs admin privileges. Or not, if you just copy existing FS2 installation from somewhere. Running installer and having it install whatever user wishes, shouldn't need admin privileges or make any system wide changes by default. Such changes should remain strictly optional.

Not a fan. The second you have more than one TC this quickly escalates. If you use TBP, FS2, Diaspora plus who knows what else is coming down the line, this quickly becomes a complete cluster****.

Each TC is a game on their own. Their launchers should have nothing to do with FSO's launcher.

How is separate launchers for each game better than one unified launcher?

All three use the FSO engine so having the same launcher that can be set up for each one by the use of a drop menu is a lot more convenient than having to keep track of multiple icons, especially when that launcher can have multiple configurations for each game and different configurations for each mod for each game, all of which is handled from the start tab of said launcher.

edit:

sorry for the wtf are you smoking? bit I have been of my anti-depressants for a week and I am rather irritable atm, still dosnt excuse that level of response for this but thought I had better put that out there

And none of that functionality would be removed, so what's the problem exactly?

The only difference is that Diaspora or other TC's would have their launchers installed within their own dirs, not Program Files. Any of the TC's would also be free to customize their launchers however they please. If there would be only one launcher in Program Files, this couldn't be the case.

However, if you want to use only one launcher to control all your FSO games, you can do so as the functionality to do already exists. Just pick any of them launchers already present in FSO or any of the TC's. Unless TC has decided to remove this functionality from their version of the launcher. Just create additional profiles in say, FSO launcher to manage all TC's as well.

Not only does this not prevent you from using single launcher to manage everything, it allows everything to be portable as well.

The major design decisions that people have brought up, such as FRED launching, an error reporting tab, and Fury's proposal, are things that Iss Mneur and I need to discuss more before we can respond, but I can at least respond to the more straightforward issues:

Not so much a bug, this, more of a gripe. I was in the advanced settings tab, and while hovering over the Flag Sets menu accidentally hit the scroll wheel. BAM! My precious carefully crafted game setup, all gone - reduced to "All features off". Expected behaviour of course, but still it made me go through the entire checkbox list to set up my preferences again. Cost me a full two minutes of my life! :P

This is indeed a bug, in that it's a usability problem. If you could create an issue (http://code.google.com/p/wxlauncher/issues/list) about it, that would be very helpful.

customisation controls in the mod.ini to effect things in the launcher like images and feature availability would be a handy feature whiel removing the need for project specific customisations

This sounds very close to what we're currently working on, namely getting the skin system working so that customizable aspects of the launcher are controllable through .ini files. Take a look at the mod.ini file (http://pastebin.com/xUEXinZn) that ships with Diaspora for a sample list of some features that will be controllable on top of the usual mod.ini settings.

Some launcher aspects will be customizable by both mods and TCs, such as the minimum resolution (meaning that all resolutions smaller than it will not appear in the "Resolution" drop down box in Basic Settings) and the label/value of the "Baseline recommended" lighting preset.

But as mjn said, some aspects will only be customizable by TCs, namely the skin itself, such as images, news/highlights source, and the text that appears below the banner image on the Welcome page. We think it would be jarring for the launcher to change appearance every time the player selects a different mod in the mod list, nor do we feel that supporting mod skins is worth the added complexity in the codebase -- keep in mind that just two people maintain wxL, and both are fairly busy with RL.

I'm not sure what you mean by "feature availability," though.

The wxLauncher wiki has a work-in-progress list (http://code.google.com/p/wxlauncher/wiki/ModIniOptions) of what launcher features will be customizable. Some features, such as flagsets, extremeforce flags, and localization (non-English support), will not be ready for the next release. The only things that we can guarantee will be ready are the things in the Diaspora mod.ini.

Not so much a bug, this, more of a gripe. I was in the advanced settings tab, and while hovering over the Flag Sets menu accidentally hit the scroll wheel. BAM! My precious carefully crafted game setup, all gone - reduced to "All features off". Expected behaviour of course, but still it made me go through the entire checkbox list to set up my preferences again. Cost me a full two minutes of my life! :P

This is indeed a bug, in that it's a usability problem. If you could create an issue (http://code.google.com/p/wxlauncher/issues/list) about it, that would be very helpful.

Although we'll eventually address all of the points made in the last several posts, we'd like to focus on the FRED launching question for now. The other issues are long-term questions whose implementation will require much more work, and we don't anticipate having the time to do that in the near future.

However, we'd like to comment on the question of adding new launcher features. GUI applications meant for a general audience like wxLauncher don't benefit from having more and more features added to them, since piling on features in the absence of a larger, coherent vision for the UI as a whole is liable to result in a muddled and confusing UI, even if one consisting of arguably useful features. See items 1 and 2 from these Windows User Experience Design Principles (http://msdn.microsoft.com/en-us/library/windows/desktop/aa511335.aspx), for example. For more information, take a look at the other design principles articles available from that page's left sidebar and also these (http://web.archive.org/web/20051125183807/http://mpt.phrasewise.com/discuss/msgReader$173) three (http://web.archive.org/web/20051125144552/http://mpt.phrasewise.com/discuss/msgReader$182) articles (http://web.archive.org/web/20080824134802/http://mpt.net.nz/archive/2008/08/01/free-software-usability) on common sources of usability problems in open source software.

We're primarily coders, not UI designers, and we'd love to bring on board someone with a strong UI design background to take the role of lead UI designer and help us shape that vision for the UI, but until that happens, we'll have to be fairly cautious about what features get added. This is not to say that new features won't be added; rather, proposed features must, at a minimum, provide a large benefit to a very large part of our user base. Some form of assistance with troubleshooting would certainly qualify.

Now back to FRED launching.

While it's true that a sizable portion of the modding community uses FRED, only a small fraction of our entire user base uses FRED. It becomes a tiny fraction once you include all of the people who come to play one of the TCs. Normally, a feature that benefits so few people would likely have never been added in the first place (see the principles article above), but since we recognize that FREDding is crucial to the community and that FRED launching is valuable to those who use FRED, we have chosen to include it.

But given that the vast majority of wxL's users will never use FRED, we consider it bad practice to subject all users to the added clutter of the FRED launching controls. Yes, even just three controls are clutter for someone who will never use them, especially for someone who is just trying to get started, particularly considering the wide range in our users' level of computer savvy. Moving the FRED controls to a new tab not only does little to eliminate the clutter but actually creates an even bigger problem by moving the controls from where they should logically appear, thereby breaking consistency.

Yes, the current method of enabling FRED by editing a text file is a pain and needs improvement. That's part of why the launcher is still not at version 1.0. We'd like to point out that anyone who finds locating and editing a text file to be difficult will likely find FREDding to be overwhelmingly challenging.

We are aware of the objection that not having FRED launching available by default unnecessarily adds a barrier to FREDding, but consider that FRED launching is in no way essential to using FRED. Countless FREDders have gotten by without this feature while using the Windows launcher. The real barrier to FREDding is the complexity of making missions and of FRED itself. Making FRED launching available by default will not change that.

Put another way, wxL was intended from the beginning to not only unify the launchers for all supported platforms but also be less intimidating to new and casual users, thus we disable and hide little used features by default.

Thus in our view, FRED launching belongs as a feature accessible through an advanced options panel. While FRED launching will currently be the only option available on this panel, we have no doubt that more advanced features will eventually be requested, and options to enable them will be added there. Because we haven't had time to create this panel, the current clunky method will be the only option for the moment, but we now have a bug ticket (http://code.google.com/p/wxlauncher/issues/detail?id=106) to keep track of this.

This is a poor decision... But I lack the motivation to argue such thought out stubbornness.

EDIT: Nevermind. This is a big enough deal to me... I read over your linked articles in order to seek understanding of your position. Having read your articles.. I still think you need to reconsider.

FRED is the backbone of everything that happens at HLP. No FRED, no missions, no campaigns, no mods. wxL's continuing to ignore 50% of the main Freespace related programs included in every FSO release is not only disappointing, but it shows an ignorance of the community at large and what it is built on.

Furthermore, if you want to hide behind the new users... FRED is not the place to make a stance. Under your decision, new users have an exec that the most up-to-date launcher doesn't seem to support. What is FRED? Do I need it? Who knows? wxL certainly doesn't know... which is odd, because wxL is trying to be the first FSO related window a new user (or any user!) will open. wxL should know...

Lastly, your article starts off by saying you should 'Nail the Basics'. FRED is one of 2 program execs that SCP releases. That's pretty basic... but it seems to me that you are too caught up on the article's #4 to really do #3, #5, #8, or #17...

"Think about how real users (not the marketing or PR departments) will describe your program.""Don't avoid difficult decisions by making everything optional or configurable.""People want to use your program, not configure it or learn a bunch of things.""Put the information users need to know directly on the screen.""Enabled is better than disabled. Disabled controls are often confusing, so use them only when users can easily deduce why the control is disabled. Otherwise, remove the control if it doesn't apply or leave it enabled and give helpful feedback."

It seems to me that you guys are so caught up with making an easy design that you are confusing incomplete with simple. It also may be a case of you guys 'Scratching Your Own Itch'. FRED is not important to you, so it's not being scratched.

Of course you also linked to an article that gives you an out to even listening to feedback... "In the absence of regular usability testing, volunteer projects rely on feedback from users, but such feedback is often far removed from reality."

Another point is that most of these articles talk about how 'usability is hard to measure', but you guys with one fell swoop have somehow figured out that the 3 necessary fields to FRED would bring wxL too close to the 'unusuable' line for the new guys. Do you have some feedback from new users to help me understand that?

You are so caught up with the theoretical 'new user' that is afraid of FRED than to consider the people who are actively using wxL, filing bug reports, dialoging with it's creators, and doing the footwork to recommend the launcher over another.

The biggest problem is that the file that must be edited to show the FRED options is in a location that few FREDders would think look (and it's in AppData--a hidden folder!). Furthermore, the necessary lines aren't already in the file--you have to add them manually. It's like having to open your TV and add a jumper (which you supply yourself) to a pair of unmarked pins to enable pillarbox mode for 4:3 signals.

The option to show FRED needs to be added to the GUI somehow. With the way wxLauncher is now, many FREDders and potential FREDders have virtually no clue that they can launch FRED from wxLauncher.

This is a poor decision... But I lack the motivation to argue such thought out stubbornness.

EDIT: Nevermind. This is a big enough deal to me... I read over your linked articles in order to seek understanding of your position. Having read your articles.. I still think you need to reconsider.

FRED is the backbone of everything that happens at HLP. No FRED, no missions, no campaigns, no mods. wxL's continuing to ignore 50% of the main Freespace related programs included in every FSO release is not only disappointing, but it shows an ignorance of the community at large and what it is built on.

Furthermore, if you want to hide behind the new users... FRED is not the place to make a stance. Under your decision, new users have an exec that the most up-to-date launcher doesn't seem to support. What is FRED? Do I need it? Who knows? wxL certainly doesn't know... which is odd, because wxL is trying to be the first FSO related window a new user (or any user!) will open. wxL should know...

Lastly, your article starts off by saying you should 'Nail the Basics'. FRED is one of 2 program execs that SCP releases. That's pretty basic... but it seems to me that you are too caught up on the article's #4 to really do #3, #5, #8, or #17...

"Think about how real users (not the marketing or PR departments) will describe your program.""Don't avoid difficult decisions by making everything optional or configurable.""People want to use your program, not configure it or learn a bunch of things.""Put the information users need to know directly on the screen.""Enabled is better than disabled. Disabled controls are often confusing, so use them only when users can easily deduce why the control is disabled. Otherwise, remove the control if it doesn't apply or leave it enabled and give helpful feedback."

It seems to me that you guys are so caught up with making an easy design that you are confusing incomplete with simple. It also may be a case of you guys 'Scratching Your Own Itch'. FRED is not important to you, so it's not being scratched.

Of course you also linked to an article that gives you an out to even listening to feedback... "In the absence of regular usability testing, volunteer projects rely on feedback from users, but such feedback is often far removed from reality."

Another point is that most of these articles talk about how 'usability is hard to measure', but you guys with one fell swoop have somehow figured out that the 3 necessary fields to FRED would bring wxL too close to the 'unusuable' line for the new guys. Do you have some feedback from new users to help me understand that?

You are so caught up with the theoretical 'new user' that is afraid of FRED than to consider the people who are actively using wxL, filing bug reports, dialoging with it's creators, and doing the footwork to recommend the launcher over another.

All of this, basically.

If the end goal is to have wxLauncher act as a gateway into the larger FSO community, then we also need to make the main tool by which new content for FSO is created easily discoverable.

I've never seen it that way, then again I'm a computer programmer and therefore very computer literate.

Stuff like launcher flags and lighting presets are things the average user doesn't need to touch. Altering some of them can actually have a detrimental effect on the game. And the way these are presented to the user doesn't help much either. How many average users are going to look at "Enable 3D radar" and think "Well that sounds cool, let's turn that on"? I've got no idea what that will do in Diaspora, but I doubt it would be pretty.

If you don't like the basic and advanced labels, what about Player and Developer? Or something else of that ilk. Cause while I don't agree with the idea of having to alter a text file to enable FRED, the launcher is already rather clunky and confusing for a newbie.

What Kara said - a 'Player' and 'Modder' mode would solve much of this. Players can get a straightforward, easy-to-use interface, while modders can use the full power of the launcher if they so desire. It would allow wxLauncher to focus on its two (fairly distinct) user groups separately, instead of trying to be everything to everyone.

But of course, this would require a significant interface overhaul, and therefore a lot of work. So as things stand, it'll be something for the distant-future to-do list together with the netbook-friendly resolution :)

thing is there IS a difference between modders and players and players that want to just be players dont want controls and functions for anything other than playing cluttering up their experience adding to the potential for confusion. a player who wants to be a modder will seek out the functions to do so either by experimenting with what is there and/or will go to a place where they can find the information they want.

also do you think someone who cant be bothered/too scared to experiment and poke around will have the motivation to make a mission let alone anything more substantial?

Even as a player who does know his way around FRED and some of the more esoteric command lines, I don't need to see those options when I'm just playing through a campaign normally, so a separate "Developer" mode sounds fine to me.

The only thing I have to contribute to these, regardless of our specific community, or UI theory, is that there are many examples of commercial games that provide a level editor launch button of some sort during the process of getting into the game. They may not all be perfect examples of UI design, I know many games get it horribly wrong, but the fact that it's as prevalent as it is might be something to consider. They may have easier to use editors however, but that's probably a separate discussion to be had.

Divide the wxLauncher window into three parts, where left part works as menu and right part displays settings under each menu selection. In left menu you have these:wxLauncher settings- Links to important FSWiki pages such as quickstart guide for wxLauncher- Normal mode (default & recommended)- Advanced mode (shows all settings)

FreeSpace Open settings- Select FSO executable- Presets to set High, Medium and Low performance settings- Display resolution with desktop resolution selected as default- If Advanced mode is enabled, shows custom command line text field- If Advanced mode is enabled, shows all graphics/audio/gameplay/etc settings you can set in FSO separated by categories and designed to prevent input of incorrect values

MOD settings- Select mod from the same folder as where FSO executable is located- If Advanced mode is enabled, allows enable/disable individual vp-packages within selected MOD, some ground rules should be established for this and mod_settings.ini (or whatever the name is) can set which vp-files are enabled by default

Game Controller settings- Select game controller device, OS default is selected by default if one is plugged in

And last part of the three window sections is the bottom part where you can directly launch selected FSO and FRED executables. The buttons show up once proper executable is selected and are visible anywhere in the launcher.

Like so_________| | || | || |_____||__|_____|

Or alternative menu is on top. Like so._________|________|| || ||________||________|

The bottom area which basically could contain just shortcuts to FSO and FRED executables are much smaller than depicted above in either illustration.

I really don't think the answer to the FRED problem is to re-design the entire UI again and I'm surprised so many people are suggesting that as if it's a simple matter. For one thing, wxL has found a UI that is working, and working well. I'm talking important tweaks, not complete overhauls.

The first thing you should worry about is how to name the button to launch fred, and it sure as hell should not be called "launch fred", it should be called something along the lines of "Launch mission editor". It lets the first time user know that its not the button to start the game and it explains exactly what it does. Anyone that can install freespace open can understand those 2 words.

And besides... if the new user decides the (hopefully not) big red button looks pretty... oh noes! he has opened fred...

The first thing you should worry about is how to name the button to launch fred, and it sure as hell should not be called "launch fred", it should be called something along the lines of "Launch mission editor". It lets the first time user know that its not the button to start the game and it explains exactly what it does. Anyone that can install freespace open can understand those 2 words.

And besides... if the new user decides the (hopefully not) big red button looks pretty... oh noes! he has opened fred...

And besides... if the new user decides the (hopefully not) big red button looks pretty... oh noes! he has opened fred...

You say this so casually, but do you truely realize the potential danger this horror might inflict on the unsuspecting end user?Before you know it, that unholy grid has stared deep into the end user's soul. Leaving forever a traumatizing mark, a haunting memory that will follow him/her for years to come.

We must make great strives to ensure that the end user be kept safe from such perils. I therefor suggest remapping the entire interface of the launcher to just a single button: Play Freespace.

The first thing you should worry about is how to name the button to launch fred, and it sure as hell should not be called "launch fred", it should be called something along the lines of "Launch mission editor". It lets the first time user know that its not the button to start the game and it explains exactly what it does. Anyone that can install freespace open can understand those 2 words.

And besides... if the new user decides the (hopefully not) big red button looks pretty... oh noes! he has opened fred...

We understand that FREDding is the backbone of everything that happens at HLP and that for wxL to serve HLP’s needs, FRED needs to be easily discoverable. wxL will focus on the modding community's needs after development moves towards wxL 2.0, but right now, we're trying to finish wxL 1.0, the end user release of a basic game launcher.

The target users of wxLauncher 1.0 are the thousands of people who play FS2 and the mods and the tens of thousands who play the TCs, and here we have clear evidence that the launcher is meeting their needs: only a handful of Diaspora players reported problems using the wxLauncher version bundled with Diaspora, mostly caused by a few bugs that were fixed quickly. Thus whatever shortcomings the UI may have, it's working well overall, doing its job and then getting out of the way.

Regardless of design decisions made by launcher devs for other games, FRED launching is not an end user feature and does not belong in the 1.0 interface. The only reason that it's in the launcher at all now as opposed to after 1.0 is that a modder requested it 3 years ago as a replacement for the batch scripts and manual shortcuts that used to be the mainstay of FSO modding. Since FRED launching was added long before its intended time, it had to be left as a hidden hack until it could be integrated into a post-1.0 design that provided interfaces for players and modders.

In the interest of making FRED launching more accessible in the short run, we can provide an advanced options panel to enable it, as we mentioned before. Because UI changes like these take time, it will not be ready in time for the next release, which features generic versions of the customizations found in the Diaspora launcher.

Well, at the very least, it needs to be obvious to users that wxLauncher can indeed launch FRED. Keeping that fact hidden from everyone except those who read a certain page in the manual is simply the wrong thing to do.

I did find a minor bug: wxLauncher doesn't consider 0 to be valid in version numbers. If a 3.7 build is found, this message appears in the status bar:

Quote

Revision version number out of range (0) in executable fs2_open_3_7_0_RC1.exe

Also, could the mod images be scaled using a better method than nearest neighbor, such as bilinear?

I recently tried using wxLauncher with normal FSO, and noticed three issues.First, loading time. I disabled retrieving highlights, yet it still takes about a minute to load. Not good.Second, loading graphic. Is there a particular reason why the blasted thing has to stay on top of everything? I'd rather see it gone, or at least made optional.Third, lack of FRED interaction. If I use the regular launcher, FRED reads the setting from launcher6.ini, meaning I can use it without even opening the launcher. Since wxLauncher doesn't use launcher6.ini, FRED doesn't get the mod settings.Also, the mod selection feature, while noob-friendly, is problematic for somebody who wants a bit finer control. I'd prefer at least having an option of manually selecting the mod folder.Considering all that, I'm afraid that wxLauncher in it's current state is vastly inferior to the standard one.

Third, lack of FRED interaction. If I use the regular launcher, FRED reads the setting from launcher6.ini, meaning I can use it without even opening the launcher. Since wxLauncher doesn't use launcher6.ini, FRED doesn't get the mod settings.

Doesn't FRED read the values from cmdline_fso.cfg? Or am I missing something?

I'm using the launcher on Windows and there is no loading graphics associated with the launcher. After an initial setup, setting the mod in the launcher sets it for FRED also. I've never seen a delay in loading even with the launcher retrieving highlights.

Well, at the very least, it needs to be obvious to users that wxLauncher can indeed launch FRED. Keeping that fact hidden from everyone except those who read a certain page in the manual is simply the wrong thing to do.

Yeah, we know that the current situation sucks. We'll work on making FRED launching more accessible for the release after the upcoming one. It shouldn't be long.

Also, could the mod images be scaled using a better method than nearest neighbor, such as bilinear?

It looks like we're stuck with the box sampling method (http://docs.wxwidgets.org/stable/wx_wximage.html#wximagescale) that is used with wxIMAGE_QUALITY_HIGH downsampling; however, starting with the next wxL release, mods can specify in their mod.ini a separate 182x80-sized image (http://code.google.com/p/wxlauncher/wiki/ModIniOptions#image182x80) to use in the mod list.

First, loading time. I disabled retrieving highlights, yet it still takes about a minute to load. Not good.

Try starting wxL again. It should be faster this time. The reason it's slow is that it's scanning your FS2 folder looking for mods, which it considers to be folders containing a mod.ini file. It should start faster this time because the OS caches the scan.

That said, we're aware of this issue and would like to work on a more permanent fix, but it would take a ton of work and as such is not high priority, particularly since wxL starts up much faster after the first run.

Third, lack of FRED interaction. If I use the regular launcher, FRED reads the setting from launcher6.ini, meaning I can use it without even opening the launcher. Since wxLauncher doesn't use launcher6.ini, FRED doesn't get the mod settings.

Doesn't FRED read the values from cmdline_fso.cfg? Or am I missing something?

Yeah, it does. The reason it works from 5.5g is that pressing OK or Apply in 5.5g saves the configuration to cmdline_fso.cfg, but wxL doesn't save the config until you press Play or press FRED if you're using FRED launching (aka the subject of the last two pages).

Dragon, to configure wxL for launching FRED, click on the Help button in wxL and look at the section "FRED2 Open executable selection" in Reference >> Basic Settings page >> FS2 or TC root folder and executable.

Also, the mod selection feature, while noob-friendly, is problematic for somebody who wants a bit finer control. I'd prefer at least having an option of manually selecting the mod folder.

I'm not sure what's the advantage of manually specifying a mod folder? wxL shows all the available mod folders that include a valid mod.ini anyway (including feedback on mod dependencies)

Yeah, I don't understand why you need this feature. wxL considers any folder containing a file named "mod.ini" to be a mod folder. The file can be blank; it just has to exist, since it tells wxL that the folder contains a mod.

I'm using the launcher on Windows and there is no loading graphics associated with the launcher. After an initial setup, setting the mod in the launcher sets it for FRED also. I've never seen a delay in loading even with the launcher retrieving highlights.

No loading graphics as in no splash screen? You're using a release build of the launcher?

Regarding loading times: wxLauncher on windows reads stuff from .svn directories. If you have a few of those, loading times will increase by a lot.

Hey, good point, we'd forgotten about that. We can write a custom file system traversal to skip over the .svn folders when searching for mod.ini files. It's unfortunately too late to do it for the upcoming release, but we can add it to the release after that.

I must be, how do I tell? A quick look around the interface doesn't give me any clues :)

Oh, right, there's no indicator in the interface as to the build config, other than the presence/absence of the splash screen. We should probably do something about that. :doubt:

You can check if the launcher log (~/.wxlauncher/wxLauncher.log) has debug lines in it or if the name of the build folder where the wxL binary is found is called Release or Debug or RelWithDebInfo (which I think is considered Release).

wxLauncher 0.9.4 beta has been released. You can download it from the release post (http://www.hard-light.net/forums/index.php?topic=67950.msg1341695#msg1341695).

(0.9.2 and 0.9.3 were Limited Collector's Editions Diaspora R1 launcher versions.) If you have Diaspora (R1 Patch 4 and below), download the .zip of updated launcher resources from the Downloads section in the release post.

One important change is that FRED launching can now be toggled by pressing F3. Why F3? Because it's already accepted as a hidden "cheat code" for modders, thanks to the F3 Lab in FSO. Now F3 will access modding features in both FSO and wxL.

Other changes:- New splash image (special thanks to mjn.mixael for making this)- FRED launching can now be toggled with F3- Faster startup thanks to more efficient mod.ini search- Assorted bug fixes and text revisions

Linux only:- RESOURCES_PATH can now be user-specified (special thanks to Firartix for identifying and fixing this)- cmdline_fso.cfg is now written to ~/.fs2_open/data/ instead of FS2/TC folder

The wxLauncher Team would like to thank Axem, mjn.mixael, niffiwan, swashmebuckle, and Yarn for helping test 0.9.4.

I personally would also like to thank jg18 for his hard work on getting this release out. I know it would not have happened without him.

What exactly is the F3 key supposed to do? I downloaded and installed the new version of the launcher and I hit F3 and nothing happens. I usually launch FRED from the launcher and already have it enabled in the earlier version of the launcher. Does the F3 key just enable FRED or tie it to the mod selected in the Launcher?

The F3 toggles the 'FRED2 Open Exexutable:' selector and the 'FRED' launch button. I just did it on my wxL and worked fine.

Let me see if I understand this. The F3 does what had to be manually done with the previous launcher to enable FRED and is a one time action, or is it supposed to toggle the selector and launch button every time I hit F3. I had it set up on the previous version so it just came up on the updated launcher.

Hi, just thought I'd bring to your attention. The windows .exe download is being flagged as a trojan by several anti-virus programs. Checked the others and the same isn't happening there. Other than that, terrific work! Keep it up!

Hi, just thought I'd bring to your attention. The windows .exe download is being flagged as a trojan by several anti-virus programs. Checked the others and the same isn't happening there. Other than that, terrific work! Keep it up!

Heya, I was just using the wxLauncher and found something that might be a bug.

If I try to start the game right away, without letting the launcher load the hightlights from HLP it enters a dead loop, never loading FSO.The Play button changes to Starting alright, but stays there and after a while I get the regular crash window from Win8.

Yes, every time I try to run FSO without letting the launcher load the highlights the launcher tries to start FSO but never finishes the task.Eventually Windows shows the program as not responding and lets you choose to close it or wait. I've allowed it to work for a few minutes and nothing happened afterwards.

If I make the launcher start FSO after the highlights appeared the game starts with no problems at all, almost instantaneously.

If I disable the highlight retrieval I can start FSO with no problems right after starting the launcher, so I'd say you are pretty right about the hole highlights being the probable cause.

Is there any way to install this without root privileges? The best I've been able to find so far is making a symlink from /usr/local/share/wxlauncher to the source directory's "resources" directory. This seems like an ugly hack.

Short answer: No. wxLauncher should not be installed into the same directory as FreeSpace 2. It should be installed into its own directory either to its default location in program files or as a sibling of FreeSpace 2, because wxLauncher is designed to manage several installs of FSO.

Long answer: read this thread. The ins and outs and reasoning have been covered several times in this thread.

Hi all, I'm new to the forum and had a quick question about the wxlauncher.

Anyone know why Norton internet security is flagging this file as dangerous by reputation when downloading it through Google Chrome? What is really weird is that after it is downloaded I tried scanning it with Norton Internet Security and it says the file is safe. :banghead:

I'm assuming it's a DB mismatch of some kind as it clearly isn't a bad file.

Anyone know why Norton internet security is flagging this file as dangerous by reputation when downloading it through Google Chrome? What is really weird is that after it is downloaded I tried scanning it with Norton Internet Security and it says the file is safe. :banghead:

The version number of wxLauncher is not displayed in interface. You can check the wxLauncher log, both the release and debug versions write their version number there; check in the Troubleshooting section of the OP for more info.

Also, wxLauncher is backwards compatible, so you can just download and install the new version and not worry about it.

I recently installed windows 8 and just installed wxLauncher because the 5.5g launcher doesn't work on this OS. I tried to load up the newest BP AVX build and the launcher freezes, and cannot be killed with task manager. Anyone know what might be the cause?

Relevant info: both wxlauncher and my freespace root folder are in Program files (x86). I'm running the 2014 Avast antivirus, which has been problematic for me in the past.

Edit: So, moving the root folder to C:\Freespace and turning off my antivirus seems to have allowed the launcher to work properly. However, I now have no sound when running the latest BP AVX build, but have sound when running the latest BP debug build.

Edit2: Disregard all. Normal SSE2 bp build works fine. The AVX doesn't, which seems to be a build-specific issue, not related to the launcher.

Edit3: Actually, following another few launcher freezes and computer restarts, both the non-debug bp builds have resumed having no sound. I'm a bit at a loss as to what's going on. Here's a log from debug, despite it being not very useful because there are no errors with it...

Using extension "GL_EXT_fog_coord". Using extension "GL_ARB_multitexture". Using extension "GL_ARB_texture_env_add". Using extension "GL_ARB_texture_compression". Using extension "GL_EXT_texture_compression_s3tc". Using extension "GL_EXT_texture_filter_anisotropic". Using extension "GL_ARB_texture_env_combine". Using extension "GL_EXT_compiled_vertex_array". Using extension "GL_EXT_draw_range_elements". Using extension "GL_ARB_texture_mirrored_repeat". Using extension "GL_ARB_texture_non_power_of_two". Using extension "GL_ARB_vertex_buffer_object". Using extension "GL_ARB_pixel_buffer_object". Using extension "GL_SGIS_generate_mipmap". Using extension "GL_EXT_framebuffer_object". Using extension "GL_ARB_texture_rectangle". Using extension "GL_EXT_bgra". Using extension "GL_ARB_texture_cube_map". Using extension "GL_EXT_texture_lod_bias". Using extension "GL_ARB_point_sprite". Using extension "GL_ARB_shading_language_100". Using extension "GL_ARB_shader_objects". Using extension "GL_ARB_vertex_shader". Using extension "GL_ARB_fragment_shader". Using extension "GL_ARB_shader_texture_lod". Using extension "GL_ARB_texture_float". Using extension "GL_ARB_draw_elements_base_vertex". Using extension "GL_EXT_framebuffer_blit". Using extension "GL_EXT_geometry_shader4". Using extension "GL_EXT_texture_array". Found special extension function "wglSwapIntervalEXT".

Something about OAL unknown errors, which prevents the audio device from loading.

I have two oal soft .dll's: one in wxlauncher's root, and one in Freespace root. I don't have creative's OAL installed, or OAL anywhere else in my system. I tried dumping the dll in system32, but wxlauncher couldn't find it. I have no idea how to actually install .dll's, so I probably goofed something up there.

Something about OAL unknown errors, which prevents the audio device from loading.

I have two oal soft .dll's: one in wxlauncher's root, and one in Freespace root. I don't have creative's OAL installed, or OAL anywhere else in my system. I tried dumping the dll in system32, but wxlauncher couldn't find it. I have no idea how to actually install .dll's, so I probably goofed something up there.

Edit: Nevermind, it stopped working again. Did anyone have a chance to take a look at the debug log yet? I also did a bit of googling, and this is the exact problem I'm having:http://www.hard-light.net/forums/index.php?topic=83695.0

I dug up an ancient installer for Creative OAL, and now things work fine. However, I'd like to use OA soft for obvious reasons, but it seems the launcher is incompatible with it.

Kolgena: Offhand I don't know what the problem is, and since I currently have badly blurred vision (http://www.hard-light.net/forums/index.php?topic=53623.msg1727909#msg1727909) that makes reading very difficult, I can't research this right now. Hopefully Iss Mneur can.

Since we're also talking about using openAL soft with wxlauncher I have some feedback about that too. For me, in Windows 7, I uninstalled creative's openAL and put the renamed openAL soft dll in my freespace2 folder, openAL is detected by wxlauncher because when I start it I don't get the "unable to start the program because OpenAL32.dll is missing" message and the game runs, but there is a warning at the bottom of the launcher saying "unable to initialize OpenAL". I got some stuttering in-game once and never happened again but that probably has nothing to do with the launcher.

@Kolgena: I have looked at your log. It looks like we are having trouble interacting with the OpenAL library that was loaded. Everything that we asked it to do it returned an undefined error, so if you can compile wxLauncher, try run cmake with the PLATFORM_HAS_BROKEN_OPENAL set to 1. This may allow wxLauncher to force its way past the problems.

-DPLATFORM_HAS_BROKEN_OPENAL=1If you can't compile wxLauncher, I will try and get my computer setup with a build environment (I got a new computer a couple of months ago and haven't had time to setup a build environment yet).

@iVoid: Yeah, I doubt the stuttering in-game had anything to do with it.

It sounds like both of you have installed OpenAL Soft correctly but is has been a while since I have dealt with this so I don't remember clearly.

How do I force WXL to refresh the mod.ini for a given mod? I've tried switching to other mods and launching, then switching back and launching, but it seems to retain a cached version. Do I need to delete a subfolder?

@General Battuta, that is very strange. wxLauncher does not cache the mod.ini's. It enumerates every time the launcher starts. The enumeration is why the launcher still uses the splash screen when it starts, the enumeration can take a long time on a newly booted system.

Get a debug version of wxLauncher. When it starts it will write to the log file the full path of every mod.ini that it finds. You are looking for the part of the log starting with: "Starting to parse mod.ini's..."

wxLauncher deems any directory that contains a mod.ini to be a valid mod to list, so I suspect you still have a copy of it in some dir.

Yep. That will work for Windows. Once you start the debug wxLauncher, verify that the incorrect entry is still in the mod list, exit wxLauncher, then check the "Troubleshooting" section in the OP for where to find the log.

Using extension "GL_EXT_fog_coord". Using extension "GL_ARB_multitexture". Using extension "GL_ARB_texture_env_add". Using extension "GL_ARB_texture_compression". Using extension "GL_EXT_texture_compression_s3tc". Using extension "GL_EXT_texture_filter_anisotropic". Using extension "GL_ARB_texture_env_combine". Using extension "GL_EXT_compiled_vertex_array". Using extension "GL_EXT_draw_range_elements". Using extension "GL_ARB_texture_mirrored_repeat". Using extension "GL_ARB_texture_non_power_of_two". Using extension "GL_ARB_vertex_buffer_object". Using extension "GL_ARB_pixel_buffer_object". Using extension "GL_SGIS_generate_mipmap". Using extension "GL_EXT_framebuffer_object". Using extension "GL_ARB_texture_rectangle". Using extension "GL_EXT_bgra". Using extension "GL_ARB_texture_cube_map". Using extension "GL_EXT_texture_lod_bias". Using extension "GL_ARB_point_sprite". Using extension "GL_ARB_shading_language_100". Using extension "GL_ARB_shader_objects". Using extension "GL_ARB_vertex_shader". Using extension "GL_ARB_fragment_shader". Using extension "GL_ARB_shader_texture_lod". Using extension "GL_ARB_texture_float". Using extension "GL_ARB_draw_elements_base_vertex". Using extension "GL_EXT_framebuffer_blit". Using extension "GL_EXT_geometry_shader4". Using extension "GL_EXT_texture_array". Found special extension function "wglSwapIntervalEXT".

To make sure I understand the problem (again, reading is slow), the argument to FSO's -mod flag (aka the mod line) is incorrect? There are commas in cases where there should be spaces? Any other issues?

Can you post a copy of the mod.ini you're using, or if you prefer, could you PM a copy to me and Iss Mneur? EDIT 2: Well, not sure if there's a point in PMing, since the processed contents are already in the log, so might as well just post it.

EDIT: Other questions offhand:

- Which mod did you have activated in the mod list?

- Did the incorrect -mod string that's in the FSO log also appear in the launcher's "current command line" box (advanced settings tab)?

-mod blueplanetSVN,blueplanetSVN\advtest_bp2,blueplanetSVN\adv_bp2-r2,blueplanetSVN\test_bp2,blueplanetSVN\bp2-r2,blueplanetSVN\BP,Complete\bpc-advanced,blueplanetSVN\BP,Complete\bpc-core,blueplanetSVN\BP,Complete\bpc-visuals3,blueplanetSVN\BP,Complete\bpc-visuals2,blueplanetSVN\BP,Complete\bpc-visuals1,blueplanetSVN\BP,Complete\bpc-audio1,blueplanetSVN\BP,Complete\bpc-audio2,mediavps_3612;>>>>>>>,.r6252My initial thought was that there was some merging conflicts still remaining in svn, this was apparently resolved normally. However, as Matt pointed out, the greater issue is that spaces in the commandline as written in the mod.ini were converted to commas, causing wrongness everywhere.

The strange thing with the commas is that mangled string was read from the profile (called "Diaspora"), but we read it correctly from the mod.ini because we recorded the change to the correct string to that profile.

Keeping in mind that working on this is deeply frustrating no matter what, given that I can't read even large text from more than about 8 inches (20 cm) from the screen and am working on a laptop hunched over with full-screen magnification that limits me to seeing only part of the screen at a time...

How should the mod line read? The same except that "BP,Complete" should be "BP Complete"?

Reading the logs is extremely slow. I can only see a handful of lines at a time, and wxL logs are pretty verbose. Anything you can do to point out relevant lines would be appreciated.

Please answer my questions from before.

Does the issue still occur if you create a new profile?

Please provide me with the data/steps needed to reproduce this, including a complete copy of the mod.ini and preferably also a copy of your wxL profile folder (PM a link of a .zip or whatever if you prefer). I think that any relevant mod.ini files and your wxL profile data (%appdata%\wxLauncher IIRC) should be enough.

Guys, as much as I love speculating and asking random questions, it's likely to lead to my patience falling rapidly, especially with increasing eyestrain (should I even be doing this in the first place?). Working on a bug I can repro locally is much more likely to lead to it getting fixed. This holds true to some extent in all circumstances but now more than ever.

To make sure I understand the problem (again, reading is slow), the argument to FSO's -mod flag (aka the mod line) is incorrect? There are commas in cases where there should be spaces? Any other issues?

Correct, I believe that's the only current issue. We had another problem with a bit of junk getting appended to the mod.ini but it seems to have gone and I can't repro.

Can you post a copy of the mod.ini you're using, or if you prefer, could you PM a copy to me and Iss Mneur? EDIT 2: Well, not sure if there's a point in PMing, since the processed contents are already in the log, so might as well just post it.[/quote]

Just to make sure there's nothing weird going on with your profiles, could you rename your wxL profile folder? Exit the launcher, then go to Start Menu >> Run... and type %appdata% then rename the wxlauncher folder to say wxlauncher_old .

Then start the launcher again and set up the default profile (select your FS2 root folder, activate the Blue Planet SVN mod, etc.) and see if the problem recurs.

okay. Can you open your windows event viewer and check the Application (I think. I may be under the system log) log under Windows Logs for an windows side by side error and paste the contents of the General tab here.

... i'm going to clean install the launcher, since I apparently forgot that I copied the patched build over a debug build. Edit: nope, that didn't fix it.

Google says:It looks like you have a dependency on a debug library (Microsoft.VC90.DebugCRT)

Debug libraries are not provided in any redistributable pack (because they are not redistributable).

This probably means you are trying to run a debug build on a machine that does not have Visual Studio installed. The solution to the problem is to build and distribute a release build, not a debug build.

You will need to have the debug install of wxLauncher installed first before you copy over the .exe.

@Battuta, The E: I have looked through the code and do not see how we could damage the modline like that. At no point to we split on whitespace, so it is looking like it may have been bad data. Either way, I cannot reproduce what you are seeing. If I put a well formed mod.ini in place wxLauncher will clear out the damaged modline the next time you click activate on a mod. Do you have a copy of the malformed mod.ini that you were trying to use?

PH, are there any additional errors? Does the compiler stop right after encountering the error?

Also, your distro including version number, and versions of GCC and wxWidgets you're using? Is your copy of wxWidgets from your distro's repo, or did you build it?

No additional errors beyond the standard boilerplate when a build fails. Distro is arch, gcc is 4.8.2, wxWidgets is... ah, I have 3.0 and 2.8 installed separately. That's likely the problem, then. There's also, I have just noticed, an AUR package, so I'll use that instead. Problem solved.

Okay Kolgena, finally have a build that should not produce side-by-side errors (I even freshly installed a windows 7 machine to make sure that the debug installer and this binary will work). Please let me know how it goes: https://app.box.com/s/6o5xoqrimeyedwmwoib4

What format do the mod images have to be in to display in the launcher? I already found out that if the image is not exactly 255 x 112 it will not display but I found a couple of other mod images that do not display even when set to 255 x 112. Are there other requirements?

Any .bmp image with or without alpha (24 or 32 bit per pixel) of the specified resolution will work. .pngs will also work but they will not work with the win32 launcher.

What specific issue are you having? The only problem one have seen was the one that was shipped with WoD. IIRC, the .bmp had full transparency so when wxLauncher rendered them they were "missing" but when explorer rendered them they were fine because explorer generally ignores transparency. Resaving it with MS Paint would fix it.

What OS are you using? I am using windows 7. I notice that the .bmp has an all uppercase name and like FSO we are technically case sensitive (though on windows you get away with it most of the time because the filesystem on windows is not).

If that is not the case please take a try with a debug build (instructions are in the OP) and:1) attach your log 2) a screen shot of the mods tab of the launcher with the missing image3) a directory listing of your FSO root4) a directory listing of the mod directory5) the contents of the mod.ini that you are trying to use.

If you do not want to post is publicly feel free to PM the above to me.

It was said this wxlauncher folder should be placed not in the main FS2 folder but the default program files location.

Two minor questions:

1-When I installed this it installed to "Program Files (x86)". Is it okay to leave it there?

2-Is it okay if I rename that folder to "0.9.4 wxlauncher"? (I just added the numbers)?

1) Yes, let the installer put it where it wants.2) If you insist. But please, change the folder using the installer rather than just renaming the folder because it sets some registry entries that point to its location that are needed.

I was making a new banner for our mod and noticed that although wxlauncher calls for an image of 255x112, in the actual gui it's smaller than that, forcing the image to be scaled down and look compressed. I'd much rather use GIMP to scale the image properly to the final resolution, but it seems like we can only use 255x112? What is the actual size of that image box and why are we scaling down to that size instead of using the native image resolution?

I was making a new banner for our mod and noticed that although wxlauncher calls for an image of 255x112, in the actual gui it's smaller than that, forcing the image to be scaled down and look compressed. I'd much rather use GIMP to scale the image properly to the final resolution, but it seems like we can only use 255x112? What is the actual size of that image box and why are we scaling down to that size instead of using the native image resolution?

In the actual GUI it is 182x80. Yes, some mod images do look odd when it does the compression but for most it ends up not being a problem.

The reason for us scaling the image is the original 255x112 is just too big to be put into the list at a native resolution even though it looks nice as a header image (and we do use the full native res it on the Info Popup for exactly that).

In the mod.ini add an image182x80 (https://code.google.com/p/wxlauncher/wiki/ModIniOptions#image182x80) if you need to have a native resolution image in the modlist.

[launcher]modname = Fate of the Galaxy;image255x112 = texttt.png;image182x80 = text80.png;infotext = Fate of the Galaxy is a total conversion of FreeSpace Open based on the Star Wars universe. Our goal is to deliver compelling gameplay that captures the look and feel of the original trilogy space battles. May the force be with you.;website = http://fateofthegalaxy.net/;forum = http://www.hard-light.net/forums/index.php?board=70.0;

The mod.ini looks fine to me. BTW, secondrylist is supposed to be secondarylist. Not that it would break this.

If it doesn't like the 182x80 image then it will reject it and fall back to the 255x112 image. Get a debug build as described in the OP and check the log, it will print the reason when it is parsing the mod.ini's.

The mod.ini looks fine to me. BTW, secondrylist is supposed to be secondarylist. Not that it would break this.

If it doesn't like the 182x80 image then it will reject it and fall back to the 255x112 image. Get a debug build as described in the OP and check the log, it will print the reason when it is parsing the mod.ini's.

Huh...so I built a debug version and ran it...and it uses the correct image now! Went back and built the standard version again from scratch and it works fine there too now. Don't know what happened to my last build, since it was from the same source, but it looks fine now. Thanks for the help.

Huh...so I built a debug version and ran it...and it uses the correct image now! Went back and built the standard version again from scratch and it works fine there too now. Don't know what happened to my last build, since it was from the same source, but it looks fine now. Thanks for the help.

Interesting. Not sure what would cause that other than the launcher not getting restarted between tests (all of that data is read on start up).

had me download and install development libraries that may be needed to compile your launcher that your instructions do not show? Perhaps libraries that are not a part of Linux Mint by default but may be for the Linux OS you did test for?

There's been a few (http://www.hard-light.net/forums/index.php?topic=87577.0) posts (http://www.hard-light.net/forums/index.php?topic=87581.0) in support recently about the "default" FS2/FSO registry entries being missing (i.e. hkey_local_machine\software\volition\freespace2). So the question is, how wxLauncher interact with the registry? Does it create the entire tree from volition up if it doesn't exist? Does it write the resolution (and/or any other entries) to that location when a resolution is selected in the Basic tab and then play is pressed?

There's been a few (http://www.hard-light.net/forums/index.php?topic=87577.0) posts (http://www.hard-light.net/forums/index.php?topic=87581.0) in support recently about the "default" FS2/FSO registry entries being missing (i.e. hkey_local_machine\software\volition\freespace2). So the question is, how wxLauncher interact with the registry?

Does it write the resolution (and/or any other entries) to that location when a resolution is selected in the Basic tab and then play is pressed?

wxLauncher only writes to the FSO locations (registry and cmdline_fso.cfg) when play (or FRED) is pressed. The settings are persisted into the profile, after each change if auto-save is on (which it is by default), or when told to save with the save button or the save settings prompt on profile switch or launcher shutdown.

I am curious how they installed FSO without writing to the registry. I would also be interested in the wxLauncher log from those people because it should be working.

wxLauncher only writes to the FSO locations (registry and cmdline_fso.cfg) when play (or FRED) is pressed.

Yeah, is there any way to get it to do that without pressing play? Cause when I'm coding I usually want to change my settings from the usual ones I have to play with. Which means launching FS2 and then immediately killing it (or just changing the cfg file directly, which is what I usually do).

Yeah, is there any way to get it to do that without pressing play? Cause when I'm coding I usually want to change my settings from the usual ones I have to play with. Which means launching FS2 and then immediately killing it (or just changing the cfg file directly, which is what I usually do).

Not currently. Truthfully it wasn't really considered because wxLauncher is not designed for the coder use case, not that we won't do what we can to help with that, it certainly will not be a default option. There are a couple of ways we could make that accessible so, create an issue in the issue tracker so that it gets addressed at some point.

The first post mentioned that the project files for Visual Studio > 2010 were generated incorrectly. I encountered the same issue and implemented a fix for that in my CMake branch. I have adapted the changes to wxlauncher which means that it doesn't need the registry_helper anymore and it can be build with newer visual studio versions (I tested 2013).A patch with the necessary changes is attached.

I have recently had a user reporting issues with vJoy and Diaspora whereby the virtual stick is unusable (game binding routine does not recognize input) under win8 when the launcher is started with physical sticks plugged in as well as the virtual stick being installed.The only known workaround is to unplug all physical sticks, launch the game, then plug the physical sticks in.

Could anyone maybe help shed any light on why this may be happening, so we can maybe fix it?Unfortunately I cannot replicate the issue myself - apart from all sticks showing as "microsoft pc-joystick driver" everything works fine under win7.

We have a discussion going on the vJoy forum here (http://vjoystick.sourceforge.net/site/index.php/forum/4-Help/452-windows-8-1-can-t-receive-buttons-axis?start=20#1138)

Part of the problem of course is that all the sticks are named the same in wxLauncher, so we do not know which one *should* be vjoy. We think it is entry #1 as when that option is selected, none of the physical sticks work.I take it that the pertinent code is here (https://code.google.com/p/wxlauncher/source/browse/code/apis/JoystickManager.cpp)?It seems to me that if we could maybe improve the code in wxLauncher to actually name sticks correctly, or try to output the state a stick axis/button is in, then we could tell if the virtual stick was working according to wxLauncher. Shaul posted in our thread on how to find a stick's name correctly, so maybe that would be a good place to start.

I have recently had a user reporting issues with vJoy and Diaspora whereby the virtual stick is unusable (game binding routine does not recognize input) under win8 when the launcher is started with physical sticks plugged in as well as the virtual stick being installed.The only known workaround is to unplug all physical sticks, launch the game, then plug the physical sticks in.

Could anyone maybe help shed any light on why this may be happening, so we can maybe fix it?Unfortunately I cannot replicate the issue myself - apart from all sticks showing as "microsoft pc-joystick driver" everything works fine under win7.

We have a discussion going on the vJoy forum here (http://vjoystick.sourceforge.net/site/index.php/forum/4-Help/452-windows-8-1-can-t-receive-buttons-axis?start=20#1138)

In response to Shaul, yes the wxLauncher handling of joysticks is quite inflexible, though that is primarily because fs2_open is worse at handling it. wxLauncher follows more or less what the engine does.

Part of the problem of course is that all the sticks are named the same in wxLauncher, so we do not know which one *should* be vjoy. We think it is entry #1 as when that option is selected, none of the physical sticks work.I take it that the pertinent code is here (https://code.google.com/p/wxlauncher/source/browse/code/apis/JoystickManager.cpp)?It seems to me that if we could maybe improve the code in wxLauncher to actually name sticks correctly, or try to output the state a stick axis/button is in, then we could tell if the virtual stick was working according to wxLauncher. Shaul posted in our thread on how to find a stick's name correctly, so maybe that would be a good place to start.

Cheers.

You have found the correct location for the wxLauncher code. The code for fs2_open and how it detects joysticks is in joy.cpp as found here (http://svn.icculus.org/fs2open/trunk/fs2_open/code/io/).

So, after falling down that rabbit hole, here (https://app.box.com/s/krei70myt4jalexrq7pq) is a debug installer for wxLauncher that names the joysticks as per the riseofflight forum post (http://riseofflight.com/Forum/viewtopic.php?f=353&t=24560&hilit=joystick+IDs).

To diagnose the issue further, the user will need to post a wxLauncher.log using the debug build of wxLauncher I linked above (details for how to find the log are in the OP) and an improved fs2_open.log from the engine using the debug_filter.cfg attached to this post (details are on how to do this are found here in the support FAQ (http://www.hard-light.net/forums/index.php?topic=56279.msg1180359#msg1180359)).

@chief1983: wxLauncher always lists the sticks as they were identified by windows. They are not sorted by name.

@evilc: I would post this on other forum but I am still getting "CAPTCHA is not properly configured (public key is missing). Please contact site administrator!" when ever I try to post something. And now even from a different computer I still get the same message.

@foxfire: run Diaspora as I requested with the debug_filter.cfg and post the wxLauncher log and the fs2_open.log from both tests. When debug_filter.cfg is installed correctly the fs2_open.log contains much more useful information about the joystick than what is presented in the default log. Same goes for the wxLauncher.log it contains diagnostic information that will help us diagnose the issue. You should be posting 4 logs total.

@shaul: you are correct the engine locates the sticks using the win32 multimedia api and assumes that the order as enumerated there does not change except when a brand new stick is connected that was never connected before. My testing with 3 (physical) joysticks seems to be the case. This code has not changed since the engine was written for Freespace 1 in 1997-98. It will be at some point replaced with a better SDL based code but that has not happened yet.

@evilc: I would post this on other forum but I am still getting "CAPTCHA is not properly configured (public key is missing). Please contact site administrator!" when ever I try to post something. And now even from a different computer I still get the same message.

I know Shaul made some changes to the CAPTCHA setup the other day - I will let him know that there are issues.

Hello, I am having an issue with the launcher freezing as soon as I selet an FS2 executable. I put the details here: http://www.hard-light.net/forums/index.php?topic=87720.0Any suggestions would be appreciated.

Might be thinking of -voicer, the voice recognition flag that is only on Windows. There is no *nix code for voice recognition yet, except a patch in Mantis for OS X that utilizes an Apple-only API, which still doesn't help Linux. The Text to Speech flag is -speech which is also Windows-only.

Might be thinking of -voicer, the voice recognition flag that is only on Windows. There is no *nix code for voice recognition yet, except a patch in Mantis for OS X that utilizes an Apple-only API, which still doesn't help Linux. The Text to Speech flag is -speech which is also Windows-only.

After many months on using launcher5.5 I wanted to give this one a try. It has a feature that can make my life very easier, I mean the profiles stuff. I thought I could set my own tweaks for each and every mods I use and just select them instead of remembering every values I put in custom flags or filing my desktop with batch scripts. Can wxlauncher do it for me? Sounds like good news. But Jeez What a hard fight I had to make it work with my joystick! At first it was detected but It could not work once in fs2. Also my sound card did not show up in launcher but I did have sound and music. This felt so insane.

I ended up with trying debug version of both launcher and game and guess what? it came to work! Like some kind of magic I'm afraid I'll never get to understand, which is too bad because I don't know how long it will run ok. And then I tried again with normal build of fs2 and it ran ok too, it still does as I'm writing these lines.

Everything's fine for now and I'm finally able to enjoy selecting a profile and I'm ready to blow some zods up!So I wanted to thank you for your good work and also I have one last question:Can I stay with debug version of wxlauncher because I don't want to screw it all up by reinstalling normal version?

Maybe you'd like to hear about this weird behaviour of wxlauncher I caught up lately, so I post it here. Please redirect me if necessary.I wanted to use the [recommendedlighting] section of mod.ini file so I put this at the end of the file:

[recommendedlighting]name = Jack's setupflagset = -ambient_factor 100 -spec_exp 0.7 -spec_tube 1.0Then in wxlauncher interface I could see my new preset line replacing the other one (baseline recommended) and when i selected it new settings appeared in "current command line" box.

But when I ran the game after this settings I could see no change in lightings. I know it could be very subtle changes at times so I dig further in this and I found out that cmdline_fso.cfg did not reflect my changes. Instead it had:

-ambient_factor 75 -spec_exp 11 -spec_tube 0.4

which are the exact settings you get when not using that mod.ini section! (or if one checks baseline recommended preset line)To get it to work I had to copy my settings to custom flags box after choosing it in preset list (which automatically checks "Preset off"). This obviously makes mod.ini section useless, but I did get the good options in cmdline_fso.cfg and I could see changes in game too.Hope this does not look like too confused explanations, I wish I could fix it by myself, but I can't :(

Maybe you'd like to hear about this weird behaviour of wxlauncher I caught up lately, so I post it here. Please redirect me if necessary.I wanted to use the [recommendedlighting] section of mod.ini file so I put this at the end of the file:

[recommendedlighting]name = Jack's setupflagset = -ambient_factor 100 -spec_exp 0.7 -spec_tube 1.0Then in wxlauncher interface I could see my new preset line replacing the other one (baseline recommended) and when i selected it new settings appeared in "current command line" box.

But when I ran the game after this settings I could see no change in lightings. I know it could be very subtle changes at times so I dig further in this and I found out that cmdline_fso.cfg did not reflect my changes. Instead it had:

-ambient_factor 75 -spec_exp 11 -spec_tube 0.4

which are the exact settings you get when not using that mod.ini section! (or if one checks baseline recommended preset line)To get it to work I had to copy my settings to custom flags box after choosing it in preset list (which automatically checks "Preset off"). This obviously makes mod.ini section useless, but I did get the good options in cmdline_fso.cfg and I could see changes in game too.Hope this does not look like too confused explanations, I wish I could fix it by myself, but I can't :(

:v: A+Jack H.

Hello Jack

To clarify, after selecting the new lighting settings did you press the the "play" button to start FSO or did you run the FSO binary directly?

I clicked play after I modified the settings, indeed I always start the game this way, I mean from wxlauncher, but I only save when I'm satisfied with the settings. As a matter of fact I noticed that when play button is clicked then the cmdline_fso.cfg file is updated just before game launches. And from what I understand it contains options used also if you start the .exe directly. Is this correct?

So I wonder if it's really necessary to activate autosave, but I'll try it as soon as I get back home. :v: A+Jack H.

I clicked play after I modified the settings, indeed I always start the game this way, I mean from wxlauncher, but I only save when I'm satisfied with the settings. As a matter of fact I noticed that when play button is clicked then the cmdline_fso.cfg file is updated just before game launches. And from what I understand it contains options used also if you start the .exe directly. Is this correct?

So I wonder if it's really necessary to activate autosave, but I'll try it as soon as I get back home. :v: A+Jack H.

That is correct. It sounds like you are doing everything to correctly. I will have to look in to this issue when I have a chance and see if I can reproduce.

I tried to auto save but to no avail, I was sure it wouldn't help anyway. I hope you can reproduce it and see what happens because I really like this new launcher, it is a true evolution compared to the other launcher5.5. With this one I'm 2 or 3 clicks away from any mods or TC, each with its own combination of settings. I feel like it'll be the only one in the future although launcher5.5 is still pretty stable.

I tried to auto save but to no avail, I was sure it wouldn't help anyway. I hope you can reproduce it and see what happens because I really like this new launcher, it is a true evolution compared to the other launcher5.5. With this one I'm 2 or 3 clicks away from any mods or TC, each with its own combination of settings. I feel like it'll be the only one in the future although launcher5.5 is still pretty stable.

thx for your help on this. :v: A+Jack H.

Hello Jack,

I cannot reproduce the issue. Can you please list step by step (including your editing of the mod.ini) of how to reproduce this issue? Please attempt to reproduce the issue using a debug build (see the "Troubleshooting" section of the first post). Please attach the log from an instance where the cmdline_fso.cfg does not get updated, their may be useful information about what is going wrong in their.

First session is Default: I selected the Default profile listed in first tab2nd session is nopreset: this one has my new profile and uses mod with no changes in mod.ini. preset selected is "baseline recommended"3rd session is preset: this one has my new profile too and uses modified mod.ini. preset is then selected in advanced tab4th session is customflag: this one has my new profile and uses modified mod.ini. lighting options are copied from preset to custom flag box

I can see the change in lighting only after running 4th session, please see all files in attachment. Just a word about OS: it's Win7 ultimate 64bits.Hope this helps

I'm afraid not, why would I do that anyway? ;7I can only say I modified the mod.ini because I used only this mod during testing, so I had to. I might have mistaken.

Quote

The 3rd session doesn't show "Jack's baseline" in the MediaVPs_2014 mod.ini until after you switch TC's to BRTL and then back.

Well I don't remember of this behaviour, what does BRTL stand for?hmm I seem to have failed this one, perhaps I forgot to add lighting section in mod.ini before I begin the test :banghead:I'll do session3 again and repost logs tonight, sorry I was too quick. Now I think I understand why you asked.

He probably meant BtRL, 'Beyond the Red Line', and may have been confused with Diaspora.

Yes, Beyond the Red Line. No, it was definitely BtRL because it was loading fs2_open_3.6.9.exe. On Jack's computer it is installed in "D:\Programmes\BtRL\" and is apparently called "Beyond the Red Light" by its mod.ini file @ D:\Programmes\BtRL\mod.ini.

The 3rd session doesn't show "Jack's baseline" in the MediaVPs_2014 mod.ini until after you switch TC's to BRTL and then back.

Well I don't remember of this behaviour, what does BRTL stand for?hmm I seem to have failed this one, perhaps I forgot to add lighting section in mod.ini before I begin the test :banghead:I'll do session3 again and repost logs tonight, sorry I was too quick. Now I think I understand why you asked.

:v: A+Jack H.

Thank you for your patience and thoroughness in the debugging of this issue.

yes it's BtRL and I modified the mod.ini there too.Here's the new log, I guess it doesn't need any more explanation, I just start wxlauncher, select my profile and mod (Advanced tab shows my preset ), start the game and get the same cmdline with Baseline recommended settings.I'm still impressed if one ever managed to get it working, it seems so straightforward. So I may not give up until it works on my computer too!

Yeah. Before I applied that patch, the compile process failed somewhere around the 2 or 4 % mark. Now it fails, as I said, at 57%. I forgot to give my build environment other than in general terms, though. OpenSuSE 13.2 64-bit, GCC 4.8, cmake 3.0.2 (no option to downgrade with this release of OpenSuSE), wxWidgets 2.8.12. Don't recall what else I might need for dependencies.

Might just try a vagrant machine (https://vagrantcloud.com/berendt/boxes/opensuse-13.2-x86_64). Or a VirtualBox Appliance (http://virtualboximages.com/openSUSE+13.2+x86_64+VirtualBox+VDI+Virtual+Computer). I've got FS2 Open compiling on the vagrant one already, updating the Wiki with an entry for OpenSuSE now under the Linux howto. I'll take a crack at wxLauncher if I get another break in the workload today, but no promises. Hectic times, we're building out our new production datacenter.

Ok, so far I've used zypper to install cmake, wxWidgets-devel, and python-Markdown. Everything else in the deps list was already installed by default or from the FS2 compiling environment. I was able to reproduce both mentioned compiling issues, the 4% one, which I patched from the linked issue, and then the current one (at 54% for me).

IssMneur, if you do get to running OpenSuSE, you should be able to follow the install commands in the FS2 Open for Linux documentation now, to get a compiling environment and the dev libs for FS2 Open, and then install the packages listed above to get the remaining deps for wxLauncher from the README.

Hi,I installed Windows on C: drive. I added D: drive afterwards because I needed more space and then I ended up installing non system related software on D: (like games). So you can assume only windows is on C: and everything else on D:

I have played FS2 Open quite a bit, and find it enjoyable.Recently, I got a new computer, and I wanted to reinstall FS2 Open to at least try to finish the FS2 campaign, and try some nice mods.

I've installed the Debian testing Jessie, which will be the Stable distribution in a few month. On the stock distribution, there are cmake 3.0.2 and libwxgtk 3.0 packaged. Although it's specified wxLauncher should use cmake 2.8, it works fine with cmake 3.0.On the other hand, the compilation failed with libwxgtk3.0, and it looks like I need the 2.8 version off the library.This one is not packaged in current Debian. I could always install package from Wheezy, but unless it is really necessary I would prefer to not manage package from an old version.

So, do you guys plane to make an update from libwxgtk2.8 to libwxgtk3.0 ?Or do you have any ideas to what could make it work with the last wxgtk library ?

Hey Iss Mneur, would you be interested in transferring ownership of the wxLauncher GitHub repo to the scp-fs2open organization? It should help us keep tabs on things and maybe also help attract more attention to wxL.

Unfortunately, I'm unable to run the new version. Installation works fine, but when I try to run wxLauncher, I get this error:

Quote

C:\Program Files (x86)\wxLauncher\bin\wxlauncher.exe

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe for more detail.

I tried using the debug build in hopes that it would generate a log, but it didn't. In fact, it doesn't seem to be writing anything to AppData. I also tried running it as an administrator with no luck.

Unfortunately, I'm unable to run the new version. Installation works fine, but when I try to run wxLauncher, I get this error:

Quote

C:\Program Files (x86)\wxLauncher\bin\wxlauncher.exe

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe for more detail.

I tried using the debug build in hopes that it would generate a log, but it didn't. In fact, it doesn't seem to be writing anything to AppData. I also tried running it as an administrator with no luck.

Fix versions of both the release and debug installer have been uploaded in the place of the previous, so the URLs have not changed. Please redownload it and try it now. The installer should prompt about removing the same version.

In the end it was incorrect CRTs but for multiple reasons. It seems that the new build script was not actually swtiching between debug and release, it was only makeing release builds. So, the the release and the debug version were identical, which explains why the release version had the debug CRTs. In addition, it was linking against both VC9's Debug CRT and VC9 SP1's Debug CRT, but the installer only includes VC9 SP1's Debug CRT, which was what was actually causing the SxS error.

Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Software\Volition\Freespace2Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Volition\FreeSpace2The former appears to have been written by wxLauncher; the latter is the one FSO seems to use.

Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Software\Volition\Freespace2Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Volition\FreeSpace2The former appears to have been written by wxLauncher; the latter is the one FSO seems to use.

Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Software\Volition\Freespace2Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Volition\FreeSpace2The former appears to have been written by wxLauncher; the latter is the one FSO seems to use.

So, on Windows, it doesn't generally obey resolution settings anymore. I can say "Run in a Window" at 1280x800 and it will instead run the window at 1024x768 no matter what. Same for "Full Screen Window".

Also, this version of wxL somehow causes my screen resolutions to jump all over the place when FSO is started. This makes my multimonitor windows jump all over the place. I reverted back to what I had before 0.9.4 and these issues are not present. Basically it seems that at least the Windows version has issues properly setting resolutions.

So, on Windows, it doesn't generally obey resolution settings anymore. I can say "Run in a Window" at 1280x800 and it will instead run the window at 1024x768 no matter what. Same for "Full Screen Window".

Also, this version of wxL somehow causes my screen resolutions to jump all over the place when FSO is started. This makes my multimonitor windows jump all over the place. I reverted back to what I had before 0.9.4 and these issues are not present. Basically it seems that at least the Windows version has issues properly setting resolutions.

Do you still have this problem with 0.10.1 ( released today)? What about 0.9.6, which can be found on the releases page on github?

Hmm, my mistake. AdmiralRalwood suggested I double check 10.1 again in case I was accidentally on 10.0. I thought I was on 10.1, but clearly not because these issues are not present on testing 10.1 this time.

Hmm, my mistake. AdmiralRalwood suggested I double check 10.1 again in case I was accidentally on 10.0. I thought I was on 10.1, but clearly not because these issues are not present on testing 10.1 this time.

Good to hear. What you were reporting what what the fix for 0.10.1 would have affected the most.

Also, this version of wxL somehow causes my screen resolutions to jump all over the place when FSO is started. This makes my multimonitor windows jump all over the place. I reverted back to what I had before 0.9.4 and these issues are not present. Basically it seems that at least the Windows version has issues properly setting resolutions.

Also, this version of wxL somehow causes my screen resolutions to jump all over the place when FSO is started. This makes my multimonitor windows jump all over the place. I reverted back to what I had before 0.9.4 and these issues are not present. Basically it seems that at least the Windows version has issues properly setting resolutions.

Please dear all that is holy can we get these settings out of the damned registry? (I know, that's not a wxL thing).

I had a patch for that at some point and I also have a PR that adds support for using SDL to determine where to save configuration files which is required for the configuration file changes.The configuration path changes are ready to be merged and I'll see what I can do about the configuration file on windows but I currently don't have a Windows install so that might take a while.

Step 2. Open regedit (Windows-R, enter "regedit", press return)Go to HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\You should have a key named "Volition" there.

Step 3. Right-click on it, and select "Permissions".When I did this, the "Group or user names" field was blank. If it is, click "Add".In the dialogue that now pops up, Enter "ALL APPLICATION PACKAGES" into the "Enter the object names" field.Click OK. The dialogue should now be populated.

Step 4. Go to the FreeSpace2 subkey under the Volition entry. Check permissions as above, and if necessary, fix as above.

Minimize wxL causes the bottom info bar to cover the buttons. While it looks like you can press the buttons in those images, you can't... because they are "covered" by the info bar. You can to press on the very tip top edge of the FRED/FSO buttons.

Minimize wxL causes the bottom info bar to cover the buttons. While it looks like you can press the buttons in those images, you can't... because they are "covered" by the info bar. You can to press on the very tip top edge of the FRED/FSO buttons.

That's not happening on my Windows 7 64-bit SP1 system. Maybe it only happens on newer versions of Windows.

Minimize wxL causes the bottom info bar to cover the buttons. While it looks like you can press the buttons in those images, you can't... because they are "covered" by the info bar. You can to press on the very tip top edge of the FRED/FSO buttons.

That's not happening on my Windows 7 64-bit SP1 system. Maybe it only happens on newer versions of Windows.

Happened on my install of Windows 7 forever. I just put up with it. Suppose I'll be putting up with it indefinitely if no one else can reproduce it.

Minimize wxL causes the bottom info bar to cover the buttons. While it looks like you can press the buttons in those images, you can't... because they are "covered" by the info bar. You can to press on the very tip top edge of the FRED/FSO buttons.

That's not happening on my Windows 7 64-bit SP1 system. Maybe it only happens on newer versions of Windows.

Happened on my install of Windows 7 forever. I just put up with it. Suppose I'll be putting up with it indefinitely if no one else can reproduce it.

Doesn't happen to me on my Win10-64 install, and I don't recall it ever happening on my old Win7-64 install. Might be related to multiple monitors?

Minimize wxL causes the bottom info bar to cover the buttons. While it looks like you can press the buttons in those images, you can't... because they are "covered" by the info bar. You can to press on the very tip top edge of the FRED/FSO buttons.

That's not happening on my Windows 7 64-bit SP1 system. Maybe it only happens on newer versions of Windows.

Happened on my install of Windows 7 forever. I just put up with it. Suppose I'll be putting up with it indefinitely if no one else can reproduce it.

Doesn't happen to me on my Win10-64 install, and I don't recall it ever happening on my old Win7-64 install. Might be related to multiple monitors?

*Tests theory.

Yup. I installed wxL on my old computer that is now a single monitor machine. The problem does not occur.

Can you try an older release (e.g. 0.9.6 (https://github.com/scp-fs2open/wxLauncher/releases/tag/release-0.9.6)) and tell us if that release works? I changed how the registry was accessed but that code was written for Windows 7 so it's possible that it won't work with Windows 8 or 10.

Ha! I thought I'd run into this before (http://www.hard-light.net/forums/index.php?topic=89162.msg1784873#msg1784873). For some reason the mod.ini files for ASW1 & ASW2 also have a colon in their settings section:

Ha! I thought I'd run into this before (http://www.hard-light.net/forums/index.php?topic=89162.msg1784873#msg1784873). For some reason the mod.ini files for ASW1 & ASW2 also have a colon in their settings section:

Are you sure that field actually works? Because I tried it myself and it didn't do anything. I even looked at the source code for wxLauncher and the old Windows launcher; as far as I can tell, wxLauncher has zero support for it, whereas the Windows launcher has code for parsing it that's commented out.

Correct, it doesn't do anything and as already noted, as far as I can tell, there is no indication of what it is supposed to even do. Some examples I have seen are used sort of like the flagsets feature of wxLauncher.

However, the actual problem is the format is incorrect. It is should it should be

[settings]flags= -ship_choice_3d;The win32 launcher doesn't care so I need to "fix" wxLauncher not to either, but that hasn't happened yet. Though if a mod is being distributed with the above setting...

Correct, it doesn't do anything and as already noted, as far as I can tell, there is no indication of what it is supposed to even do. Some examples I have seen are used sort of like the flagsets feature of wxLauncher.

I'm pretty sure it's supposed to specify which flags are always supposed to be enabled, regardless of the user's settings. For instance, in the example given, the -ship_choice_3d flag is supposed to be enabled, even if the user has not enabled it.

EDIT: Here's the comment of SVN revision 5199 (http://svn.icculus.org/fs2open?view=rev&revision=5199), which commented out the code that loads this field (emphasis is mine):

Quote

massive conversion of old hackish ini bookkeeping to new encapsulated bookkeepingnobody try to run this yet; it's not debugged and doesn't even compile

(The commented-out code is in CTabMOD::GetSettings in TabMOD.cpp, in case you want to look.)

Judging from that comment, I'm now quite sure that this was used to store user settings, not mandatory settings. If this is true, then wxLauncher should definitely ignore this field as it does now.

Right. In the old Launcher 5.5, the top section contained the mod-provided flags and the bottom section contained the user-customized flags. It wasn't implemented very well though, and that commit was the beginning of an attempt to code an alternate system.

Since wxLauncher has its own system of storing user preferences, it should* ignore that field entirely, as you said.

*Actually, I can think of an exception. If a project published the mod developer's own mod.ini file, there is a chance that the mod's recommended flags would be incorrectly specified in the user preferences section.

If by "top section" and "bottom section" you mean the [launcher] and [settings] sections respectively, then I'm pretty sure that only the [settings] section stored flags; I don't see any part of TabMOD.cpp, before or after that commit, that tries to read a "flags" field from anywhere other than the [settings] section.

EDIT: If it's normally displayed as info on the bottom, I can't see it because I have an info tip about Windows reporting 0 joysticks and 0 being plugged in.

EDIT2: I noticed, upon opening, wxLauncher displays like 3 messages in the bottom info section, which are each quickly replaced with the next message, and no way to view a message log of what was displayed. Not sure if that is intended behavior or not.

EDIT: If it's normally displayed as info on the bottom, I can't see it because I have an info tip about Windows reporting 0 joysticks and 0 being plugged in.

EDIT2: I noticed, upon opening, wxLauncher displays like 3 messages in the bottom info section, which are each quickly replaced with the next message, and no way to view a message log of what was displayed. Not sure if that is intended behavior or not.

There is/was a button on the bottom left labeled about. But I don't remember if it is still there it was removed. I will have to look tonight.

WTF? I just tried it again with a clean system (I needed to reinstall because of my own stupidity) and now it worked out of the box. I'm fairly certain that I used 0.10.1 both times and both times it was a clean install of Windows 10.I guess that's just another reason to use a config file on all platforms. The current way of writing to the registry probably isn't very robust anyway.

well i have the screen resolution problem. i fix using the custom flag -res 1920x1080

-resAllows you to specify a resolution if the desired one cannot be set in the Launcher. For example, -res 1920x1080 would run the game in 1920 x 1080 resolution. Since it requires an argument, it needs to be entered as a custom flag when using the Launcher. The "Run at specified resolution" option the Launcher gives is essentially this, but without being able to actually specify a resolution, it doesn't work.

What version of FSO are you using? 3.7.4 RC2 should have a fix for this bug by enabling the "Use a different registry path" option in the launcher. I don't know why but sometimes the Windows registry just doesn't work anymore for FSO. It will be properly fixed after the 3.7.4 release when a new configuration system will be used that doesn't rely on the registry anymore.

Yes, it's probably cause by the registry virtualization but for some time it worked on my Windows 10 install but then it suddenly stopped working without a clear reason. Well, it doesn't really matter that much. For the 3.7.4 release there is the troubleshooting option and for future releases the new config system should fix all these issues.

What version of FSO are you using? 3.7.4 RC2 should have a fix for this bug by enabling the "Use a different registry path" option in the launcher. I don't know why but sometimes the Windows registry just doesn't work anymore for FSO. It will be properly fixed after the 3.7.4 release when a new configuration system will be used that doesn't rely on the registry anymore.

That's why I added the troubleshooting option so the people who have this problem can fix it. Fixing it properly would not be worthwhile since Antipodes has the new file based config system which will fix this issue.

Here (https://github.com/scp-fs2open/fs2open.github.com/blob/master/code/osapi/osregistry.cpp#L114) is the code but basically the option enables a behavior where FSO tries to determine the compatibility registry path typically used by Windows for older applications instead of relying on the registry virtualization that Windows uses for the paths FSO typically accesses.

...does Windows allow direct access to this, or does it attempt to block direct modification of the compatibility reg path? MS might block it to try to deter people from relying on legacy settings instead of updating their programs to use user profile specific (instead of machine-wide) reg paths.

It worked on my machine for quite a long time with both Windows 7 and Windows 10 but now it suddenly stopped. The problem isn't that reading the compatibility path fails but that reading the "old" path fails.

Ok, wxLauncher SERIOUSLY needs a way to distinguish between game controllers in Windows. Doesn't matter if it's a Logitech Wingman Extreme 3D Pro or a Madcatz Xbox 360 controller, all it says is Microsoft PC-joystick driver. ARGH! I should not have to switch out game controllers completely to avoid hassle with figuring out which one is the stick and which the gamepad.

:nervous: Well, that problem has already been "fixed" for antipodes/SDL2 builds but the old builds require using the old API which is currently broken. Antipodes should be merged soonTM so then that issue will be fixed for most users...

Well that's good. I mean, I knew which one it had to be because of the order they had been plugged in, but if I leave them plugged in and I reboot, who knows which will initialize first? I look forward to the upcoming code merge and fixed behavior.

No, keep the newer version.What I meant was that if you have 0.10.1 installed and if you are only using 3.7.4 then you don't need to change that. However, due to changes in how FSO interacts with the launcher the recent nightlies require 0.11 in order to work correctly.

As I understand it, the latest 'official' wxlauncher version is 0.11. However, there is also work being done on "release candidates" for version 0.12; when 0.12 gets finalized and official, will it be announced here in this thread and put in the opening post list?

The latest official release is 0.10.1, which is the one that you should use. When a new official release is made the OP will be updated and a new post added (so feel free to turn on notify for this thread).

Great question. Unfortunately only Iss Mneur would know for sure, and he hasn't been around in over two weeks. :blah:

From what I remember, he was working on refactoring the third-party dependencies like OpenAL/SDL into a Git submodule. However, that shouldn't be required for 0.12.0.

Offhand I can't think of anything else that needed to be done other than probably more testing. The best way to accomplish that most likely is to release a new wxL RC on all platforms and get it in people's hands with the 3.8 RCs/nightlies. As always, I can help with macOS releases. Currently there is no public macOS release of wxL that can run the 3.8 RCs or nightlies.

This is probably a must-fix (http://www.hard-light.net/forums/index.php?topic=93352.msg1845475#msg1845475) since it could shut out a lot of potential joystick users who would stop by for such a major release.

wxLauncher (at least the most recent version) already uses the same SDL2 APIs that FSO uses.The wxLauncher code does it in the JoystickManager (https://github.com/scp-fs2open/wxLauncher/blob/master/code/apis/JoystickManager.cpp#L363) file and FSO does it in joy-sdl.cpp (https://github.com/scp-fs2open/fs2open.github.com/blob/master/code/io/joy-sdl.cpp#L78).

wxL itself never manually sets the GUID to zero (that is, a long string of zeroes). It sets the GUID to an empty string on error, which will cause FSO to ignore the GUID entirely AFAICT.

AFAICT the only case where the GUID gets set to 0 is in SDL itself, from the SDL wiki page (https://wiki.libsdl.org/SDL_JoystickGetGUID):

Quote

Return Value

Returns the GUID of the given joystick. If called on an invalid index, this function returns a zero GUID; call SDL_GetError() for more information.

Therefore wxL may be specifying the wrong index when getting the joystick GUID for XInput devices? That's one thought. I need to compare more carefully to the FSO SDL joystick code. That's what I have so far.

EDIT: Wait that doesn't make sense. wxL is passing in an SDL_Joystick* (and not an array index) when getting the GUID. I wonder if something is wrong with the version of SDL2.dll that ships with wxL?

Firstly, sorry about the timeframe on this. New house and new job and bull**** from the previous job have not been leaving any time for wxLauncher. But lets see what I can do this week.

Well, I have been integrating SDL 2.0.5 in all of my builds since October.

As for the 360 controller, I have an XBox One controller and I end up with a null GUID with it as well. I have tried tinkering with it and there are no errors being reported by SDL, it seems that SDL doesn't see anything wrong. Maybe it is how I am compiling the SDL2.dll.

I seem to recall the hold up on releasing 0.12 RC3 was getting a build that would actually work on macOS. It has been a while since I was fiddling with it, but iirc it was something to do with wxWidgets.

Are you compiling the SDL2.dll, or compiling _against_ the SDL2.dll headers? Because I'm pretty sure on Windows everyone should be using the officially provided SDL2.dll binaries for consistency. I think someone even stated that using the SDL2.dll from FSO (the official dll) seems to have fixed the problem?

Also, I have been using a working 0.12.0 rc3 build on Mac for quite a while. There are some wx issues but it is usable. Mostly you can't Cmd+Q to close it, have to click the red close button I think. But it has at least been stable for me, not once lately I can even remember an actual crash.

Probably going to release 3.8.0 RC2 really soon (probably tomorrow now that we got the TrackIR dll thing sorted out), if this is available by then I can try to update the release post template to include a new link.

Is this launcher compatible with 3_8_0? It refuses to launch at all when using 3_8_0. Older versions seem to work fine.

3.8.0 RC1 will not work properly with wxLauncher 0.10.1. You might have better luck with a recent nightly build (http://www.hard-light.net/forums/index.php?board=173.0); if that doesn't work, you'll need a newer version of wxLauncher (https://github.com/scp-fs2open/wxLauncher/releases).

I'm having a couple issues with wxL 0.12.0.1. It doesn't show the screencam script in the list of mods.2. The help just says "None" over and over.Neither of these problems are present in Diaspora's launcher.

I'm having a couple issues with wxL 0.12.0.1. It doesn't show the screencam script in the list of mods.2. The help just says "None" over and over.Neither of these problems are present in Diaspora's launcher.

Have you tried this? wxlauncher-0.12.0-rc.2.exe (https://github.com/scp-fs2open/wxLauncher/releases/download/0.12.0-rc.2/wxlauncher-0.12.0-rc.2.exe)

I wanted to ask: if it's OK I replace the SDL2.dll 2.0.3 file in wxLauncher with the one in FSO 2.0.4?

I wanted to ask: if it's OK I replace the SDL2.dll 2.0.3 file in wxLauncher with the one in FSO 2.0.4?

Replacing the DLL is fine (and, with 0.12, fixes the bug where xinput gamepads can't be selected), but be careful: if you use the 64-bit version of FSO, its SDL2 DLL is also 64-bit, and cannot be used with 32-bit wxLauncher.

Have you tried this? wxlauncher-0.12.0-rc.2.exe (https://github.com/scp-fs2open/wxLauncher/releases/download/0.12.0-rc.2/wxlauncher-0.12.0-rc.2.exe)

I am using that version.I figured out the Screencam script problem; it needs to be added as a dependency in the desired mod.ini.As for the help file, I tried compiling it myself and the issue isn't there, so I'm not sure what the problem is with the released binary.

Thank you AdmiralRalwood and chief1983, will download SDL2.dll 2.0.4. But what about 2.0.5? If I replace both SDL2.dll with it with the correct bitage would it work better or is irrelephant?PIe then open a Mantis