Jump to content
The simFlight Network Forums

Pete Dowson

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Pete Dowson

  1. As well as what Thomas says, you do really need to use the Installer. Just moving files is not sufficient to tell P3Dv5 to load and run FSUIPC. The Modules folder is not actually normally used with FSUIPC6 in any case. FSUIPC5 was the last to need such a folder. You can choose whatever folder you like when installing FSUIPC6. Pete
  2. I don't know any reason why it shouldn't, but I've not had a WinXP system to test anything on for years. Certainly some of my programs will no longer work on something so old. Pete
  3. There is a control "SIM RATE SET" which should do it. It never did anything in FSX, but you could see if it now works in P3D. I'm not sure what the parameter should be though. Whilst 1 sounds sensible, internally a sim rate of 1 is represented by 256, so it may well be 256. the larger number was to allow fractional sim rates -- like your 1/2 which would be 128. Assuming it still doesn't work, which is likely, then really you just need to be more careful to press your assigned button just the once -- I assume you've not set it to repeat? Pete
  4. If it is a simple process of reacting to GSX events then possibly a Lua plug-in could do it all, more simply than having an external program interfacing to FSUIPC. Otherwise John is correct of course - better to use the FSUIPC SDK or the .Net client. To interface to FSUIPC use the FSUIPC SDK or Paul Henty's .NET DLL. The P3D SDK will enable you to use SimConnect, build scenery, and make aircraft models, but unfortunately the Local variables used in aircraft panels and add-in DLLs such as that from GSX are only available to other in-process programs -- hence FSUIPC which already has L:Var access built in. Pete
  5. Ah, if the values are available via Lvars, then you can either use a Lua plug-in to read them, or program an FSUIPC interface into your program and use the offset facilities to request the LVars. The Lua facilities are documented in the Lua PDFs installed with the FSUIPC documentation, and the interface to FSUIPC is documented in the FSUIPC SDK. Or you could use Paul Henty's .NET DLL. Check this thread: Pete
  6. Wouldn't it be better to ask this of the GSX authors, or at least on their forum? Not sure how you think this relates to FSUIPC? Pete
  7. Okay, understood now ... John evidently understood it was this you were having problems with, and informed me privately. I was thinking more in terms of the use of the device(s) with assigned buttons. Pete
  8. There are no delays from the PFC driver side. it simply sends it on after calibration (which is merely a short arithmetic calculation). The rest is up to the Sim. Is it just with that aircraft? What sort of delay are you talking about? I use a similar driver for my GA28R cockpit, one made by Aerosoft Australia and modelled on a Piper Arrow. Sadly there are no Piper aircraft at all available for MSFS at present, so i too try the C172 -- the bare bones version, as I have old-fashioned working analogue gauges in the hardware. I've not really noticed any delay, but I think it might depend on your expectations. Pete
  9. Not sure I said anything to disagree with. The FSUIPC PTT facility was designed originally for Roger Wilco, and the standard method used by RW was adopted by Squawkbox and others. i have no idea how IVAO implement it, but if the FSUIPC PTT action doesn't work then you needed to find out what from IVAO, as I said. It looks like you've found that out now, and it appears they did not follow the standard way (which is actually a Registered Windows message) but offered a key press method instead. A lot of add-on programs rely on keypresses. FSUIPC doesn't cope with every such option in all such programs by inventing specific controls to send a keypress when it i just as easy to assign a keypress in the first place. Anyway, well done for finding the solution and thanks for posting the details for others. Pete
  10. The Install log appears to indicate otherwise: Checking version of the FSX EXE:... Version which clearly indicates a version of Prepar3D version 4. This isn't surprising since the FSX install path in your Windows Registry gives SetupPath="C:\Lockheed Martin\Prepar3D v4\" This is confirmed by the sequence: How your Registry got in such a mess I don't really know. A complete uninstall of FSX and re-install should fix it. It would be quicker to edit the Registry directly, using RegEdit, but take care to make a Restore Point first, then using RegEdit go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 and edit the SetupPath parameter to point to wherever you put FSX. Pete
  11. Yes. It's only supposed to ignore that option if you've not yet got a valid COM port set. I've just checked, and this is due to a difference in timing during loading. it looks like the option isn't applied early enough. I've modified the DLL for this. Please try this version and let me know: pfccom64.5051.zip Pete
  12. There was no need for a picture! Why not just say you tried the PTT assignment I suggested? If the PTT assignment doesn't work it will because the version of IVAO software doesn't recognise its actions. I'm afraid you need to seek help from IVAO. I've never used any on-line ATC program myself. Pete
  13. You are using Windows XP still? I hadn't noticed that in the Log, sorry. I'm actually a little surprised FSUIPC itself still works on XP. I don't think later versions of FSUIPC (5, 6, and 7) will run on anything earlier than Win 7. BUT if the 4.974 installer worked, I know of no reason at all for the 4.975 one to fail. The changes in the Installer are only related to the detection of later SimConnect and FSX-SE versions (specifically the final Beta release of FSX-SE by Microsoft). Is there nothing in the Windows Event Viewer? On the original problem, have you tried eliminating a possible weather file corruption? If not, try deleting all the .WX files in your FSX Documents folder, and deleting the wxstationlist.bin file in the FSX AppData folder. FSX will make a new one when it starts next. If that doesn't help then I really think that you should re-install FSX. Pete
  14. But if they both arrive only the one which is assigned will have any effect. FSUIPC doesn't act on un-assigned button presses (except during assignment). Using Profile-related assignments would be your solution, surely? You are not constantly re-assigning actions are you? Pete
  15. Could you do some elimination on those? Quickest way is to try FSUIPC with none of those then add one at a time, see which one is involved in the crash. So something has changed. No additional add-ons? No updates to add-ons? Ah, that is different. FSUIPC is trapping the error with the offset read/write, so that in itself won't crash FSX -- that's the point of it being trapped in FSUIPC. It may be the other way around: whatever is causing FSX to crash also causes the problem in FSUIPC. So, maybe it isn't being caused by an FSUIPC add-on, but one of the others. So we need to eliminate those too. The CPU upgrade presumably then required a Windows re-installation. And update? Did you re-install FSX afterwards? Seems quite a lot of changes to investigate. I doubt that it is hardware related. It'll be some corrupt software somewhere. Pete
  16. There's no Push-To-Talk facility built into flight sim. There is one added by FSUIPC which should be in the assignment drop down: "PTT on" and "PTT off". These might work with IVAO, but that's another matter. If not you'll need to contact IVAO support to see how to operate their PTT. Pete
  17. As well as John's suggestion, if they are looking distinct, with distinct assignments in FSUIPC, why not use Profiles and only assign to one or the other? Pete
  18. The error appears to be when some add-on application tries to do some offset writing / reading. Can you list the FSUIPC applications you are using, please? Also, try the latest version (4.975a). Please use the <> parentheses (see the editing options bar above the message entry area) to envelope text files like INI and LOG, rather than show them directly in your message -- the spacing makes the INI file quite difficult to read. Or, alternatively, ZIP them and attach them. Pete
  19. So you can do what you want immediately with MSFS? With all jet aircraft and props with reverse? Yes. I use to glue a little piece of card cut into a triangle which overlapped the lever groove a little, to mark the idle position. These days I have separate reverser axes, which can be assigned separately in FSUIPC. I must admit I'd not heard of such a facility in MSFs. Seems oddly unrealistic for something like that to be implemented as standard. However, it appears that others have had this idea before -- see this thread in the User Contributions subforum above. I think you'll not need to spend a long rainy autumn weekend on it after all? Pete
  20. I may be misunderstanding this, but with the throttles so assigned in FSUIPC, if you make sure the "No reverse zone" option is off in the calibration tabs (which i think it is by default), and calibrate a "centre" (idle) zone, the reverse thrust is obtained on the same axes by pulling back beyond the calibrated idle position. That's the normal way of having reverse on the same levers. It gives you whatever range you need to reverse control -- normally you'd calibrate 4/5ths of the movement to forward thrust and just 1/4th to reverse, but you can choose exactly where to place "idle". Pete
  21. Is the only change you made upgrading from FSUIPC5 to FSUIPC6? If you made no other changes, no Windows updates, no P3D4 reinstallation, then all the settings in your FSUIPC5.INI file must still apply after renaming to FSUIPC6.INI if they were left intact. To help we do need to see the FSUIPC6 INI file, so please supply that. The FSUIPC6.LOG file would also help us to see that things are loading okay. Pete
  22. That indicates that they are registered in Windows as digital, not analogue -- i.e. on or off only. The only way I know of fixing that, without editing the registry, is to uninstall the device and any drivers, via the Windows Device Manager, then re-booting and reconnect the device so that its proper details are recorded. If you want a more definite way, or if re-installing it as above doesn't work, then check this for registry editing: I know it refers specifically to Saitek, but the principle is the same for all joystick devices. Pete
  23. As well as what Thomas said, if you start a continuously-running Lua plug-in (i.e. one using events) in ipcReady, or via an [Auto] section (or by assignment), then the event.sim function can be used to detect and act upon the closing of the simulator. I'm not sure how well this currently works with MSFS, mind. Pete
  24. The "AP HEADING HOLD" control is a toggle, so that should do it. You can have multiple assignments to the same button. To do this you would need to edit the assignments in the INI file -- details are provided in the FSUIPC Advanced User guide. Alternatively, ifi t's a push button you are using, then you can assign one action to the press and the other to the release. Pete
  25. FSUIPC6 is for Prepar3D v4 and v5 only, not X-Plane. There is a subset implemented by another parties for X-Plane, called XPUIPC. I would guess they've done their best to implement some compatibility, but i really couldn't comment on how much as i've never used it. With FSUIPC, developed since FS98 and over the years covering all the versions of FSX and P3D, we have always striven to maintain compatibility with previous versions as far as possible. So there's a good level of compatibility between FSUIPC6 on P3D and FSUIPC7 on MSFS. After all, MSFS is in many ways just continuing the line (actually from FSX rather that from P3D, so a different branch of the family. But again I cannot say whether this applies to X-Plane with XPUIPC. 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.