Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    168

Everything posted by Pete Dowson

  1. It can be as simple as copy these files over from your previous FSUIPC6 installation foder: FSUIPC6.INI all *.Lua files all *.Mcro files your Profiles folder, if one exists (if not, don't worry, it's an optional folder). It will help enormously if you were using Joy Letter on your old computer, because then the different identifcations of your connected controls (joysticks) be be very easy to adapt to the new PC. If not, and you still have the old computer up and running with P3D it would be worth your while connecting the devices back as they were (same sockets if possible), and enabling joy letters there first. then run P3D once to get the letters assigned correctly. One you have set up the new PC a revised FSUIPC6.INI file will be generated and you should be able to see if any adjustments are needed. If you come back here for help, attach the old and new FSUIPC6.INI files. Pete
  2. Changing individual weather values isn't always successful due to the quirks of the FSX/P3D weather interface, which is very convoluted. You would normally have to first put the weather system into Global mode (i.e. the same weather everywhere). That can be done via the New Weather Interface (see below), You need to understand that there is no weather actually defined for every spot on the globe. The weather is only defined at Weather Stations (as listed in wxstationlist.bin). The weather elsewhere is calculated by extrapolation. So to change the weather in one place you need to change all the nearby weather stations (by ICAO ID). The more reliable way is via the METAR strings, as John suggested, or using the New Weather Interface (see the document in your FSUIPC SDK). The METAR strings set weather at weather stations (you give the ICAO ID). You can set the global or general weather that way too, but that only takes effect if you put the weather into global mode except that the global setting is also the default weather for any weather station for which no METAR has been read. Also try using WeatherSet2 to see what happens. That uses the NWI. One last thing: sometimes the weather changes slowly to your settings. This is deliberate. No one likes sudden changes. If you want more immediate and much easier controls you need to revert to the less well simulated weather in FS2000 and before. It got more and more complex after that. Most of the offsets other than the NWI and the METAR string method date from the very early versions, and, whilst FSUIPC does its best to apply them, it is well nigh impossible without prior settings paving the way. Nowadays, with such high quality weather setting programs avaialable, some of which are using much more complex hooks into FSX/P3D, the facilities to set weather via FSUIPC is much less used, and the those weather programs which do use it use the METAR string or NWI methods. Pete
  3. Yes, as described in the documentation. The numerical Id is used internally and the details in this section allow FSUIPC to derive the correct numerical ID to the letter, which is not at all related to anything internal to windows. Pete
  4. With encoders like your trim wheel you need to assign to both press and release -- each click is only a press or a release, alternately. That alone doubles the speed. You could also always alter the amount of trim from each press. There's a section on how to do that in the User Guide -- search for Offset Increment/Decrement Controls (it's on page 27 in my copy). If you want two different speeds of increase you'd need to use a Lua plug-in. There's an example in your Example Lua Plugins document. It's called 'rotaries.lua'. It would need adapting for your device and needs. Pete
  5. Research the ProSim configuration facilities, like I did. Sorry, I can't instruct you. My motorized trim seems to work fine from the standard FS offsets for trim, even with the trim axis assigned in ProSim. The way you talk, ProSim can't manage motorized trim wheels. I'm sure that is not true and in any case you should be able to relate your trim wheel position to the normal FS trim offset. I'd pursue this on the ProSim Forum if i were you. it really isn't an FSUIPC problem to solve -- unlike, possibly, the crash you reported and for which, as I said, John may need much more information about what ProSim was trying to do at the time you went into the Axes settings so forcing a rescan of devices. I am now thinking that might have been to do with whatever your Trim driver software was doing. Either way, what you are now asking is still nothing to do with whether you have ProSim in SimConnect or FSUIPC mode. I don't know why you are still confusing this. I think this will be all from me on this topic. You seem not to read all I say. Why not try just switching to SimConnect mode (as in fact you said you were using in the first place!). Pete
  6. No, I can't see and I'm not going to try to magnify your pics. Please never bother to post pics. They are no substitute for proper explanations in words! If they are offsets to drive the motor for the wheels I'm sure that you can assign to those AND have them assigned in ProSim. None of that is, however, anything to do with whether PS is in SimConnect or FSUIPC mode. As I said, that mode is concerned with how it controls the aircraft in the Sim, it is not at all related to any your control inputs. Pete
  7. Why not use the actual controls for Trim Up and Trim Down? You make it more complicated than it need be. Pete
  8. Are you assigning trim in ProSim as you must to allow it to control the aircraft correctly? If so, you really need to talk to Humberto about it. Sounds like you have something wrong. Almost all my hardware is driven through FSUIPC but I assign all my axes via FSUIPC offsets in ProSim -- and ProSim is set to run in SimConnect mode (Even though that cockpit is on P3D5 I chose that mode to relieve the traffic going through FSUIPC). If you are insisting on trying out MSFS with ProSim I think you need to expect some teething problems. I have MSFS on my VFR cockpit (a Piper Arrow III) and still need to sort out quite a few oddities. It was perfect on P3D5. Does your setup work okay with ProSim on P3D5? In SimConnect mode? Pete
  9. Turn off the Event logging, or put the event numbers in a "DontLogThese" list (see the Advanced Users manual). Many advanced aircraft constantly and repetitively send loads of events to themselves. A thorough waste of processor time in my opinion! BTW your chosen thread title is misleading. They aren't non-existing events. They plainly exist as you see! Pete
  10. I think you misunderstand that part of ProSim. Assigning a control via FSUIPC won't need PS to be in FSUIPC mode. The PS mode is to do with how it controls the Sim. It is nothing to do with how it gets inputs from controls. I don't mean anything by it!! I was just quoting (that's why it shows as a quote!) what i found out about the error. If you actually read it all you would see that was only one possibillty. Pete
  11. But when I asked about the PS mode you said "SimConnect Pete"! Why have you changed? The only information I can find about that error is: So I think John will need to know what the last changes were that PS tried to make through FSUIPC, as it seems very likely to be some clash between those requests and the joystick scan FSUIPC does each time you enter the assignments menus from Axes or Buttons. I suggest you try PS in SimConnect mode, as I'm sure is currently advised. I am even using SimConnect mode on my P3D5 cockpit despite all the hardware being driven by my own drivers through FSUIPC. Pete
  12. Note that WideFS's facility to send local button presses to FSUIPC won't operate with the normal FSUIPC joystick IDs 0-15, and won't be covered by the extra information I was proposing. I assume you must at least be testing your .NET application on the FS PC? With Visual Studio you can install a debugging server on the main flight sim PC, and still use the VS debugging facilities on your development PC to debug your program on the flight sim PC. Pete
  13. It is one of the files in the Installer ZIP you downloaded. You are meant to read it BEFORE you run the Installer It doesn't get installed! It is part of the assistance for installing correctly, along with the Installing and Registering FSUIPC7 document, also in the ZIP file! Pete
  14. You really should read the documents provided in your Installation ZIP file. There's one called README.txt, which title asks you to read it. In there you'll find details of the fix for the exact problem you are reporting: Problems running FSUIPC7 ======================== 1. If you receive the following error when running FSUIPC7: The code execution cannot proceed because VCRUNTIME140_1.dll was not found. Reinstalling the program may fix this problem. Please see https://answers.microsoft.com/en-us/windows/forum/all/vcruntime140dll/8fe4965d-2013-49cb-816e-17cc2bb0c077?auth=1
  15. Further to what Paul suggests, the FSUIPC Log file contains more details, including the VID and PID IDs: 672 Product= Saitek Pro Flight Quadrant 672 Manufacturer= Saitek 672 Vendor=06A3, Product=0C2D (Version 2.2) 687 GUIDs returned for product: VID_06A3&PID_0C2D: 687 GUID= {33BA5110-5CD5-11EB-8001-444553540000} 687 Details: Btns=9, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X255,Y255,Z255 plus 719 Device acquired for use: 719 Joystick ID = 4 (Registry okay) 719 4=Flight Throttle Quadrant 719 4.GUID={33BA5110-5CD5-11EB-8001-444553540000} So the Joystick ID number can be matched up, via the GUID. I expect it would be easy enough for FSUIPC to put the Vendor and Product IDs into two 16 WORD arrays in offsets (cost 64 bytes of offset, so that much free space would need to be found), one pair for each ID number 0-15. You'd need to post a request in the main Forum so John will see it. but, beware, only FSUIPC6 and FSUIPC7 are still in development. And John is very busy with MSFS matters (but if he agrees, I could assist with this change, at least for FSUIPC6). Pete
  16. It IS that SimVar, with the sign reversed and the value scaled to the same range as that offset used to have in earlier versions of FS. Possibly you need ELEVATOR DEFLECTION PCT instead (the value in 0BB4)? If you write to it, then read it back, do you see something different? Pete
  17. So, why can't you restart it without also restarting MSFS? Especially as ProSim isn't dependent upon FSUIPC if you have it running in SimConnect mode. And aren't you supposed to assign all axes in ProSim in any case? Anyway, you still haven't supplied the most essential data -- the crash details from the Windows Event Viewer. Otherwise the Log isn't a lot of use. Pete
  18. Just download and run the Installer. There are instructions included in the ZIP file. You actually posted in the Download Links subforum (incorrectly -- it isn't for support requests), so you know where it is. You can also download from FSUIPC.com. Pete
  19. Did you have this console working before? With which driver? I know of no reason for any buttons or axes not being recognised, though i admit I have never seen a throttle lever fitted with buttons except the one fitted for me by PFC is my PFC737NG cockpit. But that's using the old serial protocol, not HID like the cirrus. Do you have a test program supplied by PFC which allows you to verify the operation of these switches and buttons? As far as I remember, all 6 possible quadrant axes, plus the yoke and pedals, are treated like normal joystick devices and assigned to whatever you want -- prop pitch or more throttles, for instance, to support 1,2,3 or 4 engined planes, jet or turbo or simple prop. Please use the logging facilities built into the PFCHid64 driver. You'll see you can have a Console display for that (but turn off the FSUIPC one -- only one console can be owned by a process). You can log the Comms (very much logging would ensue), the Data (a bit less data) and the Decoded meaning. Start with just the last and see what it gets for those switches. I'm not in a position to test here nor do any more PFC development, as I don't have the requisite hardware now. PFC driver development for FS terminated many years ago. The only recent change was recompiling for 64-bit, for use with P3D4 and P3D5, and it is that version being applied to MSFS. Incidentally, the button I think you are calling "go around" is the A/T disconnect button. the TOGA button is normally fitted lower down. And I think there was only one carb heat switch on the Cirrus I had for a while. FS only supported one in any case. I don't recall the R-Alt button. Is that the one used for ALT mode on the autopilot? If so I know it as ALT. Not sure what you can adjust on a radio altimeter -- it just measures your altitude from the ground provided you are low enough for the radar to operate. And if you want me to look at anything, please supply the Logs themselves, nit a moving picture of them which I cannot read. Pete
  20. Retrieve it from your SimMarket Account, as it tells you for lost keys in the FAQ sub forum above.
  21. You really need to refer to the WideFS documentation, NOT any old googled texts. The documentation is supplied for good reason and tells you what to check. The Protocol parameter is only necessary to overcome a Broadcasting problem which ALSO needs you to specify the ServerIPAddr parameter! The WideClient.INI you posted shows neither have been added. Is 192.168.1.20 the correct IP address for the PC running FS9? If so the most likely problem is your firewall. Try disabling it. Pete
  22. It isn't the different PFC hardware (the hardware is fixed and dealt with already by the PFChid driver). I think you mean the different aircraft options. As John say, the aircraft in MSFS seem to vary in what controls they need to see for various functions. To handle such variations the PFChid driver uses FSUIPC's Macro facilities. So first you need to construct FSUIPC macros which operate the aircraft function you need. The macro names are fixed and relate to the switch or encoder on the PFC hardware. These names are listed already for you in the PFCmacroindex file. Please see the section in your PFChid documentation entitled: Macros: configuring a PFC HID device for FS add-ons Unfortunately this PFChid provision doesn't work for L:Var access because macros for L:Vars use the L:Var name as the macro name. I'll talk to john about how that possibility can be addressed. Pete
  23. Lvar support is still in development for FSUIPC7. This is the list of limitations (from the Announcement above): Missing Functionality The following functionality is not currently available in FSUIPC7. We may look at re-instating some of these items at a later date, if and when such facilities are provided by the MSFS SDK: 1. Mouse Macros (and other mouse functionality, e.g “mouse look”, etc): pending facilities to be provided 2. lVar access: pending facilities to be provided 3. AI Traffic management (Traffic Limiter and Zapper): pending facilities to be provided. Note that the offsets for AI traffic are populated. 4. Text display facilities: pending SimConnect functionality (some basic functionality may work) 5. Menu facilities: pending SimConnect functionality 6. Weather: apart from a few variables concerning ambient conditions at the aircraft, no other weather information is currently available for reading or updating Of those good progress is currently being made on item 2, but there is no sign of any useful facilities being planned by MS/Asobo to help with the others. 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.