Pete Dowson

Possibly an easier way would be to take the ZFW (offset 3BFC) from the total weight (offset 1334), then also take off the payload weights (using the count at 13FC and the sequence following). All I know about that is what it says in the documentation -- "units unknown but dividing by 625 seems about right". Pete

Yes, add up the fuel in each tank and use the fuel weight conversion factor in offset 0AF4. There's a count of the tanks for each engine, but I think those are the ones switched through. I think you just add up all the fuel in al the tanks that have any. Regards Pete

Sorry, I don't understand you. Your original message merely indicated that you'd somehow got a copy of FSUIPC and wanted to install it into FSX. I pointed out that you cannot do that yourself, you need to use the Installer. Have you run the installer? If so you will now have a Modules folder in FSX and FSUIPC should be getting loaded when you run FSX. What "key" are you trying to "check" with SimMarket? Do you mean you can happily install FSUIPC4, and it is working okay, and you now want to purchase it? Regards Pete

Okay, I have reproduced this in the current interim update as well. So there is not need for you to send me any logging, after all, at least for this problem. But I believe it is only affecting the calibration screen, not the RAW axis scanning or its operation. So if you do have some other problem, like that elevator centering, you'd need to try using the logging to isolate that. It does sound more likely to be either an odd incorrect value coming from the EPIC, or, more likely perhaps, an alternative elevator assignment interfering with its values. I will work on fixing the way the RAW input are affecting the calibration IN values, though I must admit, as I said earlier, it was never really intended for RAW values to be "calibrated". In fact in may be an oversight arising from that fact.*** I would advise you to try using the normal inputs for analogue values (as opposed to software-generated specific values). *** LATER: For information, I've identified the cause of the wrong calibration "IN" values. It does only apply to the calibration, and to FSUIPC4 only. It is actually a function of FSX. In order to continue scanning FSX-assigned axes whilst in FSX's "dialog mode" (which has to be used for FSUIPC to present its options), FSUIPC has to make a call to FSX to make it happen (after all, for such axes FSUIPC is dependent upon FSX supplying the values, and this doesn't normally happen when it is "stopped", as in dialog mode). The call it does to achieve this is a facility of SimConnect. It seems that, even if no axes (no joysticks in fact) are enabled in FSX itself, this call does a scan of attached joysticks and puts the calibration mode back to normal, thereby disabling "raw" mode. In turn this creates entirely the wrong range of values in FSUIPC4. I've fixed it, ready for the next FSUIPC4 update, by restoring RAW mode on entry to and exit from the options dialogues. However, unless there are really good reasons for staying in "RAW" mode, I repeat my advice, to try always using the normal inputs for analogue values (as opposed to software-generated specific values). I'm sure it would be less problematic. Regards Pete

The latter is better. Both will work provided the numbers don't change before you next load FS. Sorry, I now see it isn't clear in my update notes. I will have to expand upon that when it gets into the documentation. Maybe I'll edit it now. The numerical "assignment" lines are provided to show you the current setup in Windows. That might change if you unplug things and move them around, and they disappear if you load FS with one of the entries unplugged. The letter assignments do not disappear, however, and you would simply get a warning appended at the end of the unplugged line saying there was no joystick. Next time you loaded FS with it plugged in, the numeric line would reappear and the warning cleared. This works even if the number is then different. No, you don't need to do that. It will be done for you automatically using the numeric assigns to translate. That's why you don't realy want to delete them. Regards Pete

It sounds like you are only looking at the drop-down list for "direct to FSUIPC calibration" assignments. "Pan view" is an FS control, and doesn't (can't be) calibrated in any case so it won't appear in that context. Regards Pete

In that case the "Mouse button up" controls I've added won't do any good. Sorry. Well it is always sensible to keep a backup of your INI file, but, no, FSUIPC won't change anything simply because you updated it, except possibly adding new parameters where stuff has been added. Yes, that's why I suggested calling the new file 2test" or something, so you could delete it afterwards. You should delete all the duplicates. You only want one of each -- and since "APU Norm" doesn't work you might as well delete all of that. Well, what would be simplest and quickest to load would be this, instead of all the above: 21=APU Start=RX70280*X8bcc 22=APU Norm=RX70280*X8bcc 23=APU Off=RX70310*X8bcc except, as i say, you might as well omit the non-working line 22. Don't you think it might be worth while getting in touch with the aircraft developers, to see if they have any suggestions for a solution to the APU Starter return when not using a mouse? You never know. Regards Pete

