Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. The "U" in "writeUD" stands for "Unsigned". For signed values you must use "ipc.writeSD" (guess what the S stands for) 😉 I don't actually know of any real aircraft on which you can instruct the A/P with a negative altitude and it may not be simulated in SimConnect. I expect I'll be corrected on the former point by someone who knows of such real-world aircraft. What does offset 07D4 read when you manage to set a negative altitude using the mouse? (You can monitor it via FSUIPC's offset monitoring facilities, in Logging). Of course, it is also possible that the coding in FSUIPC doesn't allow such values. Pete
  2. It might be useful to know from the other sufferers what addons they use, so that we can see if there's anything in common. Pete
  3. I just happened to browse the P3D support forum, and I find that you posted about this problem there. Here's what you said on the 9th: And, even more interestinlgy, a later post by Nunez12, someone with exactly the same problem, clearly says: Now in a later message in that thread you said The problem first occured about 2-3 months ago during a long haul flight I feel I must ask: what that your first flight attempted over 7 hours? If not, what might have changed since things were okay. 3 months unfortunately is a long time later to try to remember such things, but that's certainly what is most important. things worked ... then they didn't. what changed? Did you ask yourself that nearer the time? Pete
  4. Something is undoubtedly going on in your system, but John is at a loss as to what to suggest to determine what it is. Have something fail after 7 hours is just so out of any normal experience anyone can have with software, and nothing you've provided suggests any reasons that we can investigate. I applaud john for even attempting a 7 hour flight. it's more than I would have done! There is one thing which may not have been suggested. You say it happens even with no assignments made in FSUIPC. Is that right? If so this does strongly suggest some action from something outside FSUIPC's code -- another application, possibly using FSUIPC, or a Lua plug-in possibly. Try a test with FSUIPC installed and running but with FSUIPC unregistered. To do this just remove or rename the FSUIPC6.KEY file in your FSUIPC6.DLL folder. This will mean FSUIPC is doing nothing but requesting and receiving information from SimConnect and dealing with any user applications. So the next step then would be to identify every other add-on which is running, and try again without them, as far as possible. We then might need to do a process of elimination. List the add-ons for us, those running externally as EXE programs and those running internally internally (eg with DLLs or add-on extra Gauges). Whatever interaction is going on may possibly be narrowed down that way. Pete
  5. 6Mb might be too big for an email attachment, but you could try. Else you could save them as lossy compressed JPEG files without losing clarity. Even the free paint.net program can save at a chosen compression where you can see what the result would be beforehand. My emai is petedowson 'at' btconnect.com. Thanks, Pete
  6. In the Client log the problem of connection becomes clearer: 563 Trying TCP/IP addr x.x.x.x, port 8002 ... 563 LUA: "C:\...\Initial.LUA": not found 2625 Error on client pre-Connection Select() [Error=10061] Connection refused 2625 Ready to try connection again 3625 Attempting to connect now 62688 Trying TCP/IP addr 10.48.249.244, port 8002 ... I don't know why the first attempt has "x.x.x.x" for the IP address. You seem to have that set in the INI: ServerIPAddr=x.x.x.x I assume you did that? If it was only for posting here, I don't know why as WideClient only operates on your local network, and local IP addresses are no interest to others. Most of us have the same set of IP addresses for all PCs etc in our local network -- mostly 10.1.x.x or 192.168.x.x. These are the ranges allocated for LAN use. It isn't something useful outside. The second time, which luckily you missed, shows 10.48.249.244, which is most unlikely to be an IP address of anything on your Network. I think this is to do with the way your router/hub is configured. What you need to do is set the correct IP address for your server in the ServerIPAddr parameter in the client INI file. You can find that in the Network settings in Windows. Pete
  7. As the offset list states: (Writing here uses the AP MAX BANK INC and DEC controls to try to approximate to the angle written.) Basically, whilst we can read this value from FSX via SimConnect, writing back doesn't work. So there's a fiddle in FSUIPC to try to obey a write by using the INC and DEC controls. Perhaps you can log Events in FSUIPC Logging so that you can see what it actually does. Pete
  8. Sounds interesting. You make your own hardware? Will this be a dedicated Simulator build? Maybe post some pix when you have it all together? No problem. glad you got it sorted. Pete
  9. The PMDG coding appears to do things similar to FSUIPC, intercepting the regular Sim Controls (the ones the sim would assign if you used those) at a high level. FSUIPC offers those same controls for assignment (AXIS .... SET) and will send them to the Sim the same as if you'd assigned them in the Sim. So both parties should be happy. The problem then comes if you set calibration in FSUIPC. Then FSUIPC also traps the control it has sent, and puts it through the calibration to emerge changed accordingly, and that changes value it then sent f to the Sim at a different level. The two values processed for the same control can therefore conflict. Because of this, generally folks using PMDG aircraft are encouraged to assign all flight controls only to the FS "AXIS ..." controls and not calibrate. I know some folks have found ways through this restriction, but in general that's how you should start. Make sure everything works correctly that way before attempting things like calibration. For reversers, PMDG aircraft work best with button for "THROTTLE DECR", as I think you have. You could try the FSUIPC Reverser but just make sure you get the main controls working correctly first. Not sure what discussions you expect to have with PMDG. They usually don't want to know, just advising folks not to use FSUIPC. Pete
  10. You need to check your work with a default aircraft. If the 737NG you are using is the PMDG one then it has its own programming for the MCP and probably doesn't use the default FSX values. Check things the other way around. Monitor the Offsets in FSUIPC (right-hand side of the Logging tab) and FSInterrogate, and observe what you get as you change the ALT and VS values on the on-screen instrument. Pete
  11. I don't know. Are there controls called "engine switches" in an Airbus? The fuel idle/cutoff switches (levers) in default jet aircraft are operated by the mixture controls. So "Mixture Lean" ("mixtureN lean" for engine N) is cutoff whilst "Mixture Rich" ("mixtureN rich) for the idle (fuel enabled) position. Not add-on aircraft necessarily obey the default controls. the more sophisticated add-on aircraft tend to have their own separately written subsystem code. But try with those first. If you are using the FSL or Aerosoft Airbus you might find you have to use other methods instead. Maybe mouse macros or Local Variables (LVars).. Pete
  12. It's very unusual for Bodnar devices to have anything wrong with the axis Registrations. So it's your PMDG configuring which doesn't suit their methods. Looking at the INI file, I see that you have set calibration for every axis, but have not actually calibrated any of them -- the values for calibration are all defaulted! So why bother? The assignments for the 777 are very strange indeed. You have multiple different (conflicting) assignments to both THROTTLE 1 and THROTTLE2 -- TWO to Thr 2 both on the Bodnar, THREE to throttle 1, one on the Bodnar, two on an unconnected device 2. [Axes.PMDG 777] RangeRepeatRate=10 0=1X,256,F,65821,0,0,0 -{ TO SIM: THROTTLE2_SET }- 1=1Y,256,D,12,0,0,0 -{ DIRECT: Throttle4 }- 2=1Z,256,F,65698,0,0,0 -{ TO SIM: FLAPS_SET }- 3=1R,256,D,22,0,0,0 -{ DIRECT: Spoilers }- 4=1U,256,D,10,0,0,0 -{ DIRECT: Throttle2 }- 5=1V,29151,D,9,0,0,0 -{ DIRECT: Throttle1 }- 6=1T,256,F,65760,0,0,0 -{ TO SIM: FLAPS_DETENTS_SET }- 7=2X,256,D,22,0,0,0 -{ DIRECT: Spoilers }- 8=2Y,256,F,66420,0,0,0 -{ TO SIM: AXIS_THROTTLE1_SET }- 9=2Z,256,D,9,0,0,0 -{ DIRECT: Throttle1 }- You've no FSUIPC assignments to ailerons and elevators, so I assume those are assigned in P3D. You likely have conflicting assignments if you haven't disabled controllers in P3D. either use FSUIPC or P3D for assignments, not both. mixing always gives problems! With PMDG aircraft it is best to use only the FS controls, AXIS_XXXX_SET, and not calibrating. Otherwise your results will not be completely predictable. If I were you i'd delete the PMDG 777 profile settings and do them again, trying to stick to those methods known to work with PMDG aircraft. There's been plenty written about this, especially here in the Forum. Pete
  13. Why is that? Which of the above devices is actually your throttle? Couldn't you locate the correct entry in the Registry? The only things which are assignable in FSUIPC are those listed in the log, see above, and in the INI file (which would be the same). Show me the INI file so I can se which of those you are using as Throttle in your assignments. Vendor 06A3 is Saitek. You have no Saitek devices listed as being connected! Pete
  14. Sorry, I've no idea how it is possible for the registry to be changed just by pressing a button. That is surely impossible, unless LINDA is doing it -- as i said I have no idea what LINDA does. Note, however, that PMDG aircraft do not like calibrated axis inputs. they seem to intercept the axis inputs at a conflicting level. Also, most folks with PMDG aircraft find the reversers only work correctly using THROTTLEn DECR assignments, repeating on a button, rather than any type of axis input. But according to your log you have these assignable devices: 94 Product= T.A320 Pilot 94 Manufacturer= Thrustmaster 94 Serial Number= 1 94 Vendor=044F, Product=0405 (Version 2.0) 94 GUIDs returned for product: VID_044F&PID_0405: 94 GUID= {E4093CE0-F8D3-11EA-8001-444553540000} 94 Details: Btns=17, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R255,U0,V0,X16383,Y16383,Z255 94 Product= T-Pendular-Rudder 94 Manufacturer= Thrustmaster 94 Vendor=044F, Product=B68F (Version 1.16) 94 GUIDs returned for product: VID_044F&PID_B68F: 94 GUID= {DED9A120-F76A-11EA-8002-444553540000} 94 Details: Btns=0, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X65535,Y65535,Z65535 94 Product= Alpha Flight Controls 94 Manufacturer= Honeycomb Aeronautical 94 Serial Number= 6D323C1325153B00 94 Vendor=294B, Product=1900 (Version 0.33) 94 GUIDs returned for product: VID_294B&PID_1900: 94 GUID= {DED97A10-F76A-11EA-8001-444553540000} 94 Details: Btns=35, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X255,Y255,Z0 94 Product= BU0836-LC Interface 94 Manufacturer= Leo Bodnar Electronics 94 Serial Number= BZ0498 94 Vendor=16C0, Product=05B7 (Version 1.39) 94 GUIDs returned for product: VID_16C0&PID_05B7: 94 GUID= {A506C460-138E-11EB-8001-444553540000} 94 Details: Btns=32, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R4095,U4095,V4095,X0,Y0,Z4095 See that none of the devices assignable in FSUIPC have a VID (Vendor ID) of 06A3 !!! Pete
  15. So I'm sure FSUIPC will allow you to set 7 zones. It is that count it uses. Perhaps you need to explain why you cannot in more detail? Without worrying about the detentes, can you achieve all of the positions by moving the lever. or not? Pete
  16. This is a problem mostly experienced by Saitek Throttle users, but can occur with others. It's a bad registration by Windows. Please see this thread in the FAQ subforum: Fixing problems with 50% (or digital on/off) action with Saitek levers Is this with the 777 loaded? If so, how many flap positions does FSUIPC display in the field "No. of detentes"? It gets this information from SimConnect for the specific aircraft when it is loaded. I see you are using LINDA, and the Log is almost all LINDA -- stuff I've no knowledge of at all. You may need LINDA support as I don't know what it might be doing. Pete
  17. A BETA version of MakeRunways version 5.00, with MSFS support added, is now released for wider user testing and feedback. Please see MakeRunways Beta version 5.00 for MSFS Pete
  18. No, I did actually mean assign to buttons to send values 0 and 16383, explicitly, in case the axis wasn't getting through with such a range. A button for 0% and another for 100% would show whether the action you couldn't make work with an axis assignment was only because of incorrect values. Anyway, I see Thomas has already done the testing in MSFS and reported the results for you. (Thanks Thomas!). Pete
  19. Well, from curiosity I did this and tool a quick look. Unfortunately, apart from it being in some C or C++ or C# variant I don't understand (with lots of library calls to non-included libraries), it is also very lean and has headers referencing all sorts of other packages. I assume those other packages could be from the same or other authors also on the Free GNU system and GitHub, but quite honestly for the amount I got left to do it will be much quicker for me to press home. Thanks anyway, Pete
  20. FSUIPC is using SimConnect all the time anyway, to maintain the data in the offsets. The unregistered FSUIPC is useful fo many applications which use these facilities, and can also be useful for it's logging facilities, but offers no User-oriented facilities. For those a purchase is needed. The documentation does explain this. Any, glad you solved it by yourself. Mind you, I should have notice d that it wasn't a registered install, from your Log, where it clearly stated: FSUIPC4 not user registered Apologies for that! Pete
  21. Does Anti Ice Set work for it if you assign in FSUIPC instead? I can test tomorrow just using a button assigned to Anti Ice Set with parameter 16384 and another the same but with parameter 0. Those are the values I'd expect to produce 100% and 0% respectively. I'm wondering if it might be yet another MSFS bug. If you enable Axis and Even logging in FSUIPC, does the FSUIPC log show the anti-ice events at all? You might also check via PFCcom64 logging. Just for my education, please tell me, when would you use partial carb heat, eg 50%? What would be the purpose? it seems to me you either want the hot air on the Carb to prevent or remove ice, or off because it isn't needed. I always thought it would just be an on/off setting. Pete
  22. The only change in my PFC drivers to work with MSFS is to recognise FSUIPC7 so that it links to it correctly. Otherwise it has been unchanged for many years. The main change in the last 5 years was to make a 64-bit version to work with FSUIPC5 on P3D4. Pete
  23. Please show us your INI file. The usual reason for such a message is NewInterceptTextMenu missing or set incorrectly. Otherwise it has to be a corrupt or incorrect FSX API.DLL module. Pete
  24. Thanks Pelle, but I'm not sure I'd understand other folks code any better than decoding the files for myself. Anyway, i don't see how to get any source. I'm progressing quite well, thanks to help from Matt on FSDeveloper, who has written a BGL to XML decoder. I've one remaining problem for the data -- getting the ILS data which is now separated from the Runway data (in "NAX" files in fs-base-nav instead of with the runways in the APX files in fsBase). What i've got working at present is working for MS-Store installations, but it appears I have to do more work to make it work correctly for Steam installs. Than, possibly, DVD installs are different again. 😞 Of course nothing i'm doing will work for add-ons using DRM protection techniques for their scenery. It's all a bit of a mess, if you ask me! Pete
  25. I've been thinking about this since your original message, and two thoughts occurred to me. On jet aircraft there's an "anti-ice setting, and looking through the list of controls there's one called ANTI ICE SET. Now most "SET" controls are actually usable as axes. So, since the function of Carb Heat it to prevent or remove Ice, I wondered if that might work? Worth a try. Of course, like many other controls, it might not be connected up inside MSFS (yet). There's also Pitot Heat, but that is to prevent the pitot tube blocking and giving causing wrong airspeed readings, so I doubt that would be used for carb heat. 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.