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. So you've got a way. Well done. Pete
  2. The secret with the PMDG commands is getting the parameter correct. I think the parameters are all actually "mouse flags" -- values which tell the panel what mouse action has occurred. The default will be left mouse button press. The dials are probably left button for one direction, right button for the other. So, it'll be the same command, but with the parameter for right mouse button. Isn't there are list of them in the document from which you got the command name? If not then maybe ask in the PMDG Forum, or search for the mouse flags in Microsoft websites (it's part of the Windows encoding of mouse events). Jerkiness would tend to indicate conflicting assignments -- eg. both in FSUIPC and in P3D, but I don't know about pausing. that's odd. However, in general PMDG aircraft do not like axis controls assigned "direct to FSUIPC calibration", or even being calibrated in FSUIPC. Just assign, in FSUIPC only, to the FS AXIS controls and don't calibrate them. Pete
  3. First thing would be to report the error to the XPUIPC author. To fix it in your program you'd surely just need to set your comSelection value the other way around for your X-Plane version. If you can test whether you are talking to FSX/P3D or XPlane, then just make it conditional on that. Pete
  4. Well done. But in general, when you want to test one "bit" in a byte, you'd use: if (x & mask) ... where x is the value you've read, and "mask" is the value of the bit( you want to test for. So in your case: if (audioSelection & 128) for COM1, and if (audioSelection & 64) for COM2 There are other bits for the other audio switches. Bit values are derived from evaluation 2 to the power n, i.e. 2 times 2 'n' number of times, with the special-seeming case that 0 results always in the value 1. So: bit 0 = 1 bit 1 = 2 bit 2 = 4 bit 3 = 8 bit 4 = 16 bit 5 = 32 bit 6 = 64 bit 7 = 128 For more about bits, see the FAQ subforum help thread entitled About bits, numbers and hexadecimal Pete
  5. That's ok, but I'll try to give it to you snyway. I think the error is when the Installer tries to change the permissions and finds it can't do it. We never worked out why, because we are following what appear to be the rules -- and it always worked fine on Win 7. Following John's suggestion you changed the rules manually, so it then worked, but the program still tries to change them (it doesn't check to see if they need changing first. John is planning to avoid such problems by using different install methods, but that won't be soon. Too late now, but it is best, really, to avoid installing P3D in Program Files, even though it defaults to that location. Sometimes other third-party addons have difficulties too. This is the reason many say you have to run them with administrative privileges. That shouldn't really ever be necessary. Only Installers should need that. Pete
  6. I think you must mean that assigning to PMDG aircraft panel actions simply doesn't work. I expect you are assigning to the default P3D controls. Those are fine for most aircraft, but PMDG does its own thing. There are lots of threads and help about assigning PMDG's own controls using <custom control> numbers published by PMDG in its SDK, installed with their aircraft. Please refer to the FAQ subforum. One of the first items is How to program joystick buttons and keys to control PMDG aircraft Your other questions are on the same subject. Pete
  7. "Rudder", "Aileron", "Elevator" and "Throttle" controls are named that in respect of the "output" they affect. Surely it would be far more confusing to call them by other names. You can't just refer to "pedals" as many folks don't have pedals and either use auto-rudder or control it by a twist on a stick, or just keyboard. Same really applies to the others. You name a control after the affect it has. Interesting. Thank you. I didn't know that. So the FSUIPC facilities are currently as good as it gets. I suspect, though, that some add-on aircraft use the Steering Axis input to make the visual nosewheel turn, even if the actual effect is no different. Pete
  8. Oh, yes, I know that. i thought you were saying keep the nosewheel turn from the tiller to 7% Sorry, how are they changing with ground speed in P3d? I do that with the tiller/pedal blending in FSUIPC, but I don't think the rudder actually turns the nose wheel. At least that's what i'm told and why I then suggest trying the P3D steering axis instead. I never see my nose wheel so I have no idea if it turns at all for me. You manage to create tight turns at 160 knots? Really? What are you assigning your pedals to? I think you should experiment with the methods I've suggested. Anything else must be flight model related. Pete
  9. I realise you wern't talking about landing gear, but also I don't know of a steering "gear box". if you mean whatever it is which links the tiller to the nosewheel, then that relationship is merely in the way you calibrate. 7 degees sounds like a rudder limitaion. It seems to small to tuen tight corners -- most airliners can effect a 90 turn in not muchmore than their own lenth if tha. More likely the other way around. Really I don't know what you are confused about. Why not try the FSUIPC method, both calibrated as "direct" axes, and see if you like the results. Most folks do. BTW even a 7% nose wheel deflection during take off rolls up to 150 knots ground speed is surely going to do some damage somewhere, so i really don't agree with your "regardless of ground speed". Pete
  10. I didn't know there was a sample. So didn't that work? What was wrong? You need to program it as a DLL. For example, there's no WinMain but a DLLMain. And unless you create a separate thread you don't have your own WndProc -- the main Windows message processing WndProc is the process one, in P3D. Then the SimConnect interface is a bit different. You have to declare different things, and there's a DLLstart which it calls when ready. i really cannot undertake a tutorial here. You'll have to do first the Windows DLL programming techniques then the special application to SimConnect. Pete
  11. You need to code the DLL. There are plenty of add-on DLLs. The can be loaded via the Add-On.xml method as others, or by direct entries in the DLL.XML file (as is currently the case with FSUIPC). You'd need to read up about programming DLLs. That's a Windows thing. There are rules for P3D DLLs but the programming has first to follow Microsoft Windows rules for DLLs. Pete
  12. Ah, yes. FSUIPC is a DLL running inside the Sim. There are a lot of things you can't do from an external process (which is why FSUIPC has always been an internal module, not a separate process). Pete
  13. Sorry, I don't understand the term "gear ratio" in this context! Rudder is controlled by pedals, the nose wheel is a steering mechanism controlled by the tiller. I don't know your SW, but FSUIPC supports separate Rudder and tiller assignment in its "direct to FSUIPC calibration" list. If you assign there you can calibrate the separately so that the tiller has a more immediate and dramatic effect. both actually use the rudder, but FSUIPC transitions from one to the other depending on ground speed. Because it uses rudder for both you won't see the nosewheel rurn. P3D does offer a Steering control too, which should be separate from the rudder, but i think that although it turns the nosewheel it also moves the rudder. From an FSUIPC application you can send controls via offset (3110 (check that please). FS controls are lin the List in your FSUIPC documents folder, FSUIPC ones towards the end of the Advanced Users guide. Pete
  14. The SS and CSE refer to plug-in Lus files, which evidently you don't have installed. If they've decided that's what you must do, then, yes. The drop down list will only show assignable P3D controls and added FSUIPC controls if there are no macros and no plug-ins installed (both add more assignment possibilities). FSUIPC doesn't know of controls specific to an addon unless that addon installs plug-ins or macros, or accepts special event numbers (as is the case for the PMDG Boeings). If they've not provided anything else, then it may be the only way. But for switches on screen you can see if mouse Macros can be generated which you can then assign to. That would be more efficient. Check the FSUIPC documentation for details. What program is that? There's no documentation for other add-ons provided by the FSUIPC install. Pete
  15. If it is jumping about there are only two possible reasons: 1. you have a jittery controller, maybe through dirt, wear , or connection problems, or 2. there is a conflicting assignment. Maybe you have it assigned in FSUIPC and in P3D. disable controllers completely in P3D (no need to delete assignments) if assigning in FSUIPC. The "Slopes" facility is more about getting the right "feel" to suit your device and aircraft (jets and stunt aircraft would need faster more immediate response than an airliner). It's not a smoothing facility. Pete
  16. Do you mean the FSUIPC In-Sim options? Request "DIALOG MODE" from SimConnect before invoking the Windows dialog box (for that is what it is -- FSUIPC is written in C and knows nothing of "Forms"). You don't need to use the SIM STOP event. Pete
  17. When you install FSUIPC5 the documentation is also installed -- into the FSUIPC documents subfolder. But there is not so much difference as far as the offsets are concerned, maybe a few new ones. The most up t date list of P3D controls accessible through FSUIPC assignments is produced as a text file automatically when it is first run with an new build of P3D. but otherwise the current "List of controls" PDF is pretty close. There are new ones added now and then which will appear in the generated text file. Checking the current PDF covering FSX and P3D it seems those two I mentioned are NOT new to P3D4, nor even to P3D. Pete
  18. I don't think any version of FS simulates the fire panel as such. so the former isunlikely. Of course it's a read-out not a control. But if it is only add-on aircraft simulating it it won't be a SimConnect function. For Engine Fires FSUIPC does provide an offset which can be used to start and stop them and also as an indication. Search the FOffsets list PDF in you FSUIPC Documents folder. also, if you look through the assignable controls 9at least for P3d4) you'll find these EXTINGUISH ENGINE FIRE APU EXTINGUISH FIRE but I suspect those might be P3D4 only. Pete Pete
  19. I'm sorry, but there's no "Simconnect" interface in FSUIPC's lua library. Simconnect calls will be used in executing some of the requests, but no way is there a direct connection. And what are they? Maybe you are not simply recognising them, as offsets or as controls. Pete
  20. Yes, and I assume that if there is a "start fire" option in the PM IS they set the correct bits in the appropriate offset in. have you tested that? You'd need somehow to tell "fs2phidgets" how to read the offset. I can't help with that I'm afraid. If PM have provided the facilities surely they must have programmed it already to use the correct offset? Your question on PM should really be directed to the PM support forums, and the phidget ones to theirs. I'm afraid i can't really help with either. Sorry! Pete
  21. What am I supposed to get from that? It seems to ramble on, and much of it I don't know anything about. Sorry, I don't know anything about phidgets. What's the txt file for? You want to START a fire using a fire panel? That's a little odd. Pete
  22. I have never used the facilities. The offset validity was checked for me by actual PMDG aircraft users, which i am not. All FSUIPC does is receive the complete lot of data from the PMDG code, via Simconnect, and i map it with no change, no editing, directly into the offsets areas. I then spent a lot of time working out where that placed everything in FSUIPC memory. I don't know what most of it is, that's defined by PMDG. This is as a simple service to PMDG users wanting to interface hardware and so on to their aircraft. In the past many aircraft mafers have actually done this themselves directly, using offset space assigned when they applied. If the documentation provided by PMDG is not enough (and it is a bit flimsy I agree), remember it was written by programmers for programmers. I'm sure folks over in the PMDG forum might help clarify terms you are unfamiliar with. If you ask specific questions about it here I could halp i expect. But you need to refer to the PMDG document and work out what it is you don't understand. Your data shows it isn't being read as a "string" because strings are terminated by zeros (your \x00). You need to match what you read to whatever the PMDG aircraft supplies. It isn't all strings. In your program you need to use what the PMDG document provides, in other words this, from your message above (I don't have the original file to check): struct PMDG_747QOTSII_CDU_Cell { unsigned char Symbol; unsigned char Color; // any of PMDG_747QOTSII_CDU_COLOR_ defines unsigned char Flags; // a combination of PMDG_747QOTSII_CDU_FLAG_ bits }; // 747QOTSII CDU Screen Data Structure #define CDU_COLUMNS 24 #define CDU_ROWS 14 struct PMDG_747QOTSII_CDU_Screen { PMDG_747QOTSII_CDU_Cell Cells[CDU_COLUMNS][CDU_ROWS]; bool Powered; // true if the CDU is powered }; Then read the correct number of bytes into a struct PMDG_747QOTSII_CDU_Screen which you've defined, length sizeof(struct PMDG_747QOTSII_CDU_Screen). Only then might you make any sense of it. I'm afraid I am of no help regarding the data itself. I've never used any PMDG aircraft. I can only advise about programming, and then only in C. Pete
  23. Did you enable CDU broadcasts as instructed in the Offsets PDF? As with most all of the offsets populated from PMDG aircraft, the format of the data is documented by PMDG, not by us (it is their aircraft after all). This would be in the .h document referenced right at the start of the Offsets PDF. Pete
  24. No, it isn't really the right forum as it is purely a question about P3D which is answered in the L-M website. However, you should be able to learn from any other Addon files you hsave in your documents folder in Windows. Look in the Prepar3D v4 Add-ons folder (or v3 as appropriate). There's a separate subfolder for each add-on, and the crucial part in those is the Add-on.xml file which tells P3D exactly what to load and where it is. Pete
  25. You need GFDev.dll or (for P3D4) GFDev64.dll in the P3D modules folder. You can find these in the "Useful Additional Programs" thread in the Download Links subforum. 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.