Pete Dowson

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

No. Did Elite? It seems to be their problem, don't you think? Pretty much all of those symptoms really cannot be anything whatsoever to do with FSUIPC. It seems that the Elite DLL is misbehaving rather badly. What do their support say? I really know nothing about what Elite have done. They have never contacted me for any assistance nor ever been interested in any way in obtaining a license for their use of FSUIPC. They are determined on "going it alone" and must therefore support their own devices themselves. I am sorry, but there is nothing I can do. Regards, Pete

Okay then. Sorry, I'm all out of ideas as far as my software is concerned. it is only reacting to what it is told by Windows. Something is not right, but it looks like it is between the Network driver/card/cable at each end. Possibly uninstalling the network hardware in both PCs and reinstalling (so it reinstalls drivers and restores itself) should be the first step. If it is hardware playing up it doesn't look like it, and unless you have alternative Network cards/connections it isn't so easy to check. Regards Pete

The "buffer problem" is not the problem, as I said -- that is merely the result of all those failing attempts to connect. The Windows sockets available are getting all used up. On my systems that would take 128 tries, on yours only 16. But it is a symptom not a cause. Your WideClient log is odd: The timing out of the response is occurring only 50 mSecs after the attempt to connect. Have you been changing parameters in the WideClient.INI file by any chance? Show me, or, probably best, delete the INI file and start again. Regards, Pete

No, only the 4 separate engine cowl flaps in floating point -- 37F0, 3730, 3670, 35B0, as documented (just do a search on "cowl"). The old 0-16384 axis offsets were for compatibility with FS98 practice, and that didn't provide cowl flap axes. Otherwise you'll need to use offset 3110 to send COWLFLAPn_SET controls with appropriate fixed-point parameters. Regards, Pete

Sorry, that makes no sense. There's no "type" called FS98CHILD. That's just a Class Name. HWNDs are always of type HWND. You only use the Class Name to register a new window or to find one of that class. For all other Window activities you use the handle (HWND is a Window Handle). Pete

That is a sure sign of a bad key. Where did you purchase your keys? I have no record of your current email address -- is the one you are using here different? The only explanation which fits everything you are seeing is that you have somehow acquired a bad (possibly illegally generated) Key, either for FSUIPC or for WideFS, or for both. If you would like to ZIP up your KEY file along with the receipts from SimMarket or wherever, or at least the name and email with which you registered, then I can try to resolve your problem. Make sure you ZIP things and send to petedowson@btconnect.com. Regards, Pete

What do the WideFS logs say? (There will be a WideClient.Log and a WideServer.Log). You say "will not work with my 3.5 reg", but there are no version-specific registrations. It actually sounds very much like you are using an invalid user Key for either or both of FSUIPC and WideFS. Delete your FSUIPC.KEY file and try again. If that makes everything work, you will need to send me all your details (not here -- I'll give you the email address then) so we can find out why your registration is wrong. Regards, Pete

SB3 needs TWO completely separate connections to FS. One is to FSUIPC (optionally via WideFS). The other is through FS's own Multiplayer interface. Check the latter. I know nothing about Multiplayer and it isn't anything to do with FSUIPC or WideFS. Regards, Pete

The reason may be on the Client side, or at least it may be logged there. There is no error logged by the Server. Look: I've never actually seen the "no buffer" message, but it will have occurred only because there are already the maximum number of connections (Sockets) allowed in your network settings. If you count them there are 16 before the 17th one fails. Probably 16 sockets is the maximum allowed by default on your Server. Although you can probably increase that, it isn't the problem. The problem appears to be that the Client is not actually seeing any notification that its connection has been accepted. So it tries again. It is doing two attempts every 60 seconds, if you notice. What was in the WideClient log? That may be more helpful. According to this log you never actually got properly connected at all, though you say This log shows no successful connection at all -- there was no transmission to be stopped! Regards, Pete

That's a bit odd. PM normally deals with the V/S in 100's. BTW rather than use /1 (divide by 1) just have no multiplication or division. i.e. remove your /1, it will only make it a little slower. Dividing by 1 doesn't actually accomplish anything. Anyway, checking back, according to the PM documentation offset X4E6 is used as follows: but this is a bit ambiguous. If correct it means that a V/S of, say, 6000 would be 60000 here. I read it the other way, that 6000 is here as 60. After all, a value of -6000 would otherwise give -60000, which is actually impossible in the two bytes alloted. I must admit I am very confused by this, as well as how you were (before) seeing the CORRECT value when you were adjusting it. Hmm. It shouldn't do either normally -- BC is a Back Course on the ILS, but this is something airliners (like those supported by PM) do not have! I canot recall what Button number the BC button sends to FSUIPC now, so I cannot check how it is programmed. Sorry. But it is rather unlikely that I assigned it to "V/S", as Level Change is more useful in most A/P modes. Doesn't the MCP have a V/S button in any case? [LATER] Reading a bit of my own documentation (for GFdisplay), I found this: So, unless there's a mistake in the FSUIPC.INI stuff the BC button should do neither of the actions you suggest. ;-) Regards, Pete

