Pete Dowson

Are you testing it whilst on the ground? If so, don't -- try it in the air only. Most of the time in FS2002 and FS2004, arming spoilers on the ground will deploy them 100% in any case. You realise also that when spoilers are used as speed brakes, in the air, they don't deploy 100%? There's a maximum flight detente at about 70% on the 737, I believe. You can only actually get 100% after touchdown. I find it best to program an axis for spoiler control so you have fine use of them as speed brakes. Anyway, back to the PMDG aircraft. Are the keypresses you are using the standard FS ones, or does PMDG do its own? In other words, what are you actually programming? Regards, Pete

Actually, I have heard of "No", but I don't seem to be all that good at using it I'm afraid! :) Regards, Pete

No. What parts of it would you expect to interface to? It's really a program which interfaces to the Traffic DLL -- i.e. a front-end user interface. If I were to implement something it would be to the part of FS which does things, not really the part which display menus, tables and maps. Have you tried the facilities at offset 2900? Regards, Pete

You had problems before? What were they? Are there errors reported in the Log? Did you check to ensure that you have a properly updated FS9.1? So far I think all these problems are a result of an FS9.1 update which did not complete correctly. See the list of changed modules in my own FS9.1 update announcement at the top of this forum and check your installation please. The DLL causing most of the problems appears to be WEATHER.DLL. It seems there's a patched version of the 9.0 DLL going around. If this was installed before you applied the FS9.1 update, then the latter will not replace it with the new one, and the result will stop FSUIPC from working. If this is the case, and it sounds like it, then I am surprised FS itself doesn't give other problems. It will certainly cause problems for many add-ons in such a mixed up state. And it won't operate as Microsoft intended it to -- you will be missing many of the improvements. I am working on trying to make FSUIPC deal with any horrible mixture of FS9.0 and FS9.1 modules, but it isn't easy, and a horror to test. And it won't make your FS work as FS9.1 should be, it would just stop people writing to me about it! :wink: Regards, Pete

I'll have a look when I've finished testing what I've done to date. If it is easy I may slip it in on this next release, but otherwise it may slip. It will get done though. Regards, Pete

Yes, that's good. Furthermore, there is absolutely no sign of Squawkbox even attempting to access FSUIPC -- so it doesn't look like it is getting that far. I don't think this can be anything to do with either your FS9.1 or FSUIPC 3.40 upgrades. Something else is bad in the Squawkbox side separate entirely from this -- unless it attempts to connect to Multiplayer before FSUIPC and that is where it is reporting this "no response"? I call that "hanging" (or "freezing" for visual things like FS). But you did say it was reporting an error, didn't you? Here: ... or did I misunderstand that? Is that a message from Windows when you try to do something, rather than a message from Squawkbox complaining about FS or FSUIPC? Yes, good idea. I'm sorry I have no idea now. You could try a fresh install of SB in case the earlier fiasco with a partially-installed FS9.1 mucked up something vital in its data files. Regards, Pete

You can only use FSUIPC 3.40 or later (when a later one exists) with an updated FS 9.1. There should be no reason for Squawkbox "crashing" -- though from what you say it isn't crashing exactly, is it? Where's the log from FSUIPC for this, please? Are you sure you registered Squawkbox as an application, using its Freeware Key, or is your FSUIPC fully user-registered? I assume you have checked the FS DLLs against the list I mentioned? Regards, Pete

Well, so far I have added: Offset Byte Cyclic Inc Offset Byte Cyclic Dec Offset Word Cyclic Inc Offset Word Cyclic Dec These four operate on specific FSUIPC offsets and allow cyclic changes between zero and an upper value. They complement the existing Offset Inc/Dec facilities but deal with cases where you need to make a choice with only one button instead of two to search up and down. Then there's a set of controls to handle the current in-use COM1, COM2, NAV1 and NAV2 frequencies (separate inc/decs for whole and fractional parts). These are for single display type devices like the GoFlight GF45 and GF46 modules, ones with no way to show both standby and in-use values. Finally, for Button programming only (not Keys at present) I've added a conditional facility based on reading FSUIPC offset byte, word or double word values. The reasons for these choices will be clear when I release the GoFlight display handling program I've developed and am testing now. This complements the FSUIPC GoFlight button programming facilities. Regards, Pete

Thanks. I think those crashes may be due to a partially implemented expansion of the weather system. Ever since there have been clouds in FS only those four have been selectable. The other numbers were listed in some of the Microsoft SDKs with different, more complex, cloud types (like cirrostratus, stratocumulus, whatever) but only gave one of the basic types anyway when used. It looks like they changed that so that additional graphics could be selected but didn't follow through. Regards, Pete

