Pete Dowson

Please update your two-year old (!!!) version of FSUIPC first. Then ask again. Regards, Pete

Where any of the PMDG indications are actually the FS indications, yes, you can make them work. But where PMDG have their own, separate, indications and displays, then, no, since we don't know where they are or how to read them they cannot be displayed externally. GFdisplay interfaces to FSUIPC, and FSUIPC is able to read just about everything (but not quite) in FS. But it cannot read proprietary values which are contained only in third party code, as is the case with most of the PMDG stuff. Until and unless PMDG release information on how to interface hardware to their panels then I don't se that anything can be done. And they've expressed no desire to do so, quite the reverse, except for specific drivers they may bring out for specific hardware (as, for example, is the case for the Engravity CDU I think). You need to hammer on PMDGs and GoFlight's doors to get them to agree. I'm afraid there's nothing I can do. I've tried my best to persuade PMDG to no avail. Regards, Pete

Okay. The log named "WideClientWithServerName.Log" shows: or, on the other hand, the other Log (just named "WideClient.Log") shows: So both methods work in the sense that the Server PC is identified correctly. So you can leave both the Server Name and IPAddr parameters out. However, please look at the IP address: 192.168.1.101 In your previous set of files you were actively setting the IP address as 192.168.0.101 If the so-called "subnet mask" is set to its usual default, 255.255.255.0, then the difference between that 1 and that 0 could be absolutely crucial! I think that BOTH PCs MUST BE ON THE SAME "SUBNET". In fact all PCs you want to work with each other should be on the same subnet. Check the IP address of the Client PC -- if that is not 192.168.1.??? (??? is anything), then you either need to change it, or change the Subnet Mask so that the 0 and 1 difference does not matter (e.g. change it to 0). I don't know how you managed to get the Network into this sort of mess. Are you setting IP addresses explicitly, or letting them be assigned by a Router or something? Maybe you are assigning one explicitly and the other automatically? You need to be consistent. This is really all in the realms of Networks which I know little about, by the way. It is nothing to do with programming. I had to figure out how to get my Networks configured by reading Windows Help and using trial and error. I know it isn't easy and I'm sorry if I'm not good at explaining things I know little about. But let me know if you cannot find where all this stuff is set or examined. I can help you there. Pete

So, even with the correct parameters (which you did not show me), it still does not see the Server? There is no error reported in the logs you sent, merely a timeout at both ends though lack of any connection. Can you show me files relating to your attempts with the correct parameters? Maybe there are then more clues? Yes, the problem in the files you sent were that the parameters were incorrect. You put the IP address in the Server name parameter. I suggested trying both using the ServerName ("DADS"), and even, if you have Windows XP installed in both, leaving both Server parameters out. Neither of these steps require you to be a computer programmer, surely? I don't know where you get that idea from. I did say that all these things are mentioned in the documentation. I assumed you had not bothered to look, otherwise you woyuld have surely realised that the word "ServerName" is not same as "ServerIPaddr"? The WideServer log even explicitly tells you the Server name (DADS) in case you don't know how to find it! Now that you have tried the suggestions I made, without success, perhaps you could show me the results so that we can move on? That is the weirdest response and attitude I have come across in a very long time! Where are you coming from on this? You say you have a problem, and send me files. I study them and make at least two suggestions as to why it may not be working and things you should try, and you react so crazily? If you don't want any more help, that's fine, but I don't understand why you should bring in all this irrelevant stuff about programming and "not being worthy" (?) as an excuse. I help as much as I can with the information I am given and at the same time try to encourage folks to find ways to help themselves. If you are doing the latter now, that's fine. If not, let me know.. Pete

