Pete Dowson

Mouse macros are only supported for aircraft panels and switches. The Flight Map is a build in Window. I've had a look for you. There is a Panel ID for the Flight Map ("HELPID_GAUGE_FLIGHT_MAP" = xAB8F) so i tried manipulating it using the PANEL_ID_OPEN and PANEL_ID_CLOSE controls with that ID as parameter -- to no avail I'm afraid. Looks like the only way is to use the mouse to click on the Close button. Pete

If the buttons are programmed generically -- i.e NOT whilst in a profile, or with the profile check mark off -- then the apply all the time unless overridden in a profile. But if you programmed then whilst in a profile and with the profile check mark on, then they ONLY apply to that profile. That's the whole point in having profiles, so you can have different settings for flying different aircraft. I've never heard of profile selection by airport -- I don't know how you'd do that. You normally use the Sim's scenarios for that. I think you maybe mixing up FSUIPC's profiles and the saved flights or scenarios you have? the latter are to do with the Sim, nothing to do with FSUIPC. FSUIPC's profiles are changed automatically depending on the aircraft you load. Maybe you'd better show my your FSUIPC INI file (the one with the settings in) and tell me which button assignments keep "disappearning". Pete

There is currently no menu system provided in MSFS, and seemingly nothing like it planned at present. Radar Contact is, unfortunately, a menu-driven program. You could look at using something like Pilot2ATC which is voice driven and has no menus. It is being used successfully with MSFS. Pete

Your settings are recorded in the FSUIPC INI file. They cannot be changed without you visiting the assignments tabs in the Options and changing them, or by you or some other outside influence editing the file. Files simply do not change themselves and lose lines. I suspect you are just using Profiles with different settings and have some otherwise similar aircraft registered in different profiles and you are thinking they should be the same. It really sounds like you need to tidy it all up if so. Pete

Here are the Axis assignments you have for the Profile for the Alabeo Aztec: [Axes.Alabeo Aztec] RangeRepeatRate=10 0=AX,256,D,4,0,0,0 -{ DIRECT: Throttle }- 1=AY,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 2=AZ,256,D,6,0,0,0 -{ DIRECT: Mixture }- 3=AU,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 4=AV,256,D,6,0,0,0 -{ DIRECT: Mixture }- 5=BX,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 6=CX,256,D,1,0,0,0 -{ DIRECT: Aileron }- 7=CY,256,D,2,0,0,0 -{ DIRECT: Elevator }- 8=CP,0,F,66416,0,0,0 -{ TO SIM: PAN_VIEW }- You will see that you only have a Right Brake assignments, none for the left brake. No wonder you get the "Differential brakes" message. And is axis X on your CH Pro Pedals really your right brake? Seems most unusual. I notice you have no rudder assignments. I would expect X to be left toe brake rather than right. Your generic assignments, those for non Profiled aircraft, are these for the same pedals: 3=BX,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 4=BY,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 5=BZ,256,D,3,0,0,0 -{ DIRECT: Rudder }- i.e axis X assigned to Left brake, not Right. And Right brake and Rudder assignments too, which seems a more useful set. You also have two different axes assigned to the Mixture control. Mistake? Maybe you just need to redo your assignments in this profile, and make sure you complete them, and the correct way around? Looking further, I see you have another Aztec profile: [Profile.Aztec] 1=AH_Piper_Aztec 2=Alabeo PA23 Aztec F 250 WHITE 3=Beech Baron 58 Paint1 with these Axis assignments: [Axes.Aztec] RangeRepeatRate=10 0=AX,256,D,4,0,0,0 -{ DIRECT: Throttle }- 1=AY,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 2=AZ,256,D,6,0,0,0 -{ DIRECT: Mixture }- 3=AU,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 4=AV,256,D,6,0,0,0 -{ DIRECT: Mixture }- 5=BX,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 6=BZ,256,D,3,0,0,0 -{ DIRECT: Rudder }- 7=CX,256,D,1,0,0,0 -{ DIRECT: Aileron }- 8=CY,256,D,2,0,0,0 -{ DIRECT: Elevator }- This is different in that you have the Left brake assigned to axis X, but no Right brake, and also two mixtures, but at least it includes a Rudder. Pete

Sorry, then. without the relevant settings I can't help. The only possibly explanation of the "Direct" label in the Calibration is that the assignment was still direct, not the AXIS ones to FS as suggested. I suspect you had a different profile active to the one you did those assignments for. Just change your assignments to FS controls "Axis ... Set" as suggested. I'm sure this will solve it. There really is no puzzle here. And please do understand that there's really little point in asking for help without supplying the relevant information, so please, next time, do only supply files which relate to the report you are making. Okay? Pete

Yes, the option to REVerse the axis is certainly part of the calibration you need to do. If you read that section of the User Guide you will find easy step-by-step instructions for proper calibration. This is because the INI you attached shows that there are no (ZERO) assignments to AXIS_THROTTLE controls. ALL of your assignments are "Direct to Calibration" except the STEERING _SET and RUDDER_SET assignments on most of the profiles. You have NOT changed your assignments to the AXIS_ ones listed for FS controls at all! Pete