Sorry, I don't understand this part. "Freedom" in the sense that it isn't imprisoned? Or freedom for people to use it and interface to it? Can you be a little more explicit, please? Well, it's merely one way of writing code to interface to FSUIPC. It's almost exactly the same as the way things were interfaced to FS5IPC and FS6IPC beforehand -- that was the whole point, compatibility -- so if Adam's publication of how to do it was "public domain" then I guess this is. It is an illustration, an example, as well as being a short cut for those who aren't interested in fiddling about with the interface workings. The other language variants were all derived from this, independently, by other people, not me. I provided them all as a service, with their permission. I've no idea whether they would regard their work as public domain or not. Sorry, I guess I'm not cut out to be a solicitor (lawyer). Regards, Pete

Can any reader here read this and translate it for me, please? It may be important, but I cannot tell. Regards, Pete

FSUIPC doesn't look at any location for built-in FS controls. All it does is send the control to FS, the rest is up to FS. There are many additional "pseudo-FS controls" added by FSUIPC (and more coming in the next version), but those certainly are not any of those. The same applies to NAV2 as well, by the way. Furthermore, the same happens when using the mouse on the radio stack -- try it! Interestingly enough, COM1 and COM2 are okay in this respect! It looks like a bug in FS specific to the NAV radios. Regards, Pete

As far as I can see, from all the references, this is using the USB connection as a standard serial port. If it looks like a serial port to GPSout, and the program you are sending it to can read that serial data, in NMEA format, yes, of course it will work. The problem I have with my iPaq on its USB cradle is that the USB link, although it certainly seems to be emulating a standard COM serial link, appears to be permanently "owned" by Microsoft ActiveSync at the PC end and some synchronising program in the iPaq end. I expect I could kill both processes and get access to the link as a normal COM port. But I've not really tried. To start with I have nothing for the iPaq which could make use of the data in any case. Quite honestly I prefer to use FliteMap and other programs on a proper PC with a nice large screen! :wink: I'm pretty certain there will be a USB driver there which is making the USB link operate as a COM link. I use this already with GPSout because I ran out of COM ports and had to use USB. I think that depends on the scenery you are using. The Latitude/Longitude system used in FS can measure down a lot more accurately than GPS in any case -- that's how scenery designers position things to the nearest fraction of a metre -- but if the resolution of the scenery is poor or someone's made a mistake and placed the lake in the wrong place, obviously they won't match. Microsoft make accurate detailed scenery for some areas, less detailed and possibly less accurate for others. Most of it will be derived automatically from satellite survey data and other databases which are available. There are many add-on scenery packages which are coming out with greater detail and, hopefully, more accuracy. They also often use satellite or aerial survey data to base their work on. In fact the UK VFR scenery is not only very accurate, it is made from real aerial photographs -- I can navigate over that using UK Ordnance Survey maps at 1:50000 scale with great accuracy as all that detail is present. It doesn't. There are add-ons (GPSout is one) which take data from FS's innards, process it into NMEA format, and chuck it out on a selected COM port. Regards, Pete

You have a corrupted installation of FS2004, one on which you have run the FS9.1 update but where that update has not succeeded. By the look of the error reported in FSUIPC's log, the CONTROLS.DLL, for instance, is the one from the original FS2004 release whereas the WEATHER.DLL is the one from the 9.1 update. If you look at the announcement I made in this forum about FS9.1, the one at the top of this forum, you will find a list of those DLLs changed by the 9.1 update. All those should bear a date in September 2004. Otherwise you have a partially installed FS9.1 update which is going to cause you problems. I have received a few reports like this, not actually the same as yours (usually the other way around -- an old WEATHER.DLL in an otherwise updated FS9.1), and it is really a bit of a pain, so I am currently testing a version of FSUIPC which tries to cope with any stange mixture of FS DLLs from FS9.0 and FS9.1. I will log two especially important ones (CONTROLS and WEATHER) so that folks can see for themselves whether their system is okay or in a bit of a mess. I hope to release this updated version of FSUIPC in a week or so. Meanwhile I can only suggest you check your FS2004 installation and try to correct the partial update situation. Regards, Pete

Has it been longer than 24 hours? As it clearly says on the purchase site, the Key will be emailed to you within 24 hours. If not, you need to go back and report a problem. I think there is a method of doing this called a "problem ticket" or something. I am not involved in this activity at all. This Forum is for technical support and announcements, but you should realise that human beings are involved in the sales process and they need to do other things occasionally like sleep and eat. Okay? :wink: Regards, Pete

Yes, with a registered version of FSUIPC and WideFS. This is how: In FSUIPC's Keys page, program each keypress you want to send as the "FS control" (actually one added by FSUIPC) in the drop down list called "KeySend". Allocate a different parameter to each one -- the values don't matter, just list them. First one parameter 1, second parameter 2, and so on. Then in the WideClient.INI file on the other PC (the Client PC), you specify what keypress each of these KeySend codes should produce. The parameters just say KeySend1= a keypress definition, KeySend2 =, and so on. Details are in the WideFS documentation for the latter. You can also get the keycodes for the keypresses you programmed in FSUIPC from the FSUIPC.INI file's [Keys] section. On their own these KeySendN= parameters merely send the key code to Windows using its "recorded playback" facility. Whatever program which has keyboard focus will see the keypresses. If your target program does not have focus then you would need to find a way to direct the keystrokes. WideClient offsers two ways -- one involves knowing the "Class" name of the window of the program to receive they keys. The easier way would be to get WideClient to load the program in the first place (using one of the Run or RunReady parameters). Then the SendKey parameters can be told which of those to send the keys to. There is one catch. If the program reads key presses directly, or via keyboard state details, rather than relying on the normal Windows KEYDOWN/KEYUP and CHAR messages, none of this will work. To get things to work for such program I think you would need a much lower level driver progam, sitting below the normal Windows API. Regards, Pete

