Pete Dowson

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

Not if they are all disabled, but in that case it is difficult to see why you are getting two different sets of throttle controls being sent to FS. And as I've said, FSUIPC itself never generates a value for an axis itself, not even 0. It waits for an axis value to change and sends that (IF the change is bigger than a set "delta" value). So something else is doing that it seems. Might there be any other add-ons or add-ins doing this? There is some extra logging you could do, just to get more information. With "Debug=Please" added to the [General] section you can also add "LogExtras=16" (replace any previous LogExtras line). This will log akk the events, axis or otherwise, sent by FSUIPC4 itself, whether via SimConnect or direct by Sending or Posting messages. Just run FSX till you know you have a spurious 0 axis value you don't think you should have, then close it. Don't bother to go into the FSUIPC4 options, please, as that would confuse the log somewhat. Regards Pete

It is fixed in version 3.822, available in the Other Downloads announcement now. Regards Pete

Okayit isn't actually a 'real' bug, at least not the "problem" I found. Do you have the Reverser calibrated in the Calibrations? If so, that is stealing the Mixture input to use as a Reverser. Try setting the option to only do this for jets, and then load a prop. Does the Mixture now work as advertised? This is a bit of a design oversight. Obviously if you are assigning Direct I shouldn't steal the axis for other things, and especially not if the reverser is assigned direct as well (as there is obviously no need to steal an axis then). I shall fix this, making both direct assignments truly work "directly". Sorry about the confusion. You sould be able to work around it for now, as I say, but it needs fixing -- both in FSUIPC3 and FSUIPC4. Look out for an update in the Announcements quite soon. Thanks for a useful report. Regards Pete

Well you ticked all the right boxes, so I'm at a loss -- if the routine reading the vales in the Axis Assignment sees them, then I really don't understand how they aren't seen in the Calibrations: the same routine is used. That's weird. FSUIPC doesn't store anything in the Registry. Everything is in the FSUIPC INI file. Okay. Meanwhile I will double check the Mixture axis here. I will be using version 3.821, the latest. Perhaps you could too, just in case it is different? You can download it from the "Other Downloads" announcement above. [LATER] Okay. I can reproduce it here with 3.821. Strange. I shall fix it straight away ... Regards Pete

Are the other axes okay? Does the axis show proper movement in the Axis Assignment section? Which of the 5 mixture controls did you assign and where are you looking in the Calibration section? Does the mixture control in the calibration section have a "Reset" button showing? If not, you haven't told it to calibrate. Press the left-most "Set" button. Is the word "Direct" shown in the calibration section? If not it is either the wrong one (not the one you asdsigned), or you haven't truly assigned it. Regards Pete

