Pete Dowson

Okay. It isn't my program. Does it allow sounds to be played? Regards Pete

I very much doubt that the panel has been re-written for FSX. If it had been it would not have had this problem, because they would most certainly have used the FSX tools available. Er, please don't apologise -- what problem has such advice caused? I'm confused now. I thought you had a problem and were looking for a solution? Yes, fine. I don't see where that is relevant nor why you are assuming I thought you did. I thought I already made that extremely clear? Where's the confusion? You were advised to use an option that, so far, has not been possible to implement in FSUIPC4. The reason you were advised to use it is because that's how they got around the problem in FS9. I explained all about how I fiddled it for FS9 but not for FSX. Of course it does. No, because I knew all that, excepting for the fact that I suspect your belief that you have a completely newly-written FSX aircraft panel is mistaken. It will be an FS9 panerl made to work in FSX. Not by me in FSUIPC4, excepting, as I very clearly said before (and here I've emboldened the salient words which you seem to have missed): You seem to have been very confused by my reply, where I thought I was being helpful and explaining everything. I can see I should refrain from that in future. In particular I find your next paragraph rather odd: Surely I made it clear that I fully understood the problem? I even repeated your complaint (which you now repeated back to me!?). It appears you simply have not read much of my explanation, so I'm sorry for wasting your time. In summary, at present there is absolutely nothing I can do to resolve such panel programming. If you ever do wish to re-read my earlier message and actually do the Logging I suggested I will certainly take a look and see if there's some way I could help. But really the problem is in the panel, and the programmers should have fixed it. Relying on the work-around I did for FS9 is not a good excuse. If i don't hear from you again I will understand you don't want me to look at it further. Regards Pete

Sorry. what is "FSU"? You've lost me already. I really don't understand what you are talking about now. Is this "the saitek new flight sim yoke and quadrant?" Start from basics. Forget FSX. Get the joystick working properly with Windows Game controllers. Calibrate and test there. Then delete your FSUIPC4.INI file so you start again. Load FSX, get everything on the Joystick working in FSX, forget FSUIPC4. THEN and only then, see what you want to do with FSUIPC4. Regards Pete

Acceleration data? You mean the raw information from SimConnect? I can't see how any changes to FSUIPC can change how the Sim Engine itself behaves. No, none at all. I'd need quite a bit more information. a lot of the recent changes, leading to 4.20, were to fix such problems with LevelD aircraft. To do with axis intercepts. The list of all the changes between major versions is given in the History document. There is a later version of FSUIPC4 in the FSX downloads announcement above. Is that the same? [LATER] From the title of the thread, should I assume you mean you are reading acceleration data from FSUIPC, not FSX, and you suspect this? can you log the stuff and tell me what you think is wrong, perhaps? FSUIPC does provide quite comprehensive logging -- use the monitor feature (Logging right-hand side), and set "normal log". You could also see real-time values on screen using the FS display option simultaneously, but the log file will contain the original Simconnect values as well as the ones I'm providing. Pete

