Pete Dowson

In that case it is unlikely that there's any way of fixing it without the help of those who made the software. But we can possibly look further.If it is controlling throttles via FSUIPC, or via SimConnect using axis events, it might be possible to intercept them and stop them whilst the separate reversers are in use. But we need more information. Do this. Put the throttles to idle. Then before operating the separate reversers, go to FSUIPC Logging and enable ipc writes, non-axis events, and axis controls. Just those three, on the left side. Ok out of that, then operate the reversers a little, but don't touch anything else. Close FS and show me the FSUIPC log file. Regards Pete

I've never heard of too much data being a reason something cannot be done. Do you really mean you can't find a way to access it, via L:Vars or offsets? The offsets at 03C0 are expressly provided so that prgrams can detect the state of the buttons. There are no others for 'real' buttons. But with a rotary the buttons would be toggling on and off quite rapidly. I'm not sure you'd be able to catch them all in an external program. You'd probably need to add a second assignment for each button to increment or decrement a count in a user offset (there are 64 free ones from 66C0 - 66FF), and have your program read those instead. Regards Pete

I don't know anything about what your TQ is doing. I assume it comes with its own driver software which is writing directly to the throttle controls in FS? If so, I think you need to get some help from the suppliers. Really their software should not be sending data for the throttle when it is parked in idle -- that's probably the only way you can get a separate reverser working. Apart from the physical disconnection you have tested there's really no way to stop one without stopping both. If, on the other hand, the TQ throttle inputs have been assigned by you in FSUIPC's axis assignments, you could simple use the throttles off ot toggle control in FSUIPC -- assign it to a button or key. Regards Pete

You've now sent me three emails and I've replied to each one but each is being rejected because your email address is in an "incorrect format" (at least, that's what the rejection it says -- I can't see why it thinks that, though). Please PLEASE read this thread. I explained what was wrong with your INI file long before your second email! I've fixed FSUIPC4 so version 4.81 won't crash on the sorts of errors found in your INI file -- it will add the missing ] to those lines for you. However, I've also tidied up your INI file, removing the duplication and put everything tidily into Profiles. Pete FSUIPC4 INI.zip

I didn't either, but i was trying to get two keyboards sending different things for the same keys to two different programs running on the same PC. I think the author of HIDmacros is quite helpful. Have you tried? Regards Pete

You need to be careful here. The default and most add-on aircraft don't use the main elevator to control pitch but the trim. In a real aircraft trimming moves the "hands off" poisition of the yoke as well as the trim wheel, But there aren't many home cockpits which have such a mechanism. Either way, because the A/P maintains the aircraft in trim there is no need for the pilot to do anything with the trim or the elevator when turning off the A/P. The ailerons should be no problem in any case as you'd rarely if ever disconnect the A/P while it is turning, unless it was going wrong. Additionally, yoke movements by the pilot, apart from small movements maybe, would disconnect the A/P automatically as it assumes he's taking control. I think the only serious candidate for motorised control to match position is the throttle, where the throttle position should match the autothrottle setting. The PMDG 737 implementation actually provides a little marker on the N1 gauge on the EICAS which you can line up with the current A/T setting so that when you disconnect A/T the throttle doesn't change. It isn't actually possible to move the throttles with all A/T implementations, though, unless you disconnect them from FS first. FSUIPC does provide such a facility, and also the readout which you need to match to the FS A/T setting by moving the throttle. There are many cockpits which have this, and there are commercial throttle quadrants available to cockpit builders which implement this. Regards Pete

Well, that PMDG one didn't have "Boeing" in the title. You might need another line too: 2=PMDG 737 There's no practical limit on the number of lines here. You could have simply added all your aircraft to the Profile as you loaded them for the first time, but otherwise these generic substrings will work. Note that you'll also get the default FSX 737 in this profile as well, i expect. Regards Pete

Sorry, I don't understand what it is you want to do. What sort of "rig"? I can help answer software questions, but for hardware you'd be better off in some place like http://www.mycockpit.org/forums Regards Pete

Actually, with the setting "ShortAircraftNameOk=Substring", they don't need to actually begin with the characters provided, they will match anywhere within the name. Sorry, i din't think i was "talking down" in any way whatsoever. I try my utmost to help everyone who comes here for help, whether they purchased anything or not. You can surely see that if you browse a little here. I think you are being very unfair, especially when I go out of my way to help 7 days a week at almost any hour. I don't think you'll find many other products supported as well. :sad: Pete

Logs and INIs arrived. I've had a brief look. Your button and key assignments are one f the clearest cases I've yet seen for using an abbreviated name, or even Profiles, for the assignment sections. You have lots and lots of duplicate assignments for the same aircraft type just because of different liveries. Oddly you seem to have UseProfiles=Yes but you've not defined any profiles. And, worse, you have ShortAircraftNameOk=No Change that to ShortAircraftNameOk=Substring then you can delete all of the duplicates and shorten the aircraft names in the titles to common parts. I'm not sure yet what is crashing FSUIPC but I suspect it's one of the corrupted sections. You have several headed badly: [buttons.Level D Simulations B767-300ER - United Airlines [buttons.Level D Simulations B767-300ER - Delta Air Lines [buttons.Level D Simulations B767-300ER - British Airways [buttons.Level D Simulations B767-300ER - Varig [DXT3] [buttons.Level D Simulations B767-300ER - Continental Airlines etc. I'm. not sure what Windows will make of those -- they need closing ] characters.I also don't know how your file got into this state. Windows standard profile functions are used to maintain the INI file, and that must have section titles delineated by [ ... ] I'll do two things: 1. Fix FSUIPC so it doesn't crash on such bad inputs 2. Tidy up your file and send it back to you. I think with Profiles, not Aircraft-specific settings, don't you? I'm just relaxing for the evening now, though. I may do it later tonight, or if not in the morning. Regards Pete

