FYI on 4.35.2 update and Falcon BMS.cfg file..
-
Mine says “Falcon BMS 4.35.2 (x64) Build 23835”….
-
-
me too but only after I uninstalled and reinstalled BMS 4.35
-
ctd is gone indeed
-
Not everybody reads the release notes, so it’d be nice if the installer either
o displayed a big fat warning message before making the changes
o or copied the existing falcon bms.cfg file to a safe place, notifying the user of the backup location after installation.
All the best,
Uwe
-
Not everybody reads the release notes, so it’d be nice if the installer either
o displayed a big fat warning message before making the changes
o or copied the existing falcon bms.cfg file to a safe place, notifying the user of the backup location after installation.
All the best,
Uwe
Or do it in the most proper way and let the installer apply changes to the existing cfg without changing any of the user made changes. For the current U2 we are talking about 2 new parameters added to the config and 3 existing values changed.
so hopefully devs take the suggestion made to build an installer in the future that does it in a proper way. Doing installer based editing of user config files is a process that is just a standard in software deployment. -
Or do it in the most proper way and let the installer apply changes to the existing cfg without changing any of the user made changes. For the current U2 we are talking about 2 new parameters added to the config and 3 existing values changed.
so hopefully devs take the suggestion made to build an installer in the future that does it in a proper way. Doing installer based editing of user config files is a process that is just a standard in software deployment.Its not the only standard, though. Pacman has a sensible approach, which is to copy the new version and alert the user, so you can decide on merges yourself.
-
Its not the only standard, though. Pacman has a sensible approach, which is to copy the new version and alert the user, so you can decide on merges yourself.
Where is the use case to force the user to merge back.
There is no usecase that the changes a user made to the cfg and used just to the moment he updates would all of a sudden not used by the user.
Adding new values to the cfg don’t require to reset everything else back to defaults. Even if the default value of an existing parameter needs to be changed ie ambient with U2 again no use case to reset everything else.In 20 years as professional software developer in major industries I never encountered a project doing it in the way BMS handles that case introducing complete uneccesarry manual steps.
I’m doing R&D all day long so feel free to provide a proper use case that would require a full reset or manual merge of cfg parameters that otherwise could be completely handles automatically by the installer process
Gesendet von meinem SM-G930F mit Tapatalk
-
not the only standard
Folks love to hate the registry in Windows, but this is basically why it exists… key/value granularity for updating config! (ok ok it has a lot of other problems, but not this one…)
apply changes to the existing cfg
I don’t know but I can imagine the weird two-phase unzipping installer tech might be limited in its ability to parse and manipulate text files…
Imho the right approach is not emitting default values for these properties in the stock cfg file at all. (Or maybe just list them all, commented-out, for ease of discovery.)
(For the prior sins of that, like g_fAmbientMin=0.1 … if you want to impose a new default value, you deprecate the old prop and define a new one, eg. g_fAmbientMinV2. This change can be documented, and the only people affected are the tiny few power users who hand-modified their cfg to begin with, and they’re presumably capable of dealing with the change.)
-
Where is the use case to force the user to merge back.
Where the updates may make previous versions of the cfg file obsolete, due to significant portions of it changing. Ive described, loosely, the way pacman (package manager) handles config files for packages.
It has another upside: It means that by default, you have a working cfg file, with default settings, and that its up to you to ensure that you make sane changes to the sane defaults.