Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I see that no one else here has chimed in with any help. I think you need to seek help from the makers (Eaglesoft), especially as you appear to suggest that the problems are only with that aircraft. I don't see any way that FSUIPC is involved in any of the odd goings on you mention. It most certainly doesn't interfere with Throttle Cut and Throttle Decr (the default assignments for F1 and F2). The only thing likely to do that are conflicting signals coming from an assigned throttle axis -- i.e. a jittery device. Pete
  2. This is a common problem with Saitek units. The installation sets some axes incorrectly in the registry. Please see this thread in the FAQ subforum: This might simply be the Windows USB default setting for "power management". Look in Windows Device Manager, and check the Properties of all the USB hubs and other USB entries. Turn off power management where the option is present. Pete
  3. The problem there is that the error message is NOT from FSUIPC. Not only that, it isn't even a message related to any that we can see might be related to anything FSUIPC might report as an error. So the only people who can help are those responsible for the software which is reporting that error -- in other words, ProSim. I am also a ProSim user and have been for several years, and i do keep it up to date, but I know that the software is being developed all the time and some changes they make do cause errors to crop up on individual systems. So, as well as reporting it and asking for help in their support forum, it is a good idea to try other versions, later or earlier, of their software. It would help them as well as you if you can isolate it that way. Accusing us of throwing you out is unfair when we are trying to point you in the right direction to get the help you need. Pete
  4. Sounds like you have the mixture axis assigned in FSUIPC and it isn't set correctly, so the fuel flow is never enabled. Check your assignments. FSUIPC doesn't interact directly with any PMDG aircraft except where you have assignments to its controls via <custom control>.. Pete
  5. You can certainly play havoc with some of the systems, for default aircraft anyway, through FSUIPC offsets you can write to. There are some specific offsets concerned with instrument failures too, but i'm not sure how well they work. For add-on aircraft it might be another matter, though, as many of them have their own systems, programmed outside of the code affected by FSUIPC. As for the second part of your question, that is all completely in the realm of programming, and whilst with Lua it would certainly be easy enough to do, you'd need to learn more about Lua if it is new to you. I'm afraid I can't help directly there -- you need to refer to the very good reference and tutorial materials available on the www.lua.org website, and available in published books on Lua. Pete
  6. Hmm. Sorry, I cannot explain that. But I doubt that it is related to the number of USB connections, though I suppose you could easily check that by disconnecting all the others. I'm afraid that this is really a problem which needs discussing on a different Forum. I'm only really knowledgeable about the software I writeand support. Pete
  7. I don't really think a large number of USB ports in use will slow down your system. After all, most of the time they are not doing anything. What makes you suspect they are? A WideClient connection for devices will certainly work fine for buttons and switches, but joystick axes are not supported that way. this is mainly because the results would not be good enough. no matter how good the network, it could never be as responsive as a direct connection. If that screen is set as an extension to the main screen, via the Windows facilities ("extend my desktop"), then undocked gauges should work there. This isn't across a Network, of course. Pete
  8. But it only takes a moment to adjust. If it feels too sensitive for you, flatten the centre a little, if not sensitive enough, steepen it. There's no "testing", just fly it and see! Pete
  9. And as it says there, the transponder isn't used for or by AI aircraft. As well as what Thomas says, the Transponder code may well be available for multiplayer aircraft, but FSUIPC includes no support at all for multiplayer. The internals for handling such things by add-ons are likely available now, at least in P3D4, but you'll then need at least a program interfacing direct to SimConnect or, more likely, internally via the PDK interface. If the question is not answered for you via Squawkbox or other existing MP related programs then you'd be best off answking in the L-M P3D Support Forum. Pete
  10. I certainly wouldn't recommend PMDG's 737 for a cockpit build. It is no doubt the best free-standing solution, but it doesn't do well in a cockpit scenario at all. There are too many difficulties and too much extra software you'd need to write, or purchase (if available). Project Magenta used to be the best, and for a while, only, solution for cockpits of all descripptions. But nowadays, for 737NG cockpits soecifically , the real solution is ProSim737. It isn't cheap (neither is PM), but it has all you need for most hardware solutions. Don't take my word for it. This is the FSUIPC + WideFS support forum, not an advice place for cockpits -- try other sites too and review websites. There are several about cockpit building and the software solutions involved. Pete
  11. I'm not sure where you are getting those GPGGA lines from. The output from GPSout.DLL (the original), and the equivalent GPSout facilities in all of FSUIPC3, FSUIPC4 and FSUIPC4 versions is actually hard-coded to be a 1 in that position. I think you must be looking at something else? Pete
  12. Thanks for the further detail Hervé. I think I'll leave it be for now. This area of MakeRwys coding is complicated enough (in the "ugh!" sense) and i'll only mess things up. Pete
  13. Okay ... just loading up to check at UK2000 EGCC ... ... Ah, yes!!! See them! so all is okay -- except that ATC programs which provide taxi onstructions will get the wrong hold positions as there's no way they can "see" the visibly marked hold shorts! 😞 Pete ...
  14. Did you actually see the lines on the ground? That's my real problem. I'll have another look. EGCC is my home airport and will be quick to re-check ... Pete
  15. Good point. But in the airports I've looked at I don't there are any hold short lines. But I can check again. Also whilst I see more hold short points defined that I would have thought were essential, wouldn't the AI hold at every one, not just the last before the runway? Also the default automatically drawn lines have always looked okay to me. Seems a lot more work to superimpose thrid party ones. Thanks. Pete
  16. I have that one. Do you really mean the AIRAC stuff updated by the likes of Navigraph and Aerosoft's AIRAC service? MakeRwys only gets ILS data from the AFD BGLs . Is that where those pix you added came from? Evidently not, as you proved in the data you showed. As I said, since I didn't know you could have multiple ILS's for the same runway MakeRwys would not be likely to scan further once it found one. But I wouldn't know exactly what goes on without examining the code and checking an actual BGL containing such data. Would it be important for MakeRwys to include this data? I assume it would mean double entries in the assorted Runways files it produces. I don't want to change the format as too many programs depend on it. Also it would depend how those programs assimilate the data. If they are only expecting one ILS would the order in the files be important -- would they take the first and ignore the second, or would the second override the first? It could be a bit of a nightmare and not something ot be entered into lightly. BTW, I'll soon release version 4.88. We found that many recent airports (most of the UK2000 ones for instance) have the runway HOLD POINTS set as "NO DRAW" -- they are invisible. Why Gary has done this we don't know. Really it should be applied only to Grass and Gravel taxiways. Anyway, this type of hold point uses a different code in the BGLs, one not recognised by MakeRwys as a Hold Point. The same applies to ILS Hold Points. I've fixed this is 4.88 and when testing is finished I will be releasing it. Pete
  17. I don't know. I've never heard of twin ILS's for aone approach. Why would that be? Which would you choose and why? What program makes those displays of details? I expect that once MakeRwys have found one ILS it wouldn't search for another. but the code is now very old and convoluted and I'd really need a lot more details to delve into it. Are those Add-on airports you find these in, if so which ones? Pete
  18. Just a bit of clarification about that. If the controls are calibrated in FSUIPC then it will arbitrate between the two inputs, using the value with the most deflection from "normal". They won't conflict. This is the arrangement used for dual controls, caprain and first officer. But, Yes, for PMDG it isn't good to use "Direct to Calibration". The way their aircraft work simply doesn't like it, and you can get conflicting actions. Pete
  19. If you mean the Schiratti website, then the link there for FSUIPC4 says it is for 4.971, but will actually download the latest there is (the owner of the website doesn't unpate it much). Otherwise this is the only "website" dealing with FSUIPC. I don't know where you are seeing "the new version downloads". Can you explain? The only other official place for Downloads of my software is just above, in the "Download Links" subforum, here: No, that was a commerical derivative of FSX called ESP and which has been substantially developed as Prepar3D. In fact a license to develop FSX further was sold to DoveTail Games who released several versions via the Steam system called FSX-SE ("Steam Edition"). Kept me very busy doing FSUIPC4 devlopments for too many years. That version is also finished. (Microsoft have announced plans for a new Flight Simulator next year). The official Microsoft site for the FSX updates has long gone Just a quick use of "Google" just found this place https://www.patches-scrolls.com/flight_simulator_x.php I checked the links for the SP1 and SP2 updates and they still appear to work fine! No, updates don't change your settings (unless you delete them). Only replacement versions, like going from FSX to Prepar3D. Well, ProSim is pretty advanced stuff for a beginner. I know about slowing down though. I'm 76, and trying hard to become officially retired, so FSUIPC4 is no longer being developed and my son has taken over FSUIPC5 development, leaving me to tinker with my own P3D4 based 737NG cockpit and, yes, using ProSim. I only got into flight sims because I couldn't get a Pilot's Licence through tunnel vision (caused by hereditary Retinitis Pigmentosa). Pete
  20. 1. Please update your FSUIPC. We cannot support old versions. (You don't purchase a specific release. All updates to FSUIPC4 are free.) 2. You are also using the original bug-ridden version of FSX. There were two free updates, both free. 3. You have no axes assigned in FSUIPC, just plenty of buttons or switches on several devices. I ask again: how did you test? What does the log show when you enable button logging and press buttons or operate switches? If you are trying to operate buttons and switches in ProSim, then note that there are no direct ProSim assignments possible in FSUIPC. FSUIPC talks to Flight SIM, so will deal Flight SIM aircraft. FSUIPC is not specific to other add-ons. Please ensure you update FSUIPC before posting again. Pete
  21. Ah! LINDA use is different and I don't know it so cannot help. Please check with their support. Pete
  22. Testing this how? Is this with P3D4 or a different simulator. Please try to use the Logging facilities (Logging Tab) to see what is happening. You can log both axes and buttons. If you can't figure it out from that we'd need to see these files from the Modules folder: (They'll be FSUIPC4 ... if you are using P3D3 or earlier, or FSX): FSUIPC5.INI FSUIPC5.LOG FSUIPC5.joyscan.csv No, you don't need to use offsets for ProSim. You can assign axes directly once you enable the directInput driver. For help with ProSim you need to go to their Forums. That's where I have to go for help with my ProSim setup! Pete
  23. Well, FSUIPC 4.974 wouldn't have changed itself. Have you updated or changed the relevant aircraft? A log from the log Lvars lua plug-in would be useful. And you know this how? By using the logging? Pete
  24. You'd best have a Lua plug-in to write your preserred values. If to offsets use ipc.writeUW or ipc.writeSW, or you could use ipc.control to sent the relevant AXIS controls with a parameter definiing the position (there's a list of controls provided in a pdf). For LVars you use ipc.writeLvar. See the Lua library reference document. Pete
  25. No example. I think we expected anyone brave enough to try wrtiing a DLL running within the Sim would be experienced enough. The interface is almost the same. Please refer to the text documentation within the relevant ZIP in the SDK: Library for FS Internal Users.zip (32-bit sim) or ModuleUser64.zip (64 bit sim -- i.e. P3D4) I wasn't referring to anything in the FSUIPC5 SDK, but to Paul Henty's .NET DLL, an independent development. I don't know if that can be used for an internal DLL -- I doubt it. But there's no harm in asking him if it looks interesting. See his website: http://fsuipc.paulhenty.com/#home 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.