Pete Dowson

No idea, sorry. Does it work without the extra 1? Have you tried making your own macro for it? I only supplied the Macro files as (I hoped) working examples. I'm pretty sure i checked each one but maybe I forgot to use that one. I don't have the PMDG 737 aircraft panels installed as a rule, and i am a bit tied up at present, unable to install and check immediately. If it works without the '1' let me know please and I'll change the example. Really? That's odd. It seems to work here. Are you pressing "confirm"? I'll do some experiments, but it will be later in the week. [LATER] Okay, I've reproduced the problem and fixed in in FSUIPC4, so it will be the same in FSUIPC3. I'll sort it out tomorrow, probably. Look out for an update. If the Macro is in error all I can do at present is fix my copy (delete the '1'?) and include it when i upload the updated FSUIPC3. Regards Pete

I suspect the stutter will be related to the nature of the asynchronous interface used, the Windows messaging system, so it will vary from system to system depending on performance and workload. Good. Thanks for confirming. Regards Pete

Thanks for the example. I have reproduced that and found the bug. Sorry about that. I am building versions 3.823 and 4.304 now and will upload them later today. Please watch for updates in the Downloads announcements. [LATER] Okay, the updated versions are now available. Regards Pete

No, "0" isn't replaced by "&H". The "&H" part just says "the following number is in in hexadecimal" -- the same as the prefix "0x" in C/C++. Preceding 0's in a hexadecimal number mean EXACTLY the same as preceding 0's in a decimal number, or a number in any radix -- absolutely nothing, just zero! The offset 0231 is the same as 231 and 0000000000231. The number of 0's at the beginning are completely irrelevant. Same as decimal 0000001 is the same as .... 1, no larger, no smaller! They can begin with 1, 2, 3 or 000001, 000000002, 03, whatever you like. The only thing to be aware of is the peculiarity of Microsoft VB to change any hexadecimal number larger than 7FFF into one starting FFFF... ("sign extension"). For instance, it changes &H8100 into &HFFFF8100. Why? No idea -- it is bad programming or bad design or a bug. It even changes &H00008100 into &HFFFF8100 ! Apparently, to stop it doing such stupid things you should add another & at the end. Thus: &H8100& which does actually compile as &H00008100 ! Pete

I can understand possibly re-installing the Level D 767, but from all the reports I've read, re-installing FSX is likely to induce many more problems than it solves. Does that include the Windows "WinSxS" folders containing SimConnect versions? You don't need to remember it. As it says on screen, there is a file, the Install Log, which tells all. You've messed up SimConnect, which seems to often happen when you try to reinstall FSX. The way to fix it ("repair SimConnect") is described in the "FSX Help" announcement above. Regards Pete

I think the way to make that work is to assign the "Press" action it to "Throttle decr" with repeat enabled, and "Throttle cut" on release (or the individual engine versions of these two controls). This is not sure-fire knowledge though, it is only a hazy recollection. Regards Pete

Okay, so I should be able to reproduce it. Thanks, Actually all i needed was the Keys section -- i.e. this bit: So, now I need to know which of these keys I should be testing to reproduce the result you get. Don't you remember, I did ask You seem to miss half of what i say and ask each time, so this is getting to be really hard work! i am not going to embark on experiments to reproduce the problem until I can do exactly what you are doing, so I need for you to TELL me. See? I cannot see your PC from here, I cannot guess exactly what you do, this is why I ask the questions. I have to repeat the same questions over and over because you seem not to read them. Incidentally, I note that you already have one key programmed for Macro actions on both press and release. This one: 6=N77,8,M1:165,0,M1:164,0 That appears to be for an ordinary "M" key press (i.e unadorned by Shift, Control etc). Regards Pete

I hope you mean 3.82, not 3.20! Please first try 3.822 which you can obtain from the Other Downloads announcement above. Yes, but I understood what you were saying in your first message!!! What i said last time, which you appear not to have read at all was this (I have highlighted the parts asking you to do something): The point here is that I want to test it here and to make sure I do EXACTLY the same as you I need the EXACT information I asked for. I don't ask these things for nothing! Regards Pete