I've had just a brief glance at the code. I'm no VB programmer, but it looks to me as if you are using a different signature each time. Why? To FSUIPC this makes you look like a different program, and it will lock you out for the timeout (14 secs) on the previous request. The TXT file about the NWI does explain this -- you should use your own unique signature to prevent others messing you up, but the SAME ONE for each request, or Zero if you don't care about others getting their weather (as for instance my own WeatherSet using zero). You are also apparently checking the signature as your "handshake". Is that right? Why? Where do you get that from? As is clearly documented, the handshake back to you is a change of timestamp. You watch for that then check that the ICAO is the one you wanted. If not, it failed. Please do read what is written in more detail. I can answer questions if you like. It would certainly be a lot easier than posting code to be looked at. And please do use the FSUIPC logging, which would show all this stuff in no time. Pete

It certainly sounds like you have something wrong there. No, not at all. There have been several weather radars based on the interface. It have been around for quite a few years. I myself use SA-WXR in my cockpit for weather radar on my Project Magenta ND, and the same author sells a gauge using it. Maybe you have the handshaking wrong? Have you bothered t use the FSUIPC logging facilities, specifically provided to help you resolve this sort of thing? Not FSUIPC logs though. don't you like using FSUIPC facilities to help? I don't understand. I would have thought that would be your first port of call. Regards Pete