I'd have done memcpy (pDBAK, pS, sizeof(PMDG_NGX_Data)); i.e the size of the struct itself. Then you can see what it is directly and make less mistakes! ;-) Regards Pete

Did you calibrate it? If not it won't work. Please read the section on the User guide on calibration. Follow the numbered steps. Sounds like you also have a throttle assigned which is not constant. You should park the thrltte in the idle position -- a nice stable idle, a calibvrated dead zone. Have you calibrated the throttle? If not, that's going to interfere. There's only one real control over this in FS -- revere is merely negative throttle. Regards Pete

There you go. Since the previous time you deleted the "PMDG737" entry, which was probably not a match for anything in any case, and added two other 737s -- not PMDG? If you want that profile for all 737's, not just PMDG'd, you just need to replace all three of those lines by "1=737". But otherwise you need to carry on what you are doing, selecting the PMDG737 profile each time you load up a new 737 that you've not yet assigned. There can't be thousands of them. Eventually you'll have them all listed. As I said, FSUIPC cannot guess that you want an aircraft it hasn't seen before assigned to a specific profile. it's up to you to tell it! Regards Pete

A memcpy with the size set to the size of the struct copies the whole struct. I've no idea what you mean by "the arrays in the struct are not cloned". Do you mean the arrays are represented by pointers to somewhere else in memory? If so, whose memory? Bear in mind this SimConnect client data feature can be used by a separate EXE or even from a separate PC, so all the data must be in that one block which is passed via a Pipe or TCP protocol. Regards Pete

Not sure why you need to reinstall FSX. Earlier you said If it is so consistent, why a reinstall? What does that do for you? Regards Pete

You've still got something wrong then. The profile box should already be ticked and the Profile name showing in the options title bar. That's what it's all about. Make sure you are running version 4.80, and show me the INI file as ou now have it. Pete

Look at the aircraft you have listed for your "PMDG737" profile: The "PMDG737 aircraft might not match ANY of them if they all have a space after PMDG, ad the only other one you've added is the House Winglets 800. You either need to select the profile for each variation as you load it (it will be added to the above list so you only need to do it once for each), or simply make a short version of it in that list which matches them all, such as "PMDG 737". Either weay it isn't hard nor a lot of work. You seem to expect FSUIPC to guess? Pete

Surely the other way round, only checking those which are requested to see if they've changed? Regards Pete

Surely you just copy the data in one call to the Runtime C lib function memcpy() or to the Windows function CopyMemory(). What's taking 500 mSecs? Pete

If you have MS visual Studio installed you should be getting definitive information from MSDN (Microsoft Developer Network), which access is normally installed with MS Visual Studio. Here's what that gets me: To create a Message Only Window specify HWND_MESSAGE(-3) for the cp.Parent member. Message-Only Windows A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages. To create a message-only window, specify the HWND_MESSAGE constant or a handle to an existing message-only window in the hWndParent parameter of the CreateWindowEx function. You can also change an existing window to a message-only window by specifying HWND_MESSAGE in the hWndNewParent parameter of the SetParent function. To find message-only windows, specify HWND_MESSAGE in the hwndParent parameter of the FindWindowEx function. In addition, FindWindowEx searches message-only windows as well as top-level windows if both the hwndParent and hwndChildAfter parameters are NULL. Regards Pete

Ouch! So there's something in those assignments which 4.80 doesn't like. I certainly need to fix that. Can you please send the INI which causes the crash to me so I can fix it? AND the FSUIPC4 log file which is produced in an attempt which crashes.ZIP it and send it to petedowson@btconnect.com. I am working on 4.81 this very moment for a release this week, so as soon as you can send me this the better, please. Please then also try version 4.805 which you can get from the Download Links subforum. Regards Pete

This sounds a bit like the SimConnect "trust" bug, which is quite a problem with the original FSX release and the SP1 update, but which was mostly (but not completely) fixed in SP2. I see you supplied the Installer log, which isn't really relevant because your install went okay, you say. Is there an FSUIPC4 log file there too? If so, please show it to me. If there isn't, it means that FSUIPC isn't even getting loaded. in that case see the first thread in the FAQ subforum. The usual reason for a crash at the point you got to is a corrupted weather file. But the run-time log should help determine that. The other piece of useful information would be the details from the Windows event log -- there will be an entry there recording the crash and pointing to the culprit module and the position within it. You can find the log in Computer Properties - Manage - System Tools - Event viewer - Windows Logs - Application. Regards Pete

Hmm. Odd. How could a facility which is off unless you engage it affect something else? I assume tooltips are implemented by FS seeing where the mouse is hovering and then displaying little windows? I can understand that not happening if the mouse is not really allowed to hover, maybe, because of other actions it is being used for at the same time, but if mouse look is not in use I don't understand how it can affect it. [LATER] Aha! I see ... yes, my error. I relegated the mouse operations check to a function and used its return to determine whether to call the normal Windows procedure or not. I was returning the wrong value (a little -, i.e. minus sign, missing) if mouse look was enabled even if not engaged. Sorry. Odd that it hasn't been reported before. This isn't new. It'll be fixed in version 4.81, which will be a new complete release ready for Prepar3D's forthcoming 1.3 update. I'll probably rleease this on monday. Pete

There appears to be something wrong with either your FSUIPC or WideFS key, as FSUIPC doesn't like it. Please send your details, including a Zipped FSUIPC.KEY file, to me at petedowson@btconnect.com. Pete

Sounds like the SimConnect trust bug. FSUIPC isn't even getting loaded. See the first thread in the FAQ subforum. Pete