Pete Dowson

Oh, that. No idea really. It isn't anything to do with FSUIPC, it relates to how the problem of passing pointers to data in managed (i.e. interpreted) languages which MS seems keen on these days. was solved. Maybe someone who understands how the managed languages work can explain -- I never get that far away from the machine. Regards, Pete

Sounds like the axis is using a Log pot, not a Linear one. Regards, Pete

Because WX and FLT files are saved by FS, not by an external program. The problem with the external program arises because it gets notified of the second save and gets its name before managing to react fully to the first one. Really, if you are keen on saving files manually it may be better to simply uninstall AutoSave. Use one or the other, not both. Regards, Pete

Actually the current version, the one supported, is 3.60, though there's also now3 a 3.601 available above with a small fix. Not really. FSUIPC doesn't use any keypresses at all unless you program them, either in the Hot Key or Keys sections. Maybe something else is trapping that key? The sort of crash you are seeing is generally related to video drivers and their settings. If you are using full screen, try Windowed mode, or vice versa, to see if it make a difference. ALT + ENTER toggles these modes. You may also find that changing the "render to texture" FS hardware display option may help, or small adjustments to the anti-aliassing and other settings in your video driver. Finally, you don't say, but if you have not updated your FS installation to FS9.1 do that -- there were many crashes of this type in the early version. Regards, Pete

Take a look at the documentation you already have for FSUIPC. You don't pay for a particular 3.xxx version, but all 3.xxx versions. In fact you are expected to upgrade otherwise you don't get support -- as it says above, in the assorted announcments, I only support the latest versions. The same applies to unregistered users too, by the way. I don't expect anyone to stick with old versions. Regards, Pete

No, as it clearly tells you in the first few paragraphs of the WideFS documentation (see Important Notes). Exactly. Not only that, but it doesn't even use FSUIPC to interface to FS, so how would it use WideFS which is merely an extension of FSUIPC onto other PCs? Regards, Pete

Actually the latest build is 86, as I am using here. No idea, sorry. You'll need to ask someone who knows about these things. Try the Project Magenta support forum, pmSystems section. I think for use with PMsystems all your switches should operate pmSystems offsets, not FS directly. However, I really cannot support pmSystems. Whenever I have a problem like that I ask in the PM support area. There are some clever folks there who understand all that stuff. Regards, Pete

Well, round it up to a multiple of 16 at least ;-) When I said to be economical I didn't mean you had to be really stingy! ;-) Regards Pete

You are making an error with one or more parts of the entries then. Your name, email and Key must ALL be the same as originally notified to you for registration. If you still have difficulties email me all those details to petedowson@btconnect.com. However, all such problems in the past have been folks trying to use different details each time. The only exception was with FSUIPC versions earlier than 3.53 where registrations purchased in 2006 wouldn't work. Incidentally, the current supported version of FSUIPC is 3.60. I am on holiday from later today until May 14th so if you are not quick enough you'll need to resolve it with SimMarket. Regards, Pete

Did you look into the FSUIPC SDK? Check the table in the programmer's documentation. No. All that area is allocated and used by one application or another. Why use FSInterrogate for that when it is all documented? What you'll find that way depends on what applications you are using, and you cannot possibly use all that exist at the same time! ;-) If you want offsets not used by any other application you need to work out how much you need (please be economical -- do not, for instance, use a 32-bit DWORD as a single 'switch' when it can accommodate 32), then apply for an allocation. That is the only way I can ensure no clashes. Write to me at petedowson@btconnect.com. If your email doesn't arrive within the next 12 hours it will await my return from holiday on the 14th May. Regards, Pete

Didn't you check the FSUIPC user documentation. Here, I'll quote the relevant part from the table documenting all the axis calibrations: On a turbo the 8192 level is used by FS as the idle level, not 50% rich. If you are not using a turbo aircraft with separate cut-off and idle positions, simply calibrate the minimum at your detente, and make sure the two centre values are identical and approximate to the correct position on the lever. It sounds like you are calibrating for a turbo. Regards, Pete

No effect? Surely that cannot be? With maximum null zone in FS you normally loase the use of quite a bit of the axis movement. Maybe just not enough to reach halfway, though, which you may need? No idea, sorry. What "joystick programming software" do you mean? Yes, that arises through not having a large enough null zone for either. But, having got that far, I think you could now go to FSUIPC's calibration, calibrate left brakes with the "MIN" point set with the dial more than half way left, then the Right brakes with the "MIN" point set with the dial more than half way right, giving you a null zone in the middle. Experiment. Now you've nearly got there I'm sure it will be possible. Regards, Pete

Yes, of course. You must never have multiple copies of FSUIPC or any other module in FS -- if two identical modules are present, FS will load them both and they will compete/clash, both trying to do the same thing. Regards, Pete

