More efficient "Profile-specific" setting ?

[xcorez]

Greetings Pete,

I recently changed my 'aircraft-specific' settings into 'profile-specific' settings.

While editing the FSUIPC4.ini manually, I often found some aircraft variants which can be assigned to the same Axis-assignment and calibration setting, but need different button-assignments since they have different panel/gauges.

The current method of creating and assigning "profile-specific" settings, albeit simple, it's still not efficient since we have to repeat the axis assignment & calibration routines whereas it only needs particular buttons/keys assignment (or vice versa).

Example case :

For the FSX default Beech Baron 58 with analog & glass cockpit variants, we could call and use the same exact axis assignment and calibration, but apparently they needs different buttons assignment.

Proposed solution :

I think we could trim down the amount of lines in FSUIPC4.INI and make it more efficient if we can use "cross-referencing" codes calls from the [Profile.specific] sections as follow :

[General]

..

UseProfiles=Yes

ShortAircraftNameOk=Substring

..etc

[Profile.MSDefault_BE58]

UseAxesProfile

=TwinPropPitch

; cross-referencing call for axis assignment

UseCalibProfile

=TwinPropPitchNRZ

; cross-referencing call for axis calibration setting

UseButtonProfile

=BE58MS_Analog

; cross-referencing call for buttons assignment

1=Baron 58 Paint

...

[Profile.MSDefault_BE58G1000]

UseAxesProfile=TwinPropPitch

UseCalibProfile=TwinPropPitchNRZ

UseButtonProfile=BE58MS_Analog

1=Baron 58 w G1000

[Profile.MSDefault_B350]

UseAxesProfile=TwinPropPitch

UseCalibProfile=TwinPropPitch

UseButtonProfile=B350_Default

1=King Air 350 Paint

...

[Profile.MSDefault_DC3]

UseAxesProfile=TwinPropPitch

UseCalibProfile=TwinPropPitchNRZ

UseButtonProfile=DC3_Default

1=Douglas DC-3 Paint

...

[Axes.TwinPropPitch]

1=0X,32,D,1,0,0,0

2=0Y,32,D,2,0,0,0

3=1Z,128,D,4,0,0,0

4=1R,128,D,3,0,0,0

5=1U,128,D,5,0,0,0

6=1S,128,D,6,0,0,0

...etc

[JoystickCalibration.TwinPropPitch]

UseAxisControlsForNRZ=No

Aileron=-16384,-128,128,16383

Elevator=-16384,-128,128,16383

Rudder=-16384,0,0,16383

Throttle=-16384,16383

Mixture=-16384,16128

PropPitch=-16384,16128

...etc

[JoystickCalibration.TwinPropPicthNRZ]

UseAxisControlsForNRZ=Yes

Aileron=-16384,-128,128,16383

Elevator=-16384,-128,128,16383

Rudder=-16384,0,0,16383

Throttle=-16384,16383

Mixture=-16384,16128

PropPitch=-16384,16128

...etc

[buttons.BE58_Analog]

0=P3,10,C66615,0

1=P3,11,C66616,0

2=P3,12,C66617,0

...etc

[buttons.BE58_G1000]

0=P3,10,C66776,0

1=P3,11,C66777,0

2=P3,12,C66778,0

...etc

[buttons.B350_Default]

0=W0366=1 P3,10,C1003,3844

1=W0366=0 P3,10,C1004,3844

...etc

[buttons.DC3_Default]

0=...

1=...

...etc

With this trimmed-down and more efficient profile, it's easier to manage and edit the FSUIPC4.INI file manually and would take less effort to re-assign and re-calibrate the axis when we have to do these routines due to the change of hardware or system configuration.

Another possibilty, is by adopting the way of "Reality XP" manage their products configuration settings (Flightline, GNS430/530 etc). They allow us to save "aircraft-specific" setting file into respective aircraft folder.

Using such that way, we can keep the main setting file clean, slim and efficient since it only holds general setting and global variables. No more residual settings leftover from the uninstalled aircrafts or from those unused aircraft we moved out from SimObject folder (to speed-up the loading of aircraft selection screen, for example),

More importantly, this method will minimize the risk of losing all the settings at once which is likely to occur in such centralized setting scenario when the master configuration file get error/corrupted.

I hope the next major revision / release of FSUIPC will has such that feature which allow us to store "aircraft-specific" profile settings into a separate folder within the respective aircraft folder along with its specific lua and macro files.

Regards,

-XC-

[Pete Dowson]

Thanks for your suggestions. I will think about your ideas, certainly, but I'm a little reluctant to make any drastic changes. The problem is that all these facilities have been gradually bolted on a program which is getting on for 7 years old. Every bit of tinkering I do is liable to make the whole edifice crumble if I'm not careful. This is one of the reasons I added Lua plug-ins, to let users add their own facilities instead.

I've also got the problem of trying to keep FSUIPC3 and FSUIPC4 more of less compatible parameter-wise so folks can move to fSX from FS9 easily. This has usually meant doing the same changes on even older code (15 years!) with more potentially disastrous results.

I would also like most users to be able to do most things without actually editing INI files, and I would find it really messy trying to manage some of your ideas via the dialogue system without substantial changes.

Regards

Pete

[xcorez]

Feels like bumping an old thread. I'm revisiting this thread to propose another idea.

Pete, your reluctant to make any drastic changes in FSUIPC is pretty understandable, concerning the disastrous result that might arises from major overhauling of FSUIPC just for accomodating such this minor feature.

As to avoid drastic changes in FSUIPC itself, is it possible to make a separate plugin DLL as an optional component/module of FSUIPC to scan the folder of aircraft we're loading? If it finds a local 'distributed' FSUIPC4.INI in there, it will read and load its paramaters to the FSUIPC memory address to be treated as profile-specific setting as usual.

Compares to my initial proposal, this approach doesn't require structural modification to the FSUIPC4.ini file, it's the same as current structure of main FSUIPC4.ini file but the 'local' version only contains parameters setting specifically applies for this particular aircraft.

On the end-user side, to switch over to this method can be done simply by copying the current FSUIPC4.INI from the modules folder to particular aircraft(s) folder, edit this now-localized FSUIPC4.INI so it only contains this aircraft specific settings ( [Axes.local], [JoystickCalibration.local], [buttons.local], [Auto.local] ) while keeps the general settings applies globally on the main/master FSUIPC4.INI in the modules folder.

To apply customized FSUIPC setting for several aircraft can be done by copying or possibly aliasing particular FSUIPC4.INI and distribute it into each folder of aircraft we want it to have same setting. On the other hand, we can disable its setting temporarily by simply rename that localized FSUIPC4.INI without affecting other aircraft or the general settings. If we uninstall the aircraft, we can remove its associated INI file or to keep it without scattering the main FSUIPC4.INI with redundant leftover from its profile-specific settings.

This distributed setting may also be considered as "Disaster Management" scheme. If one profile fails, it's not necessarily affects the other. If the main FSUIPC4.INI fails and needs total reset, we'll still have those 'distributed' local settings so we don't have to re-assign buttons and keys from the scratch.

