[feature] Store profiles in user's home directory

[MathijsG]

I always put the new files of your software in the folder of the current folder and replace every file. Normally the settings were intact, but now every profile is gone and only the default profile shows up. Is this by design or is this a bug somehow? By the way wouldn't it be better if the settings were put in the userfolder instead of writing settings in the regular install location?

[sthalik]

The software doesn't delete files on its own. We should default to Documents/opentrack-VERSION but it's not a bug.

[MathijsG]

But I only replaced the newer files, or did I accidentally overwrite the settings with that? Because always when I load up settings for your program within your program, I see files which I don't see when I manually browse to that location. How and where are the profiles organized?

[sthalik]

The full pathname to the used profile is stored in registry. Other settings are loaded that are in the same directory.

You probably have an issue with file/directory permissions.

We should definitely store in hardcoded document location, replace "open" with "copy" and allow for opening that directory from the main UI.

[sthalik]

What can we do about portable installations then? Look for is-portable.txt and then force the directory to be "install/settings/" instead of user's documents path?

[MathijsG]

Yeah maybe? Don't know how many use it portable when the app has a real installer.

[sthalik]

We still need to refresh the config list automagically.

[sthalik]

Done, awaiting feedback

[Len62]

I noticed that on the mapping screen, in RC17, that Yaw and Pitch default to Asymetric being checked. If I uncheck them the info is not being saved, when I stop and re-start they default back to them being checked. Not sure if this info is in the config file or not. Also, no option to save current profile - I assume it is now done automatically?

[sthalik]

I'm working on fixing the bug.

Does the first of your profiles contain asymmetric yaw and pitch? It's getting pulled from somewhere.

[Len62]

I think they were. Forgot I had set them in that profile. But, in RC17, if I uncheck them the change is not being saved. I'm not sure how the auto-save works. If I load the default.ini and makes some changes they are automatically written to the ini file, effectively modifying the default settings? If that is the case wouldn't it be better to be able to load an ini, modify it, and then do a save as to preserve the original ini file settings? I may be missing something here...

[Len62]

Okay, started from scratch w/RC17 using the default.ini file. During the course of setting opentrack up the default.ini file was modified automatically each time I made a change. To me, a default file should not be modified, it should exist soley as a baseline and to return the program to default settings. Tracking is smooth as silk using a PS3 eye cam. I have noticed that when I return my view to the center that my view in the game, IL2 BOS, stays slightly off-center, both in yaw and pitch, roll is disabled. I've tried adjusting the mapping dead-zone, and the rotation dead-zone and sensitivity w/o any luck. Any thoughts? Also just noticed that after exiting and re-starting the default.ini is loaded and my settings are intact except it defaults the tracker to aruco.

[sthalik]

@Len62 I've run into the config issues as well. Please check rc17p1 if they still occur.

As for default non-empty config we have no notion of immutable empty configs for now.

For the off-center thing you might have a filtering deadzone set. Try reducing it.

[Len62]

RC17p1 config issues are all working OK. Thanks! Not sure how I fixed the off-center issue but I think it may have been a setting in the game config.

[sthalik]

Great to hear that. Thanks!

[sthalik]

Are there any more issues remaining, guys?

[Len62]

I don't have any.

[nanospork]

I seem to be having some kind of config write issue, ONLY in the test build you sent me, sthalik. First I start tracking, then stop. I then go to select a different input/protocol/filter (not change their sub-settings). When I press "Start" again, the protocol or filter will reset to the previous selection. Restarting the program will usually allow me to select a new input/protocol/filter, but even that is somewhat inconsistent.

This doesn't seem to happen in rc17p2, but I believe the test build is newer (rc17p2-8-g22bde7a) so I thought you should know this issue was showing up. It's very minor as those settings are hardly changed after initially setting up a profile, so it really isn't hurting anyone. It might not even be reproducible in the most current build, but I wanted to let you know anyway.

[sthalik]

Yes, I've run into the same issue. Here's the latest version though: https://www.dropbox.com/s/gzhdm9ooge875gg/opentrack-test-20150901.7z

Please confirm the issues are gone, and if there are other ones.

[nanospork]

Issue where it resets on pressing "Start" is fixed, but it now often resets when pressing "Stop."

[sthalik]

@nanospork it shouldn't. There's no "load settings" code in stop handler whatsoever.

Note that saving settings to a file on disk is delayed by five seconds from the last change. Is this the culprit? It should be changed then.

[sthalik]

Note that if changing settings isn't delayed, it might take up to half a second after every change to save the main ui's settings. There's visible lag and delay between switching trackers.

[sthalik]

I'll look into it regardless, but please confirm.

[nanospork]

Yes, it looks like if I wait 5 seconds the setting remains as it should. If I change a setting and then press "stop" within five seconds, it reverts. Perhaps "stop" is interrupting the save?

Also, by your description, seems like the 5 seconds is worth it to avoid the lag. So the behavior I'm experiencing is really a non-issue.

[sthalik]

It is an issue. It's a pretty serious bug actually. I can reproduce 'stop' bug.

[sthalik]

With the last commit It looks fixed. On stopping tracking, it's saved immediately if there is save timer pending. Thanks for finding this obscure case @nanospork.