Pete Dowson

By "current" do you mean 4.953 or 4.954c? Both are concurrently available, the latter being an interim update with additions and fixes. Sorry, not without more information, no. Where are these assigned, and what to, exactly? How are you proposing the intercept these axes in SimConnect? FSUIPC is doing the same of course, as with all controls (events). So do PMDG aircraft, and I assume others. And finally, why are your throttles normally only giving -7040 to +7040? If calibrated in Windows they should give -16k to +16k. Are you taking some raw data instead? (Most digital types give such a range in any case without calibration.) Pete

Always crashing, FSX and P3D? If this was happening to everyone the Forum would be littered with nothing else. What does the crash actually say -- what module, what offset? The stack is little use as it looks like it is corrupt. FSUIPC might be the last DLL standing because it tried to tidy up, sending termination notices etc. What "stuff" of yours is running which might interact so? Pete

Oh dear. :-( Registration has not been done in FS/P3D for many many years! Please PLEASE read the Installing and Registration guide, the document actually packaged in the same ZIP as the installer and which you have apparently completely ignored! Pete

I never said it was a problem, I said I don't know why the other encoders aren't being seen, that other controllers I've used and seen used work with that Lua plug-in. Maybe the only way I'd understand what is going on with it would be to analyse the binary data being received on the USB cable to see why the extra encoders, over two, are not being seen. The function being used -- "com.gethidbuttons" -- may not understand the data it sees. Perhaps it is a completely valid set of data, but just in a format I did not know when I wrote that function some years back. All I can think of doing is to add a lot more code to the Lua, or maybe into FSUIPC itself, to get and log the actual data being received, for you to run and test each rotary in turn, then send me the log so I can match up what happened to what was expected. There you go again. the PROBLEM is not the card, the problem is not knowing why it is different, or in what way this is going wrong. I have been trying to help you sort it out, but if you read back it's only been these last hours where we are finally coming to the conclusion I stated, which you seem to consider as me accusing the card of being or having a problem! I do not know the Pokeys system, I have no idea what it is or what it does, and I cannot possibly know about all the possible interfaces out there. All I can do is try to help. I do not want to have to buy a card just to see. The Lua plug-in system is supposed to alleviate the load on me meeting user requests, by allowing them to do their own thing rather than me add more and more to FSUIPC. If you wish to carry on, when I have a little more time (which I certainly haven't since last Thursday, whilst working with an engineer on my cockpit trying to sort my own problems out), I will look at code needed to find out more about what is happening. I can't really look at that before Wednesday. Pete

No no! I didn't suggest that. I said assign the same FS control for "press" and "realeae", because the rotary does a "press" on one click and a "release" on the next -- or at all the rotaries I've ever met do. So you only get ONE increment per click. There are TWO actions on each rotary -- clockwise and anticlockwise. They signal separately -- otherwise how can they be distinguished? Well, in that case I would say it is something to do with the interface you are using. If I had it here I would you a USB analyser program on it to find out what it is doing, because it is not acting in a standard way. Are all the rotaries recognised as buttons on Joy #2? P="Press", "U" = "Unpress" (couldn't use "R" for release because that's used for "Repeat whilst pressed") All this is explained in the FSUIPC4 documentation, in the section in the Advanced guide which explains button assignment formats. Pete

Okay. But something is making such heavy use of SimConnect that is slows to a crawl. That doesn't necessarily relate to frame rate, though the two are sometimes connected. It could be related to memory, but with it starting to happen within, what 70 minutes or so from the start, that seems unlikely (though not impossible). Here is where the problem starts: 4639734 **** No SimConnect events or states being received! Re-connecting now ... **** 4639828 SimConnect_Open succeeded: waiting to check version okay 4639828 Running in "Lockheed Martin® Prepar3D® v3", Version: 3.2.3.2 (SimConnect: 3.2.0.0) 4639828 Initialising SimConnect data requests now then again only 5 minutes later: 4946953 **** No SimConnect events or states being received! Re-connecting now ... **** and so on, till no response at all. I don't know what FSUIPC applications you have running, but at the possible cost of adversely affecting them you could try increasing the SimConnect timeout in FSUIPC4.INI. The parameter is SimConnectStallTime. Read about it on page 11 of the FSUIPC4 Advanced Users manual. Pete

