Pete Dowson

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

If SA_WXR is loaded by WideClient then it may be able to receive the keys direct, without gaining focus. It depends whether WideClient can get its actual running Window handle. You direct the KeySend to the "Run..." program in the INI parameter. You could try with PostKeys=Yes or No. One might work. The awkward programs are those which don't create the window which you need to send the keypresses too till later, using some othe introductory window first. even that should work IF the later, desired, Window is a child of the first. Regards, Pete

It occurs to me that, if you are running SA_WXR on a WideFS Client PC, why not simply use keystrokes? I assume SA_WXR accepts keyboard commands for its assorted options? If you have WideClient load SA_WXR then it is easy enough to program KeySends in the Client INI file to send it the requisite keystrokes, and the keysends can be assigned to your "button" signals in FSUIPC. Regards, Pete

Well, that' rather a shame. I can put on my list a facility for a seondary action (probably only programmable in the INI file) to take place n seconds after the switch was operated, but I'm afraid there's no way it will get done this year, and I'm on holiday in January. If you have no solution by February get back to me and ask again. Regards, Pete

Have you tried writing non-zero to the "Fail ADF" byte at FSUIPC offset 0B64? From a key press or button you'd simply use the Offset Byte Set control in the Keys or Buttons page. If that works and you want a toggle on one button or key you'd need to use Offset Byte Togglebits instead with a parameter of 1. Pete

That's not a message from FSUIPC, so I can't really say what its problem is -- FSUIPC does not need "initialising". It just runs when it is loaded as a Module by FS. You may need to contact SB support. If you want me to take a look, please try again, then close down FS altogether, find the FSUIPC.LOG file (it'll be in the FS Modules folder), and show me what it says. Keep the 'session' short and show the whole log. Regards, Pete

For programming, FSUIPC only sees a button or switch go from being "open" (not set, off, or zero) to being "closed" (set, on, or non-zero). In use, however, it can be programmed for an action when going from open to closed (off to on) and a different one, as you like, going from closed to open (on to off). FSUIPC terms the former "press" and the latter "release", as if it were just a button. The only difference between a latching (toggle) switch and a momentary (button) one is that with the former the two events, press and release, will usually be completely separate events, whilst with a momentary button the release will follow the press as soon as you take your finger off. That would indeed be a problem. Though you can make one switch event send more than one control (by editing the INI, a complete sequence could be sent on one press), the problem is that if the events merely change the same offset, as I think you need here, that is going to happen so fast that there is really no chance that SA_WXR will see the correct intervening values. You would need to either toggle or turn your switch again, or have a separate button to send the clearing value. Possibly some exchanges with the SA_WXR author, Florian, would be beneficial? His interface doesn't seem to be so well thought out for easy button or switch programming, being more oriented towards other applications I think. Possibly he could come up with some improvements? If he needs more FSUIPC offsets he only has to ask. Regards, Pete

Yes, a corruption in some settings, somewhere, I assume. It gets horribly complicated. I'm glad you solved it. If you effectively regenerated the registry then those FS add-ons which like to have their installation data in the registry may need re-installing, but this isn't usually necessary. For FS itself there are only a few entries needed in the Registry I think. One way to get them in is to rename your current FS folder (so it doesn't get messed up), install FS again, then delete the new installation (just delete its folder) and rename the original folder back. This is what I usually do. The settings for FS itself are in FS9.CFG, and shouldn't have been lost by only reinstalling Windows. Regards, Pete

Sorry, I don't understand what you are saying. The reason your are running out of buffers is because the maximum number of sockets are being opened. But none of those (or only one or maybe two in some of your logs) are ever actually connecting suffuciently well for any data transmission. Look: This shows a socket (2988) which is connected correctly and which had at least the initial exchanges successfully completed -- hence the Server knows the Client's name. But: Of all those connections the only one which got as far as one simply data exchange (for that is all it needs to identify the client PC's name) was the last, socket 3004. Then: None of these connections ever resulted in any data exchanges! The only reason you get the "no buffer" is because Windows Sockets has used them all up is supplying all those inactive (failing) sockets! And the repeated opening of new sockets is due, simply, to the Client's attempts at getting some response from the server. The Client log will show that (the timeouts). Unfortunately, if the Server doesn't get any data from the Client then the latter won't get stuff from the Server either. It's a two-way thing. It isn't possibly to say, from the logs, who is responsible. there are no actual errors being reported by windows in either case. It is merely doing nothing that is the problem. This woeful lack of data exchange is reflected in the summary at the end: I'm sorry, but I have never seen anything like any of this before, and WideFS has been going string now for 8 years or so (well before FSUIPC was even thought of, in fact). If I were faced with what you are seeing I'd be going through a provess of elimination to find where the problems were in my systems. I'd start by replacing (or finding alternatives for) each Network adapter/card, the cable, the hub or switch if you are using one. Then, after that I'd certainly consider reinstalling Windows in either or both PCs. You are using Windows XP I take it? Is it up to date? If not try updating to SR2 in both systems. I am afraid I am not a Windows or a Networking expert. All the Networking part of the code in WideFS is lifted straight out of Microsoft examples. Everything I've learned is in the WideFS DOC and much of what is in there has come from users. If you would like to go through all the Network settings on both PCs and write them down and show them, I'd be happy to compare them to some of mine, but I'm not sure where that would lead. We could try changing some, but there are thousands of WideFS users happy with default Windows settings, so I don't hold out a lot of hope (unless you've been changing things yourself?). As a final attempt to try to see what is going on you can enable more logging in both Client and Server. First please download the very latest interim test versions from the announcement above, near the top of the Forum. Install both the Client and the Server parts. This will ensure we are both working from the same page. Then, before running anything do this: in the Client INI change the Log= option to: Log=Debugall and in the Server INI change it to Log=Debug Then run the system FOR A SHORT TIME -- just long enough to see the problem. The Log files will get huge very very quickly. Be sure to ZIP them both up, and send them to me at petedowson@btconnect.com. Regards Pete