Hmm. Not sure how that could happen. Buttons and joystick axes are completely separate -- in fact Buttons and POVs are read via the old Windows "joy" API whilst the axes use the new DirectInput facilities. I wonder if these are interfering at driver level. Shouldn't happen of course. Ah, butwait a mo'. I did provide facilities in FSUIPC4 (only) for programming up to 4 POVs per joystick (P, Q, M and N) in the Axis Assignments facility too. In fact you could use that instead of programming the POV as a set of buttons. I may need to experiment there, if I can get hold of a device with POVs (used to have such things, but these days I'm all PFC). Then you should simply be able to assign it to the standard FSX PAN command used for POVs. Regards Pete

Why ask "via FSUIPC4"? All it does with them is send them to FS. How can they be more or less relaible than via any other way of sending them? Anyway, please see this thread, where someone has got exactly what he wanted working in FSUIPC4 + FSX: viewtopic.php?f=54&t=66828 Regards Pete

Ouch ouch! cMea culpe! I meant "raw" -- the 0-255 range thing implies Raw and I said direct. Damn. I'm getting senile. So sorry. You can use Direct to FSUIPC all you like. That's not the problem, sorry. It was only the 0-255 range which worried me. FS doesn't actually offer any calibration itself. If you try to invoke that it simply calls the Windows Game Controllers. you are better of setting up and calibrating everything before you get anywhere near FS itself. "RAW" mode bypasses the Windows calibration, but as I said I don't advise that except for software controlled axes. I think the documentation I provide is clear that the FSUIPC calibration for FS controls is based on making the CONTROLS inside FS more accuratley do what you want. The basic setup from windows has to be reasonably good in the first place otherwise it only has poor material to work with. Ah, good. Glad you got over my bad mistake earlier. What is this "detente"? Is that where you calibrated your Idle position? Your calibration figures are (do you have one or two throttle levers, BTW?): Throttle1=-16384,-10922,-10662,16383 Throttle2=-16384,-10922,-10922,16383 which seems to place the idle very low, and with barely enough moving space between lower idle and upper idle. Maybe there's not really much gradation on your levers between -10922 and -16384? Can you tell me which aircraft this is with, please? Choose something like the default 737. Observing the throttle quadrant panel whilst pulling the lever(s) back, what happens when you pull back passed idle? Well, it is, really. I can't see what you can see so I don't know why it has been such a problem for you. Sorry. Regards Pete

Hmm. No, not really. you've got the main instrument panel okay? What if you use the Views menu to select the other subpanels? Is this will all default aircraft? If it is for all panels, everything, then it sounds like it has to be either a corrupt module in FSX, so a repair should fix it, or, if you are getting the right shape/size black boxes but no graphics, some graphics setting or video driver incompatibility. You say you reformatted the hard disk -- extreme, that! -- so presumably you installed new video drivers after Windows? Maybe these weren't the ones you had before? Regards Pete

Ah, ok. Ah, yes, actually a 55 mSec interval, 18.2 Hz. But I didn't know you were an FS programmer then. ;-) Not explicitly. You'd have to do it the same way FSUIPC has to do it -- intercepting the axis controls (events) and not forwarding them on when they are to be inhibited. Anyway, could you tell me which version of FSUIPC4 you've been testing the 310A facility with? Because of problems with axis interception on some aircraft (LevelD in particular) I've had to make a lot of changes and now FSUIPC4 only intercepts axes if it has to -- for calibration or re-direction. I've looked at the code and this also (now) applies to the 310A disabling options. So it SHOULD work, but maybe only with very recent versions. This appears in the History document for 4.16: so you should be okay with the current release 4.20 and the latest interim release in the Downloads announcements above. Regards Pete

Ah, right. Yes, I suppose that's another (hopefully rather rare, however) reason! ;-) FSUIPC? The first version was for FS2000, but made to work on FS98 as well so I could make it compatible with all the nice FS98 add-ons I had at the time, and which used "FS6IPC", Adam Szofran's little interface module which did actually simply open a window into FS's global data module. Of course, by FS2002 not much was actually global or easily accessible at all! All the added user facilities really arose through user requestsFSUIPC just hapened to be positioned in the right place to accomplish all these things efficiently. Okaythanks. The RESET option was really an option in any case -- I prefer views snapping forward when I release the change, but I can see how others wouldn't. However, I don't fully understand why, in that case, you need anything on the release. Won't the view stay put in any case? What does "PAN VIEW" actually do? Okay, good. Once I understand why you need the PAN VIEW with -1, could I publish this in my User Guide (credited to you of course, or do you prefer anonymity?)? Regards Pete

Why didn't you just repeat the question here? I would be a lot more efficient and help others stumbling on this thread. Seems I have to do it: Your problem was: and you were advised to use the "fix control acceleration" option in FSUIPC. Basically you are trying to use what must be an FS9 panel in FSX and it is one of those which rather unwisely sends frequent multiple controls, most of them of no consequence (being repeats), but having the side effect of causing incorrect acceleration of other controls. The reply you got saying it is a general problem which could affect default aircraft too is wrong. It doesn't affect any default aircraft because none of them use the methods these type of panels use. To illustrate how the problem arises try enabling event logging in FSUIPC (Logging tab) and, without touching anything, see what sort of streams of controls are being sent all the time. Show me a section if you like. When, long ago, I discussed the problem with Microsoft guys they explained that what they are doing is correct and it was up to the panel writers to follow the documented methods and not devise these rather OTT methods for controlling things. The fix in FSUIPC3 for the resulting symptom was intended as a temporary work-around, hoping panel writers would mend their ways. MS are certainly in no mind to change what FS does in this area. Unfortunately, that fix was based on a hack into FS9 which I cannot repeat easily on FSX as the actual compiled code of FS has changed dramatically and such things are becoming more and more difficult to find. Hopefully, for FSX, there would really be no need for it anyway as really the panel designers who did this sort of thing should be mending their ways and doing things correctly using all the new facilities at their disposal in FSX. Maybe, in the New Year (no time before Christmas I'm afraid) I may pluck up enough courage and have enough time to dive headlong into some of FSX's code to see if I can help. But on my few forays so far I don't hold out a lot of hope. As they use new highly optimising compilers and rewrite more and more in convoluted high level C++ it gets more and more difficult to work out what the hell is going on, no matter how hard you look. Added to that, I'm getting too old for the long long hours needed. Regards, Pete

Oh, if it support 115,200 then there's no worries over how much you send it! ;-) Great. Glad it is all working well! Regards Pete

Okay. FSUIPC4 is not being loaded at all, although it shows as being correctly installed, so something is wrong with the SimConnect installation. Please look at the "FSX Help ..." Announcement above and obtain a SimConnect Log for me to look at. It is looking like some sort of FSX repair may be needed. Regards Pete

No, not totally screwed. I'm amazed you can even run FSX plus a moving map program on such a configuration in the first place! my test PC is a 3.2GHz hyperthreading PC and it's unflyable with anything else running at all. I'd never dream of slowing things down with moving maps. You really do want to consider any old cheap PC for the mapping. If you like, but what was that about a Vista64 beast? Surely that's not also so underpowered? Regards Pete

Okaythere's no changes in FSUIPC4 specific to SP2/Acceleration in any case, only recognising the updated SimConnect so it gets used. This makes me think there is something related to either the multiple processor usage new to FSX+SP2 -- effectively squeezing the MixW program out of processor access more effectively -- or to do with all the graphics driver changes they made (to include some DX10 support), which may affect MixW by its extra IRQ usage. Do you have FSX frame rate limited at all? If not could you try limiting it way down, to possibly 10 fps (just as an experiment of course). If the problem alleviates or goes away I'm betting it's that the MixW is starved of sufficient processor time to properly present the consistent "fooling" needed to generate virtual ports. Maybe running it at a higher processor priority would help, or restricting FSX+SP2 to using one less of your cores (there's a mask parameter in the FSX.CFG for that). Yes, I gathered that. The symptoms in the FSUIPC dialogue are just another symptom of MixW not successfully maintaining the virtual ports. If MixW cannot be made to share the PC with FSX then I'm going to have to mention this in my Dox at some stage. There's no way I'm going to try to debug someone else's program. Regards Pete

There's further evidence of SimConnect problems on Vista64 here: http://forums.avsim.net/dcboard.php?az=ic_id=1118 so please do report these problems! Regards Pete

Which version of FSUIPC? Level D did have some problems with some things I did, but I think they've all been resolved now. Make sure you use the latest version (the Download announcements above often contain later versions). Check the LevelD support forum too. Regards Pete

This is because an axis value is ignored until it changes. To shut off reverse you need to send zero or a positive value to the thruster, but with no axis changes that cannot occur. You could try programming the reverse switch as a toggle. Is it a button or a toggle anyway? If it's a real toggle then program "press" as you have but "release" as THROTTLE_SET, leaving the parameter as zero. If it is a button you'd have to use its Flag to get it to send these two controls alternately -- that means editing the INI file. Flags are discussed in the FSUIPC Advanced Users guide. Let me know if you need any help. Regards Pete

Can you clarify this please? Are you saying you never used it with FSX before SP2, or that you had no problems before SP2? (Is SP2 out now, BTW, or do you mean Acceleration?). The dialogue lists the port you specify only if it can find it in Windows list of available assignable ports. Otherwise it lists those it does find. When it shows COM1, what else is in the drop-down? Could the virtual port driver for your device be, er, "fluctuating" in its mapping somehow? Maybe FSX is somehow interfering? Maybe the list is okay later, with FSX paused, but not with it running. I'm using GPSout continuously with FSX + Acceleration, with no problems. But I run the MixW virtual ports program on a separate PC, using WideFS for GPSout. I'd need to either be able to reproduce this problem, or possibly work out some method of diagnosing what is going on there (a lot more logging!). I'll see if I can set it up on the same PC as FSX. It may be a shortcoming of MixW needing something it can't get when FSX is running (IRQs perhaps?). If so then there's not going to be a lot I can do -- by not populating and selecting from the list in the dialogue until after some short delay I could problably make it look consistent (i.e. COM5 all the time), but if MixW is messing things up subsequently, as it seems, there's nothing I can do -- it isn't easy to complain to them as it is usupported freeware. I don't think it is GPSout "refusing to work" -- the code internally is identical in both cases. It seems more like an incompatibility between MixW and FSX. But is this only since SP2 or before as well? If you are thinking of using a separate PC then via WideFS there's no virtual ports uses on the FSX PC in any case, so I don't think the decision is dependent upon that. Anyway, I'll get to try it later in the week, maybe the weekend. Regards Pete

Isn't there a separate menu option for disabling crash detection with objects but still allowing "normal" user aircraft crashes? Surely that is the one you want to switch on, and you could leave it on all the time. Why switch it off in the air? Anyway, for FS2004 (not FSX) there is an FSUIPC offset which certainly reads the crash detection action. I don't know if writing to it does anything useful, but you could try it. Offset is 0830 (1 byte will do). It is 0=Ignore, 1=Reset, 2=Graph (?). You'd program your key or button to use the FSUIPC control "Offset Byte ToggleBits" with a parameter of 1. Try it. I don't hold out much hope that it will change anything though. Regards Pete

The Goflight rotaries are actually mentioned spcifically in the FSUIPC documentation 9user Guide, Buttons section), where it explains that each such switch provides 4 distinct "button" numbers in FSUIPC -- fast right, slow right, slow left, fast left. You can program these for incs and decs as you like. Each click is either a press or release -- they alternate -- so if you want every click to count you program both press and release for the same INC or DEC. GF rotaries will work fine. BARO is by Kohlsman Inc and Kohlsman Dec controls, Decision height is Decrease Decision Height and Increase Decision Height. Pete