A Window which is Maximised! i.e. Windowed mode (the normal window display where you see other programs on the Windows desktop), but with FS maximised (press the maximise button, top right in the Title bar, next to the "X" button for termination. To change between Windowed and Full Screen modes, press ALT+ENTER. Here the only disadvantage of using Max'd Window more is that you have a title bar at the top. My frame rates are the same as in full screen mode. But take care to make sure the Windows Task Bar is hidden -- set its properties to "Auto-Hide" and untick the "Locked" and "On top" options. The Task Bar properties can be accessed by right-clicking on the Windows Start button, selecting Properties then TaskBar. Regards Pete

Yes, the Install log looks fine and shows FSUIPC4 is installed correctly. But that isn't what I asked. I said: Maybe you could go and find the correct answers, then we might get somewhere? Do you also confirm that this "IFly 747" uses FSUIPC, and that it is compatible with FSX? A lot of panels designed for FS9 won't work in FSX, or only work in DX9 mode. Are you using DX9 or DX10 with FSX? Regards Pete

Okay, so it sounds as if it isn't using any protocol I know about. Message formats? You mean PFC's Proprietary protocol? I don't think I'm allowed to publish that -- you'd need to apply to PFC and probably sign a non-disclosure agreement. If it isn't set to Elite protocol, then it must be some protocol I've never heard of, used before I ever heard of PFC or saw its products. Sorry, you do need to discuss it with PFC. I really cannot support disused protocols. Regards Pete

By "new FSUIPC", which do you mean, please? Always state version numbers, they are easy enough to find. Please show me the [Keys] section of your FSUIPC INI file and tell me exactly what additional action you are trying to assign to which key, and I will try it here. -- but if you are not using the very latest FSUIPC version (3.822 or 4.303 at present, see Downloads announcements above) please try that to make sure it is still a problem. I hate looking for problems I've already fixed! Regards Pete

That's much better -- at least you don't have the dual axis types both being used. The fact that there's an initial "8192" (calibrated from 0 I assume) being sent is now most certainly due to a zero reading being sent either by your joystick or by its driver. So that's really as much as FSUIPC can do for you. Why you don't see the same in FS9 is odd -- but maybe you should do all this in FS9 and compare logs (though, sadly, I don't have exactly the same logging there). Maybe it is occurring in FS9 but has no noticeable effect because it occurs before FS9 is "ready to fly" -- in FSX these operations are not actually started until that stage, so you may be observing a spurious reading from the driver/joystick which has always been there. For the PMDG? So now it is impossible to see if anything in the PMDG code is responsible, or contributing. Don't you ever use other aircraft? Results from a default aircraft would have been far more relevant and interesting. Why not simply make that section THE default [Axes] section, so you can use it with all aircraft? By the way, I did say I fixed the problem setting the logging options in 4.302, and now 4.303 is released, but I see you are still using 4.301 (not that it would make any difference here). I don't think there's much else I can do for you as the cause certainly looks external to FSUIPC. I cannot make any of my "cheap" joysticks/gamepads (that I keep around just for such testing) do the same -- they use default Windows drivers. Regards Pete

I don't know, sorry -- I don't have anything to do with that side. You'll have to raise a "problem ticket", with SimMarket. Pete

If you are testing the spoiler lever on the ground, DON'T! With FS, as you operate the spoiler lever it naturally passes through the "ARM" position (detente). If you are on the ground at the time, FS sees the ARM and the fact you are on the ground, and deploys 100% spoilers automatically (as if you'd just landed). Getting them back down is then difficult until you spool up again (e.g. as if for a Go around), as you've found. the same thing can be seen if you use the mouse to drag the spooler lever on the Quadrant gauge in your FS panel. Regards Pete

I use a 9800GTX on one PC and a 9800GX2 on another. The newest nVidia drivers I've got, 177.79, are actually very good, performance-wise (much less stutters in DX10 mode than even using 177.70), but I have had three occasions this wee where FSX has "crashed" into a black screen with on way out. This wasn't when going into a menu item, just with FSX sitting there, parked at an airport, one occasion flying. I've taken to using maximised windowed mode (same frame rates) for now. Regards Pete

