Pete Dowson

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

Yes, it is. Mine is 04-15-2004. There's also a version number in the COMM window -- 32 here. Regards, Pete

No. You are reading a cached file! There are notes on the website as to what to do, please read them. This is reported on every new release. No one reads the notes? See "Important information and download troubleshooting FAQ at the bottom of the page." Pete

Okay. I've looked into this, and those codes are wrong, and completely explain the problem. On my Jetliner the codes the A/T disconnect produce are: Press: 9C 08 Release: 9C 00 Now, according to the PFC protocol documentation that code is supposed to be TO/GA, and I understand that's how the original throttles were labelled, but in fact they are now labelled (correctly) "A/T disconnect", and I've programmed the 9C 08 code as A/T disconnect. In test mode, try your A/T Arm toggle switch. doesn't that also give you 9C 00 when off, 9C 01 when on? It does here. The 9C 00/01 code IS the A/T arm switch as far as my driver knows. that's how it is documented. So it looks like your button is wired to disconnect the A/T when pressed and reconnect it when released, exactly as if you flicked the toggle off and on. The driver cannot distinguish between identical codes. Check the toggle switch. Maybe they've got the wiring mixed up? Either way you certainly have a need for hardware support from PFC. Sorry I can't help with that. Regards, Pete

Have you gone to the site where all my software is downloadable and looked for the Software Development Kit (SDK)? The SDK has all the information and examples. That is what it is for! Seems you've not looked far yet? Maybe FS's own multiplayer or WidevieW could do that. Neither FSUIPC nor WideFS can link two copies of FS together. Regards Pete

Why have you started another thread when replying to the same subject? Please keep to the threads, else things get fragmented and hard to follow. Of course. I have one PC client running Radar Contact, ActiveSky, pmSystems, pmSounds, FSRealTime, SA_WXR and AIsmooth. The only real limit is the speed of that PC -- at some stage it'll get bogged down. But there are few appplications as greedy as FS! ;-) Pete

The buttons on the outside of the two throttle levers? Press either or both of them, and the A/T disconnects. That's it. I have them on my Jetliner and in my 737NG cockpit. Really? It isn't programmed to do that. It sounds like you've re-programmed it (in FSUIPC?), though I've really no idea what function would do that, at least not consistently. What does the PFC driver say in its "Test" mode page when you press it? What aircraft are you using it with in FS? Maybe it is a function of some add-on aircraft? No. That isn't possible. In the real aricraft that arming switch would actually flick off when you pressed that button, but that needs a switch with an electromagnetic catch. It's one of the occasions (the A/P disconnect is the same) where some of your switches become out of sync. To re-engage A/T you'd need to toggle the A/T switch off and back on. If the A/T disconnect has been re-programmed to operate the "speed" button then that might explain what you are seeing, though that would depend on what A/T mode you are using at the time, and probably on what aircraft you are flying. There are several A/T modes - Speed, Level Change and VNAV. No toggling of any of them disengages the A/T, only disengaging the A/T does that. Regards, Pete