Sorry, somehow I was unable to continue my last message , so continue here: The button flags supplied by the USB deviceare defined here. You list pairs 1,2 and 3,4, and 5,6. Without seeing the input from your USB connnection I cannot tell, but you could try: Rotaries = { 1,2,3,4,5,6,7,8,9,10 } There's no "buttonbit = 4", only a "buttonbit = 4 * buttonbit", which shifts the bit up 2 places to address the next rotary acion. Remember it needs 2 bits per direction for each rotary (bits = button numbers). And anyway, you don't have a "lack of Joy#64". That parameter is ONLY for the main [Buttons] section. You must still have an entry somewhere with "j" in it, maybe your use of j.b earler. Search for all instances of j, or show me the complete INI/ Pete

Rotaries alternately signal "on" and "off", so you should always program both the "Press" and "Release" to the same control in order to get an It will be 2 clicks. action on every click. That is because the default "Rotaries.lua" is set for just the first 7 buttons. Look: Rotaries = {1,2,3,4,5,6,7} -- Example { 31, 30, 25, 22 } would be 31+30 for one, 25+22 for the next, and so on -- Which is clockwise and which counterclockwise doesn't matter -- you'll get -- fast and slow of each in any case

Why have you removed the top lines from the FSUIPC log? I have the FSUIPC version number there, and ALWAYS need to see that! Anyway, the log shows that the SimConnect part of P3D has gradually "clogged" up, as if it is severely overloaded. Are you perhaps running short of memory by this time (VAS)? You can increase FSUIPC's time out for SimConnect data arrival. It defaults to 1 second, which equates to 1 frame per second, but once messages are delayed by more than that (which should certainly NEVER happen), it will close the link and re-initialise it, on the assumption that the connection is lost. Restarting the connection itself is a big load because there is lots of data to get and set each time. Eventually, unless the performance improves, it clogs up completely, never getting any answer whatsoever from SimConnect. What's your average frame rate with the 777? Have you looked at all the problem reports on the P3D support forum at L-M? FSUIPC is not in control here. The system is not coping. Pete

You've never shown me a FSUIPC log after such a shutdown -- the two you showed so far show normal closing actions, something which certainly wouldn't happen after an error such as the one you show above . I don't know what error C0000374 is, but the module NTDLL is a central part of Windows and provides many of the functions all programs make a lot of use of. so, apart from going through a process of elimination (stopping assorted add-ons, possibly reinstalling FS and so on), the only think I can think of trying is repairing Windows and if that doesn't help, re-installing it. Googling the error I did find this, which mainly relates to the same error during a Windows update, but you might find it useful to follow the same advice: https://www.sysnative.com/forums/windows-update/15943-windows-update-error-code-c0000374.html Pete

I can probably help. Please email me on petedowson@btconnect.com. Pete

InitialButton just does a one off "retend" press of that button. I don't think you need any of that forrotaries. It is just intended to show there can be multiple entries. That's why there's also a "..." afterwards, which is normal punctuation to mean "and so on". Each entry is in the format j.b, separated by commas. You never literally put j and b in! On your earlier reply, I seem to have missed this part: If the assignment to "fast" was when you turned is fast, and vice versa, then changing the assignments around, "slow" for "fast2 and "fast" for "slow" MUST work. It has no alternative. it is merely sending what you tell it. Perhaps you should show me the [Buttons] section from your FSUIPC INI file, so I can see what you've done. Pete

Again, just as before the log clearly shows that FS did not crash, and that FSUIPC terminated normally, look: 969656 *** FSUIPC log file being closed Minimum frame rate was 4.1 fps, Maximum was 11.2 fps Minimum available memory recorded was 1734Mb Average frame rate for running time of 601 secs = 6.1 fps Average weather filter write interval in that time = 75115.3 msecs G3D fix: Passes 16627, Null pointers 0, Bad pointers 0, Separate instances 0 Maximum AI traffic for session was 24 aircraft Memory managed: 157 Allocs, 157 Freed ********* FSUIPC Log file closed *********** If you are not telling FS to close down, something else is, but it is patently nothing whatsoever to do with FSUIPC! If you think FS is crashing, where is the crash information from Windows? And if there is a crash at all, it is certainly occurring AFTER FS was closing down in any case! I really cannot help diagnose problems with other folks' software. Sorry. Perhaps you should try Eaglesoft, if this is the only thing you have this problem with? Pete

