xcorez

just a little correction, it should be 16 joystick devices; 32 buttons per joystick. -xcorez-

Have you tried to reset the FSUIPC.INI ? It seems your INI contains some duplicated and/or corrupted parameters. The same paramaters in my FSUIPC.INI shown as : .. MinimumVisibility=1 MaximumVisibility=2000 MaximumVisibilityFewClouds=6000 MaximumVisibilityOvercast=2000 MaximumVisibilityRainy=1000 OneCloudLayer=No ThinClouds=No ThinThunderClouds=No CloudThinness=1000 ThunderCloudThinness=10000 .. I do recommend to rename your current FSUIPC.INI (ex. FSUIPC_BACKUP.INI) in the Module folder. FSUIPC will automatically create a new INI with initial default settings. Check the above parameters related to the visibility setting. If it works okay, you can copy the rest of parameters back from your backup INI. Regards, -xcorez-

Those butttons won't be recognized as normal DX buttons by FSUIPC if they have control-assignments that were set by Logitech Profiler. Sorry, I don't have G940, but perhaps this "Tutorial - How to set up Logitech Flight System G940" might helps you to find the right way of setting those button as standard DX buttons so as to be recognized by FSUIPC. regards, -xcorez-

In FSUIPC4 (for FSX), the WideServer is already included as 'built-in' facility, so you will NOT find WideServer.DLL and WideServer.INI in the module folder as they're no longer required. The WideServer setting has been merged into FSUIPC4.INI, under [WideServer] section. To assign your joystick button as Teamspeak remote PTT using FSUIPC4, do the following steps : Set your button using 'Buttons + Switched" facility page, Select "KEYSEND 1-255 (WideFS)" for Button Press AND Button Release action, Enter different KeySend number into each their PARAMETER box, e.g 1 for Press & 2 for Release. (These number MUST equals to the KeySendN number used in WideClient.INI inside your remote WideFS folder.) If it has been set properly, the button settings in FSUIPC4.INI may look like this : [Buttons] 0=P0,7,C1006,1 ; KeySend SCRLCK PRESS 1=U0,7,C1006,2 ; KeySend SCRLCK RELSD * Note the button parameter value (1 & 2) And its corresponding settings in WideClient.INI : [User] UseSendInput=Yes KeySend1=145,16 ; SCRLCK PRESS KeySend2=145.24 ; SCRLCK RELSD * Note the KeySendN number (1 & 2) It's better to properly set the KeySend settings in WideClient.INI first, run WideClient.exe and then set the button in FSUIPC afterwards so you can immediately check the button setting whether or not it's working. Regards, -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-

Hi Marco, I've been using IvAp User Interface on the remote 'Client-PC' which also run WideFS. That's my common setup used while flying in IVAO. (Unfortunalety I don't have much enough time recently, so mostly I fly on FSOpen multiplayer now for such a quick and short flights that doesn't require any flightprep) So to anwer your question, YES, you can run both the IvAp UI and WideFS on the same Client-PC. But as Pete said, it's not required. However, if you have WideFS, you may optionally (but recommended) to use FSUIPC 'KeySend' facility to program one or more of your joystick buttons on your 'FS-PC' (PC that's run your FS), to act as the Teamspeak PTT button, and/or Hotkeys of certain IvAp function (TCAS window, Transponder mode, Squawk Mode etc.) on 'Client-PC. Optionally, you may also install Input Director (Free) on both your FS-PC and Client-PC, so you can use keyboard and mouse of your 'FS-PC' as remote-input-device of your 'Client-PC'. With this setup, you can input text msg, commands or for filling the flightplan form directly from FS-PC, without having to switch to Client-PC's keyboard/mouse. Hope you'll find this useful. Regards, -xcorez- edited. PS. Pete, I've just read its manual at-a-glance, IvAp uses FSUIPC in populating its TCAS table of online traffic. Marco, you can find the detail about how to set WideFS for Teamspeak PTT on IvAp Manual.

Pete, let me first quote some points from my previous post as key points in answering your question, 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. 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. 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-

Hi, Pete Sorry to not have replied earlier, but considering I'm a slow-typer — this is my new personal record! :D 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 (?) 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. 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. 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.

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.