The currently released version of AutoSave works fine with Radar Contact. Version 1.501 removes the oldest .WX, .FLT, .PSS, .FMC, .ABL and .RCD file in the saved flights folder each time it requests a new FLT to be saved. No, that cannot be happening -- AutoSave only ever deletes one file of each type every time it causes a new FLT to be saved, and the filename part is identical in each case. In addition, since it cannot possibly know what filename you are using in your ; request and it only ever deletes files by explicit full filename, what you are saying cannot happen. I think possibly you are misinterpreting the results of a clash where Radar Contact is told of the save for the ; command from you so close to being told of the AutoSaved save that, although it knows there have been two saves (because of FSUIPC's count of saved flights), it doesn't have time to retrieve the filename of the one before it is overwritten (in FSUIPC's readable memory) by the filename of the other. It would be pot luck whether this results in the user-saved or AutoSaved copy being lost. Yes, but since, in this case, the AutoSaved files are so close in time, there's no difference, so you haven't actually lost anything if you want to re-commence at that point. Just select the autosaved file. There's really nothing either AutoSave or RC can do about such a coincidence. The same could actually occur if you used ; twice quickly in succession, or even more slowly at a time when RC was very much tied up with its wave concatenation or has some other problem processing the data fast enough. Regards, Pete

What token variable where? Sorry, you need to be a little more specific. Regards Pete

Yes, the FSUIPC facilities are specifically for multiline messages. You can make yours appear to be multiline by including a line feed or return character in them, at the end for instance. LF = hex 0A (decimal 10), CR= hex 0D (decimal 13). Pete

Thanks. I don't know Thunderbird, but it appears to be the same for Firefox. I see that Enrico has put instructions for Internet Explorer on the download page now, in red! ;-) Regards Pete

Further to my previous replies on this, I've now done some additional investigations. This is the story regarding the AT Arm toggle, the A/T disconnect button, and the TO/GA button. When PFC first added the buttons on the outsides of the two 737 throttle levers they assigned them to "TO/GA", though this was of course incorrect -- the TO/GA buttons are mounted lower down, in a vertical position on the throttles. Because it was more important to have the A/T disconnect buttons correctly working, I programmed the TO/GA buttons on the 737 quadrant for the Jetliner to operate A/T disconnect. Then PFC developed a version for the 737NG cockpit. this featured both A/T disconnect and TO/GA buttons in their correct places on the quadrant. In the cockpit there is no A/T Arm toggle switch because, naturally, the arm switch on the MCP is used instead. On this version of the quadrant and its control board the A/T disconnect buttons do the same as yours -- 9C 00/01. When the 737NG cokcpit is selected as the CONSOLE in my driver, these codes are interpreted as A/T disconnect and work fine. The TO/GA buttons produce the codes expected of them, and they work fine too. So, it looks like your quadrant's A/T disconnect buttons are wired/connect as if they are the A/T disconnect buttons in a PFC 737NG cockpit. I'm not sure how to resolve this. I've written to PFC but haven't received a reply yet, and I am on holiday after tomorrow until May 14th. If you are using an MCP with an A/T Arm switch, and don't mind losing the use of the toggle for it on the Jetliner, then I could possibly put in an option to treat the Jetliner 737NG quadrant like the console version. I cannot treat the A/T toggle and the disconnect buttons differently at all because they send the same codes. Please see if you can arrive at a solution with PFC. If you still need this option in PFC.DLL when I return on May 14th, let me know. Regards, Pete

Thanks. Version 3.601 is now available in the Interim Versions announcement above. I won't make a full user release of it as there are bound to be a few more silly errors yet. Even though I make advanced releases here regularly in the hope that everything gets tested before full release, there are just too many possibilities and it is impossible to re-test everything each time. Good flying! Pete

Okay, found it. In fact it isn't hung, it is just trying to read millions of Payload centres. There are two errors here, one it mine and one it Etienne's, but mine is the worse. The gauge reads the count of payload stations, provided by FSUIPC at a particular offset. Unfortunately, in this version (and some time back over the last few weeks), that count has been corrupted and now reads rubbish. I will fix that immediately. Etienne's error is in using the count without imposing a maximum of 61 stations, which is all there is room for in FSUIPC. This limit is actually documented. Evidently he felt that there was no need to check this as it would presumably be unlikely that more stations would be present (though I suppose one could conceive of an airliner model with a separate payload for every seat). I will fix 3.60 and release it as 3.601 before I leave for my holidays. Regards, Pete

I'm not aware of that either, sorry. You need to talk to VoxATC. Sorry, that message is not from FSUIPC. You need VoxATC support. Regards, Pete

As far as I know I've done nothing which would change anything in any area that would affect such things, but the changes between 3.53 and 3.6 are extensive. The precursors to 3.6 have been on release here, in the Interim Versions announcement, bit by bit, over many separate 3.5xx releases since Christmas with no such problems reported. It has been because all of the last pre-releases, downloaded and tested by many hundreds of folks, have been so problem free that I have just at last released a new version. The next version I hope won't be needed for many more months. Please write to the author in the first instance in any case. If Mr. Martin cannot resolve his problem, then he can get in touch with me. It may be relying on some undocumented property which has now changed -- the only interface supported is the one that is documented. If it is a freeware gauge I could try it here for him (where do I get it?), but please note that I am on holiday from Tuesday until May 13th. Regards, Pete

You use Internet Explorer? Try "Refresh" (icon at the top, left of the little house. Firefox has a similar one. And what does it say on the web site? Ctrl+F5? Did you try it? I don't understand why some ISPs don't update their files either. I should complain to them if I were you. Mine seems okay, but I have no control over the Internet, sorry. Regards, Pete

Please write to the website owner. I don't have any control over what happens there. I'll write to Mr. Schiratti as well. I supply my modules to about 50 websites. The Schiratti site is the only one which puts them all in one place which is why I tend to refer folks to it, and it has been the same as it is now for about 7 years. The problem with file caching is actually specific to a few Internet Providers, not many, and even with those the files do seem to gradually trickle through. I think it is to do with date and time checks, which appear to be missing in some ISP implementations. Here I always see the files immediately Mr. Schiratti uploads them. Local caching in folks own PCs is easy to deal with. On FireFox there's a "refresh" facility which deals with it (a sort of blue re-cycling icon). Regards, Pete

No it doesn't! The modules folder is for FS modules. That's where most of FS's own modules go, plus many add-on modules such as my own FSUIPC, WideServer, AutoSave, PFC, Advdisplay, EpicInfo and GPSout. Please go and read that part again! ;-) Pete