Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    37,984
  • Joined

  • Last visited

  • Days Won

    158

Everything posted by Pete Dowson

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. Thanks John, but I've had to update it to 5.127 (for the change mentioned just above). Pete
  7. 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
  8. 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
  9. 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
  10. 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
  11. Controls can be sent via offset 3110. Pete
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. They certainly don't do anything in the sim's built-in systems implementation. But there may be an indication internal to the specific aircraft implementation. I'm afraid i don't know that add-on aircraft so I couldn't say, but you could see if there's a local variable (L:Var) for them. You can list them using an assignable control in FSUIPC, or log them as they change using a Lua plug-in supplied in your Example plug-ins ZIP file. Pete
  22. I've no idea what this "npm" package is. Are you hoping someone here might be familiar with it? Maybe the authors have their own support places? You can write to offsets in FSUIPC by assigning buttons or keypresses to "Offset ..." controls, of which there are variations for different value sizes and formats. Pete
  23. Offset controls are NOT "custom controls", but are actually listed for selection in the drop down list, with all the other named controls, as Offset ... Please do READ what you are told. We are really trying to help, but you do need to read what we say. Here's what John said: So, scroll to that control in the list (or just enter "o" to get there faster). The offset entry field will be there when you select that control, but I think for the offset in hexadecimal (as A000 is) I think you may need to enter it as xA000. Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.