Sorry if it sounds so complicated for such quite simple rationale of managing those profile-specific setting. The objective is to keep the main/master FSUIPC4.INI as-clean-as-possible out of redundant parameters of not used/rarely used profiles. This streamlined master INI acts as fallback whenever something bad happens due to misprogrammed button/key function and assignment. In this current 'centralized' scheme of FSUIPC ini file, that scenario could bring FSUIPC quits working completely.

I had already spent some tedious hours of diagnosing my very long FSUIPC4.INI to find out why suddenly all my profiles didn't work. checking it line-by-line was pretty tiresome as it already much bloated by repetitious setting parameters duplicates from multiple profile-sepecific entries. Fews hours and grammes of caffein later, eventually I ended it up with grand ceremonious banging-my-head-to-the-table as I found the problem was caused by just a single character(!) accidentally typed in while saving the file, surely rendered it invalid. Silly me.

I know this shouldn't be a big deal were I just using my old joystick; a standard 3 axis 12-buttons joystick. But since I purchased FSUIPC and WideFS, I've gradually acquired more controllers, and in consequence needs more extra lines for defining their control assignment. Now my HOTAS, yoke and buttons interface boards (*not necessarily the pricey sophisticated ones, but cheap DIY interfaces hacked from $5 each gamepads) really depend on FSUIPC for their coexist-interoperability functions, and of course these need a lot of flags and compund buttons definition. These even further complicated by multiple profile-specific settings as i try to adopt "cokcpit commonality philosophy" on my deskpit. lol.

So, the bottomline is we need an optional 'distributed' profile-specific setting. An optional DLL component whic can read, write and load the distributed settings to FSUIPC memory address on-the-fly is maybe the most possible solution without having to overhaul the FSUIPC module. Users have the option either to use the current 'centralized' setting, or switch to "distributed' setting merely by installing this addon component DLL, and activate it via a single parameter in main FSUIPC4.INI (like "DistributedSettings=Yes/No").

 

Well, that just another 1 cent's worth of idea.

Regards,

-xcorez-


PS. Sorry for this lengthy post, but believe me, this is much shorter than my current FSUIPC4.ini ... and if you look up at the date of posting, yes I'm a slow-typer. It needs exactly 1-year to compose this reply. lol. And also as english in not my primary language, this take lots of time and effort to arrange word-by-word to be generally understandable.

 

 

[Pete Dowson]

To apply customized FSUIPC setting for several aircraft can be done by copying or possibly aliasing particular FSUIPC4.INI and distribute it into each folder of aircraft we want it to have same setting. On the other hand, we can disable its setting temporarily by simply rename that localized FSUIPC4.INI without affecting other aircraft or the general settings. If we uninstall the aircraft, we can remove its associated INI file or to keep it without scattering the main FSUIPC4.INI with redundant leftover from its profile-specific settings.

 

Quite honestly, this sounds like it will only ever be used by a few dedicated folks, because it's so complicated. I wouldn't know how to begin even documenting it for the average user!

 

I had already spent some tedious hours of diagnosing my very long FSUIPC4.INI to find out why suddenly all my profiles didn't work. checking it line-by-line was pretty tiresome as it already much bloated by repetitious setting parameters duplicates from multiple profile-sepecific entries.

 

I don't understand how you finsih up like that in the first place. A profile does NOT have to have settings in every category. For all those aircraft which can use the exact same Axis settings why not simply have those settings as the default set and no profile sections for them at all? Same with calibrations. And if you do need variations you tell FSUIPC to base the new Axis section on the default.

 

Button and Keys should be no problem, because your default set applies in any case exacept where overridden by specific assignments. The only reason this doesn't happen for axes is that axes are always active whilst buttons and keys are noly active when you use them.

 

I am really really busy with FSUIPC stuff relating to ASN, P3Dv2 and so on. I need to get on and finish stuff before my family start arriving for Christmas. Then I'm away half of January. If there's something easy to do and depending on the load I have at the time I'll look at what can be done, but I'd rather simplify things than make them so much more complex.

 

Regards

Pete

[Pete Dowson]

I am really really busy with FSUIPC stuff relating to ASN, P3Dv2 and so on. I need to get on and finish stuff before my family start arriving for Christmas. Then I'm away half of January. If there's something easy to do and depending on the load I have at the time I'll look at what can be done, but I'd rather simplify things than make them so much more complex.

 

