Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,023
  • Joined

  • Last visited

  • Days Won

    158

Everything posted by Pete Dowson

  1. Does it not register in FSUIPC's Axis Assignments tab? If not, check if it works in Windows own game controller. Calibrate it there first to make sure it is registered correctly in Windows. That looks okay. If you enable axis logging in FSUIPC does it log the PAN VIEW control? If so it is definitely getting sent to P3D (the log is from notifications by P3D's SimConnect). Just ZIP them! They are simple text files and ZIP up really small! Not for FSUIPC5, for which development has ended. You could put a request in to John for such an enhancement in FSUIPC6 or FSUIPC7, but I know for FSUIPC6 at least it is not a trivial job. The options screen is a standard Windows tabbed dialogue and it appears as that facility dictates. You could possibly try increasing the font scaling in Windows, making the text larger, but that might result in text partly disappearing outside its confining box. I know it used to on Windows 7 but Windows 10 may handle it better. I have a similar problem in that I have a 7680x2160 display on a large curved screen. The size is good enough, but the curving and the blending in the centre makes dialogues hard to use with mouse positioning. What I do is have another cheap small monitor to the side and have the options (and other things) positioned on that. If it a normal 1920 x 1080 monitor. FSUIPC will remember the position. Pete
  2. I upgraded to 5.2 and have no such problems. There really isn’t anything in FSUIPC these days which is dependent upon P3D differences. All that finished with the change from 32 to 64 but (P3D3 to 4). There will certainly not be an update simply because 5.2 has been released. I think you need to look elsewhere in your system. FSUIPC doesn’t ‘manage’ devices, it simply responds to signals from them. Your devices are managed by Windows and possibly your USB hubs. Check that your install of 5.2 has not reenabled P3D joystick processing. Pete
  3. No. If WideFs is enabled in FSUIPC (check that) the if WideClient isn't receiving the version number for FSUIPc then it is more likely to be a problem of communication between the PCs -- probably a firewall issue. You need to show the WideClient.log from the TC PC and the WideServer.Log from the P3D Pc. Pete
  4. I'm actually retired and have little to do with MSFS, and John doesn't work 24/7. I'm just trying to help. And you are not asking specifics. A specific is stating exactly what to want to accomplish, specifically, and then we can assist, specifically. Incidentally, if you truly want SimConnect SimVars as opposed to values derived from those and written for you into offsets, then why aren't you using the SimConnect SDK instead? Please do go and have a look and see how easy that is. I'm going out soon so there may be a delay till a further reply, unless you are very quick. Pete
  5. Reading offsets to get sim values is just a matter of using the relevant ipc.readXXX library function. You would need to refer to the Offset list to find the values you want , noting the offset value (0x????) and the size (signed or unsigned, byte, word, dword, float double or string), and read them in your script using the appropriate ipc.readXXX function. Many of the example Lua plug-ins provided show uses of these functions. Take the VAS_Monitor or the ThrustSym ones, for instance. You need to make a little effort to help yourself. We cannot spoon-feed you. Sorry. Pete
  6. Check the Lua Library document for event.terminate. That will call a function in your plug-in which can turn off your LEDs. If you don't understand Lua itself you will find lots of assistance on www.lua.org. There are also several good books on it -- start with "Beginning Lua Programming". But for many simply things the examples provided in the ZIP file should help. mostly, in simply plug-ins, the code is almost all calls to FSUIPC provided library functions, documented in the Lua Library PDF. We can help if you don't understand the library functions, but we cannot undertake to teach Lua. Pete
  7. When changing PCs the "GUID"s, which are guaranteed unique but which are generated afresh on your new PC, will be different. This section of your new INI defines which device each of your letters actually now refer to: [JoyNames] AutoAssignLetters=Yes 0=Controller (Gamepad F310) 0.GUID={AEE20C10-C9DC-11EB-8002-444553540000} 1=Flight Yoke System 1.GUID={FE9129C0-CA9B-11EB-8001-444553540000} 2=Saitek Pro Flight Rudder Pedals 2.GUID={FE9150D0-CA9B-11EB-8002-444553540000} 3=Saitek Pro Flight Quadrant 3.GUID={FE9BB110-CA9B-11EB-8003-444553540000} A=Controller (Gamepad F310) A.GUID={AEE20C10-C9DC-11EB-8002-444553540000} B=Saitek Pro Flight Yoke << MISSING JOYSTICK >> B.GUID={FE9129C0-CA9B-11EB-8001-444553540000} C=Saitek Pro Flight Rudder Pedals C.GUID={FE9150D0-CA9B-11EB-8002-444553540000} D=Saitek Pro Flight Quadrant D.GUID={FE9BB110-CA9B-11EB-8003-444553540000} E=Flight Yoke System E.GUID={FE9129C0-CA9B-11EB-8001-444553540000} If you can recognise which should be which you merely need to change the letters accordingly. I can see two which should be easy to change, but you first need to delete the two lines starting "B", as that one doesn't exist now. It would be much easier if you still had a copy of the INI file from your previous PC. Then the changes would be easy t do as you could match one to the other (or I could do it for you). I can do a little -- according to your [Axes] assignments A should be your Yoke and B your pedals, so instead of E: A=Flight Yoke System A.GUID={FE9129C0-CA9B-11EB-8001-444553540000} and instead of C B=Saitek Pro Flight Rudder Pedals B.GUID={FE9150D0-CA9B-11EB-8002-444553540000} that leaves just: A=Controller (Gamepad F310) A.GUID={AEE20C10-C9DC-11EB-8002-444553540000} D=Saitek Pro Flight Quadrant D.GUID={FE9BB110-CA9B-11EB-8003-444553540000} Strangely you don't seem to have any Throttle assignments for the quadrant -- only one throttle on the Yoke system. Aren't you using the quadrant? So, that just leaves some button assignments. Those appear to be either on the yoke system (already sorted), or device C. So: C=Controller (Gamepad F310) C.GUID={AEE20C10-C9DC-11EB-8002-444553540000} And that completes it, giving: A=Flight Yoke System A.GUID={FE9129C0-CA9B-11EB-8001-444553540000} B=Saitek Pro Flight Rudder Pedals B.GUID={FE9150D0-CA9B-11EB-8002-444553540000} C=Controller (Gamepad F310) C.GUID={AEE20C10-C9DC-11EB-8002-444553540000} D=Saitek Pro Flight Quadrant D.GUID={FE9BB110-CA9B-11EB-8003-444553540000} Try replacing the contents of the [JoyNames] section with that. Pete
  8. I've moved your message to the Support Forum. Please do NOT post support questions to any of the reference subforums. FSUIPC5 is replaced by FSUIPC6 and is no longer in development and is not sold. I think you must be wrong in any case -- there are plenty of Linda users on FSUIPC6 (and even FSUIPC7, for MSFS). Check with Linda support. Pete
  9. That's one way. Or just uncheck the assignment in the Axis assignments tab. If you assign another control in the same line (there are 4) then it will replace the previous one in any case. Unticking it instead allows you to change from "Direct to ..." mode to "Send to FS" mode, where you can access the Axis ... Set controls. Pete
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. Thanks John, but I've had to update it to 5.127 (for the change mentioned just above). Pete
  19. 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
  20. 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
  21. 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
  22. 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
  23. Controls can be sent via offset 3110. Pete
  24. 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
×
×
  • 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.