Yes. There's no access to LVars through normal SimConnect functions, so FSUIPC needs the internal module (the WASM) to obtain them and supply them through data facilities in SimConnect. Why the question? The WASM module does no harm. Pete

Thanks John, but I've had to update it to 5.127 (for the change mentioned just above). Pete

Okay. I'll update MakeRunways to do that. Meanwhile there's already an update for LPPD released on Orbx and updating it via Orbx Central seems to have worked with the ã replaced by a. I'd guess that MK Studios or Orbx have realised the problems with strictly illegal characters in pathnames and have changed it already! Pete

I noticed you were using MakeRunways version 5.11. The latest one, which I was checking is 5.126, and that is the currently supported one. Possibly version 5.11 has got code in to show the hex value of non-ASCII characters, as I added such code when working with Pelle Liljendal to try to determine how bad characters were getting into an airport name (not a scenery path). So please try 5.126 and let me know:. It is certainly available in the DownLoad Links subforum (Useful Additional Programs thread). I notice the text on FSUIPC.com still says 5.11 even though it does link to the same version. Pete

It isn't just MakeRwys. The Lorby-Si AddOnOrganizer doesn't like the ã character either, saying the path is illegal. I suspect something similar occurs in the Lorby-Si scenery list exporter which MakeRwys uses. In my case I have edited the path name to change the ã to an a. If I don't do that I can't use AddOnOrganizer to manage my scenery library. When MakeRwys produces XML files it takes care to "escape" those characters not defined for XML use, but ã should be left as is. The escaped characters are just: & => &amp; " => &quot; ' => &apos; < => &lt; > => &gt; and those are all. So I'm not sure what is converting the ã -- there's nothing in MakeRwys doing it. Are you sure it isn't the editor you are using? I'll check here next time my system is up and running, but if you rename the file as test.txt instead of runways.xml does it still show the ã as xE3? If not then it is the XML reader being used which is converting it. If this is the case then can you try changing the first line in the file to <?xml version="1.0" encoding="Windows-1252"?> Perhaps that encoding instruction will stop this happening. If so it's an easy change in MakeRwys. Pete

I think the highest I've seen actually defined for PMDG Boeings is +14659 ( = 84291) -- for the 747QOTSII. That higher value could be from almost any add on. I don't know any way of identifying the source, but the aircraft being used is the most likely. Maybe an internal unpublished PMDG control. Pete

Controls can be sent via offset 3110. Pete