Sorry, I know of no change whatsoever in the PFC protocols I support which would make it "not recognise" any PFC digital control system set in PFC digitaL protocol mode. The protocol has been substantially extended over the last three years, but not in any way made incompatible. What version of my driver did it EVER work with? Are you sure it is one of the series of PFC systems which are supported by their digital protocol? Are you sure it isn't one of those systems with dual PFC/Elite protocols built in, and is switched to Elite? (I think they had a protocol switch behind the throttle quadrant). Are you sure it is operating at the serial line speed set in the driver? You may need to visit PFC's forums for more help -- www.flypfc.com. Regards Pete

If you are assigning axes in FSUIPC, there are only two "ways" -- (1) assign to an FS control. That routes it back to FS, and then FSUIPC calibration is optional. This method is less efficient, but gives you the complete range of FS axis-type controls to choose from. Or (2) assign "Direct to FSUIPC", which bypasses FS altogether, going direct to the calibration section. Using that you MUST calibrate in FSUIPC, or you won't get any results. This way is more efficient, but you are then limited to the axes FSUIPC can calibrate for you. Provided they cover all you want, it is the best way. I'm pretty sure it does say most of this in the documentation some place, too. Regards Pete

A "black screen" isn't a CTD. CTD means "crash to desktop", which means FS simply disappears without trace, leaving no window, no message, and you are dumped back on the Windows desktop. Surely your Windows desktop isn't all black? If you do really mean a black screen, then it sounds exactly like a fairly well known video driver problem. Try switching FS to windowed mode first. If it then works you have a video driver problem. See about updating your drivers. Regards Pete

What are you "fiddling" with? You just assign the axis, don't touch anything else there, and then go to the Joystick Calibrations tab and calibrate it. It isn't complicated, and you shouldn't be fiddling with anything. What "other ways"? If you want to use FSUIPC for your joysticks you MUST calibrate. If you don't calibrate in FSUIPC what's the point? Have you found the User Guide? It is supplied with the program and has extensive sections on both joystick calibration (which you can use with FS assigned axes or with FSUIPC assigned axes, it is the same for both), and on axis assignment -- which is where you should start if you've disabled all joysticks in FS and want to use FSUIPC only. There are even pictures provided to help. I cannot reproduce everything here, please do take a look. If you've been "fiddling" with things and got yourself into a mess (why?), just delete the FSUIPC INI file (from the Modules folder) before loading FS, and you can start again. But don't fiddle. Do one thing at a time. Read the relevant sections first. Pete

If you want a dedicated Reverser, rather than reverse on part of the throttle, then you can either assign it to the Mixture in FS, then calibrate the Reverser in FSUIPC joystick calibrations, or assign the lever to "Reverser" in FSUIPC's axis assignments, using the "direct to FSUIPC" option. If you just want reverse on a portion of the throttle, go to the Throttle calibration in FSUIPC and check to "Map to 4 throttles" options, then go to the 4 throttles page a calibrate the 1st throttle with reverse and idle positions as well as max. For Gear Up/Down on a lever you assign the lever in FSUIPC Axis Assignments, and use the right=hand side for those controls, do not assign an axis control. This particular use of an axis is actually the example provided in the FSUIPC User Guide, and that provides more details (and pictures) than I can provide here, so please refer to the User Guide. All your questions are answered there in any case. Pete

Probably because WideServer isn't running. WideClient only thinks it can connect to SimConnect when you used the same Port number, but of course it cannot talk to SimConnect -- they use entirely different protocols. If there is no WideServer log in the Modules folder, then WideServer is not active. Have you even registered it by entering your WideFS7 key when you installed FSUIPC4? Check the FSUIPC4.LOG. What does it say near the top about your FSUIPC4 and WideFS7 keys? What does the "About" tab in the FSUIPC4 options show (look to the bottom right-hand)? Pete

