Pete Dowson

:oops: indeed! Pete

The latest release of FSUIPC4 is 4.20, not 4.16. 4.16 is not supported. Please see the List of current supported versions in the Announcements above. PFC do not usually release up to date versions of PFCFSX.DLL -- try the version (4.30) from http://www.schiratti.com/dowson , where you can also find FSUIPC 4.20. By "taps" do you mean "throttles" or what? I'm not familiar with that term in aviation I'm afraid. If you do mean throttles, are you saying the throttles just don't wpork. Have you calibrated them in PFCFSX at all? What INI file are you talking about? If you've claibrated in PFCFSX and delete its INI you will lose all your calibrations. You should be able to simply copy over your PFC.INI file from FS9 if you used it there, and rename it to PFCFSX.INI. Oh. Hi! ;-) Regards Pete

SP1 is included in Acceleration in any case. And, yes, the version of SimConnect installed by Acceleration is better. It is much much more efficient (faster) and uses Named Pipes instead of TCP/IP, thus avoiding all the problems with firewalls and security programs. Pretty much all of the known SimConnect problems are actually fixed with Acceleration/SP2's version. Unfortunately it isn't SimConnect which is the problem. It's the horrendously complex installation / deinstallation process. SimConnect is only one component to suffer -- check all the other non-SimConnect related problems folks are having. I also think there are problems in the Windows Side-by-side library system. It seems to be very critical exactly how things are installed and de-installed, and interruptions, accidents, misreads, whatever, get it all corrupted. I've know several cases where a disk reformat and windows re-install was the quickest route to resolution! :-( Well, the Log from FSUIPC is incomplete. I've never seen one finish there unless FSX crashed immediately. And the Log from SimConnect couldn't possibly be the one related to the FSUIPC Log, as it ALWAYS shows the loading of DLLs, and most certainly FSUIPC was loaded else it cannot make a Log. They are both fragments, just the first few lines. But the SimConnect one crashes earlier or it isn't the right one, as it doesn't even show FSUIPC being loaded, as I said. That looks okay. The FSUIPC4 install log may have been useful. Remove FSUIPC4.DLL, run the 4.20 installer again, then copy in 4.205 to get back up to date. Please try again to get FSUIPC and SimConnect logs. I really cannot believe those are correct. I've never seen any such short fragments unless everything crashed. Regards Pete

There are multiple control facilities provided in FSUIPC. You can actually assign both in FSUIPC's axis assignments, but I would be concerned that they may interfere which one another unless they are very stable indeed. The specific facilities for multiple controls depend upon using FS axis controls, rather than "direct to FSUIPC" assignment, and assigning the 2nd set to a different otherwise unused set of FS controls. For instance the first would have Aileron and Elevator as normal, but the second might be Mixture 2 and Mixture 3. You have to look up the control numbers for those (in the Controls Lists I provide) and edit parameters in the FSUIPC INI file to tell FSUIPC that these controls are for the second set. Doing it this way solves the interference problems. FSUIPC takes the maximum deflection of the two controls and ignores the other. You want to try and achieve identical calibration in Windows Game Controllers first, as you can only calibrate one of the pair in FSUIPC. If they are wildly different there could be some odd problems. There are sections about all this in the documentation I provide. Regards Pete

Thanks! Pete

Find the Modules folder in FSX and delete FSUIPC4.DLL. If you only want to do this to stop it reading your joystick, it would make more sense just to delete the FSUIPC4.INI file, as I said. It contains whatever settings you made. without it, FSUIPC4 will generate a new default one, and by default it doesn't touch any joysticks at all. Both mixture and flaps are standard axes in FSUIPC4. You calibrate them in the Joystick Calibrations section. All the calibration stuff is described, with pictures, in the User Guide. There are no "fscontrol options" to worry about. You seem to be a little mixed up here and making it much more complicated than it is. Regards Pete

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