Pete Dowson

  • Content count

  • Joined

  • Last visited

  • Days Won


Pete Dowson last won the day on May 13

Pete Dowson had the most liked content!

Community Reputation

114 Excellent

About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Near Stoke-on-Trent, UK
  • Interests
    Flight Simming, Steam Railways, Table Tennis

Recent Profile Visitors

17,991 profile views
  1. Sorry folks, another break. This time for two weeks in Poland, enjoying Polish Steam Trains and delicious Polish beer! ;-) Please help each other as much as possible, and Thomas will no doubt be around for anything no one else picks up. Thanks! Pete Dowson
  2. Sorry folks, another break. This time for two weeks in Poland, enjoying Polish Steam Trains and delicious Polish beer! ;-) Please help each other as much as possible, and Thomas will no doubt be around for anything no one else picks up. Thanks! Pete Dowson
  3. Aha! The previous FSUIPC log shows that there was a crash, so FS did not close down properly. The details, actually shown by FSUIPC (instead of Windows) shows the crash was at location 5098183D, which it lists as being in DINPUT8.DLL, which is the Windows library involved in DirectInput. So it seems you have a bad or corrupted Direct Input device -- one of these most likely: 0=Saitek Pro Flight Rudder Pedals0.GUID={6D7C8EC0-0EF7-11E7-8001-444553540000}1=Thrustmaster Virtual Game Controller (root)1.GUID={FABB19E0-8BDC-11E5-8005-444553540000} How it got corrupted is another matter. Have you perhaps had a PC crash, or a power outage, or switched the PC off without closing down recently? Try disconnecting AND uninstalling both devices, including drivers, from the Windows System-Device Manager. Then check loading FS again (saying Yes to the question about running FSUIPC and trying more than once if necessary). If it is okay, connect one device at a time and check after each. The "Thrustmaster Virtual Game Controller (root)" sounds like a driver anyway, not an actual device. Is it software you have installed which does other things with some Thrustmaster device? Can you use it okay without? If so it would be better. Windows native DirectInput drivers are best with FSUIPC (and with FS in general, really). Pete
  4. FSUIPC installing does NOT delete any files, so what happened to the INI and LOG? Did you delete them? If FSUIPC did not run, why didn't FS start? The Windows error you post above says it crashed in AI_PLAYER. That's to do with AI Traffic. Perhaps you have a corrupt add-on traffic file? The Install log isn't relevant or useful. The last FSUIPC log would have been useful though. As the FAQ subforum threads say about FSX not starting with FSUIPC even though FSUIPC never runs, you have to try to tell it to run a few times, sometimes. I think Windows sometimes marks it as bad for some reason, possibly because you are occasionally having FS actually crashing when you close it down -- FSUIPC is often the last part still running. It would be worth your while taking a look art relevant FAQ threads (it's a reference subforum above). Pete
  5. Yes, that statement is still mostly true, though I have investigated how difficult it would be to convert FSUIPC to 64-bit, and it is definitely doable if and when necessary, at least as far as the program interface is concerned. I'd be less sure about some of the user facilities. To start with I'd probably discard all the weather fiddling stuff in the options, which are largely redundant these days with programs like Active Sky, Opus, and so on doing all these things much better. Anyway, I'm on holiday soon for two weeks. Back 26th May. Pete
  6. Do you have any Lua plug-in scripts running? That's the usual problem fixed this way. That/s the Sim's "user interface", mainly used for menus, so it's a bit odd. Pete
  7. You'd need to use a small Lua plug-in to do it, assigned just to the ON event. So you'd only have two lines in the assignments, both facilitated in the Options (no need for INI editing operations), The Lua script would simply send the control (ipc.control function) then sleep(2000) then send the control again. Three lines of script, that's all. Pete
  8. Well it has been, for several weeks, yes.. But with my latest changes I think all will be well -- provided nothing is getting in the way. From your description whatever IS in the way is messing up P3D's ability to read it properly as well. Sounds just like a toggle switch assignment to some shortcut provided by your add-on aircraft. It isn't implemented in P3D itself that I know of. However, I don't know why you'd even consider using the nose wheel steering on the rollout. Just the rudder should do to keep you straight on the runway, including the turns for those "high speed turnouts". For other turnouts you should surely be well under 30 knots in any case. With most aircraft (not the VRS?) you could actually assign your steering axis to FSUIPC's own direct steering control, which uses the rudder, but for which you can use calibration to adjust the effect separately to the rudder axis input. Then, once you are on the ground, FSUIPC gradually changes from using rudder to steering input for the sim's rudder control, between 60kn and 0kn, with them about level at 30 (the 60 limit is an INI parameter). This makes things feel very realistic, both for takeoffs and landings. Oh, and sorry, but I don't really have time, especially this week (away early Wednesday) to investigate the link you provide, but if the normal steering controls in P3D don't operate to steer your aircraft you'll need to find out how to do it. For that their website would seem more appropriate in any case. FSUIPC can only directly support those things implemented withing the sim itself. Pete
  9. There is ALWAYS an INI as well as a LOG file. The INI file is where all your settings are stored. You have Windows hiding filetypes from you so you'll have files just called "FSUIPC". As stated in the FSUIPC installation, and in the User Guide, it is best to turn that annoying and stupid option off (or, possibly turn ON "show filetypes", I don't recall which way around it it). Meanwhile an INI file might just be described as "configuration settings" (which should be a good clue in any case!). FSUIPC reads everything that the device provides, it doesn't pick and choose. It arrives in one block. The fact that it is getting anything shows that it is using the correct information, the GUID in particular. Both X-55 Stick and Throttle provide 2 each, and one on each reads nothing. You were luckier than some having 4.966c get the right GUID without me having to mess in your Registry. (4.966m fixes it by determining in advance which GUIDs work and which don't -- this is the story tabulated in the Spreadsheet csv file you provided. I think you have some Saitek software running which is interfering with the ability of both P3D and FSUIPC receiving all of the data. You either need to uninstall it, or program things correctly in that software. Alternatively you need Saitek support. I am testing X55 here with NO Saitek software or drivers or anything from tthem installed at all, and they work perfectly. The names listed for controls in the assignments are those provided by P3D, not by FSUIPC. I don't even know what the all do, but in this case, even if I hadn't tried it, I would have thought it obvious that steering is relaled very very closely to the nose wheel steering. What else could it be if not? No idea what you mean by HI/LOW gain, sorry. If you did that just to provide this file you wasted your time i'm afraid. The JoyScan file is purely concerned with recording all the stages involved in detecting and setting up the devices in the first place. It completes its job with the writing of the [JoyNames] section in your (unrecognised) INI file, which is also when the Log file underscores the end of the "Joystick Device Scan" section. Pete
  10. No, it isn't at all. Look at the evidence: 1. BOTH logs show completely successful sessions with FSUIPC running and closing normally. 2. The error Windows shows that FSUIPC wasn't even loaded:What is "P4: FSUIPC4.dll_unloaded" What is happening is that it isn't being loaded -- something is stopping it, yet SimConnect, the part of FS which is loading it, still tries to enter it. This causes the "BEX" error which is basically attempted execution of data or rubbish as if it were code. If you read the FAQ about this (in the FAQ subforum) you will see it is always best to tell it to try running. It often recovers. The error on loading, occurring even before FSUIPC starts, is generally caused by a previous session which crashed on exit rather than closing down correctly. When the sim is closed properly, FSUIPC has threads which are among the last to close. These are threads doing things like tidying up any loaded plug-ins, ensuring connected applications know what is happening, and, if WideFS is being used, notifying the other PCs so that the closure is tidy all round. So, next time it happens you need to look for a PREVIOUS crash, not "FSUIPC_Unloaded", which might help explain what caused a crash on exit. Pete
  11. As I said, I was lucky enough to get the similar X-55 donated for testing. To start with one part worked, and the other didn't. Then I got them both working and my USB hub blew! With the new one they decided to change GUIDs quite oddly -- one took a GUID previously associated with the other. Weird. They've actually changed in ways that FSUIPC would have lost them at least twice. Anyway, in the end I decided my code was too complicated and i didn't understand it any more. It's grown horribly over the years. So I chucked it all and started with a fresh plan. This was on Wednesday night. I completed it yesterday, tested it and did some corrections this morning, and I've just uploaded it as 4.966m for folks to try -- but, as I said, I'm away on Wednesday for two weeks so I don't want any feed back till 25th May! ;-) Please see the Download Links subforum for details. DO keep your current FSUIPC4.DLL and INI files safe to restore in the event of problems. When you do (later) send me feedback (positive, hopefully!) please include not only the LOG and INI files but also the new FSUIPC4.JoyScan.csv file. That files saves a real heap of logging! Pete
  12. It is fixed in an Interim update 4.966m, which you will find in the Download Links subforum soon. But take care -- do save your current FSUIPC4.DLL and FSUIPC4.INI files first so yuo can go back, as there are a LOT of serious changes in this test version and I need feedback for users. Please read the instructions BEFORE downloading! But no feedback till after 25th May please. I'm away till then! Pete
  13. It depends on the assignment and the calibration. With PMDG aircraft in particular, and I think the Aerosoft Airbus, it is inadvisable anyway, no matter how FSUIPC does it, to use FSUIPC calibration for the throttles, because even if it uses events it has to feed them in at a lower priority that those aircraft monitor them. FSUIPC has to do this to avoid feedback loops. Those aircraft take the values at the same priority level that FSUIPC does, though FSUIPC bypasses that level if you elect to "send direct to FSUIPC calibration". Then those aircraft probably don't see it at all, and the FS engine beneath changes without their control -- which may or not be a good thing. Pete
  14. Okay. How are the buttons programmed? To set bits or toggle them? Single bits? Hmm. Good spot. Yes, actually, there is a little logic problem in FSUIPC, and as Thomas implied, originally caused by the strange way FS has implemented those buttons. If you set bit 6 whilst bit 7 is still set. Bit 7 still takes priority. Looks like this problem has been in FSUIPC forever -- strange, either no one else has found it before, or has done and not reported it! I'll fix in the next update (end of the month, unfortunately*). Meanwhile, either use Thomas's suggestions, or simply try toggling both bits -- i.e if you are programming, do an exclusive or of 3122 with 0xC0, so 80 changes to 40 and 40 to 80. For assignments just assign Offset Byte Togglebits parameter xC0 or 192. Toggling the bits is actually logical -- after all the COM1/COM2 button are toggling. You don't seem to be able to turn transmitting off at all, they are just mutually exclusive with one always on. Pete * Since I've changed the code here for this already, it will be fixed in the next interim update, hopefully today or tomorrow. But that one will NOT be a replacement, but a test release. I've completely re-written the Joystick scanning and axis and button identification system because it was all getting too complicated, so much so even I, the author, couldn't understand it! This was precipitated by X-55 and X-56 oddities, but it's been coming. The point is though, I can't yet trust it as a fully working release. I'll only release it for trials and feedback.
  15. No it won't -- the data inside is in a completely different format. And renaming it will probably prevent P3D loading it. Pete