What are you thinking of, putting this parameter in the WideClient INI file: ServerName=192.168.0.101 ? That isn't a name! It's an IP address. Please check the WideFS documentation. Although, somehow (I don't know how), Windows does seem to recognise something with that "name" as something with the same IP address, it is a very odd way to misuse the WideClient parameters. As far as I can see it probably isn't even the correct IP address. Why not use the actual Name to save having to worry about such obscure things? Your ServerName is apparently "DADS" (see the WideServer LOG). It's a whole lot easier. You seem to want to make it difficult? ;-) In any case, if you are using Windows XP on both PCs you don't need to give either the ServerName or ServerIPaddr. Clients will find the Server automatically. It's one of the new facilities since 6.50. Again please see the documentation. Pete

No. Purchasing a registration gives you access to the additional user facilities in FSUIPC. Without user registration FSUIPC is still the FS interface for applications it was always meant to be, like FS5IPC and FS6IPC before it (though greatly extended, of course, to match FS developments since FS98). If you read some of the Announcements above you will learn more, and even more again from the user documentation included in the FSUIPC ZIP file. Regards, Pete

The facilities in FSUIPC for programming buttons and switches have no knowlege or facilities for driving displays or indicators. No, but it may help you sort it out. There aren't any magic solutions until GoFlight and PMDG come up with some agreement to work together. Is the documentation too obscure? It uses the facilities provided in the GoFlight SDK to drive the displays according to parameters you provide. How much more do you need to know? If you want technicalities, first download the GoFlight SDK then ask specific questions, but preferably ask GoFlight support, eh? ;-) It is unlikely -- unless you can hack into PMDG code to find out where they store the information you need, and how to convert it. The do not publish anything useful. All jet aircraft have some way of switching the fuel flow to the engines on and off, for engine starting and cut-off. Obviouisly the PMDG ones do too. Do you assign the switches to whatever keyboard short-cuts PMDG assign for those? Sorry, but I really cannot undertake to support either GoFlight or PMDG products, and especially not both at the same time. You must ask your questions of the appropriate support. If they use the standard default FS methods, then they use the Mixture Full Lean for cutoff and Mixture Full Rich for start. I advise you to first try a default FS aircraft, for which these things are documented by Microsoft. When you can start and stop the default Jets, try the PMDG ones. From what you are saying you seem to be trying to run before you can walk? Regards, Pete

You are using version 3.48 of FSUIPC, which is old and which I cannot support. however, the log shows no attempt at an access by any recognised gauge at all, only some illegal access unidentified. If you want further help please first update to a supported release -- 3.50 or later. Version 3.51 will be released within two weeks and then 3.50 won't be supported. Regards, Pete

Okay. These parts: 85943 Module [M1] identified = "sbmpjoin9.dll" 85953 Module [M1] "sbmpjoin9.dll" access registration is okay 101776 Module [M2] identified = "sbmod9.dll" 101776 Module [M3] identified = "sbtrans9.dll" 101786 Module [M3] "sbtrans9.dll" access registration is okay 199076 *** FSUIPC log file being closed certainly indicate that 2 parts of SB3 connected okay -- SBMPJOIN9 and SBTRANS9.DLL. The part called SBMOD9.DLL hasn't realy done anything by the time you terminated 90 seconds later, so it was neither accepted nor rejected. There is certainly nothing wrong with the SB3 access to FSUIPC. I really don't know what they mean by the message you say they give. I can only suggest you ask SB3 support. BTW, is SB3 formally released now, or still in Beta testing phase? A lot of folks seems to be using it with no problems at all. Regards, Pete

Doesn't look to be anything wrong with that. Sorry, I'm out of ideas. Something in your system is moving the Window. How or why I can't say, sorry. Check what things you have added which deal with window positions. There really must be something doing it. Regards, Pete

Well, nothing should really need posting. As stated clearly in the documentation (and in one of the Announcements or "stickies" above), the registration is "for at least the life of FS2004 and any official updates provided I live that long". Since I also state, again in the announcements above, that I only support current or later versions (see the list of Supported versions), it is fairly explicit that the registrations cover all version 3 updates, and that, for support, you are really obliged to update, not discouraged. I would have problems trying to support old versions! If you follow the Installation procedure in the documentation (that is, copy in the new FSUIPC.DLL to your FS Modules folder), then nothing else changes -- your registration, your options and settings, all remain intact. If you delete all the FSUIPC.* files then you would need to re-register (using the exact same details as originally), and you would too if you reformatted your disk, or re-installed Windows, or moved to a different PC. But the registration details remain the same. You only pay once. Regards, Pete

Is it assigned in FS as the Mixture control? If so, have you, by any chance, elected to use it as a Reverser in FSUIPC (Joystics tab, page 7)? If so, just make sure you check the option on that page to only have it so diverted for Jets. That version is well out of date now, and not supported. Version 3.50 is current and is due to be replaced in early December by version 3.51. That sounds like another axis is operating on the mixture too, one which is stuck at one end (possibly because it isn't actually connected). If FS Options - Controls - Assignments, go the the axis section and check the device drop-down (I think it is top right) -- see if there are other devices listed. If so select them and check for additional assignments which may be duplicating the one's on your quadrant. If the mixture axis is not actively calibrated in FSUIPC (just click the "Reset" button in the relevant Page if it is visible), then FSUIPC will not be touching it at all. The only way it could be involved is if some other program or add-in were setting full rich via FSUIPC's interface into FS. This seems unlikely, but check with a default aircraft just in case. Regards, Pete

Just to amplify what Jim has said: They should (but may not, that is the problem) first check whether the version they wish to install is a later version than the one you have installed. Otherwise they should not install it. This is one of the conditions I request of products which do install FSUIPC. If you do find any that violate this, please report this to the originators as this is really a bug or omission. To safeguard yourself against such installs, always go to the FSUIPC options (ALT M F) after any new install and check the version. Currently anything before 3.50 is out of date and unsupported. Version 3.51 should be available early December. The latter does not count as an "installed" FSUIPC -- ASV will be putting it there for your convenience, in case you do have an earlier version. The current version of FS (FS2004, updated to 9.1) will only load add-in modules if they are placed in the FS Modules folder. There is some suspicion that earlier versions of FS may have loaded modules placed in the main FS folder too, but certainly never from anywhere else. The Windows file system ensures that you cannot have multiple copies of the same file in one folder, unless you have renamed any. The name has to be unique in the folder. So, good rules to follow are: * Never rename any modules in the FS Modules folder. If you want to keep different versions "just in case" make a new folder, for example "Saved", and put them in there. * Never install any add-in module into the FS main folder. Although this doesn't seem to matter with FS9.1 it may have had an adverse effect in earlier versions and, you never know, may do so again in future. Incidentally, for quite a long time now FSUIPC has had a built-in check against two or more versions of itself being loaded at the same time. If it detects another copy of itself running it will tell you so, when FS is loading, and will attempt to terminate one of them. Regards Pete

Okay, I found out what is wrong with your Reverser calibration. You have (possibly by mistake) set a "Slope" for that Axis. Unfortunately the slope mechanism cannot work for the below-centre parts of asymmetric axes, and in the case of reversers, in fact there's only the below-centre part, if you see what I mean! Even if you don't see what I mean, the remedy is easy. In the FSUIPC calibration page for the Reverser (page 7 for the single reverser), click on the "Slope" button and adjust the slope to be a straight line (it'll have the number '0' underneath the graph). The reverser calibration should then work fine. In the next version of FSUIPC (3.51, due out early December) I shall disable the Slope option for the reverser axes to make sure it cannot happen accidentally again. Thank you for discovering this oddity! Regards, Pete

WideClient itself NEVER decides its own 'restored' window position or size -- you have something else which is doing that. Some background program or windows organiser, or possibly a video driver "remember positions" facility that is going wrong. Something like that in any case. There is really nothing WideClient can do to stop other programs resizing or repositioning its Window without also stopping you doing so too. I'm not sure what you want the WideClient window to be visible for (is it for the ButtonScreen option?), as most would want it hidden. You could try using the "Visible=" parameter to force a specific size. You have the options of Visible=Min to initialise minimised Visible=Max to initialise maximised, i.e. the whole screen. Apart from that I can only suggest you look for whatever it is which is moving the (rather small?) window you have. As a possible "last resort" you could, I suppose, try making the INI file read-only, so that it loads okay next time, but this wouldn't prevent it being moved whilst running. Perhaps you can show me what the Window parameter looks like when you have WideClient as you want it? Regards, Pete

This could be due to: 1. FS is not running or GPSout is not installed OR 2. The incorrect COM port is specified in the GPSout.INI file OR 3. The incorrect speed is specified in the GPSout.INI file OR 4. The cable is incorrect OR 5. The receiving software has been given the incorrect COM port OR 6. The receiving software has been set to the wrong speed OR 7. the NMEA sentences specified for GPSout are not those required by the software which is supposed to receive them. All these or any combination of these are possible answers to your question. You need to deal with each one to determine what is wrong. To check the data on any COM port you can download the Freeware program "PortMon" from http://www.systeminternals.com. You can use that in the FS PC to see what is being sent where by GPSout, and on the other PC to see if anything is arriving. Regards, Pete

You cannot write an interface to FSUIPC in one line. Sorry. There are examples in the SDK. Please just say what it is you don't understand. Well, I'm sorry you feel that way. If you browse through this Forum then you will see that lots of folks ask questions and get helpful answers, but you do need to do a little work first so that you can actually ask decent questions. The answers to generalised questions such as you've come up with are bound to be to, first, look at what is provided, Try to work it out, and come back if you get stuck. That's all we've been saying. No one minds helping someone who is willing to help himself, but you must make some effort too. Regards, Pete

There's a working VB6 example and all the source in the SDK. What is the problem? I don't see how you could expect more without someone else writing your program for you? Folks don't mind answering specific questions if you run into specific difficulties, but you are unlikely to get the job done for you. Sorry. Regards, Pete

Not sure what being "quite blurr" means, but you will need to either Register FSUIPC as a user, or obtain an Access Key, to access data through the interface. Please read the Access Registration document which is part of the SDK. Pete

Taking the speedbrake first, do NOT test these on the ground. FS has a habit of deploying 100% if you are on the ground, and then you can't get them back down. Check them in the air. There should be no relationship between thrust and speedbrake -- or rather, there is none in either FSUIPC or FS. The logic in the LDS 767 may be doing something though. In the real aircraft, on the ground the speedbrake would normally come up full automatically two seconds after touchdown and only retract when you raised the thrust again to taxi off the runway. Maybe it is this latter action, trying to simulate the real thing, that is confusing you? This is really a question for LDS support, as it is totally independent of how you calibrate -- the speedbrake/spoiler axis can be calibrated in FS without FSUIPC, FSUIPC is only adding more precision. As for reversers, I assume you mean you have calibrated a spare axis/lever for a reverser in FSUIPC? You don't say. You also don't actually say what is wrong with the reverser? Hoever, the values you show for the reverser calibration don't look right. If those have come about through FSUIPC calibration there is something wrong. I'll investigate here and get back to you. Please tell me the Version number of the FSUIPC you are using -- that is always essential information! Regards, Pete

Not sure what "xtr yr BU fee" means, but if you have a key properly purchased from a legitimate seller such as SimMarket, then it should certainly work -- provided you are entering all three parts (name, email and key) correctly. Best to cut and paste from the Notification email. If you still can't work it out, email me a copy of the emailed notification, or at least all the details, to petedowson@btconnect.com, and I'll check it for you. Regards, Pete

Sounds more likely. Can you tell from the dates on them? Pete

Okaysounds like a good process. Let me know if you do find anything interesting. Regards, Pete

First I need to know that you are running the latest version of AutoSave, 1.50, as the very first one released for FS2004 would not delete files on foreign (non UK/US) versions of FS because they get saved into a differently named folder. I found out how to get the proper folder name later. Please note that each AutoSave set consists of a .WX and a .FLT file (from FS). If everything is working there should only be 10 of each of those -- unless you have been having lots of crashes of FS (or you switch off the PC with it still running). In this case the AutoSave CFG file doesn't get updated with the details of the next file to be deleted, so some get left each time. Are all of the files actually sets of .WX and .FLT files, or do you have lots of other types, e.g. .PSS, .FMC or others? If you have others then these are actually saved by other add-ons, like the PSS Concorde, the Wilco 767, and so on. The new Radar Contact (when released) will save .RCD files. The current version (1.50) of AutoSave does know about, and deal with, some of these -- the ones I know about -- but it may not deal with all, so please check the file types. You also say What does that actually mean, please? There cannot be more than one file with the same name, so what is this "same thing"? Do you mean same "filetype" (i.e. the part of the name after the last .)? If so, was it one of the FS types (.WX or .FLT) or one from an add-on? Regards, Pete

You cannot read any "address", hex or otherwise from that list. It is a list of controls. The names are the control names listed in FS's "CONTROLS.DLL" and the numbers are just the numeric representation of those controls, used internally by FS. I don't know this "IO master from Opencockpits.com", but it sounds like their documentation isn't telling you correctly what to look for. If they access FSUIPC offsets (not addresses -- the offsets are more like just token values), which are normally known by their hexadecimal representation, then these are listed in the Programmer's Guide for FSUIPC, which is part of the FSUIPC SDK. Well, you won't find Control Names listed in either FSinterrogate or the Programmer's Guide. FSUIPC's direct access bypasses the control system of FS and there is no special correspondence in any case. They are different things entirely. There are actually no offsets for any of the GPS switches. You can only operate them through the FS controls, which are easily programmable in FSUIPC's Keys or Buttons pages. If your hardware's driver can only operate via FSUIPC offsets then you would need to persuade FSUIPC to send the control for you, which you can do via offset 3110 -- please look it up. Regards, Pete