Pete Dowson

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

Here's some of your confusion. Just because the FSUIPC offsets are documented and known in hexadecimal doesn't mean that they can only be addressed in hexadecimal. That's merely a convention. It's a number. You can express numbers in a lot of different ways. The offset &HF080 is the same as decimal 61568 or binary 1111000010000000 or octal 170200. Inside the computer they are all the same! You simply use the most convenient format in your program, the compiler converts it all to internal representation. This is all basic fundamental computer science, something which should be in the first chapter in any programming book, even one on VB. Why on Earth are you copying from one place to another? Why not simply USE the data where it is? I don't understand your obsession with making copies of everything. It is so wasteful, and anyway completely irrlevant to anything to do with the FSUIPC interface. Once you have the complete array of 96 slots in your program, do with it as you wish. That part is entirely your concern, that's YOUR program. I don't mind helping ith the FSUIPC interface, but everything else is yours. I thought you said you'd written programs already? Regards Pete

I think you must have posted in the wrong Forum? Pete

Good grief! Can't you read the whole set in one statement? Why not replace all that with If FSUIPC_Read(&HF080&, 3840, VarPtr(AI(0)), dwResult) Then If FSUIPC_Process(dwResult) Then I really cannot see how the compiler knows what the 3840 means, compared to the 40, and it is the FSUIPC interface code which is filling the bytes in, so why not read all 3840 in one statement? And why use strings for numbers anyway? What's wrong with CurrOffset = &HF080& + (i * 40) Something's getting very very muddled here. I've never known any programming language in which you have to give literal numbers in strings when you are operating on them arithmetically! Pete

In that case I'm afraid I've no idea where your "zero" readings are coming from. SimConnect and interception of axes doesn't come into it with that route, and as I say FSUIPC doesn't create its own values to send. Maybe you could enable Axis logging in FSUIPC (Logging page) so we can see what FSUIPC traps as being sent to FSX. I'm not sure how you are measuring this "zero" raw value in any case? Regards Pete

Well, I more or less gave you it. With TCAS_DATA tcasAirBorne[96]; declared, the Read call would simply be: FSUIPC_Read(0xF080, 3840, (BYTE *) &tcasAirBorne[0], &dwResult); or even just FSUIPC_Read(0xF080, 3840, (BYTE *) tcasAirBorne, &dwResult); because C/C++ uses the address of an array when its name is used, though I like to explicitly show I'm taking the address (&...) of the first element of the array ([0]) because i think it is less ambiguous when reading it. The (BYTE *) casting probably isn't needed either -- the prototype for the call specifies this parameter as a "void *" (pointer to a void), meaning what it points to doesn't have to be typed. However, again, I don't like the possible uncertainty, and when the call gets to where it is going it is being cast into a BYTE pointer in any case, so it can be copied across into the shared memory block. Pete

Most of the capitalised types are Windows API types, declared for C/C++ users in Windows.h or one of its subsidiary files. DWORD is simply an unsigned 32-bit integer, much as WORD is an unsigned 16-bit one and BYTE is an unsigned char, or 8-bit quantity. I use standard Windows types (as opposed to C/C++ types) a lot, because much of programming for Windows, and FS, uses API calls which declare them for their parameters, and it saves having to use casts all the time. I seem to remember from other VB users that "&HF080" is actually changed by VB's compiler into &HFFFFF080, which is no good. Even giving it as &H0000F080 seems to be no good. I think you have to use a postpended & to tell the stupid compiler not to mess about, thus: &HF080&. But please check this. I'm only vaguely remembering it. Really you need to talk to someone who knows a bit about VB. This isn't FSUIPC programming. Not sure why you have to copy data from one place to another. And I don't understand the syntax of these assignments at all. Why can't you simply use the data as it is, in the Array? Why so ccomplicated? Well, sorry, I can't help with that at all. All your troubles are now with understanding VB, more than FSUIPC. You need to read up some more, maybe, or hope for some VB guru to come along. Maybe you should now formulate all your VB questions and post in a new thread with "VB Help Please" some place in the title. We do get some helpful VB experts popping in here now and then, but they won't be enticed by the current thread's title. Regards Pete