Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Ah, right. that's interesting. Maybe it keeps track over re-plug-ins. Mind you, it might not if you plugged it into a different USB port. Pete
  2. If you wouldn't mind. Thanks. Jut the main controls I think -- throttles and pedals. Certainly those were usually reassigned by FSX. Pete
  3. As the Lua is first executed, it executes all of the lines, in turn, jumping over functions altogether (because they have to be explicitly called). The functions will be called from the event, and the event will occur not before the complete first execution, right to the end. Checking your latest logs, the difference is immediately obvious. (Much easier to see without all the other plug-ins intervening). When running from ipcReady, which is early, it seems the "onground" flag has not yet been set, so your routine "welcome" jumps around a lot of code and sets "finalflag=1". Then, next time, when the "onground" flag is set, finalflag is NOT zero, so again the code is skipped. In other words your logic is not right. You only want to set finalflag IN the main code, after you've processed the change to "on ground", You don't want to set it to 1 on the "else" condition. Not sure about wcflag. Not checked through enough to see what that's for. Pete
  4. Okay. The only problem shown is indeed an incorrect registration. If you'd like to rename the FSUIPC4.KEY file (as, say a .TXT file) and send it to me as an email attachment petedowson@btconnect.com, I will check it out for you. Your SimMarket order number would also be useful, so I can check it against the SimMarket files. (The rename is needed because .KEY files get blocked). Pete
  5. Sorry, I'm rather confused. There's an FSUIPC4.KEY file in the Modules folder, containing the correct registration? Yet the screen says "you must register" or something? Maybe you should just paste the contents of the FSUIPC4.LOG file here. It's usually the fastest way. That's why a log is produced. The SimConnectP3D2.DLL is installed by FSUIPC. However, at present (through something odd in P3Dv3 only, not yet resolved, it isn't seen by FSUIPC or Windows, so you need Simconnect installed in any case. However, if that was the problem you wouldn't even get an FSUIPC menu item. Pete
  6. So, what exactly makes you think the "registration is not picked up"? Is FSUIPC running? The only place to see if the Registration is recognised is in the FSUIPC Options, so I assume that's where you looked? Pete
  7. I need more information. Have you run the Installer for FSUIPC 4.947, the currently supported version? I'm not really understanding what you mean about "can't register myself.". You register via the installer, so what are you doing instead? If you are "copying files", where from? Pete
  8. Can you try the current version, 4.947? There was actually an interim update, 4.946a, released within hours of 4.946, which fixed this amongst other things. It was due to a different way P3Dv3 listed the controls -- they split the total list in two and FSUIPC was not picking up the second half, so missing many of the controls including that one. Pete Pete
  9. You only pay once and get lifetime updates for free. If it ever has to be re-written in future, as FSUIPC5, then that would then be a new purchase, but not before. I hope and expect folks to keep up to date, at least before they come here for support, because I cannot support older versions. Pete
  10. I've been doing more tests with extra logging. Before I send you a link for a test version of FSUIPC, could you please find your DLL.XML file (in the same folder as the FS CFG file), and paste its contents here? There appears to be a big difference in what happens depending on whether the as_btstrp.dll is loaded before or after FSUIPC. On my system if the AS_CONNECT entry is not last in DLL.XML then I get a warning from ASN saying I must restart FSX before ASN will work correctly, and when I do I find ASN has reversed the order of the AS_CONNECT and the FSUIPC4 entries, making as_btsttrp.dll run last. When it is that way around it always worked. I managed to get it to NOT work once when I carried on and ignored the ASN warning. Judging from your log, I think you might be trying to run without the change which ASN seems to do to make it work. This part indicates this: 1529 ------ Setting the hooks and direct calls into the simulator ------ 1529 --- CONTROLS timer memory location obtained ok 1529 --- SIM1 Frictions access gained 1529 ASN active function link set 1529 --- FS Controls Table located ok 1529 --- Installed Mouse Macro hooks ok. 1529 Wind smoothing may be by ASN, not FSUIPC, if it is running 1529 Will switch smoothing action when ASN starts/stops 1529 --- G3D.DLL fix attempt installed ok 1529 --- SimConnect intercept for texts and menus installed ok 1529 --- All links checked okay If so, I'm not understanding why you don't get the warning from ASN? Meanwhile I'll try to find out why it sometimes doesn't work with the loading order reversed. Pete
  11. Another USB HID device seems to have "come alive", but it is causing the error: From HidScanner: 172: Error 6 [00000006] returned on HidD_GetAttributes: (\\?\hid#vid_1493&pid_001b#6&34f5874&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}) Device at "\\?\hid#vid_1493&pid_001b#6&34f5874&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=007F, Product=0000 (Version 231.22) Manufacturer= Product= Serial Number= and, not coincidentally I'm sure, the last device being scanned by FSUIPC is that one, here: 235 Checking: \\?\hid#vid_1493&pid_001b#6&34f5874&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} So it looks like some sort of odd, (not quite valid or normal?), device recorded in Windows, and FSUIPC not properly handling that error 6 return. I think I can track that down now. Thanks very much for the feedback! Pete
  12. Good. Okay. I'll post another link anyway later today and be patient! ;-) Pete
  13. Yes, as documented. The profiles only OVERRIDE assignments to the same keys or button, they don't replace the whole set. You use the general assignments for common things and the profile assignments for specific things. It has always been this way, and it has been found to be the most useful. It doesn't apply to axes and calibrations because joystick axes are always active, so could interfere. But keys. buttons and switches only activate when you, the user, causes them to be. They don't. it is the other way around. Profile keys override settings for those same keys in the general section. Pete
  14. I think you'll need to install at least the FSX SP2 version of SimConnect. There are other threads on this. Something has been changed for P3D version 3 which we haven't solved yet. Meanwhile please use the solution already posted, i.e. install the FSX versions of SimConnect. You'll find all the versions of Simconnect in the P3D "redist" folders. Try the Simconnect.msi from redist\Interface\FSX-SP2-XPACK, for example. I think you'll find you'll be needing at least the FSX-SP1 and FSX-SP2 SimConnects installed if you ever intend to use many FSX Addons with P3Dv3. Pete
  15. Ah, but does it still work if you remove those extra logging lines? If not then I have a difficult timing bug to locate. If it does still work then I think I know what it must have been ... Thanks for the log. It is very useful to help me improve some things in any case. ;-) I'll have another Test version later today. Would you mind trying that for me too, before I "unleash" any more trouble? Pete
  16. Ah, that's good. So either they removed the auto-assigning mechanism, or your particular device isn't a "known" one, i.e. one for which they have the typical usage mapped in the files. Thanks, Pete
  17. Ah, THANK YOU very much. That's much more helpful. So it's hanging in the device scan, even before logging the first device. Hmm. Could you please download this test version,FSUIPC4947a_TEST with additional logging added. Before running P3D, add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=x200000 Please just run it to get, hopefully, a more detailed log. You should then remove the LogExtras line before going back, temporarily (hopefully) to 4.946. Another way to help please, if you don't mind, would be to runHidScanner and show me the log resulting from that, please. The new scanning code in FSUIPC uses the same methods as HidScanner. If this doesn't hang as well it will give me a log more info. You really mean crashes rather than hangs? If so, can you locate the windows crash data from me, please? In Windows' event viewer? That'll be most useful too. Thanks Pete
  18. Why? How will I ever fix problems is everyone did that? I have to find and fix problems! Okay, that is more helpful. So it HANGS at the start-up screen, not CRASHES? i.e. Windows doesn't report a crash? Oh dear. It is precisely BECAUSE it doesn't fail here thgat I need your help in finding out why it doesn't work there! There are so many variations on folks systems that I cannot possibly test here. I do my best, but then I'm reliant on nice friendly users giving me feedback, information, with which to continue to improve the program whilst trying to avoid or at least fix any problems! That's really unhelpful! All I asked for was for more information so I could fix it. I'm sorry you don't have the time nor patience to do this. Hopefully the next person to get a similar problem won't take the same attitude, otherwise I'll not be able to fix it at all, and such users will never be able to update their P3D or FSX-SE either, because each such update requires a new update for FSUIPC. :sad: [LATER] Ah, I see the next person has been more helpful, so I won't bother you any more. Pete
  19. That is always advised in any FS or P3D IF you are assigning axes in FSUIPC, simply because of the possibility of conflicts otherwise. The only additional thing in P3Dv3 at present is that you'd have to assign in FSUIPC if you want to calibrate in FSUIPC. This is wrong, and will hopefully be fixed. I have asked L-M but have had no response yet. I've no idea what FS Force is doing to make this necessary. However, there's a misunderstanding here. The ONLY reason for disabling controllers in FS or P3D is to avoid a potential (and I mean potential) conflict should at any time in the future FS or P23D automatically re-assigned axes. To reproduce an explanation I've already written in another thread near here: If you can live with the fact that such things may well occasionally happen, and then solve them there and then (by unassigning all the axes or buttons which have been automatically re-assigned), then you can do whatever you like, mixing this that and the other. The problems in the past have simply been the amount of problems folks get into with these conflicts, when they do arise, and the work in trying to resolve them which should not be necessary. Pete
  20. No, I always disable controllers in the Sim. You should really do this if assigning in FSUIPC. No. How can it get "over-tasked".? Pete
  21. It runs fine here on all those plus FSX. I need more information, please. Specifically what actually happens -- "will not run" is rather less than informative. And a view of the FSUIPC4.LOG file (in the Modulers folder) from the unsuccessful attempts would be handy. There's really no point in reporting things like this with no accompanying information, don't you see? Pete
  22. No. It looks like a P3D corruption or driver conflict. I'd report it to Lockheed-Martin if Iwere you. Pete
  23. If it is a purchased key, for FSUIPC4/WideFS7 (not FSUIPC3/WideFS6) then it will be correct. So this means you are making a mistake. ALL three parts -- name, email, key MUST be exactly right, exactly as listed in your SimMarket account. However, this part of your first post is nothing to do with Regsistration: This shows there's something wrong with your FSX-SE installation, and I can only help with this by looking at the Install Log file, as I asked. These are two completely separate matters! Pete
  24. Thank you. But actually, you might not know it works .. yet. The auto-reassignment in FS occurred when FS thought the device was newly connected. Sometimes that's because you unplugged it and reconnected it, or sometimes it is an electrical oddity in the device, and sometimes it's just some update or other difference happening when re-booting the PC. However, I have high hopes that it is indeed not doing it in P3Dv3. They seem to have a lot of things to fix in this area in any case, and the FS auto-assignment action was a deliberate user-friendly facility in any case, so that beginners didn't have to worry about assignment of the more common and known device types. Pete
  25. This is a P3Dv3 problem, Please read the pinned thread about this at the top of the Forum. 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.