Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Okay, but: as I said you could have left that and simply set the ShortAircraftNameOk to "Substring", so it would have found the name after the [DXT3] part in any case. Of course, because you've told it to accept that short name for all of those. No, the short name is whatever you have in the INI file. If the only entry in the INI file shows [buttons.Level D] then you'd match everything starting "Level D" and that's what you would see! Please do refer to the description of this facility in the documentation. If you set the ShortAircraftNameOk to "substring", then you could have "767" instead and it would match anything with "767" in the title. No!!! It is either "No", "Yes" or "Substring". That parameter doesn't dictate the part of the name, the name part of the [buttons.] title does! You can have any number of those, with different names. All the "ShortAircraftNameOk" parameter does is tell FSUIPC not to check ALL of the name, only part of it! PLEASE read the documentation, which explains it! I shouldn't have to repeat it here! :-( Pete
  2. No, unless upon reading the documentation and finding out what they do you decide you need them. FSX "commands" different in 4.12 compared to what? 4.11? Since at least FS98, FS has supported three Gear commands == Toggle, Up and Down. For a single button or key press you can only really choose "toggle", but for a proper switch, or a big lever in a cockpit with two micro-switches, you'd obviously use gear Up for up and Gear Down for down. your choice entirely, depending upon what you are using. FSUIPC doesn't offer anything there which isn't in FS already. The list of controls I provide IS a list of FS controls. FSUIPC does offer a few additions, but these are not they. As the documentation clearly explains (you do have the documentation, don't you?), if you assign buttons in FSUIPC you should de-assign them in FS else BOTH actions will occur, which may well be undesirable. Erassign it in FSUIPC "Buttons" options. Please please please do read the documentation. Why on Earth are you using "aircraft specific" assignments for general assignments applicable to all aircraft in any case? That makes no sense whatsoever! Of course it matters!!! If they are exactly the same why bother to use FSUIPC? Just use FS and forget FSUIPC! Don't bother to use FSUIPC for things well supported in FS already. If you want bto use FSUIPC,, use it for things which FSUIPC is for. And NEVER EVER have buttons assigned in both. Please do read the documentation some time. It will help! No, not KEYstrokes -- KEYSTROKES are not BUTTONS. If you assign a KEYSTROKE in FSUIPC, it will not be seen in FS -- FSUIPC will pinch it. That doesn't apply to buttons. Please do read the documentation. :-( Pete
  3. As described in the FSUIPC documentation (Advanced Users), it would be much easier for you if you just kept the first such section in the INI file and changed the "ShortAircraftNameOk" parameter to "Yes". This would work because all of those aircraft start with "Level D Simulations B767-300ER". However, this name will NOT work: for two reasons: 1) The name contains [ ] characters which confuses the section naming in the INI, and 2) The name as shown above contains a more than one line! The Windows INI system cannot handle multiple lines in names. Or is the latter problem a result of your formatting in this message? If you want the same buttons for all variants of "Level D Simulations B767-300ER" then just keep the one section with that name, deleting all the others, then set "ShortAircraftNameOK=Substring". Regards Pete
  4. Thanks. I replied there as well, but for completeness here let me repeat this part: I really need to know why as it shouldn't happen. I don't like things being wrong like that. I shall work out a way of getting more information, and get back to you when I have something else to try (just to get info at first -- fixes come later). Regards Pete
  5. Ahthe log oddly shows that button #32 though. If the display is blank it should certainly accept anything from anywhere, including the PFC driver which it actually shares the data with. At present I am at a loss to understand it. I can't even see where I can get more information at present. I will think about it further. I may send some test version(s) to you email if I think of anything. Regards Pete
  6. Okay. Thank you. As you say, it is odd that FSUIPC3 shows things okay and FSUIPC4 doesn't. This is especially the case because the Buttons and Switches part of the program is identical between the two -- in fact it is one of the few areas which are so! Can you describe what you actually do see reported on the Buttons page in FSUIPC4? From the log it does look as if it should be showing a joystick with button #32, rather than the blank awaiting a press or a toggle. Regards Pete
  7. I can't find any option set which could do that (there are none in any case), but the Log file you supplied is odd here: 159265 *** Entered Buttons option page *** 159281 FirstButtonChange res=00000120 (0.1, 32) 226531 *** Exiting Buttons option page *** The 0.1, 32 bit refers to a "button" on a normal (non-PFC) joystick. Looks like this would be showing up on the Buttons page as the current button 'pressed'. Now button numbers 32-39 are reserved for POV "hat" positions -- 32 would be the hat position at due north. or 12 O'Clock. If this was showing and nothing else, then it most likely is stuck, repeating, so it always looks like the current button pressed. Could this be so? Something seems wrong. Could you try removing this other joystick altogether (unplugging it), to see if FSUIPC then correctly sees the PFC buttons? I really cannot see any other possibility. The fact that the PFC buttons are recognised in normal mode, just not in the Button Options, does really imply that they simply never get a look in. Regards Pete
  8. Sorry, FSUIPC doesn't handle mouse buttons at all. Isn't there a driver supplied with the mouse for assigning actions to spare buttons? Regards Pete
  9. Right. Enrico Schiratti has just informed me that he's fixed the main download link on the http://www.schiratti.com/dowson page now. Regards Pete
  10. Sorry, no idea what that means -- is that specific to your ISP? They work fine from here. How do you change DNS? This is all a bit outside my ken. Regards Pete
  11. Both the FSX and Other Downloads Announcements above have working links, but, yes, the one on the Schiratti site appears to be broken. The file you get is the same. I'll contact Enrico and get it fixed. Regards Pete
  12. SimMarket sells keys for version 3 and version 4. You do not purchase a specific release. The current version for FS9 and before is 3.75. I don't know from the information you are giving me. Please send all the details privately to me at petedowson@btconnect.com. It it Dowson, not Dawson, or Pete if you like. For Vista you need to take extra steps, as documented -- to run FS "as administrator" -- but that wouldn't make FSUIPC reject the key as invalid, it would merely either stop you entering it altogether, or let you enter it but still be unregistered. In all cases these days, invalid key problems always turn out to either be attempting to enter an FSUIPC4 key into FSUIPC3 (or vice versa), or making a mistake in one or other of the three fields: name, email, key. It is best to cut and paste to make sure every character is correct. For keys it is easy to mix up I's 1's and L's, 2's and Z's, 0's and O's. Regards Pete
  13. Well, with exactly that combination it all works exactly as it should here, so that is very odd. Since your INI file parameters copied from FS9, work, it is evident that FSUIPC4 is seeing the PFC buttons, so it is puzzling why thry are not seen in the Options screen. Yes please. The FSUIPC4.LOG and both FSUIPC4 and PFCFSX.INI files, to petedowson@btconnect.com. In return I'll send you my very latest test versions just in case. I won't have time to investigate further now till Thursday. Do you get GoFlight buttons showing in FSUIPC4? (If not, is the GFDev.dll installed? You could try the version from the Downloads announcements above). Regards Pete
  14. That looks really good! Congratulations! Regards Pete
  15. Please clarify: you aren't talking about programming these in the PFC options? Just in FSUIPC's buttons tab? Please tell me version numbers of both PFCFSX.DLL and FSUIPC4.DLL? I cannot reproduce it here with any recent versions. FSUIPC4 sees all the PFC buttons and switches it should do. Perhaps I need to see your FSUIPC4.INI and PFCFSX.INI files too, but I am not aware of any parameters you can set to prevent FSUIPC4 seeing them. The Axis Assignment tab in FSUIPC4 should also see all the Cirrus axes, the yoke, pedals and all the quadrant axes. But this may have been a more recent addition. Regards Pete
  16. There's no change in how the PFC DLL treats those buttons. That part of the code is absolutely identical. On my Jetliner Yoke the A/P Disconnect is actually indistinguishable from the autopilot button on the radio stack. You can re-program it, but only in FSUIPC. I use the rear button for ATC instead. The same set of parameters you used on FS9 (INI files) should work on FSX. Regards Pete
  17. I am part way through making some changes to give me more information, but there is one thing you can check beforehand, please. Without FS running, go to the Windows Control Panel, select System, then Hardware - Device Manager. Look for the USB Root Hubs. Right click on each in turn, selecting "Properties" then "Power Management". Make sure the option "Allow the computer to turn off the device ..." is NOT checked. The reason I am saying this is that if the device has been "turned off" when you load FSX, the DirectInput device scan I do initially will not find it. And currently I don't re-scan (because the only reason for that scan is to obtain the GUID (identifying the device) so it can be Acquired, and you only do this once). With the older Windows joystick interface there was none of that complication and any device could be seen at any time. Let me know if this answers the problem please, before I go to any more trouble with the Logging I'm adding. I may make FSUIPC4 re-scan when FSX is running. Not sure when to do it though -- I don't want to impact performance by doing it in normal flight. Maybe only on entry to the FSUIPC Options, or only the Axis assignment tab. At least then if they do "go to sleep" you can get them recognised again without restarting FSX. Regards Pete
  18. On the same PC or on a Network? Yes, run it again, try RC again, see it fail, close FSX. Let me see the FSUIPC4.Log file and the Install FSUIPC4 log files. Both from the FSX Modules folder. Pete
  19. If you reinstalled Windows or rolled back the Registry you will need to re-register. Use the same details and enter them again -- cut and paste from the KEY file if you like. It does actually explain this in the User Registration section of the FSUIPC User Guide, thus: Regards Pete
  20. No, the logs show everything as if it is perfect, no problems at all. The only possible reason I can think of for the gradually increasing latency is a pile-up of TCP/IP packets in memory, getting worse as memory fills and the swap files used. Is that an old Pentium 4, really? Not a Core 2? I must say straightaway that I do think your hardware just isn't up to FSX needs. I'm really surprised you can fly. What sort of frame rates do you see? My test machine is an old Pentium4 3.0 GHz, the slowest with hyperthreading, and it has 1536 MB memory, and although I use it for testing and debugging I could never actually fly with it! Anyway, that is no excuse, but it may well be part of the story. For now I can only suggest the workaround I mentioned. Meanwhile I am keeping up pressure on Microsoft to try to get the use of TCP/IP bypassed for internal comms, with FSUIPC and other DLLs. Regards Pete
  21. Do you calibrate your joystick axes in FSUIPC? If so, there are work=arounds you could try: 1. Set "NoAxisIntercepts=Yes" in FSUIPC4.INI. 2. Either use only FS assignments and calibration or de-assign the axes in FSX and assign them instead in FSUIPC, using the "direct to FSUIPC" option for each. Then calibrate in FSUIPC. Okay. I'll take a look. We never managed to nail this one down enough for Microsoft to prove anything. It always seemed to be due to security hooks. Regards Pete
  22. I agree. Can you report it as a bug to tell_fs@microsoft.com, please? I wouldn't have thought that it was supposed to be that way. I'll mention it to my contacts too, but a real user bug report is always good. Pete
  23. Neither have arrived yet. Pete They both just arrived, together. The FSUIPC key is valid and expires on 23rd July. I'm afraid that the WideFS key in the KEY file is not and never was a WideFS key at all. It is an illegally generated FSUIPC key, made by a pirate generator by the look of it. Using it will stop both WideFS and FSUIPC working correctly. Regards 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.