In FSUIPC4 (for FSX) you can assign it in the Axis assignments Tab to "Pan view". That should give you the same facility as the normal FSX assignment. Maybe not quite as smooth (FS doesn't have to use SimConnect), but pretty good. Sorry, but in FSUIPC3 (for FS2004) this method isn't available. Regards Pete

I've compared my code for Flaps in FSUIPC4 and FSUIPC3, and I can apply the changes I made in FSUIPC4 to FSUIPC3 too. Maybe these will be okay. I'll have to re-check on the defaults. I may have an update for you to try over the weekend. Regards Pete

You haven't run the Installer then. You cannot merely copy FSUIPC4.DLL into FSX and expect it to work! It is not like any previous FS version! Please download the full FSUIPC4 package from the Schiratti site and read the installation instructions. Regards Pete

Can you do the same things for me, then, as John did. i.e. on the Logging tab in FSUIPC, right-hand side: Monitor 0BDC as U16 for the flaps control, 0BE0 and 0BE4 for left and right flaps indicators, also U16. Set this to display in the FS (Advdisplay) window and in the Normal log you can see them in real time. Note down the values you get showing for each flap detente. It is very difficult to make sets of values to suit all add-ons. The formula I originally used was related to how FS itself interprets the values, and works for all defaults. However, those add-ons like PMDG, which implement their own flap operations, seem to have chosen different ranges. The only way I can make them work on all is to try to choose points which fall in the correct ranges in both, which is actually quite difficult in the the two outside detentes for PMDG. Regards Pete

Why use RAW? Really that facility, whilst intended for uses with EPIC, is actually suited to SOFTWARE axes, i.e. those axes controlled by the programming of the EPIC rather than merely the A to D converters for axes connected there. And then you wouldn't be sending the values "for calibration" as they would be for use as they are, real numbers for things like Headings, Altitudes, etc. By "same throttle position" do you mean exactly the same, or you mean roughly by feel or look? When you move the throttle, is the IN value moving in the high range, or is this 17800 value you see just the initial one, there when you open the Tab? That doesn't sound like the same thing at all - the neutral position would be a value which calibrates to zero, so not an extreme, larger, value but something near your 128 (for the 0-255 range). Sorry, I have no idea about that. Do you get no problem when you don't have it mapped to 4 throttles? My first inclination would be to change from RAW mode and use the normal input mode which is quite correct for analogue axes and suits them better. RAW mode is supported for passing usable numbers, not intended to be calibrated. However, I'd like to get to the bottom of this problem even if that would be the best thing (and quickest thing) to do. Obviously i need more information. Can you use the Logging facilities in FSUIPC, please? The Axis logging check box should be set. You will get HUGE logs, and I don't want to wade through them, so I'd need you to try to narrow them down to the area getting a problem. If you have to send me anything, ZIP it, please, and send to petedowson@btconnect.com. Oh, and please first update to the latest interim version, from the Updates announcement above, just in case something I've changed in the last two months affects it. Regards Pete

If it says it is an invalid registration then you are making a mistake! All three parts -- name, email address, and Key must be EXACTLY as you used when purchasing it and confirmed in your receipt. Use copy and paste if you can't enter correctly ort are not sure. If you had saved the FSUIPC4.KEY file, as advised in the documentation, then you'd only have to copy that back into the Modules folder after reinstalling FSX. You only have to re-enter the registration after a Windows re-install or changing PCs. Pete

Ugh. Most SimConnect problems appear to arise that way. I'm beginning to believe that folks might as well re-install Windows if they're going to reinstall FSx! :-( Well, that's good so far. MTX? What's that? I'd need to see both the Install and normal Log files, from the FSX Modules folder, to hazard a guess. Al the information will be there. Regards Pete

You need to use the runway centre Lat/Lon, its true heading, and its width and length to compute the Lat/Lon coordinates of the four corners, then see if the aircraft position lies within them. It is mostly simple arithmetic and a little simple trigonometry. Draw yourself a little diagram and you'll see how to work it out. Sorry, I really haven't got time to work it all out for you. If you are really stuck maybe someone will jump it, but otherwise, for general programming questions like this, you might get more detailed answers posting on one of the programming-oriented forums, maybe over at Avsim? Regards Pete

Version 3.75 is very old now (over 18 months, and almost as many versions), and is not supported. The earliest supported version is 3.85, and there are later updates supplied in this Forum, in the Announcements above. Please ensure you are using a supported version before asking for support. I really cannot deal with outdated versions. If you are not sure, please read the relevant Announcements in this Forum before posting. Regards Pete

These are the important lines: and as you can see, the mouse operation, whatever you did for "APU Norm", is exactly the same as the one for "APU Start". I was hoping that either there was some difference, or more likely a different Mouse mode shown (this would be indicated by ",n" with some number n, after the "RX ....X8bcc" part. So, I'm sorry, but I don't think I can do much for this. You haven't replied about the left mouse button being released elsewhere, so I either assume you tried it to no avail or you still don't understand what I'm getting at. But never mind. Just in case it might work (and it's a very slim chance), I have added "Mouse button 1 up" and "Mouse button 2 Up" controls which you can assign. These are in the latest FSUIPC updates available from the Updates Announcement above. Regards Pete

Such a "toggle" is in use in many hardware cockpits. The Autothrottle Arm control IS a toggling control. Use that to arm and dis-arm. Haven't you even tried it yet? If you are unsure about what controls do what, but know how to do it on the FS panel, just enable the Event logging in FSUIPC (logging tab), operate the control, and look in the FSUIPC Log file (in the modules folder). You will see the name and number of the control, and any parameter value it used. Pete

Not at present there isn't. I'll take a look. If it is easy enough to do, I'll add it as another [buttons] parameter. Pete

Ah. I hadn't spotted that one, or thought it not the relevant one. I'll see if that works. Okay, I think everything is now okay, 0898 and 08F0, if you could double check for me -- FSUIPC version 4.424, now available in the Updates announcement. Thanks, Pete

I am pretty sure the issue is fixed in FSUIPC 3.864 and FSUIPC 4.424, both now available in the Updates announcement above. Regards Pete

Yes, I'm okay, thanks, except for the eye problems getting worse month by month now, not even year by year. But that was more or less expected with this Retinitis Pigmentosa condition. Are you still flying all over the place, or have you settled into software/hardware development full time now? Regards Pete

Yes, all the default panel types have names. Here's an almost complete list: MAIN_PANEL 0 MAIN_PANEL_ALT1 1 MAIN_PANEL_ALT2 2 MAIN_PANEL_ALT3 3 MAIN_PANEL_ALT4 4 MAIN_PANEL_ALT5 5 MAIN_PANEL_ALT6 6 MAIN_PANEL_ALT7 7 MAIN_PANEL_ALT8 8 MAIN_PANEL_ALT9 9 THROTTLE_PANEL 10 RADIO_STACK_PANEL 50 COMPASS_PANEL 75 MINI_CONTROLS_PANEL 100 ANNUNCIATOR_PANEL 125 ANNUNCIATOR2_PANEL 150 IFR_MAIN_PANEL 175 COLLECTIVE_PANEL 200 GPS_PANEL 225 OVERHEAD_PANEL 250 PARKING_BRAKE_PANEL 251 FLAPS_TRIM_PANEL 252 FUEL_PANEL 253 ELECTRICAL_PANEL 254 TRIM_PANEL 255 LANDING_GEAR_PANEL 256 MISC_POPUP_1 260 MISC_POPUP_2 261 MISC_POPUP_3 262 MISC_POPUP_4 263 MISC_POPUP_5 264 MISC_POPUP_6 265 MISC_POPUP_7 266 MISC_POPUP_8 267 MISC_POPUP_9 268 MISC_POPUP_10 269 Alternatively, when the panels aren't selectable using the Shift 1-9 (PANEL_1 to 9) controls, there's usually an icon some place on screen to toggle them. If you enable "Event" logging in FSUIPC's options, then click the icon which operates the panel, you'll see the data logged. For the standard GPS_PANEL control it looks like this: 292078 *** EVENT: Cntrl= 66506 (0x000103ca), Param= 225 (0x000000e1) PANEL_ID_TOGGLE The parameter gives the ID, 225 in the case of GPS_PANEL, confirming the value for it in the list. Pete