Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. As I suggested, if you set the minimum value manually, in the INI file, to, say, -32767 instead of -16384 then it can't calibrate your -16384 down to -4096 only to -2048, or thereabouts. Okay, You can experiment to get the right value. The calibration values ibn the INIT file are the INPUTS not the OUTPUTS. FSUIPC calibration is nothing to do with FSX. Yes, and I suggested a way of doing this. The Axes section isn't relevant. Try making the -16384 values a lot bigger, negatively. As I said, -32768 would give a low of -2048. so for -3000 you want something like x = -16384 x 4096 / 3000 = -22370. Apart from any slopes you may apply, the interpolation is linear. Pete
  2. Does it? Certainly for the throttle the maximum reverse setting is actually an aircraft setting which varies from aircraft to aircraft and which FSUIPC reads from FS. The -4096 value is the usual default value (25%) in most aircraft CFG files. I don't think there is a value set for prop pitch. What output value is the "start & feather" position? You can alter the calibrated values in the FSUIPC INI file so that FSUIPC sees a minimum that the input axis will never reach. I can't think of another way. Thje same thing can be used to limit maximum settings too, of course. Regards Pete
  3. It works fine here. Sounds like it might be either an old version of FSUIPC or of GFDev.dll. I seem to remember something like that. Regards Pete
  4. It's the same thing. Just take the 0-16384 and divide by 16384. You won't get -ve numbers with A/T engaged. That can't be true as a lot of motorised throttles read the value in order to position the throttle levers automatically. But there are separate read-outs for each engine still -- 088C for Engine 1, etc. Regards Pete
  5. Wish you'd mentioned it then, I'd have fixed it earlier! ;-) Pete
  6. Okay, so it is something in the Lua part. I'll try to look at this over the weekend. I'm a bit tied up at present. If you haven't heard by middle of next week, remind me then. Regards Pete
  7. FSUIPC doesn't do anything of its own accord. Maybe you have toe brakes operating slightly -- i.e. without a decent null zone -- so causing the autobrakes to dissengage. Otherwise it must be something else using FSUIPC to operate or kill the autobrakes. FSUIPC is just a tool. It doesn't do things without being told. Maybe you still have brakes assigned to something which isn't calibrated. Try deleting your FSUIPC4.INI file. Regards Pete
  8. Even those assigned 4 bytes may only take values 0 and 1 (for "off" and "on"), and you can get 8 such values in an offset byte. I'm sure many of those must only be on/off indications or switches. I don't know any cockpit needing that many variable displays. If you look at the Project Magenta website you'll find a comprehensive PM offset list. They have a large range -- FSUIPC and PM were developed hand-in-hand and much of what FSUIPC does was because of PM. Incidentally, there are often other ways of doing things too. For instance using a pair of offsets to provide a "command" and "parameter" so that many of your variables can be handled through one channel. Regards Pete
  9. But you said: ...So something in the " realistic view patch" changed something, evidently, and the only things I know which get affected for views are cameras. But it really isn't my area of expertise, so there might be something else. Button logging isn't the same as Event logging. Are you sure you selected the right option? For instance, with Event logging on pressing "G" would log as "Gear toggle". Have you tried iFly support? It isn't really anything I know much about I'm afraid. Regards Pete
  10. Sounds like a spiking to max deflection. Usually a symptom of a bad connection or faulty or dirty pot in the control. No, that's the Log file. No. There will be two logs -- the install log and the run-time log (the one above), a KEY file, containing your registration, and an INI file, which contains all of your FSUIPC settings. It sounds as if you have Windows set to hide the proper filenames from you! You should change that, it's not good. Ah, I've just seen your second message: You really need to change the Explorer options if you want to find files properly. There are instructions in the FSUIPC Installing and Registering guide, at the end (see "ADDENDUM: IDENTIFYING FILES IN WINDOWS EXPLORER" In your INI file you seem to have an odd assortment of Axis assignments: [Axes] 0=0X,256,D,0,1,0,0 1=0Y,256,D,2,0,0,0 2=0Z,256,D,0,0,0,29 3=0R,256,D,0,2,0,0 4=0U,256,D,21,0,0,0 5=0V,256,D,0,0,21,0 6=1X,256,D,0,5,0,0 7=1Y,390,D,6,0,0,0 8=1Z,390,D,0,0,0,12 9=1R,390,D,9,0,0,0 10=1U,260,D,0,10,0,0 11=1V,130,D,0,0,11,0 12=2X,384,D,0,7,0,0 13=2Y,640,D,0,0,8,0 14=2Z,256,D,3,0,0,0 15=2R,256,D,0,0,11,0 16=2U,256,D,0,10,0,0 17=2V,256,D,9,0,0,0 Sometimes you used the first line, sometimes the second or third or even forth. Why? Generally you'd only use the 2nd 3rd or 4th when assigning 2, 3 or 4 controls to the one axis. And you have a number of duplicates too. Is that intentional? e.g. 2 x 2 (Elevator), 2 x 21 (elevator trim axis), 2 x 9 (Throttle 1), 2 x 10 (Throttle 2), 2 x 11 (Throttle 3), 2 x 12 (Throttle 4). You also have the generic throttle (3) assigned "direct to FSUIPC calibration", yet you've not even calibrated it! I reckon all of your problems are due to multiple axes all trying to operate the same controls. Why have you done that? If I were you I'd delete the whole [Axes] section, and start again, this time keep it simply. Assign only one of each, not several to different levers. You are inevitably going to get them cross-interfering! If you really don't know what you are doing, do NOT do any assignments whatsoever in FSUIPC, only in FS. You can still calibrate them in FSUIPC. Regards Pete
  11. Just paste the text into a message. That's what everyone has to do. INI, CFG asnd LOG files are only text files, it isn't a problem. Sounds correct. Why would you want to do that? Sounds like conflicting inputs. Too many things trying to provide inputs. i can't imagine any aircraft not responding to elevator trim. That makes no sense. There's a forum known as the CH Hangar. Google it. Bob Church over their gives good advice on setting up CH software and FSUIPC to run harmoniously. Sorry, no idea what you mean here. Regards Pete
  12. Oh! So no one else volunteered to do this Lua programming whilst I was away? :-( Can you remind me in about a week. From tomorrow till next Wednesday I've involved in a re-built of my 737NG cockpit and I really can't get into any other programming stuff till after. Regards Pete
  13. It is theoretically possible for FSUIPC4 to get information for ground and sea traffic from SimConnect, but it isn't something I'd want to do. The method used for Aircraft is designed very specifically for TCAS and ATC type applications. The use for ships and other vehicles is not really an "aviation" application I would be interested in. Even if i did, i couldn't really populate the current aircraft tables with such information, as it would wreck the use of this by many existing programs. So, even if i could find space for a few ships in another table somewhere, it would still mean changes to FSC9 or whatever to read it. Any program interfacing to SimConnect could get such information. maybe you can interest someone in this? Regards Pete
  14. Oh, THAT one. Sorry, I thought you meant something of your own. Yes, i really meant logging Buttons in FSUIPC. Please see if FSUIPC sees the right course knob at all. If not then it is either a problem of an out-of-date or faulty GFDev.DLL module, or an erstwhile unreported bug in FSUIPC. If it does see it okay I would need to look at the Lua part instead. I do have an MCPPro here someplace but I'm not in a position to connect it up for a couple of days. Regards Pete
  15. Yes, you can do that in Lua. If you use the read/write structure functions you can batch the operations much as you would with multiple FSUIPC_Read/Write requests before the FSUIPC_Process call, except there would be a separate function call for reads and writes. Regards Pete
  16. There is no registration recorded in the FSUIPC4.KEY file, which you should find in the Prepar3D Modules folder. Try running the Installer again and re-registering, but run it by right-clicking and selecting "run as ... administrator". I suspect you have installed Prepar3D in the part of the file system protected by Windows. Regards Pete
  17. There is nothing in FSUIPC monitoring altitude nor fiddling with autothrottle. You have something else going on. No, please don't. They won't help. Have you tried IVAP support? I don't think there's any software they use which uses FSUIPC in any case. Regards Pete
  18. Something must be determining what offset to read and write, and how big, and what format. Why? The parameters to the read/write functions (especially the read/write structure functions, which are very flexible) determine offset, size, format, exactly the parameters you'd need for any other program. The wouldn't need to be explicit, but supplied as data. Maybe I am misunderstanding what you are saying? Pete
  19. Any FSUIPC4.LOG file to show me? FSUIPC4 registration is no different in FSX, ESP, Prepar3D. Regards Pete
  20. I expect they use different camera definitions. The camera facilities in FSX are both a blessing (because they are so flexible) and a curse (because they are so flexible). And what FS control is that "right click menu" sending? Use FSUIPC event logging to find out. Sorry, i did not write FSX and I do not always know exactly what any FS commands do. As I said, I think the cameras can be reprogrammed by anyone, including especially aircraft add-on makers. Best way to determine which commands to use is to find out which ones do what you want, and FSUIPC logging can help. Alternatively, for add-on aircraft, maybe they provide documentation which helps with keyboard shortcuts or similar? Regards Pete
  21. When you say "a gfdDisplay.lua" what do you mean? Can you show me? Have you tried logging? Regards Pete
  22. It looks okay, I think. Try re-running the FSUIPC installer. If that fails to fix it, please get a Simconnect log (there's a FAQ in the FAQ subforum which shows how to do that), and show me the first few pages of that. Regards Pete
  23. Sorry, I see no details. I can't help without information. Have you checked the FAQ subforum? Pete
  24. As it says, 1DD2 is not a good decimal number. As the documentation says, you either need to give the details as strings: Vendor="1DD2" Product="1001" or as the hexadecimal VID and PID from the line before: Vendor=0x1dd2 Product=0x1001 Also you have the Product variable twice. Not sure if Lua accepts multiple assignments separated by , Regards Pete
  25. Please see the FAQ subforum where this is answered. 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.