FYI on 4.35.2 update and Falcon BMS.cfg file..
-
Before you update you may want to save your current 4.35\User\Config\Falcon BMS.cfg file somewhere and run a comparison of it vs. the new one (Winmerge app is perfect for this) after the upgrade as any changes you may have made will be gone. For me it was just cursor speed and a couple FOV changes for my triple screens. You can also see what was added to the new config file and why it’s important you do not overwrite it with your 4.35.1 config file…
-
i read that the currently installed version is 4.35.2 but in game it doesn’t say Falcon BMS 4.35.2 (x64) Build 23835, it still says 4.35.1
-
Icer - you’re right. After all, changes to the config are signalled in the update announcement. Anyway, I ran through the config again to introduce the settings that work for me (and I always remember which ones ;)) Actually I had made a backup of the whole config folder, just in case… I’d hate to have to go through the controller setup yet again, but that seems to have been left untouched
-
Hi, Icer, I think that’s always good advice, anytime for you see that "overwrites cfg " message .
TommyGun, the first time I went in was the regular UI, and a lot of HOTAS things weren’t there. However, when I exited and went back in via AL, I was good-to-go. Yet another reason I’m a fan of AL…
BTW, I’ve put a U2 Hornet test report over in “Project Bug”
Alfred, It’s strange in that it looks like your U2 is installed. Is there a " 4.35.2_Part 1_ in your 4.35 Setup> data folder.?
I feel your pain, I also had trouble with installing U2
Maybe-https://www.benchmarksims.org/forum/showthread.php?42387-U2-Install-Issue-Severe-threat-detected will help. -
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.