Do NOT tell SimConnect to use the ports WideFS wants tyo use, otherwise you are asking for WideFS to fail. Why on Earth would you deliberately choose the same port? :-( It isn't only the port in the SimConnect.xml file which may be fouling things up, but the one in the client's Simconnect.cfg file. I assume you've set that to 8002 as well? Whatever is going wrong with WideFS, it isn't going to be fixed by messing around with SimConnect files because it doesn't use SimConnect. If you aren't getting a WideFS connection the reasons should be shown in the WideFS files -- look in the WideServer and WideClient Log files! Pete

Yes, all that sounds quite reasonable, though it doesn't quite explain why Bill has differences between FS9 and FSX. Thanks, Pete

Aaarrrgghhh! Shows how tired I was then. It has been a pretty horrible week here, not much sleep, my ADSL going down for hours at a stretch (looks like BT have fixed it okay now). It should have been "Debug=Please". Sorry! :-( Which of the axes are actually troubling you? If it is only the Throttles, then it might be explained by double assignment - you are getting both AXIS_THROTTLEn_SET and THROTTLEn_SET controls going through to FS -- they won't be calibrated the same. Perhaps you need to show me your Axis and Joystick sections from the FSUIPC4.INI file, and also double check you have NO axis assignments in FSX if you are assigning in FSUIPC4. Regards Pete

No, not in the stickies, in the Announcements, as I said (remember I actually said "Your eyes don't go through the relevant Announcements it seems -- in this case FSX Downloads?". The Announcements contain lots of things to keep users informed and up to date, including ALL interim versions. Between every version you see in the official download site (the Schiratti one) there are often up to 10 interim updates and usually lots of other information. That's what I meant when I said you don't "keep an eye out". The Announcements are put at the top of the Forum, above everything else, for a purpose: so that they will usually be seen every time you visit. I make sure, with the two Downloads ones especially, that there's an update date in the title, but even if I didn't you should be able to see which ones have changed since your last visit by the highlighting of the entries icon. Regards Pete

In that case it does sound like the one value I let through from SimConnect before intercepting the axis, but that certainly doesn't apply to those assigned in FSUIPC4 and send direct to FSUIPC4 calibration. That is, it doesn't unless it is forced to intercept in any case, which is a non-standard INI-file only option. Regards Pete

Groan! :-( Just read them directly into your 96 slot array, defined as you had it. The 3840 bytes should match exactly the layout in YOUR program's memory and then you can access everything via slot number (index) and the name you gave it in your structure (data type). Please go back many messages and read them, read where all this was discussed and explained, and ignored it seems. :-( Sorry. I cannot take this any more. Please do as I suggested and ask for VB help in a fresh thread. I shall ignore it and let VB folks answer. One last point: Why is any crash "mysterious" when you have a development system which surely includes a debugger? Until your program works you should be compiling it in "debug" mode and either tracing things through, or at least allowing the debugger to give you all the information, and point to the EXACT place and cause of any crash. On this is this "Data" declared area big enough for 3840 bytes? Else it will certainly cause problems, probably crash. If data is declared as an array 0f 96 structures each 40 bytes long, it should work fine. Pete

Yes, of course. It is like memory -- every bytes, every word, everything has an address, and the offset value is simply the difference between the start address (base) and the data address. This is why it is called offset -- the amount the data address is offset from the start or base. Why not simply read the whole lot in one go, as I keep advising? It's one big array of 96 slots, taking 3840 bytes. I really think you are missing the entire point! Do NOT, repeat NOT, Open and Close the connection each time. Just Open at the start of your program and Close at the end. The interface depends on things called "memory-mapped files" and you'll be making a complete mess of memory and probably crashing through running out of real memory or handles if you keep opening and closing in a loop. Regards Pete

Sorry, what has FSUIPC got to do with it? You never mentioned FSUIPC, just a completely different product called "iFly 747", saying it was incompatible with FSX SP2. What do you think an "older" FSUIPC will do for you? Older versions are always worse than newer ones. Anyway, since you never mentioned FSUIPC before, let alone a version number, how am I to guess what you mean by "older"? If this IFly add-on actually uses FSUIPC and refuses to show panels if it isn't talking to it correctly, you need to check the FSX Add-Ons menu to make sure FSUIPC4 is actually installed and running, and that it says you are properly registered. Then check the FSX Modules folder to see if there's an FSUIPC4.LOG file, and if so look at it and see if that tells of a problem. Pete

Well, not in C, you can use the ASCII string directly in the Windows API calls. But in VB you most probably need to make a string from the BYTE array. As I explained before, I don't think VB uses ASCII strings like C/C++ (and Windows and FS) do. Sorry, I know nothing about ActiveX controls, I have no idea what you mean by the "code I have thought of", and I have too much to do as it is. Why don't you do it yourself? I thought you were (becoming?) a programmer. I really am not in the business of writing code for people. I have helped you as much as I can, especially considering I don't know VB. I don't know why you cannot understand much of what I've told you -- it seems you need to seek help from VB programmers as I suggested several messages ago. Maybe your foray into other forums will reap rewards. Regards Pete

What FSUIPC version are you using please? If this is 4.301 please add "Debug=Yes" to the FSUIPC4.INI file's [General] section, before loading FSX. Then they should work fine. Sorry about that -- it's a result of re-organising some of the analysis options to make room for a load more I have included for special purposes. I'll fix it so you don't need "Debug=Yes" in the next increment. Thanks, Pete

Those two lines show that your SimConnect installation is okay. You have SP1 installed, but not SP2 or Acceleration, correct? I would strongly advise you to download and install the SP2 update for FSX, as it fixes quite a lot of things and makes SimConnect work much more efficiently. The fact that the FSUIPC4 log is produced is good. It means SimConnect is properly loading FSUIPC4, but then it goes wrong:

I thought you said you were going to keep your eyes open? I released the update (4.301) with the relevant changes a week ago, on the 31st July! Your eyes don't go through the relevant Announcements it seems -- in this case FSX Downloads? Regards Pete

I never heard of "version mismatch code 0". My error messages are much more verbose, and they are all logged during installation. I need therefore to see the FSUIPC4 install log, which you'll find in the FSX Modules folder. If there's another FSUIPC4 log file, show me that too, but that sounds a little unlikely. Regards Pete

Without checking my code, I don't think that page says anything but a 0 till it gets a value, as it hasn't got one to show (it is a numeric field and cannot show a space). It won't get a value till the axis changes. All that really means is that you have nice non-jittery axes -- if they jittered at all you'd get a value there straight-away. What matters only is what happens in flight mode, the initial reading in the menus isn't really relevant. Regards Pete