Having written that and had more thoughts whilst walking my dog (I do a lot of thinking at such times <G>), I might have an easy (simple) way to do something like what you ask. In each routine which Loads or Saves data for the four relevant areas (Axes, Calibrations, Buttons and Keys), before doing anything it can just check if there is an FSUIPC4.INI file in the aircraft folder, and if so (when loading) whether it has the relevant section. (for saving it would create one if there isn't one already there).

 

If so, then it just switches the paths for the rest of that operation (only). Each of the four sections would be independent for reading, but not for writing -- once you make a change and an Aircraft Folder INI is present, then that's the file which is updated no matter which of the four sections you are in.

 

Anyway, that was my first thought. If you think it would be better to only deal with the Aircraft folder INI if it already has the needed section in it, even when modifying, then that may be possible, but I would then be worried about what happens when you decide to assign the aircraft which previously wasn't "profiled" to a profile. The section and Profile would have to be created in the Aircraft folder's INI, creating inconsistency and erven more confusion. So I think it best to be clear as in my first poposed way.

 

I'm not completely sure of the ramifications for adding aircraft to Profiles or creating new Profiles, but I think this would then all occur in the particult INI file, not in the main one.

 

My only worry about all this is that it will get MUCH more complicated to understand what is going on. I can see the support load increasing, not descreasing, and possibly quite markedly. So if i do it I may mark it clearly as "at user's own risk: limited support available", or some such.

 

I still find it rather odd that you'd find such an arrangement easier, but each to his own.

 

No promises, but something along these lines would be pretty easy to add. (Just not easy to document <G>).

 

Regards

Pete

[aua668]

Hi,

 

I personally found the original idea much better and creating profile aliases for several sections of the profile would really be great. Think about the situation, where you have to recalibrate some devices as they change behaviour over time or you have to replace them. Then you would do it only once for one group of profiles. And often some settings will always be the same across several profiles (e.g. throttle calibration) while other must be different according to different panels (e.g. button assignments). And only referring to one single default profile is not enough in most cases. Therefore we duplicate typically a lot of things.

 

It was a nice idea. The solution with different INI files looks really to complicated for most users being in many cases not able to manage one single INI file correctly :???:

 

Rgds

Reinhard

[Pete Dowson]

I personally found the original idea much better and creating profile aliases for several sections of the profile would really be great.

 

Okay. Then please explain it to me in a way I can understand, maybe with examples. Because i gave up on your first explanation because i got lost and couldn't see how anyone else could understand it either. Sorry if i'm being thick. try shorter paragraphs and examples.

 

Pete

[aua668]

Hi,

 

I try to give a simple example. Let's say you create a axes profile named "TwinPropPitch" as usual defining some assignments and calibrations.

[Axes.TwinPropPitch]
1=0X,32,D,1,0,0,0
2=0Y,32,D,2,0,0,0
3=1Z,128,D,4,0,0,0
4=1R,128,D,3,0,0,0
5=1U,128,D,5,0,0,0
6=1S,128,D,6,0,0,0

[JoystickCalibration.TwinPropPitch]
UseAxisControlsForNRZ=No
Aileron=-16384,-128,128,16383
Elevator=-16384,-128,128,16383
Rudder=-16384,0,0,16383
Throttle=-16384,16383
Mixture=-16384,16128
PropPitch=-16384,16128
...etc



 

Normally you would assign all the aircrafts using this profile as follows assuming you use "ShortAircraftNameOk=Substring" :

[Profile.TwinPropPitch]
1=Baron 58
2=King Air 350
...

You only need to assign and calibrate your yoke and axes once for all your twin props. But then you are limited with your button assignments to either the default settings or to the profile specific button assigments. As the layout of panels and the necessary assignments of buttons are varying more often than the assignment of axes, you must create for each panel type a profile and therefore you are duplicating also your axis assignment and calibration sections, although this wouldn't be necessary.

 

So one method to overcome is, the way proposed above. Another and maybe more simple approach to implement is, that you should be able to reference for each value in a profile setting to another profile. Something like this:

[Axes.BE58]
1=Alias.0X=TwinPropPitch
2=Alias.0Y=TwinPropPitch
3=Alias.1Z=TwinPropPitch
4=1R,128,D,11,0,0,0
5=1U,128,D,7,0,0,0
6=1S,128,D,9,0,0,0

[Axes.350]
1=Alias.0X=TwinPropPitch
2=Alias.0Y=TwinPropPitch
3=Alias.1Z=TwinPropPitch
4=1R,128,D,8,0,0,0
5=Alias.1U=TwinPropPitch
6=Alias.1S=TwinPropPitch

By that you can either reference to an assignment in another profile and you are just replacing the value by the corresponding value in the generic profile. Or you can define specific assignments for some axes as you need them. And this concept can be used for axis assignments, calibrartions and button assignments in the same way.

 

And then you are free to create individual button profiles or you are also able to reference to the assignment in another profile. And with an implemenation like this you should stay compatible. If someone doesn't use this feature, all stays the same.

 

It's the extension of the concept you have implemented with your default profile. You are now able to either assign default behaviour to a button or override it by a profile specific setting. With that method you get suddenly several default profiles: one for TwinProp, one for TwinJet, etc.

 

Hope this makes it more clear. Maybe at your next walk you have again another genious idea. I like that approach :???:

 

Best regards

Reinhard

[Pete Dowson]

So one method to overcome is, the way proposed above. Another and maybe more simple approach to implement is, that you should be able to reference for each value in a profile setting to another profile. Something like this:

 

...

 

Hope this makes it more clear. Maybe at your next walk you have again another genious idea. I like that approach :???:

 

Haha!

 

As far as I can see, you have just as many declaration lines in this structure as in the original. You are simply replacing what should be there by the reference.

 

And it would be complicated to implement without a partial rewrite of this area of FSUIPC. At present there is one routine which simply makes sure the right sections in the INI are being referenced -- i.e builds the string for the profile specific section needed. The routine which processes it only knows that section, that's its whole world. Nothing else is known.

 

Referring to other sections entirely whilst processing the current one means some sort of recursive call -- first back to the routine which gets the right section, then back to the one which just called it. (It would need an infinite loop check) -- with some sort of special parameter saying "just this one line please", and then back out again. All this for every individual line with an alias. Ugh. It would be pretty slow and very much more complex code. And it looks like so much more work and thought needed by the user I can't see many folks using it.

 

I suspect that something similar, but not aliassing specific assignment lines to another specific section, but referencing a named library of assignments (or whatever) would be a bit easier to implement, and also (hopefully) to understand. Like this, perhaps:

 

[AxesLib.NameAsWish]
1=0X,32,D,1,0,0,0
2=0Y,32,D,2,0,0,0
3=1Z,128,D,4,0,0,0
4=1R,128,D,3,0,0,0
5=1U,128,D,5,0,0,0
6=1S,128,D,6,0,0,0

[Axes.BE58]
Lib=NameAsWish
1=1R,128,D,11,0,0,0
2=1U,128,D,7,0,0,0
3=1S,128,D,9,0,0,0

[Axes.350]
Lib=NameAsWish
1=1R,128,D,8,0,0,0

Here, the AxesLib "NameAsWish" is processed as if it were the current section (i.e. just the one recursion), followed by the specials for this section -- which may be additional, or overrides. Or, vice versa, the additions or overrides are processed first and remembered so that the Library versions are bypassed.

 

I suspect it would be easier to do it the former way, as that is similar to what happens in buttons and keys sections when you have generic/default and specific settings for the same buttons or keys. the latter override the former.

 

If this meets the need, I can certainly think more along those lines -- but maybe not till mid-January or so, after my NY hols.

 

Regards

Pete

[aua668]

Pete,

 

Fine for me too. Whatever is simpler and more compatible to the existing implemention is always the best thing. You are the master.

Your proposed solution will perfectly fulfill the requirements.

 

Rgds

Reinhard

[Pete Dowson]

Fine for me too. Whatever is simpler and more compatible to the existing implemention is always the best thing. You are the master.

Your proposed solution will perfectly fulfill the requirements.

 

Rgds

Reinhard

 

Okay. I'll take a look when I get some time. It may not be till later in January, but we'll see. Could be earlier.

 

Pete

[aua668]

Okay. I'll take a look when I get some time. It may not be till later in January, but we'll see. Could be earlier.

 

Pete

 

... if the weather is better again for a walk :razz:

 

Rgds

Reinhard

[xcorez]

Hi, Pete

Sorry to not have replied earlier, but considering I'm a slow-typer — this is my new personal record!  :D
 

..
I might have an easy (simple) way to do something like what you ask. In each routine which Loads or Saves data for the four relevant areas (Axes, Calibrations, Buttons and Keys), before doing anything it can just check if there is an FSUIPC4.INI file in the aircraft folder, and if so (when loading) whether it has the relevant section. (for saving it would create one if there isn't one already there).

 

That's exactly what I mean. Therefore we can separate a particular profile-specific settings and save it into a setting/configuration file in the apropriate aircraft's folder. If we load the airplane, FSUIPC will check that aircraft's folder for the existance of that setting file. If there's one and only if its parameter is valid, the profile-specific settings from that file will override and/or appended to the relevant settings in FSUIPC4.INI. I think the entire sub-sequent processing of the profile-specific settings will be quite seamless, regardless of it's now stored in a separate file (?)

 

..
My only worry about all this is that it will get MUCH more complicated to understand what is going on. I can see the support load increasing, not descreasing, and possibly quite markedly. So if i do it I may mark it clearly as "at user's own risk: limited support available", or some such.
..

To have a better understanding of the proposed idea, I'll try to explain in more detail from my perspective as end-user, while also considering its limitation and implementation from the developer/support's point-of-view.

(Warning. This could be a very long post. Only read while enroute the long leg flight with AP engaged! <G>)
 
 
TECHNICAL CONSIDERATIONS

This proposed scheme of separating particular profile-specific settings from FSUIPC4.INI into a separate setting file that should be saved or place into that particular aircraft's folder. Basically this is more or less similar to AIRCRAFT.CFG file which store settings and paramaters specific to particular airplane.

Application of this scheme requires a new routine, either by built-in component or by external DLL component, to handle the reading, loading and writing to/from local aircraft folder INI setting file (or, it might be alternatively named as "FSUIPC4_PROFILES.INI" or "FSUIPC4.CFG" so as not be confused with the main FSUIPC4.INI /?/)

The proposed FSUIPC4.CFG file is merely just a 'cut-down-version' of main FSUIPC4.INI, so it has exactly same structure of the profile-specific sections of the FSUIPC4.INI, whilst those sections are further trimmed-down in FSUIPC4.CFG to only consists particular sections that specifically apply to aircrafts in its containing folder (providing it's qualified to the defined parameters).

While loading a particular aircraft, the afore-mentioned routine will scan its aircraft folder for the existance of FSUIPC4.CFG file, check whether the aircraft is defined and valid to use the settings. Being loaded into FSUIPC proccess memory, the FSUIPC.CFG settings will overrides the relevant settings of default assignment that's defined in the FSUIPC4.INI, whereas  the rests of profile-specific sections in FSUIPC4.INI will be totally ignored/skipped.

The default settings of [Axes] - [JoystickCalibration] - [buttons] - [Keys]  of FSUIPC4.INI will be used as 'fallback' when there is not relevant assignment defined in FSUIPC4.CFG, while the global/system-wide settings ( General, GpsOut, WidesServer, JoyNames etc ) will always be loaded from and saved to main FSUIPC.INI file in the module folder.

Any subsequence change in profile-specific settings (Keys, Buttons, Axes, Calibration) which are set using options tabs or menus of FSUIPC GUI, will be saved into the originating file from where the settings were loaded into FSUIPC proccess memory. So, if the setting was loaded from aircraft's folder FSUIPC4.CFG, it will be saved into that same file.

Non-profiled aircraft(s) by default will always use the main FSUIPC4.INI for their settings. If we initally set specific axes, calibration, keys and buttons assignment for this 'non-profiled' aircraft, its settings will be saved in the main FSUIPC4.INI as new profile (exactly same procedures like in the current scheme).

Macro, Event and LUA files should ALWAYS be kept and placed inside Module folder, as in per current scheme they are declared as global parameters.

If possible, maybe there's should be an option of "New, based on file ..." on the drop-down menu of FSUIPC's new profile creation, so we can select one of the existing FSUIPC4.CFG file as 'base-template' to be applied and saved to a new profile in main FSUIPC4.INI.

For a particular profile which is used by many aircrafts, to avoid synchronization issue it is recommended to keep its profile-specific settings in main FSUIPC4.INI file, and if required use FSUIPC4.CFG during manual editing only.

To be further analyzed :
Profile Aliasing — so we don't have to duplicate the same FSUIPC4.CFG into each aircraft folders of airplanes that share the same profile. We can use its file shortcuts (symbolic-links), or preferable a 'special' FSUIPC4.CFG that only contains a single section and parameter. It might be as simple as :
 

[FSUIPC4.PROFILE]
alias=\C172\FSUIPC4.CFG

This has similar structure and function as some aircraft's PANEL.CFG file used for aliasing other's aircraft panel. This aliasing feature is NOT mandatory, as we optionally can use the 'conventional-way' of duplicating the FSUIPC4.CFG file. But 'aliasing' is preferred as it can prevent such 'unsynchronized-setting' issue.
 

RATIONALE

Principally, this FSUIPC4.CFG in aircraft folders should be MANUALLY created and managed by user under his/her consent. So, if we want to switch/convert profile from FSUIPC4.INI into a separate 'FSUIPC4.CFG', we have to manually  'cut-and-paste' its relevant profile-specific sections, from the main FSUIPC4.INI into a newly created FSUIPC4.CFG file in the appropriate aircraft folder.

WHY should MANUALLY ? Because the main objective of separating particular profile-specific settings from FSUIPC4.INI into separate FSUIPC4.CFG is primarily aimed to ease the MANUAL EDITING proccess of such profile-specific settings of some aircrafts that needs complex assignment settings, and/or profiles with complex assignment settings due the complex setup of multi control-devices.

In such complex setup scenario, one single profile may contains more than a hundred lines of parameter settings to define its control axis, keys and buttons assignments. Mostly consists of compound or conditional buttons, flags, multiple-assignment in single button event etc. These type of assignments can only be set/defined by hand-editing the INI file manually.

The current "centralized setting scheme" of FSUIPC, uses a single file FSUIPC4.INI for storing all its configuration and parameter settings, including the aircraft/profile-specific settings. Predictably, this 'composite-setting' FSUIPC4.INI file will continue to grow over time as we add more profiles, and will become less and less efficient as it contains so many repetitious paramaters/settings. This makes this file become so tedious and riskful to edit it manually.

By separating profiles to isolate the particular profiles that we're going to manage, will ease the entire manual editing proccess efficiently. Not only editing, but in troubleshooting, it will be more easier to pinpoint the error as the non-relevant settings has been filtered-out. Not to mention the time it saves us by not having to scroll back and forth through hundreds lines of entire setting belongs to non-relevant profile(s).

To some extent, the separate FSUIPC4.CFG can also be considered as fail-safe method of manual-editing process of the profile-specific setting, as we don't have to edit those settings directly in the delicate FSUIPC4.INI which contains many substantial paramaters/settings that are critical to entire FSUIPC process routines. Editing the profile-specific settings in seperate FSUIPC4.CFG will isolate the failure, if happens  — only to this particular profile.

The procedure to convert the composite profiles from FSUIPC4.INI into separated profile-specific FSUIPC4.CFG file will not be as complicated as the procedure of switching from 'aircraft-specific' to 'profile-specific' scheme (as documented in FSUIPC user guide p.24). In this proposed scheme, to convert a profile-specific settings into a separate FSUIPC4.CFG, can be achieved by doing one of the following :

A. Copy the working FSUIPC4.INI from main module folder to the respective aircraft folder, rename that file as FSUIPC4.CFG then edit it manually to remove the general setting sections, and other non-relevant profile settings sections so it only consists settings specific for this aircraft.

-or-

B. Open the FSUIPC4.INI in the main module folder, copy the relevant profile-specific setting sections of that particular aircraft. Open the respective aircraft's folder (under "\SimObjects\Airplanes" or \SimObjects\Helicopters" folder), make a new file named as FSUIPC4.CFG and paste the copied sections into this newly-created file.

 
 
In contrast to the conversion of 'aircraft-specific' to 'profile-specific' as in per current scheme, the conversion from 'composite profile' to 'separated' profile' is NOT a "one-time" setup, We don't have to convert all of our current existing profiles 'at-once', instead we may convert our profile selectively 'one-at-a-time' at our convenience. More over, this conversion will be "fully-reversible" (undo-able), as we can copy the content of FSUIPC4.CFG back to FSUIPC4.INI anytime.
 
Although it's primarily aimed towards to users who have to manage such complex profiles, this scheme is also applicable for managing such common profiles. User who doesn't use such complex profile-specific settings and who rarely have to edit their setting manually, still can utilize the separate-profile scheme, that might be might be useful for reviewing its settings, troubleshooting, or experimenting with other alternate configuration.

Due to its nature of purpose, the application of this 'separated' profile FSUIPC4.CFG file scheme is trully OPTIONAL. Mostly users are using FSUIPC merely to utilize its globally-applied weather-related settings, and only use standard control assignment in FSUIPC, or even set their controls assignment via built-in FSX control settings only. These typical user will find that the current 'composite' FSUIPC4.INI scheme will works best for their setup, and it's recommended NOT to use separate-profile FSUIPC4.CFG as it will not provide any benefit for them.

In terms of functionality, there will be NO difference of either using composite-profile scheme of FSUIPC4.INI or using separated-profile scheme of FSUIPC4.CFG.
 
 
CASE STUDY

To illustrate, let's take look an example of FSUIPC4.INI (taken from lucagigli's thread), which represents the common structure and content of FSUIPC4.INI that has multiple profiles merged into one single composite INI. Although mostly of its assignment-settings are quite simple, the repetitious parameters from multiple profile-specific settings brings its own complexity. It takes extra effort for diagnosing it, and takes the super-extra caution while editing it manually so as to not accidentally alter setting of the unintended profile.

If we 'isolate' a single profile, say the "Pmdg 737-700", by copy-and-paste its relevant sections from FSUIPC4.INI into a separate FSUIPC4.CFG file which saved in its containing aircraft folder, we'll have a much more efficient file that is easier to review and safe to edit as it might only consists the relevant profile-specific setting sections, as the following : 
 

[Profile.Pmdg 737-700]
1=Boeing 737-700NGX PMDG House


[Buttons.Pmdg 737-700]
0=P1,1,K83,8
1=R1,0,C65588,0
2=R1,2,C65607,0
3=R1,3,C65615,0
4=P1,4,C65759,0
5=P1,5,C65758,0
7=R1,7,C66816,0
8=P1,14,C66065,0
9=P1,15,C66064,0
10=R1,20,C65602,0
13=R1,21,C65966,0
14=U1,21,C65820,0
15=R1,22,C65971,0
16=U1,22,C65821,0
17=P2,4,C65752,0
18=P2,2,C66079,0
19=P2,3,C66080,0
20=P2,5,C3,0
21=P64,0,C66080,0
22=P64,1,C66079,0
24=R1,6,C66817,0


[Axes.Pmdg 737-700]
RangeRepeatRate=10
0=0X,256,D,7,0,0,0
1=0Y,256,D,8,0,0,0
2=0R,256,D,3,0,0,0
3=1X,256,D,1,0,0,0
4=1Y,256,D,2,0,0,0
5=1Z,256,D,22,0,0,0
6=1V,256,D,9,0,0,0
7=2X,256,D,10,0,0,0
8=2Z,256,D,23,0,0,0


[JoystickCalibration.Pmdg 737-700]
AllowSuppressForPFCquad=Yes
ExcludeThrottleSet=No
ExcludeMixtureSet=Yes
ExcludePropPitchSet=Yes
SepRevsJetsOnly=No
ApplyHeloTrim=No
UseAxisControlsForNRZ=No
FlapsSetControl=0
FlapDetents=No
ReverserControl=66292
Reverser1Control=66422
Reverser2Control=66425
Reverser3Control=66428
Reverser4Control=66431
MaxThrottleForReverser=256
AileronTrimControl=66731
RudderTrimControl=66732
CowlFlaps1Control=66162
CowlFlaps2Control=66163
CowlFlaps3Control=66164
CowlFlaps4Control=66165
SteeringTillerControl=0
MaxSteerSpeed=60
Aileron=-16384,0,0,16383
Elevator=-16384,0,0,16383
Rudder=-16380,0,512,16380
LeftBrake=-16383,16384/16
RightBrake=-16383,16384/16
Throttle1=-16384,0,0,16383/32
Throttle2=-16384,0,0,16383/32
Spoilers=-16384,16383/16
Flaps=-16383,16384/16

As it's no longer obstructed by dozen of lines of non-relevant settings, its's much easier to manage and to deal with, whenever we have to edit it manually. Having this profile separated in FSUIPC4.CFG file that's saved in the aircraft's containg folder, the following condition will applies :

If we load the plane "Boeing 737-700NGX PMDG House" in FSX, the FSUIPC4.CFG in its aircraft's folder will be loaded into memory and its settings will automatically overrides its original "Pmdg 737-700" profile settings that we still keep in the FSUIPC4.INI file.

If we load another plane, for example named "Boeing 737-700NGX PMDG ZZZZ", even though it shares the same aircraft folder as this FSUIPC4.CFG, it will be treated as "non-profiled" aircraft, because its name has not yet defined and listed on any priofiles, either in the local FSUIPC4.CFG or in the main FSUIPC4.INI file. In this case, the FSUIPC4.CFG will be ignored/skipped, and FSUIPC4.INI profile assignment will take place in FSUIPC processing routine as usual.

If we select/set profile for that 'non-profiled airplane' using FSUIPC profile selection dropdown-menu, it will be assigned to profile which is listed or saved in FSUIPC4.INI. To assign it into FSUIPC4.CFG profile, we have to add it manually into the appropriate section of FSUIPC4.CFG.

If this FSUIPC4.CFG loaded in memory, any modification that takes place after to its relevant profile-specific settings set via FSUIPC GUI, will be automatically saved into this FSUIPC4.CFG, while its original profiles-specific settings in the the main FSUIPC4.INI are kept unmodified.

Anytime we want to revert to its original profile-specific settings, we can delete, or temporarily rename the FSUIPC4.CFG file and after that reload the aircraft (using FSX shortcut key, or manually by pressing "Reload All ..." button on FSUIPC Tabs of keys, buttons and axes.

If we're satisfied with modification we've made to profile-specific settings in this FSUIPC4.CFG, we can safely remove its original profile-specific sections from FSUIPC4.INI to clean it up of redundant profiles settings..

Likewise, once we have performed necessary testing to make sure it's working, we can copy all these settings from FSUIPC4.CFG back to main FSUIPC4.INI, either overwriting the original profile, or making a new profile in FSUIPC4.INI. – This method is most useful for managing and editing profile that is used or planned to be used by a number of airplanes from various aircraft folders. so we don't have to copy similar FSUIPC4.CFG each into their folders.
 
The FSUIPC4.CFG is not necessarily has only single profile, but may also holds additional profile(s) for aircraft which has different variants that need different button configs, usually due to their different panels/avionics configuration. For example, the default C172 which has analog and G1000 variant. In this case, we can make a FSUIPC4.CFG which consists multiple profiles, roughly as the following :
 

[Profile.Default C172 Analog]
1=Skyhawk 172SP Paint


[Profile.Default C172 G1000]
1=Skyhawk 172SP G1000


[Buttons.Default C172 Analog]
..
..


[Buttons.Default C172 G1000]
..
..

etc.

 

We can also use multiple profiles in single FSUIPC4.CFG for aircraft we want to vary its handling characteristic. For example, I can create an FSUIPC.CFG file inside my 'Extra300' aircraft folder, duplicate the current profile settings so I have two profiles. One for responsive, precise handling and the other for more relax, smooth response which is comfortable for cross-country hand-flying. So i can assign one variant/livery to the latter profile, and the rests to the former profile, required for flying the FSX missions.

Not to let this post even longer, I opt not to post these profile settings — but as you can imagine, the only different settings between these two profiles are just their sensitivity curves (SlopeAileron, SlopeElevator) and their 'dead-zone' value under its  [JoystickCalibration.profile] section, while the rests dozen-of-lines of parameters of these two profiles are containing the same exact setting values, which to some extent becomes superfluous.

The profile-specific settings will even get more complicated for some 3rd-party addons airplanes, that needs sort of "special-treatment". Some works perfectly with default axis setting with "Send to FS As Normal Axis" selected, while the other performs better with "Direct to FSUIPC Calibration" option selected. Not even to mention the complex buttons assignment, mostly are compound buttons with conditional flags as to conform the aircraft's custom-coded function and variables, that make this such profile very tedious to edit if we still keep it merged with other profiles in FSUIPC4.INI.  

By 'isolating' a particular profile to a separated FSUIPC4.CFG, it's not necessarily to 'simplify' its axes or buttons assignment settings, but it's more to have a better 'clarity' needed while we have to review its assignment, diagnosing, comparing its parameters and settings value with profile's, so that we can do such necessary correction, adjustment or refinement of its paramater settings.

Of course, in terms of FSUIPC features, functionality and capability, this proposed scheme does not offer anything new — they're all already there, but need tedious effort and extreme carefulness in order to utilize 'em. — So, this scheme is proposed to allow us to explore the available possibility of using potential features of FSUIPC for optimizing our FSX, add-ons and our control-devices, in more efficient and safely manner.
 

 

..
I personally found the original idea much better and creating profile aliases for several sections of the profile would really be great.
..

 

That's what I thought initially, but after reconsidering the risk of major overhaul of FSUIPC4.DLL that should be taken for accomodating new FSUIPC4.INI file structure, I'm agree with Pete and fully understand his reluctancy to do such substantial modification. From end-user side, the new structure and new parameter will create its own complexity in applying it to our existing settings, so eventually made that such proposed idea as 'applicable-but-not-feasible' option.

The new proposed scheme of 'separate-profile-setting' file, does not requires any newly defined structure and/or parameter, so it seems practically less-risky and applicable with only relatively minor modification to the routine which handles the reading, writting, and loading of profile-specific settings, while not affecting the primary function processing routines of FSUIPC.

 

..
The solution with different INI files looks really to complicated for most users being in many cases not able to manage one single INI file correctly
..

From my point-of-view, that's mostly because the current 'composite-structure' of FSUIPC4.INI, especially one which contains multiple-profiles settings, can be very long that make it even more difficult to manage. The more you're adding profiles to accomodate your new aircraft and/or your new hardware, the more complex and difficult to manage it. Let alone if you don't routinely clean it up from the leftover of no-longer-used profile(s).

That's the circumstance from where the idea of the 'separate-profile-file' comes from. Without having to 'redefine' the all-new structure of settings and/or introducing new parameters we should deal with, alternatively we could make FSUIPC4.INI settings file more efficient by simply 'splitting' its content into separates file based on its current structure and functions. Default parameters and general settings that applies globally (weather, sims function, wideserver etc) still being kept in main FSUIPC4.INI, whereas aircraft-specific profile settings optionally can be splitted up into separate file, – sort of the proposed FSUIPC4.CFG file, which is to store particular profile-specific settings of the airplane(s)  contained in the same folder where the FSUIPC4.CFG file is located.

Although it 'looks' really complicated, principally it's the same standard of FSX 'distibuted settings' scheme we've been familiar with and utilizing it regularly. As per FSX standards, the global/general simulation settings are stored in FSX.CFG, whereas aircraft's specific settings are stored in each separate file of AIRCRAFT.CFG, PANEL.CFG, SOUND.CFG, which are placed inside 'every' particular aircraft folder and its sub-folder.

I believe,  most users have been familiar with AIRCRAFT.CFG files that have to be managed and edited manually, either for common basic customization such as adding custom liveries, or for more advance modification such as adjusting its contact-points, customizing lights, effects etc. On the contrary, only few users familiar with the FSX.CFG, as by-design this file contains settings that should only set or modified using FSX GUI option screen/menus.

In current scheme of 'composite' FSUIPC4.INI which contains several profile-specific settings merged all together in one file is like having the whole contents of all our AIRCRAFT.CFG files being merged into a single FSX.CFG so as to store all settings in one place.  True, it's simple and not complicated, however it's not necessarily efficient to manage since it now contains a huge amounts of settings, not even to mention the risk of totally losing all those settings at-once. Imagine someday we want to modify one of our aircraft's parameter and have to edit it manually...

So to speak, to have and having to manage different profile-specific settings FSUIPC4.CFG files distributed into each particular aircraft folders would not be more complicated than (if not-the-same-as) having to manage many different AIRCRAFT.CFG files, to as what we have been currently accustomed with, since the day we installed the FSX.


Regards,

-xcorez-

 

PS. Pete, take your time, no need to rush! Personally, I think it will be much better if you could take a more thorough review and analysis of this proposed sheme, whether it is feasible to be implemented or if there's any possible refinement to make it more useful and widely-applicable for most users.
 

[Pete Dowson]

PS. Pete, take your time, no need to rush! Personally, I think it will be much better if you could take a more thorough review and analysis of this proposed sheme, whether it is feasible to be implemented or if there's any possible refinement to make it more useful and widely-applicable for most users.

 

I'm afraid I've not got time this side of mid-January to read and understand this long missive. All i can do is print it out and try to read it some time soon.  But first, let me just ask this one question: You emphasise MANUAL setting. Do I take it that if someone takes this toute I can thenceforth prohibit him from using any of the in-program option facilities for Axes, Buttons, Keys and Calibrations. He would then only ever ecit these 'cFG' files directly?  If not then it is too complex and worrying support-wise. Folks won't know what's going where or when -- me included!

 

And do I take it you do not like my proposal using "Library" sections, for the common stuff? I already have in mind exactly how I would do that. And it might only be a day or so's work. In fact it would take longer to test properly.

 

I might shelve all this till next Summer, when I'm stuck at home because the dear wife has lots of gardening to do. Much of next year we are otherwise travelling. Part of our "retirement" plan -- see and do as much as we can whilst we are able. And next year we will have been married 60 years, so there's extra involved.

 

Regards

Pete

[xcorez]

But first, let me just ask this one question: You emphasise MANUAL setting. Do I take it that if someone takes this toute I can thenceforth prohibit him from using any of the in-program option facilities for Axes, Buttons, Keys and Calibrations. He would then only ever ecit these 'cFG' files directly?

Pete, let me first quote some points from my previous post as key points in answering your question,

 

Any subsequence change in profile-specific settings (Keys, Buttons, Axes, Calibration) which are set using options tabs or menus of FSUIPC GUI, will be saved into the originating file from where the settings were loaded into FSUIPC proccess memory. So, if the setting was loaded from aircraft's folder FSUIPC4.CFG, it will be saved into that same file.

--

If this FSUIPC4.CFG loaded in memory, any modification that takes place after to its relevant profile-specific settings set via FSUIPC GUI, will be automatically saved into this FSUIPC4.CFG, while its original profiles-specific settings in the the main FSUIPC4.INI are kept unmodified.

--

In terms of functionality, there will be NO difference of either using composite-profile scheme of FSUIPC4.INI or using separated-profile scheme of FSUIPC4.CFG.

 

I think they're self-explained. So, either we use or not to use the 'separate-profile-setting' file, there will be no difference in term of functionality and accessibility in using all currently available feature of FSUIPC. We still able to use any of the in-program option facilities of Axes, Buttons, Keys and Calibration to set our control settings, and its newly modified setting will be saved to originating file from where the settings were loaded. (*Of course, these all depends on the to-be-provided routines which will handles the Read, Load and Write of the settings file.)

Likewise, we still have to edit the settings file manually (either FSUIPC4.INI or the proposed FSUIPC4.CFG) to access and to set certain function settings that currently can't be set directly using FSUIPC in-program option facilities. This is what I emphasized as MANUAL setting -- it's to refers the setting for such key/button sequence of actions, compund button actions, axis scaling etc that we have to edit MANUALLY, as documented in FSUIPC4 User Guide (p.27), and further explained in FSUIPC4 for Advanced Users document.

 

And do I take it you do not like my proposal using "Library" sections, for the common stuff? I already have in mind exactly how I would do that. And it might only be a day or so's work. In fact it would take longer to test properly.

 

I actually do like that "Referencing Library" method proposal. That's more or less has similar 'function' to what I'm asking for on my intial-post of this thread, as to what I called that as "cross-referencing" setting. The only difference is, I put the 'Library.Call.function" on [Profile.names] section, whereas you put it directly under profile's [controls.names]

Mine :

[Profile.MSDefault_B350]
UseAxesProfile=TwinPropPitch
UseCalibProfile=TwinPropPitch
UseButtonProfile=B350_Default
1=King Air 350 Paint
...

Yours :

[Axes.BE58]
Lib=NameAsWish
1=1R,128,D,11,0,0,0
2=1U,128,D,7,0,0,0
3=1S,128,D,9,0,0,0

I see that your approach is more flexible, as it allows us add/use other control assignment as necessary in addition to the declared referencing "Library". Is it possible to set the "Library.call.parameter" (the "Lib=....") directly from FSUIPC GUI, sort of the "New, Based On..." menu option ? Or do we have to edit it manually from FSUIPC4.INI file?

If it's the latter, that's what I'm concerned about — editing that INI file manually looks quite daunting for mostly user, especially with the current 'composite-settings" structure of FSUIPC4.INI. More over, I'm afraid the new paramater will brings its own complexity to most users IF they have to add/set by editing the INI file manually.

Personally I don't mind having to edit that INI file manually, and as a matter of fact, I'm even getting used to it as some of my profile contains complex assignment settings that I have to set manually. But I found that the greatest barrier in doing such manual editing is the structure and content of FSUIPC4.INI itself -- at which to some degree become too 'cluterred', too 'delicate' and too 'risky' to edit as it's composed with all the profile-settings we have, merged in one place (single file).

Actually I've been using my own-personal custom method which to some degree is similar to the proposed 'separate-profile' scheme. I have several copy of FSUIPC4.INI which has been carefully edited so as it contains only a single particular profile that are already set, tested and fully working. I put these INI files, each into the its appropriate 'profile-defined' aircraft folder. Whenever I plan to fly this aircraft, I just copy this FSUIPC4.INI back to 'Module folder', using a simple batch script to automatically rename the exisiting FSUIPC4.INI in the Module folder and then copying the one from aircraft's folder. I know It's rather cheap, quick-n-dirty, but at least it works for me so far ...

I found it simply saves me a lot of time and effort while I have to edit and manage its settings, and make me feel more secure from accidental errors or being overwritten as I have such fail-save-backups of my profiles.And whenever necessary, I can now edit this less-cluttered FSUIPC4.INI anytime I need to do some modification or just refinement.

Personally, that 'quick-n-dirty' trick so far already fulfill my requirement, so that I'm not really in hurry nor intending to hurry you to get the proposal being implemented so soon without a thorough review. So, take your time to read my previous post (*but, please forgive my English. I know there's many sentences which are grammarly-incorrect and confusing *), At least you may find some key-points that might be useful for you to make decision whether it's feasible or not to be implemented.

 

I might shelve all this till next Summer, when I'm stuck at home because the dear wife has lots of gardening to do. Much of next year we are otherwise travelling. Part of our "retirement" plan -- see and do as much as we can whilst we are able. And next year we will have been married 60 years, so there's extra involved.

Sixty-years! That's surely one marvelous achievement of live which deserve my personal acknowledgment at the greatest level than your marvelous FSUIPC. Congratulation, Pete.

*I learn something new here, that programming and gardening are compatible each-other. My wife and I have same interest, well, sort of ... I love virtual flying, while she loves he job in Virtual Aviation Authority, who regulates all aspect of virtual aviation, such as monitoring pilot flight hours & duty time, determining flight equipment' and addons aircrafts to conform the airworthiness walletworthiness standard. :D

Regards,

-xcorez-

[xcorez]

Pete,

This came accross while i was composing my post above and exploring my FSX module folder to lookup the FSUIPC documents. There came the new idea (oh, no! not again!  :D )

Basicaly this is quite similar approach of using separate file to store profile-specific settings. But instead of put that file into its appropriate aircraft's folder, we put all that profile setting files in "Module" folder, preferably in a dedicated sub-folder i.e "Profiles".

In this scheme, the [PROFILE.name] section will have quite similar function as the [MacroFiles] – [EventFiles] – [LuaFiles] sections that are used to register and call the related external files. So, literally the [PROFILE.name]  should still be set and kept in FSUIPC4.INI (like in current scheme), whereas the other relevant profile-specific sections goes into the a separate setting file.

Therefore, we need to apply MANDATORY 'file-naming-convention' of the referenced file to its referencing parameter, so literally the settings 'file-name' MUST be equal to its 'profile-name' as defined in FSUIPC4.INI

 

For example, we only keep this profile-specific setting section in FSUIPC4.INI :

[Profile.TwinProps]
1=Baron 58
2=King Air 350
...

and then move its relevant profile-specific sections into a separate file in "Profiles" sub-folder, named as "TwinProps.PFL"  which contains :
(*.PFL file extension to be defined later.) 
 

[Axes]
PollInterval=1
RangeRepeatRate=10
0=0Z,128,F,65765,0,0,0
1=0R,128,F,65764,0,0,0
2=0U,128,F,66291,0,0,0
3=0S,128,F,66292,0,0,0
4=1X,32,F,65763,0,0,0
5=1Y,32,F,65762,0,0,0


[JoystickCalibration]
Aileron=-16380,-256,256,16380
Elevator=-16380,-256,256,16380
Rudder=-16384,-256,256,16383
Throttle=-16384,16256
Mixture=-16384,16128
PropPitch=-16384,16128
..
..
..

[Buttons]
PollInterval=20
ButtonRepeat=60,1
0=CR(-0,2)0,12,C65615,0
1=CR(-0,2)0,10,C65607,0 
2=CP(+0,2)0,10,C65706,0
3=CP(+0,2)0,12,C65706,0
4=W0366=1 P0,27,C1003,3844
5=W0366=0 P0,27,C1004,3844
6=CP(F-15,3)1,3,C66415,0
7=CP(F+15,3)1,3,CL2:R,0
..
..

[Auto]
1=Lua NavComm
2=Lua ArduTrimmer
..
..

etc.

Note the section names. I think the sufix 'profile-name' will be no longer required to append to the section header, as each particular profile has now been 'grouped' into its own file which named as 'profile-name.extension'

Indeed, I haven't analyze this proposed scheme quite thorough. But, roughly comparing to the "aircraft-folder-centric" scheme — this "module-folder-centric" scheme has advantage of being much easier to manage since we can keep all those settings files in one place (sub-folder). So, while we open this sub-folder, we can tell at-a-glance what profiles currently we have.  Diagnosing and comparing settings of two or more profiles will even more easier to do.

Whenever necessary we can just duplicate an existing profile (as whole or partially) to another profile easily without having to edit the section header name. This will also allows us to combine section(s) of one profile with another profile sections, so this will provides the same 'flexibility' as the other proposed method of profile's section 'aliasing' or 'referencing', without have to introduce 'new parameter' that seems quite daunting for most users.

However, the major drawback of this scheme is — once being adopted, should be applied globally to all existing profiles at-once. So, to ease the conversion it requires a new routine to 'extract' the existing profiles from FSUIPC4.INI into separate profile-setting files in the pre-defined sub-folder, whereas the sub-sequent processing of these separate profile-specific setting file will be pretty quite seamless to users. This is something we have to put into consideration before adopting this scheme.

Regardless which of these two proposed schemes is most feasible to be implemented, the primary objective is quite the same — that is to provide more efficient setting/configuration file(s). The benefit is not limited to users who mainly do manual editing their profiles-setting, but also applies to mostly (if-not-all) users.

 

By having distributed settings in separate settings file, we are no longer have to be worry about losing all of our settings at-once. If something bad happens, we can safely reset the main FSUIPC4.INI to its defaults, whereas our profile-specific settings — especially ones that have taken a lot investment of time and effort to setup — are safely retained in their own setting-file.

Indeed, maybe it looks complicated by having several files instead of single file to manage, but in term of safety —   10x100 is better than 1x1000  — even it's mathematically incorrect.


Regards,

-xcorez-

[Pete Dowson]

Indeed, maybe it looks complicated by having several files instead of single file to manage, but in term of safety —   10x100 is better than 1x1000  — even it's mathematically incorrect.

 

Actually I don't agree. I would always prefer the one file. Just consider the complications if you reinstalled Windows or changed your controls. Using joy letters to overcome the change of joystick ID is easy to manage programmatically for one file, but trying to sort it out on who knows how many files could be a nightmare.

 

However, I like your last idea a lot better than the others, so I will consider it.  But even if I did it, it would not be enforced because I think most users of Profiles really don't need so many variations. I want to keep it simple for simple use, and I don't think multiple files does that. Also, even if the option were taken i don't think I'd want to implement any automatic conversion. The difference between those Profiles placed separately and those kept in the INI would need to be denoted by something in the Profile section name in the INI, i.e. a reference to the file, maybe even a pathname so you could, if you wished, store them with the aircraft.

 

But for the present my mind is boggling. I'm going to leave all this till late Jan at the earliest. I had my easy solution in mind and was prepared even to do this before Christmas, but I can see this will not please everyone. Really, I admit that I don't understand why there is a need for so many different settings. When I implemented Profiles I had in mind siimple classifications like "Prop", "Turboprop", "Jet", "Helicopter", "Fighter", "Stunt". I'm not getting the picture where almost every model of every type needs some subtle differences. I can see that the odd aircraft might be so different it needs really different settings, but most, surely not?

 

Oh, BTW, that "60 years" was a typo -- 50 years not 60. Sorry. I an only 71 next year. We didn't really get married when I was 11 years old! ;-)

 

Regards

Pete

[Pete Dowson]

But for the present my mind is boggling. I'm going to leave all this till late Jan at the earliest. 

 

Well, turned out to be nearly June before I found time, and then, once I knuckled down to it, I had a working solution ready in a few days! ;-)

 

However it needs a good testing before I let it out generally. If either or both of you (xcorez and aua668), or anyone else for that matter, are still interested in pursuing this and can do some testing, let me know and I'll provide the updated version of FSUIPC4. 

 

The facilities are based around having separate INI files per Profile, saved in a separate subfolder. The main INI file still contains the list of aircraft in each profile, and you can, if you really wish, have a mix -- some profiles in the main INI, others separate in their own file -- but a single Profile can't be split.

 

I've even implemented an automatic conversion. 

 

I just now need to do a little write up, by way of documentation, and it'll be ready to try -- over the weekend for sure. So, let me know.

 

Regards

Pete

[aua668]

Hi,

 

Thanks for that information. As soon as you have something to test just let me know. And you didn't commit in which year you will do it - just not earlier than Jan :razz:

 

Rgds

Reinhard

[Pete Dowson]

Please download FSUIPC4934a.zip.

 

You will find instructions inside. Please give it a good bashing and let me know how you get on.  Bast to make a backup copy of your INI (the auto conversion also does this, but just to be safe for now). Then if you want to do different tests you'd only need to restore that and delete or rename the new Profiles sub-folder

 

I'm not a user of Profiles myself (I only fly one aircraft each on two different hardware sims), so whatever I do here with the facilities would be completely artificial. I have tested the logic of the code and everything works as I have documented it for me, in my simple test cases.

 

Thanks & Regards

Pete

[aua668]

Pete,

 

I tested the version 4934a und FSX and P3d V2.2 under Windows 7/64 . In both simulator versions the profile files were created as stated in the supplied documentation. I tried to change settings and they were set in the correct file. I then changed settings in the profile files via editor and reloaded the setting in FSUIPC. Also this test went well. The files are now much less cluttered and easier to handle.

 

So for me it worked perfectly (as always with your products). Great job!

 

Thanks

Reinhard

 

[Pete Dowson]

So for me it worked perfectly (as always with your products). Great job!

 

Thanks for testing. I'll release it as it stands, I think. Next major release will probably be for P3D version 2.3, but I've no idea when that'll be. Probably when I'm next on holiday -- it's happened that way every time so far!

 

Pete

[aua668]

Next major release will probably be for P3D version 2.3, but I've no idea when that'll be. Probably when I'm next on holiday -- it's happened that way every time so far!

 

Pete

 

 

So please go for holidays. You have fun and the growing P3D community gets new features and improvements from LM ;-)

 

 

Rgds

Reinhard