Export to GitHub

wxlauncher - issue #64

Generated .ini file not used by game


Posted on Jul 21, 2011 by Grumpy Cat

What steps will reproduce the problem? 1. Compile wxLauncher from source 2. Run wxLauncher 3. Select joystick in the basic settings window (Logitech Attack 3 in my case) 4. Run game, and observe that joystick does not function.

What is the expected output? What do you see instead?

Upon further examination, ~/.fs2_open/fs2_open.ini does not have the correct CurrentJoystick set. It was set to 9999. Setting the joystick to 0 in the ini file resolved the problem.

What version of the wxLauncher are you using: Mercurial changeset: 547:ecc9ba2ee48e

What version of fs2_open: 3.6.12 Linux

What mods (and version, if known): N/A

What operating system and version: Ubuntu Linux 11.04 amd64

Please provide any additional information below.

I dug through the code a little bit. The problem is that it saves the .ini file to ~/.wxlauncher/pro00000.ini, but it doesn't inform fs2_open to use that file in any way. I would write a fix, but I'm not sure what the plan is there. It seems that writing to that location is the intended behaviour, but I'm not sure how to point the game at that profile directory.

Comment #1

Posted on Aug 5, 2011 by Swift Elephant

Comment deleted

Comment #2

Posted on Aug 5, 2011 by Swift Elephant

Comment deleted

Comment #3

Posted on Aug 5, 2011 by Swift Elephant

The .inis in ~/.wxlauncher are for wxLauncher's consumption only (they are internal data), they are not for FSO.

The launcher should be writing to ~/.fs2_open/fs2_open.ini (and /data/cmdline_fso.cfg for the flag stuff), which is where FSO will look for its settings.

Please compile the latest trunk version with

-DCMAKE_BUILD_TYPE=Debug [other options]

Then run the debug build (if you run the debug build from the build directory you will need '-DDEVELOPMENT_MODE=on' as well). Please attach or pastebin the resulting log file (found in .wxlauncher/wxLauncher.log).

Comment #4

Posted on Aug 27, 2011 by Happy Monkey

The debug log is quite silent about this issue, see attached.

To generate the log I did the following:

cmake -DUSE_OPENAL=1 -DCMAKE_BUILD_TYPE=Debug ../ make ./wxlauncher Set the screen resolution to 1024x768 exited

The pro00000.ini file has the updated resolution, the fs2_open.ini does not.

From a super-quick look in the code I'd have expected to see "Writing fs2_open.ini to %s" somewhere in the wxLauncher.log, but it isn't there...

(niffiwan)

Attachments

Comment #5

Posted on Aug 27, 2011 by Happy Monkey

I should add that the same happens with jg18's latest clone.

(niffiwan)

Attachments

Comment #6

Posted on Aug 29, 2011 by Grumpy Bear

wxLauncher does not write the current profile's settings to fs2_open.ini until you press the "Play" button. If it successfully writes fs2_open.ini, it then writes the statement "Writing fs2_open.ini to //fs2_open.ini" to wxLauncher.log if you are using a debug build. Does that information help?

Comment #7

Posted on Aug 29, 2011 by Swift Rabbit

Ah - partly user error then :-)

Having said that, I'm still having a different problem related to the fs2_open.ini file. It seems to have got stuck on a 640x480 screen size. I've changed the executable several times (between fs2_open_INF_mantis2467_d, fs2_open_INF_mantis2467_d & fs2_open_INF_mantis2467_d) and switched between 1680x1050, 1440x900 & 960x600 resolutions without it changing out of 640x480 (or something equally small).

Logs etc are attached.

Attachments

Comment #8

Posted on Aug 29, 2011 by Grumpy Bear

Thanks for your report.

640x480x16 is FSO's default values, which it uses when it has a problem processing fs2_open.ini. Another Linux user has also mentioned this issue. Try these steps:

(1) First, to make sure that an earlier change < http://code.google.com/r/jg18scp-osxalpha/source/detail?r=3b9f787dff272bfe754216374d74e368998fcf31 > didn't break fs2_open.ini writing on Linux, try applying the attached "reverse_3b9f787dff27.patch" to reverse the changes. The code fragment affected by the patch should (in theory) perform the same function before and after the patch.

To apply a patch, place it in the root directory of your wxL project, then type "hg patch --no-commit" while your working directory is your wxL project's root directory. To reverse the effects of a patch, type "hg revert --all" while your working directory is in your wxL project.

(2) Try applying the attached "use_play_button_to_write_config_only.patch", which makes the following change: when you press the Play button, wxL will write the fs2_open.ini and cmdline_fso.cfg files to disk and do nothing else. That will allow you to see what the version of fs2_open.ini given to FSO looks like. Note that wxL can't launch FSO if this patch is applied.

Let us know how this goes.

Thanks.

Attachments

Comment #9

Posted on Aug 29, 2011 by Grumpy Bear

Just to add, be sure to update to the latest version (type "hg pull; hg up" while your working directory is in your wxL project) before applying the patches.

Comment #10

Posted on Aug 29, 2011 by Grumpy Bear

Sudden flash of inspiration: I noticed that the first line of the copies of fs2_open.ini that you provided included the word "[Default]" at the top. Including this word at the top of fs2_open.ini was required on OS X; it might also be required on Linux. (Unfortunately, I can't verify it on my own, since I currently don't have a Linux setup capable of launching FSO.)

Therefore, try applying the attached "add_default_to_config_file.patch". Instructions for applying a patch are in Comment 8 above. Be sure to update to the latest version first ("hg pull; hg up") and revert any other patches you might have applied ("hg revert --all").

Thanks.

Attachments

Comment #11

Posted on Aug 29, 2011 by Grumpy Bear

Comment deleted

Comment #12

Posted on Aug 29, 2011 by Grumpy Bear

Just to note, you can apply multiple non-conflicting patches by including "--force" after "--no-commit" when you use "hg patch".

Comment #13

Posted on Aug 29, 2011 by Grumpy Bear

I have replicated the issue described in Comment 7 in Ubuntu Lucid (10.04) running in VMWare Fusion 3.1.3 in Mac OS X 10.6.8 and confirmed that applying the "add_default_to_config_file.patch" in Comment 10 fixes the issue. Please check whether applying that patch fixes the issue for you as well.

Comment #14

Posted on Aug 30, 2011 by Swift Rabbit

Thanks for the patches, they have resolved the issue for me.

I did the following: hg pull hg update hg patch add_default_to_config_file.patch --no-commit (build new version as per readme)

Comment #15

Posted on Aug 30, 2011 by Grumpy Bear

The patch has been committed. Thank you for your help with figuring out this issue.

Comment #16

Posted on Apr 22, 2012 by Grumpy Bear

This issue should have been fixed a while ago. Anyone who has this issue again can post here.

Status: Fixed

Labels:
Type-Defect Severity-Medium OpSys-Linux Milestone-Release0.9 Usability