I'm glad you sorted it out. That must be something to do with AS, as neither WideFS nor FSUIPC care about all that stuff. Maybe a note to the AS tech support so something can be added to their docs? Regards, Pete

That's a good advertisement for their products, I must say! :( Pete

I've not dared install SP2 on any of my PCs yet. I have heard of many folks having difficulties after that upgrade, and I have no time to spend the same number of days sorting them out as they did! I don't know the FMC, but the FreeFD stuff has always worked well on WideFs. No, nothing. I don't even understand those things let alone use any of them. My programs use the minimum number of Windows thingies as I can possibly get away with. There's no more used now in WinXP than there was when I first wrote it in Win95 days. Okay. Good luck. I'll be looking out to see if we can both learn anything. From what I've heard you have come off quite lightly if the only thing not working with SP2 is WideFs. I think you should also ask Katy Pluta over in the FS2004 Forum. She is a strong advocate of SP2 and also a WideFS user (with Project Magenta), and a bit of a Network Expert. Regards, Pete

As explained in the WideFS documentation, this indication can occur when clients time out the Server and re-connect. After a while without any queries from the now "unused" client connections, the Server will remove them and the number decreases. But the Server allows more time for the Client than vice versa. It sounds like no messages got out to one or more of your clients for quite a while. You say What does this mean? What did you kick? Are they going into some sort of sleep or suspended mode? You don't have some power management timeout operating on them, do you? Obviously if they stop receiving messages for any reason they whole thing will grind to a halt. Anyway, as with any sort of support request, if you want any help or advice I need version numbers and Log files. But first do please check these yourself, and especially make sure you are using the currently supported versions of WideServer, WideClient and FSUIPC, as listed near the top of this Forum. If you still need help, Zip up the files and write some description of your systems and the circumstances and send to me at petedowson@btconnect.com. Regards, Pete

Only SimMarket and Project Magenta then. Intercraft in Japan started after Christmas. I would have been the one if you claimed it in return for donations before July 2003 -- see the Announcement about lost keys above. Regards, Pete

Ah! So presumably this "Flight Gear" program is published under one of these, and the inquirer was wondering if linking it to FSUIPC would be against its license. Right? Looking at the link you quoted, I guess the question arises because of the business of "linking with non-free modules". That's an interesting one. Really, for freeware use in accessing FS internals, FSUIPC is a free module. There's a fee for commercial use only, but otherwise the interfacing aspects of FSUIPC are free. The user facilities should, in such cases, be regarded separately (indeed, I suppose they could, with some risk of inefficiency, be separated into a separate module, albeit with very close links to the other, and vice versa). Anyway, I hope the references to another successful implementation, that of PS1, was helpful to Pat. He's not been back yet to say. Regards, Pete

No, it means the MCP Kcodes as defined in the "FSUIPC Offsets" documentation from Project Magenta's website. I'd advise you to download that and use it for reference. I'm not surprised. According to the PM document: N11 K070 VOR1 Meaning, I think, that the K code "70" operates the VOR1 switch on the EFIS. I am not aware of such a problem, but you are correct. ALL of the PM controls offered in FSUIPC are PM-related -- FSUIPC merely operates the bits and values as documented in the PM FSUIPC offsets document. The rest is up to PM. Regards, Pete

This is usually a problem of some other (perhaps hidden) panel part being seen first by the DLL. In such cases the best way is to edit the [AdvDisplay] section in the relevant PANEL.CFG file for the Aircraft, specifying the window name it should be docked to -- usually "main panel" for the big 2D part -- please see the "Changes in version 2" section of the documentation, especially item 12. If this is also too difficult, perhaps because of some specialised panel design, the alternative is to "Lock" the display instead, and use the FSUIPC hot key to show and hide it. Of course that would need a registered copy of FSUIPC. Regards, Pete

I don't know "Download Accelerator", but perhaps it's not compatible with files on whatever website you got it from. You should check with the site. The file you should get it a ZIP file called FSUIPC.ZIP, and contains 13 items, only one of which is the FSUIPC.DLL. The 1.37 mb file is FSUIPC.ZIP. As I say, it contains 13 items including full documentation and some utility programs. Delete this non- FSUIPC.DLL from the FS Modules folder, as it is NOT FSUIPC.DLL. Please download only the ZIP file as listed on any website which carries it, then extract the DLL for installation. Regards, Pete