Separation of user and configuration files

[Sneakpeek]

Hiya all - especially devs,

iff I could have one thing for the next update it would be: Separation of the files that are modified by Falcon and the other ones - the static ones.
It would be great if all files that are modified by the program would be placed in a folder that is clearly separated from the Falcon installation.
DCS for example uses the User Home Location for this purpose.

This would include config files, logbook, ini files, tac files and the whole never-ending list .

Maybe an “overlay” approach could help, where the program would seek and write the user folder first, the installation folder afterwards.

Background is, that this would make installations and updates much more convenient…

What do you think?

Cheers,
Sneakpeek

[BlueRaven]

+1 for this, it would be great for setting up backups too.

[Arty]

errr there is already a user folder. There is a backup solution in this forum, It must be in the hotlist, and I believe it’s mentioned in the manual how to…

[CobaltUK]

I do not see any problem or difficulty with how it is now.

[Red Dog]

indeed, it works as advertized and all relevant files are in the bms\config folder
just back up that one and you’re done
no need to have files all over the hard drives which imho is a real pain

[Sneakpeek]

Hi all, well - first off, thanks for the answers so far.
At least for me my question is only partially about backups.

It’s more about installations…

I’m currently working on a installer program that ensures my squadron members and I have the same installation. Obviously this is meant to avoid MP incompatibility problems and to minimize setup efforts.
The installation would include our current Theater and maybe our squadron skins and stuff.

The program has the ability to install, uninstall and update the installation.
Pretty much like the DCS updater.
Just run it, get a glass of Weed and you’re good to go. Of course each user has to do alter the Control and Graphics configuration.

Implementing the whole download, install and verify functionality was rather easy.
Now I have to find a user-friendly and convenient way to make sure that uninstallation and updates won’t delete or modify any of the user-modified files.
One solution of course is to define which files are to be protected from being deleted or overwritten by performing a backup before uninstallation and by excluding them from the list of files that are to be updated.

While working on it, I found out, that there are more files worthy to protect than I first thought.
It’s not only the “Config”-folder (with the holy logbook-file ). You might have Screenshots, ACMIs, Campaign Saves, TE’s and so on.

As outlined above: There is a solution to it and some files are more worthy to protect than others.
Anyway, my use case would be more convenient to implement if the files would be separated DCS-style.
Just run the installer - in most cases there should be no need to alter the configuration afterwards…
Apart from that - in case of a broken configuration - just delete that separate folder and reboot. There would be no risk to ruin your installation.

I hope it makes more sense to you now…

no need to have files all over the hard drives which imho is a real pain

Usually I would agree to this one … I don’t like scattering files all about the disk either, but in this case it might help. Of course there might be other ideas…

Cheers,
Sneakpeek

[Eagle-Eye]

@Sneakpeek:

Usually I would agree to this one … I don’t like scattering files all about the disk either, but in this case it might help. Of course there might be other ideas…

Having files scattered all over the HDD can be a real pain in the ***, but if you know what you’re doing on a computer, they can be found. Not everyone is as tech-savvy, however, so if they were to be split up, it would probably be better to split them up inside the BMS/Config folder itself.

E.g.
BMS/Config/Controls/ (anything related to joystick, keyfiles, …)
BMS/Config/Graphics/ (dx9display, Window configurations, …)
BMS/Config/User/ (MFD preferences, logbook, …)
…

That being said, though, I don’t think it’s really necessary to start dividing in further subgroups, because it just clutters things, and it might not always be clear which file to place in which folder. It would be a lot easier if you just made a text-file somewhere containing a list of the files you need to backup. As a good start, check page 17 of the BMS-manual.pdf. (3.2.2 Restoring 4.32 Files, and 3.2.3 Restoring 4.33 Files)

[Dee-Jay]

Agree … it could be nice to have all the Users file in one place like Eagle-Eye example above

x:\Falcon BMS 4.xx\User\Miscellaneous\ (all files which are not supposed to saved)
x:\Falcon BMS 4.xx\User\Controls\ (anything related to joystick, keyfiles, …)
x:\Falcon BMS 4.xx\User\Config\ (dx9display, Window configurations, …)
x:\Falcon BMS 4.xx\User\Logbook\ (logbooks)
x:\Falcon BMS 4.xx\User\DTC\ (MFD preferences, DTC files)

… And in Campaign folder, saving missions into in created folders using saving name.

Just an idea :

x:\Falcon BMS 4.xx\Data\Campaign\CampaingData (with all non user files)
x:\Falcon BMS 4.xx\Data\Campaign\WeaponsPreset (weapon standard and user preset saves)
x:\Falcon BMS 4.xx\Data\Campaign_mission save folders_ (created when saving a mission with all mission files inside)

This would avoid to have everything spread everywhere in one single folder.

[MorteSil]

This post is deleted!

[CobaltUK]

Why would an un-installation touch/remove files not listed as installed by the program ? Would the program not auto backup the pre existing folder. Config is minute and User not exactly large.

[Arty]

There are more important areas that the community needs developers than the backup procedure.
I’m not saying that this is not important but theater development tools would benefit the whole community a lot more.
Just my personal prio.
Sure whatever anyone is doing for the community that will make our life easier is more than welcomed and we all are more than thankful that still ppl exist contributing on every aspect they can and will.

Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk

[Frederf]

The shift in architecture for seperated program and user files is how all modern programs are made. The theory is that there program files do not contain any user data. There are an unlimited number of potential users on an OS which should not at all be allowed to access or edit the data of another user.

The correct way to build a program today is that the contents of C:\Program Files\MyProgram contains no information or change of any kind by the user. You shouldn’t even be able to tell that another user has ever run the program by looking in this folder. It’s just the machine to process data, not to store it.

This method of organization is independent of how the uninstaller treats saved data. You can have user data preserved on reinstall or not using either architecture. The user/program seperation architecture makes this preservation of user data slightly easier and clearer but it’s neither necessary nor gauranteed.

While a noble method conceptually I don’t have the insight or skill at this thing to say if it’s worth any changes practically.

[BlueRaven]

To be 100% honest, you can already achieve the separation using directory symlinks: just put your config folder elsewhere - e.g. into ‘Saved Games’ - and replace the one inside BMS installation with a corresponding symlink… it’s completely transparent to the software, so no worries and headaches.