Not sure if the OP still need these Simvar to be listed on FSUIPC offsets. But for references, they are "LAUNCHBAR POSITION" and "LAUNCHBAR SWITCH" as documented in FSX Acceleration SDK of Carrier Operations and Notes on Catapult Launches. There's also "LAUNCHBAR HELD EXTENDED" which is triggered by the "HOLDBACK BAR INSTALLED" Simvar. The related FSX controls which already mapped in FSUIPC offsets are TOGGLE LAUNCH BAR SWITCH (66879) and SET LAUNCH BAR SWITCH (66880). Understood. personally I don't have specific neccessity of additional FSUIPC offset(s) for such those 'unmapped' SimVars in my daily regular use of FSUIPC for interfacing my controller hardware to FSX. I still able to cope with those Simvars simply by using XML to create custom LVars as 'intermediating- variables' which can be used in FSUIPC LUA scripting. So far this way works perfectly on my setup, thanks for the marvelous FSUIPC features. And honestly, rather than the addition of extra control offsets to the list I'm more expecting FSUIPC will be able to have "more efficient profile-specific setting" feature that should be easier to manage. Anyway, as not to hijack this thread any furher I'll discuss this on the original thread of its relating topic. Regards, -xcorez-

Pete, i think what he mean is "the control offsets for FSX Acceleration simulation variables" such like this 'Launchbar' SimVars. (* and i'll be very gratefull if you could also add those heli-specific new simvars eg. rotor Disk Pitch/Bank Angle, Coning etc :) ) Michael, you can workaround this by converting/transform the Launchbar SimVars to custom Lvars using an XML gauge, <?xml version="1.0" encoding="utf-8"?> <Gauge Name="Launchbar Status" Version="1.0"> <Comment> FSXA SimVars to Lvars for Launchbar status Insert this gauge in one of [VcockpitXX] section. </Comment> <Element> <Rectangle Width="1" Height="1" Color="transparent" FillColor="transparent" Bright="No"/> </Element> <Update Hidden="Yes" Frequency="6"> (A:LAUNCHBAR POSITION, percent) (>L:LaunchBarPos, percent) (A:LAUNCHBAR SWITCH, bool) (>L:LaunchBarSwitch, bool) (A:LAUNCHBAR HELD EXTENDED, bool) (>L:LaunchBarExtended, bool) </Update> </Gauge> so that you can read the Launchbar LVars value for FSUIPC LUA scripting ( * via ipc.readLvar or event.Lvar since it's non-set-able variable *). Regards, -xcorez-

The combination of "ShortAircraftNameOK=Yes" and "UseProfiles=Yes" requires the first-part of aircraft's name string listed in the appropriate [profile.XXXX] section of FSUIPC4.INI. Initially, if we choose a profile from FSUIPC dropdown list for "new/unassigned aircraft", FSUIPC will write its full name string to the selected profile. So, it's a common practice to check the "Title=" in the AIRCRAFT.CFG and manually edit the [profile.XXXX] sections in FSUIPC4.INI for automatic profile assignment according the "ShortAircraftNameOK=Yes/No/Substring" setting. e.g from initially [profile.TWINJETS] 1=Boeing 737-800 Paint1 2=Boeing 737-800 Paint2 3=Boeing 737-800 Paint2 ..etc to [profile.TWINJETS] 1=Boeing 737-800 for "ShortAircraftNameOK=Yes" or [profile.TWINJETS] 1=737 for "ShortAircraftNameOK=Substring" regards, -xcorez-

Graham, I found this Microsoft ESP online documentation about "Camera Configuration" does work for customizing FSX camera definition, and there's also an article in FSDeveloper Wiki about "Camera Views - Changing" about using saved flight .FLT camera definition for further tweaking your aircraft's camera definition. Once you have tweaked a customized camera definition for desired perspective/POV, it will be more easier to incorporate it into your existing LUA script, or XML gauge. For LUA, use ipc control 66851 - 66861 to call a specific camera defined by the HotKeySelect 1-10 keys. For XML gauge approach, call these predefined cameras via VIEW_CAMERA_SELECT_# key events. I'm sorry if this looks more complicated than it should be. I'm just trying to share it as one of viable solution to your initial query of : That's almost the same case while I was searching for a solution of automatic view switching on Slings/Hoist deployment. And for FSX, i came to a conclusion that the camera definition tweaking is far more easier rather programming a dedicated simconnect client to access and modify its STRUCT EYEPOINT datas and variables which is beyond my knowledge. Regards, -xcorez-