They show everything working well. Pilot2ATC is using the facility well: 1786984 **************** Individual client application activity **************** 1786984 Client 1220 requests: 4670 (Ave 2/sec), Data: 6129012 bytes (3435/sec), Average 1312 bytes/Process 1786984 *********************************************** So if running Pilot2ATC detracts noticeably from the performance of your MSFS installation then either 1 your MSFS PC is underpowered from what you are asking it to do, ot more likely 2 you are letting MSFS run as fast as it can with no limits and therefore notice small drops when these are occurring because of other things happening. To deal with the latter you need to limit the frame rate in MSFS, for example by setting the Vertical Sync option. To deal with the former you may need to reduce some of your settings for MSFS graphics and maybe choose a simpler aircraft to fly. I see Milan has made some more technical suggestions relating to your Network. I would never have thought of anything like that, I just use the network as it is -- my main 737 cockpit uses a Network of 10 PCs using WideFS for many external programs as well as ProSim, another Network user, and I aim for and achieve a smooth 25 fps with Prepar3Dv5. Except over London I could easily get a smooth 30 fps, but I like dense scenery. (I don't yet use MSFS on that system because it uses two projectors for a 200 degree field of view out of the cockpit and this cannot be done yet with MSFS). One thing you could change in your WideFS configuration which may help a little is to use UDP protocol instead of TCP. To do this use the parameters ServerName=DESKTOP-O2B600O Protocol=UDP in the [Config] section of the WideClient.INI file (in your WideClient folder). Pete Pete

Don't forget also to try fsuipc.com. Pete

WideFS is only doing what P2A requests of it. The proper test to show that it isn't WideFS causing the problem is surely to stop P2A running instead. Note also that MSFS will use as much processing power as you allow it, and any other activity on the same PC (such as that instigated by add-ons like P2A, even if via WideFS) will be noticeable as stutters. Make sure you limit MSFS frame rates to something your PC can manage consistently whilst running your add-ons. You omitted to supply the WideClient.Log file from the P2A PC, which is in fact the most important, as it will show if WideClient was having problems. The only odd thing showing up in the files you have supplied is the number of repeated Device Scans logged in the FSUIPC log. The scans only occur in two circumstances: 1 visiting the axis or button assignments options in FSUIPC, or 2 there's some USB reconnections occurring. If you didn't keep opening those option windows, then you need to check your USB connections. Maybe you have a Hub which is playing up. Pete

You missed the normal sim axis controls "Axis ThrottleN Set". The ones you are selecting use half of the range for reverse thrust, so the forward thrust uses only 0-16383. The Axis ... Set controls are the ones P3D would use and don't have a reverse range so use -16384 to 16383 for forward thrust. The direction in which axes work is controlled by the "REV" option in calibration. For proper support you need to supply some real information. You don't even say what version of FSUIPC you are using. Please supply your FSUIPC INI file so we can at least see your settings. You'll find that in the FSUIPC installation folder. Also take care to ensure that you are not running any other software specific to the Honeycomb devices, and that you have controllers disabled properly in P3D. Pete

ZIP it first, as I said. It's a text file and zips up really small. And don't enable additional logging options unless asked. That's what normally makes log files too large and more difficult to analyse. Pete

You need more than that. The set of files with good explanations in on the link provided in the place John pointed you too, i..e Just click this link first, then read and follow the link there, the one to GitHub. I did that in order to check that the Lua plug-ins being used are using facilities which are available in FSUIPC 3.9 -- and they are! You will probably need to adapt them for your aircraft though. It won't be the same as the one these were written for. Pete

John will need to see your complete FSUIPC7.LOG from a session which crashed. Please ZIP it up and attach it. You can check it yourself to see if FSUIPC7 actually was terminated correctly, probably because MSFS had crashed (no longer running). And in Event Viewer, always look further then the first crash notice -- there's usually one for MSFS just preceding it (i.e just below it in the list). Pete

Good to hear! Happy flying. Pete

Well it doesn't appear to have been used there. Still, if it was you'd certainly have encountered the same "multiple actions" problem. Yes, just delete it before starting FSX. Yes. Everything concerning FSUIPC in the FSX Modules folder. Please don't forget to download and install the current version of FSUIPC4. Pete

You attached two INI files, but neither show a file which has been used by a running copy of FSUIPC -- they look like they've been edited quite a bit. for example, the [JoyNames] section doesn't identify any devices actually connected: [JoyNames] AutoAssignLetters=No J=Saitek Cyborg Evo Force J.GUID={72295FC0-D3CF-11E0-8001-444553540000} T=Saitek Pro Flight Throttle Quadrant T.GUID={5CB02AD0-353A-11E1-8001-444553540000} R=DTA Rotary Encoder << MISSING JOYSTICK >> These show you HAD two devices attached, but the lines are missing showing they've been detected and giving the ID numbers. Now look at your [Buttons] section, You have many of the same assignments repeated -- I've separated the repeats out so you can see: [Buttons] ButtonRepeat=20,10 1=PR,1,C65880,0 2=PR,0,C65879,0 3=PR,5,C65893,0 4=PR,4,C65892,0 5=PR,2,C1027,0 6=PR,3,C65662,0 7=PR,9,C65607,0 8=PR,11,C65664,0 9=PR,10,C1029,0 10=PR,6,C65894,0 11=PR,7,C65895,0 12=PR,8,C65615,0 13=PR,1,C65880,0 14=PR,0,C65879,0 15=PR,3,C65662,0 16=PR,2,C65663,0 17=PR,7,C65895,0 18=PR,6,C65894,0 19=PR,9,C65607,0 20=PR,8,C65615,0 21=PR,5,C65893,0 22=RR,4,C65892,0 23=UR,4,C3,0 24=PR,1,C65880,0 25=PR,0,C65879,0 26=PR,3,C65662,0 27=PR,2,C65663,0 28=PR,5,C65893,0 29=PR,4,C65892,0 30=PR,9,C65607,0 31=PR,8,C65615,0 32=PR,11,C65664,0 33=PR,10,C65665,0 34=PR,7,C65895,0 35=PR,6,C65894,0 36=PR,1,C65880,0 37=PR,0,C65879,0 38=PR,3,C65662,0 39=PR,2,C65663,0 40=PR,5,C65893,0 41=PR,4,C65892,0 42=PR,7,C65895,0 43=PR,6,C65894,0 44=PR,9,C65607,0 45=PR,8,C65615,0 I've no idea how your arrived at this mess. Possibly you have been using Profiles at one time and then deleted the profile section headings -- [Buttons.<profile name>]? I can't see any other way you might have done this. Don't you have a copy of your working FSUIPC4.INI from the Win7 PC? It would be better to start from that. With this INI there are some steps you can take, but to be honest there's very little of any use in it. You might be better off deleting it altogether and letting FSUIPC build another. With just 12 buttons to assign, and all to standard controls by the look of it, that would be pretty quick to do. If you want to persist with this one, delete all but one of those blocks of repeating assignments. BUT if you want further support please update to a supported version of FSUIPC. You are on 4.80. The current version is 4.976. You can get it on FSUIPC.com. And next time please make sure you run FSX first before supplying the INI, and don't edit it before showing us. Pete

By not specifying the offset type/size, it defaults to an 8 byte (64 bit) floating point double. To use an FSUIPC offset control you need to choose an apprpriate size and type. In this case I assume it is just a switch which is on or off, so probably have values 0 for off and 1 for on. So you only need the smallest offset -- a byte. So: [LvarOffsets] 0=B738_Landing_Light_Left=UB66C0 Then you can assign to the Offset Byte Set control with a parameter of 0 for off and 1 for on, or if you just need a toggle, Offset Byte Togglebits with a parameter of 1. It's the same, but under the "Offsets" menu option. Pete