Ernow I'm confused. How did you program GFdisplay then? It is supplied as a basic kit with documentation and a few examples. The user (i.e. you in this case) is supposed to do what he likes with it. That's the whole point. Are you just using some examples I included and nothing else? no changes, no editing, nothing? I'm sorry, but I am having difficulty imagining that. It sounds like somehow you have FS's own VS indication (which is NOT divided by 100) mixed up with PM's VS system which does, I think, use the value divided by 100. If you can explain exactly what you have done I can try to investigate. I'm afraid I sold all my GoFlight gear this Summer past -- except for a couple of RP48 and P8 units -- and so have no display units left to test things on. (It isn't something I planned on developing any further -- there's been almost zero feedback in any case). Regards, Pete

Sounds like you have an error in the GFDisplay parameters. You can divide the value by 100 before display if needed. Did you look? Show me the relevant code if you are not sure. Regards, Pete

Okay. That is called a crash! In particular that would be "FS crashing to the desktop" or a CTD. This is an FS problem. If you are not using the 9.1 update, then get that and install it. It fixes at least 75% of all known crashes to desktop (CTDs). If you still get the CTDs, then it is likely you have a bad scenery file or scenery texture. These are the two most likely causes at any rate. There are others. None of this has anything to do with either FSUIPC, WideFS, or even Project Magenta. You need to do a process of elimination to find the cause. First examine everything you have added, especially scenery, textures, and similar. Regards, Pete

Looks like your joystick is faulty then. You'll need to get it fixed or replaced. Regards, Pete

Seems best to do away with the second PC then, and run SB3 on the same PC as FS? Otherwise you need a mixer to mix the two outputs, or wire one to the left and the other to the right earpiece? On the other hand, there's also a volume control for the sound card with the speakers, of course! ;-) Regards, Pete

Sorry, I still don't understand, what do you mean by "FS2002 is going out"? What do you actually SEE happen? These lines are not errors, the just log the aircraft name (from the Aircraft.CFG file) when you load an aircraft. What are "lost data area in FSUIPC .."? If by FS2002 "going out" you mean FS2002 is crashing, then naturally WideClient loses its connection with WideServer. wideServer runs in FS, so if FS crashes, it takes WideServer with it. I will try to help if I can, but I need you to explain what you actually see. "Going out" is what girls and boys do of an evening. I don't know what that means applied to FS2002. Sorry. Regards, Pete

No -- possibly the firmware is too early to support that connection, but that seems unlikely. I'm afraid the software can only deal with what it sees. Your course of action lies with PFC I'm afraid, not me. The switch you are talking about sends a 0 to 1 change or a 1 to 0 change. It is only a single switch, akin to a single button. What were you expecting? To program any switch in FSUIPC you simply need to IDENTIFY it by toggling in in whichever way FSUIPC will see it. In the programming page FSUIPC is only looking for an "off to on" transition -- otherwise it would get triggered on wrong events. You can still program it for both "press" and "release" transitions. Regards, Pete