Oh dear. :-( The "j" stands for joystick number, the "b" stands for button number. You are supposed to REPLACE those with your joystick number and button number. Why would a parameter always start with "j,b"? Neither j nor b are valid numbers! j = joystick, b = button. It was simply showing the format or the parameters to use: j, b instead of b,j or j/b etc etc! Pete

It may be that the FS controls are wrongly named in FS. Some are -- I don't recall which. As a test you could try assigning them to keystrokes or buttons and see if you get the same. Either way, the obvious and easy solution is to assign them the other way round! Do encoders 1 and 2 give joystick number 2 as well? It may just be that the joystick 2 input is always arriving into FSUIPC before that for the Lua virtual button. You could tell FSUIPC to ignore the buttons arriving first so it sees the ones signalling from the same action. See the IgnoreThese parameter on page 18 of the Advanced User's guide. Pete

Fixed it! The problem with conditional entry annotations being removed for disconnected devices is fixed in 4.954b, now available in the Download Links subforum. Pete

Hmmm. Strange. Are those the only conditional ones? That would be a good clue as to where I should look. Aren't there ones conditional on +Y,0, the opposite situation? That's the more usual arrangement for conditions: "do this if this or do this if not this", rather than "do this and that if this or do just that". BTW, the reason I hadn't discovered your problems before, during testing here, is that normally, when you have different controllers for different Profiles (ie. for different aircraft types, usually), you only have the buttons, axes and calibrations for the specific controllers in the specific Profiles to which they are applicable. Now, I know it doesn't matter for Buttons, which if not connected cannot be activated, but sometimes if joystick axes are scanned but they are disconnected you'd get a spuriously bad return. Unfortunately, my testing was only for the normal case, different devices for different profiles, and Profiles not being loaded are neither annotated nor have previous annotations removed. Pete

Found this bug and fixed it in version 4.954a, now available from the Download Links subforum above. Please run the 4.953 installer before overwriting the FSUIPC4.DLL with the 4.954a version. Pete

I always respond as soon as I'm able, but also sometimes I am holiday, and if it is something no one else can handle then you would have to wait! The version of FSUIPC you are using is out of date and no longer supported. Please update to the current supported version, 4.953. Do this before your next report, please. Meanwhile, your log is very large because appear to have turned on most of the optional logging. PLEASE DO NOT. Turn them all off before you supply another log. After that you do not even need to visit the Logging TAB, as the log is always made and if there are problems they will be logged. Looking at the end of the log as posted: This shows that FSUIPC closed normally, and to do so it mst have been told that FS was closing normally. There is no crash before FSUIPC closed. One thing I would note here is that the frame rates reported of 3.5-4.3 averaging 3.8 are dismal and unflyable, but maybe that was simply because the system was initialising all that time. You appear to have closed FS deliberately after just 4 minutes or so. If you want help with a crash You always need to show 1) the Windows crash details, which give the module and location. If you don't capture this at the time, on screen, you can get it from the Windows Event Viewer, and 2) an FSUIPC4.LOG from the session with the crash, not one related to a normally closed session like the one above. Pete

First a question. Why disconnect anything? Do you simply not have enough USB sockets? Second: I certainly didn't intend for the annotations to disappear just because the controller wasn't located on this current session. The annotations ARE generated afresh for each USED assignment (i.e those loaded for action -- the generic ones and those for the current Profile), but those in other Profiles are left untouched. They are only deleted when they are being re-generated after decoding when loading into the internal tables for use. So, I am puzzled. Maybe my code is cleverer than I thought, and is not loading assignments for missing controllers, so as not to possibly deal with spurious inputs (though those are really impossible because the missing controller is not being polled), Anyway, I will check here, and fix if necessary. Thanks for your report. Pete

I'll try it on another PC tomorrow. Pete

No. You buy either FSUIPC3 or FSUIPC4 (or both of course). FSUIPC3 works for everything before FSX, FSUIPC4 for everything since and including FSX. You can use it on any number of PCs and any number of Flight Sims you want, provided they are all for your own personal use. The license is to the person, not machine or simulator. Your config should be the same for P3D if it is on the same PC with the same controls. Pete

Could either the application or FS be running "as administrator" -- i.e. on a different privilege level? Mind you, the OP did say "my program usually runs fine for about 20 minutes " so neither are suddenly going to change levels. Pete

You are most welcome! Actually, I would be very interested in that too, but when I try to download it I either get a Network Error, or my Virus checker blocks it saying is it really bad! Pete

Reloading merely re-scans devices, same as FSUIPC does on first starting. Are you sure you have turned USB power management off everywhere on USB hubs in Windows Device Manager? If you haven't then devices can go to sleep. Pete