Don't do that. The only time you need to "Run Asadministrator" is when registering FSUIPC in FSX. The installer does not need it, and FSX does not either. I'm afraid this must be some bug in FSX SimConnect under Vista 64 as I cannot see any other cause for the problems. Please submit all the details to tell_fs@microsoft.com. I suspect not very many folks are using 64-bit Vista (too many other problems with it I fear), and it may not have had all the testing it needed. Regards Pete

There is something external to FS interfering with its windowing facilities. Do you use "Window Blinds" or any other such window tailoring options? The only other thing I know of which can make the dialogues do such things occasionally is a rogue mouse driver, from Kensington I think. See if you can find it and uninstall it. your mouse should be fine with the normal Microsoft default mouse driver. Regards Pete

Sorry, I'm not much help there. I've never used those controls. However, one FSUIPC user did sort it all out and supplied all the details, which I included as an example in the FSUIPC User Guide -- look for the boxed section entitled Example of assignments for HAT programming for smooth panning. Regards Pete

Why "direct"? I would really not advise that unless you explicitly want to use the actual values, with no calibration, scaling and so on. That hardly ever applies -- it is intended for "soft" axes (ones controlled by software) such as those programmable with an EPIC card. I would very strongly advise disabling Direct mode on every axis. Please do that then re-check your items A - C. The oldest original list "FS2000Ctls" (for FS2000) had some help, but it became impossible to maintain. Check that if you like -- it is still available on http://www.schiratti.com/dowson. Otherwise mostly it is a matter of trial and error I'm afraid, but if you have any difficulty ask regarding particular controls and if i know I'll tell you. Or use FSUIPC's logging -- you can log all events from controls and from axes, then use the controls on the panels in FS and see what was sent -- control value and parameter are logged. Regards Pete