It looks like you only ever fly a 747-400, then, or else use the keyboard for Throttle with all others? Your default axis assignments are: 0=1X,256,F,65763,0,0,0 ailerons 1=1Y,256,F,65762,0,0,0 elevator 2=1V,256 3=1V,B,-16384,-10012,66080,0 gear down 4=1V,B,10496,16383,66079,0 gear up 5=2X,256,F,66387,0,0,0 left brake 6=2Y,256,F,66388,0,0,0 right brake 7=2Z,256,F,65764,0,0,0 rudder i.e. no throttle assigned at all, unless you do really have throttles assigned in FSX as well. This is what it looks like in the Log. These are the assignments being used in your test: 0=0X,256,F,66382,0,0,0 spoiler 1=0Y,256,F,66420,0,0,0 throttle1 2=0Z,256,F,66423,0,0,0 throttle2 3=0R,256,F,66426,0,0,0 throttle3 4=0U,256,F,66534,0,0,0 flaps 5=0V,256,F,66429,0,0,0 throttle4 6=1X,256,F,65763,0,0,0 ailerons 7=1Y,256,F,65762,0,0,0 elevator 8=1V,256 9=1V,B,-16384,-10012,66080,0 gear down 10=1V,B,10496,16383,66079,0 gear up 11=1P,0,F,66416,0,0,0 pan view 12=2X,256,F,66387,0,0,0 left brake 13=2Y,256,F,66388,0,0,0 right brake 14=2Z,256,F,65764,0,0,0 rudder This puzzles me as I thought you said you had them assigned direct, as I advised. Instead you have them all arranged to be sent to FSX as FS controls, before then being intercepted by FSUIPC4 for calibration. As I explained, when you do this it is just the same, as far as calibration is concerned, as when you assign in FSX only. FSUIPC4 does not intercept the controls and perform the calibration until it has seen the control used -- and it has to stop interception each time to load an new aircraft or enter and exit the options so that it can re-check which axes are being used. Therefore, one value, from FSX, will always get through before FSUIPC4's calibration can take effect. Normally all this will happen quite quickly because of jitter on the axes, but if you have stable inputs, or the axes parked in a stable position (possibly jitter-eliminated by their own drivers), then you may well see FSX's initial default reading before FSUIPC4's calibration takes over -- see the message earlier from Peter Hayes You can avoid this by assigning the Axes "direct to FSUIPC4 calibration" instead of to FS controls. I thought you said you were doing this, but you are not, so the logs and so on are really of little use to us. It does worry me a little, still, that you continue to get both THROTTLEn_SET and AXIS_THROTTLEn_SET controls being sent. This is why I asked in my last message about other add-ons: Hmm. The PMDG add-on makes it "exceedingly neapolitan" if you ask me -- there's a lot of extra systems code added which takes over a lot of FSX's functions. I'm wondering if the PMDG code could be confusing the issue here. Could you please use a default aircraft for these tests? You'll need to load FSX, change all your axis assignments to be Direct, load a default aircraft, save a flight marked as "default". Then relad FSX and see if you still get the problem. Show me the logs then. Regards Pete

Yes, there is, but there is absolutely no way that FSUIPC can interfere with any of that, and it can happen as well without FSUIPC, or indeed, other things installed instead. It is a video driver related problem and all that FSUIPC contributes is a timing and memory difference, and even then mostly not in FSUIPC but in the SimConnect component of FSX. I was plagued with much worse problems with FSX -- switching between full screen and windowed, or between either and minimised, was always so precarious that I avoided doing it like the plague. However, the latest nVidia drivers seem to have fixed all that, at last (177.70, or better 177.79). And, yes, I got those problems with FSX fresh install, nothing else added, not just with FSUIPC installed. So I repeat, and re=emphasise, there is absolutely nothing in FSUIPC which can possibly interfere with anything FSX does with your video displays. And I am getting rather tired of taking blame for something which has occurred with FSX now for all the time since it has been released and happens in all sorts of circumstances. Pete

Yes, of course it does. That''s what it says in the description! Interim updates are always by DLL replacement! Have you never looked before, not ever, in the years I've been doing this? Incidentally, 4.301 has since been replaced by 4.302 and then 4.303, but neither of those affect this change. Here it works absolutely the same as in FSX. I have no idea what your hat configuration looks like, so how can I suggest any change? I have a hat assigned to the Pan View axis in FSUIPC4's Axis Assignments. That's it, nothing else to assign. It sounds like you are still using the Button assignments either instead, or as well. Check all this. The improved operation can only work with the axis assignment, and that is regulated to provide exactly the same repeat rate as demonstrated by FSX. In other words, for the same assignment, FSUIPC4 is now doing the same as FSX, so I cannot do any more. Regards Pete