Are you using FSX? If so, you may alternatively fiddle with the "Camera Configuration" and "Camera HotKeySelect" setting instead. Make a new camera definition in the aircraft.cfg, adjust its variables to your liking ( ie, "InitialXyz", "InitialPbh", "InitialZoom") then set its "HotKeySelect" key ( #5-10 available, defaults are 1-4) so you can assign a keypress or joystick button to activate this custom view anytime you wish. example. [CameraDefinition.XXX] Title = Cockpit - Landing POV Guid = {10EB1B1C-FFAA-44cf-9E23-DE622E32C70C} Description = 2D Cockpit view for approach/landing sequence. Origin = Cockpit ShowPanel = YES SnapPbhAdjust = Ordinal SnapPbhReturn = TRUE PanPbhAdjust = Ordinal PanPbhReturn = TRUE Track = None ShowAxis = FrontOnly AllowZoom = TRUE InitialZoom = 0.60 SmoothZoomTime = 1.0 ShowWeather = YES ShowLensFlare = FALSE XyzAdjust = TRUE InitialXyz = 0,6,-40 InitialPbh = 12,0,0 Category = Cockpit CycleHidden = YES HotKeySelect = 8 To make this custom view available globally (applies for any aircrafts), add/modify the camera definition in camera.cfg (%APPDATA%\Microsoft\FSX\Camera.CFG). For automatic switching of these views/cameras triggered by undercarriage up/down, try this simple LUA script, -- init landing pov ldgpov = 0 function gearstat(offset, val) if val ~= 0 and ldgpov == 0 then ipc.control(66858) ldgpov = 1 else ipc.control(66851) ldgpov = 0 end ipc.sleep(1000) end event.offset(0x0BE8, "UW", "gearstat") or, optionally by using an XML gauge : <?xml version="1.0" encoding="utf-8"?> <Gauge Name="Landing POV" Version="1.0"> <Comment> Automatic view-switching. Triggered by landing gear toggle. Change the "VIEW_CAMERA_SELECT_#" in the macro section below that suits to your aircraft's camera definition. </Comment> <Macro Name="NORM_View">(>K:VIEW_CAMERA_SELECT_1)</Macro> <Macro Name="LNDG_View">(>K:VIEW_CAMERA_SELECT_8)</Macro> <Update Hidden="Yes" Frequency="1"/> <Keys> <On Event="GEAR_TOGGLE"> (L:LandingPOV) ! (A:GEAR HANDLE POSITION,percent) 50 > && if{ @LNDG_View 1 (>L:LandingPOV) } (L:LandingPOV) (A:GEAR HANDLE POSITION,percent) 50 < && if{ @NORM_View 0 (>L:LandingPOV) } || </On> </Keys> </Gauge> Make a new folder named "custom" in main FSX "Gauges" folder. Copy and paste the XML code above into a new text document inside this "custom" folder, then rename it as "landing_pov.xml". Edit your aircraft's PANEL.CFG, append the following code into its [Window00] and [Vcockpit01] section : gauge99=custom!landing_pov, 0,0,1,1 I hope this method works on your setup. I haven't check all those script aboves thoroughly, just made some modification from my custom Sling/Hoist viewports I've applied on helis. Regards, -xcorez- HC006XC

The "pan-view" movement in FSX is defined in "camera.cfg" and can be overriden by custom camera defintion in "aircraft.cfg". Change the PanPbhAdjust=Ordinal to PanPbhAdjust=Swivel from the FSX SDK documentation : Regards, -xcorez-

You may try to use "conditional buttons assignment" for the hatswitch buttons, e.g 100=W8320!1 R0,34,C65672,0 ; PAN IN VC/EXTERNAL VIEW 101=W8320=1 H0,34,K102,8 ; KEYPRESS IN 2D PANEL VIEW so, for the above example if you press the POV-RIGHT button while in 2D panel it generates keypress (NUM-6) and operates normally as PAN button in other view modes (VC, external, top-down). Just change the keypress assignment above to your predifined key for each of HAT buttons (32-39). If you use that FIXED-VIEW XML gauge, maybe it's also possible to assign the hatswitch buttons for PANEL ID OPEN/CLOSE/TOGGLE directly, 100=W8320!1 R0,38,C65672,0 ; PAN IN VC/EXTERNAL VIEW 101=W8320=1 H0.38,C66507,10001 ; OPEN PANEL ID 10001 (CUSTOM FIXED-VIEW) 102=W8320=1 U0.38,C66507,10001 ; CLOSE PANEL ID 10001 I hope this will be helpful, Regards, -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 : 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-