Pete Dowson

The change between the previous version and this one is extremely minor -- it simply doesn't now bother to check whether a newly-loaded aircraft is different to the previous one, as it used to. Did you have such a problem with the previous one? Is this observable with default aircraft? Pete

In FS the "condition" levers are the same as the "mixture" levers. Just use FS's Options-Controls-Assignments to assign your lever to the mixture axis. However, if you are using FSUIPC's jet reverser to get reverse thrust on a jet, remember to check the option on that FSUIPC page to have it only operating for jets. By default the FSUIPC jet reverser uses the mixture axis. You'd have to use the same lever for both, and what it does would then depend on the aircraft you have loaded. Regards, Pete

Okay. Thanks. I just tried it and I can't make anything fail, no matter what I do! Can you give me precise instructions, please, on how to make it fail. I am using the latest FSUIPC (3.411), and FS9.1, and the default 737-400. Now what? Unless I can get it to fail here I can't see how I can do much. Incidentally, I noticed you listed three entries as "not working": //These are not working... 5 = VB31F4 = 4, 6, 0 //Pushback 6 = VB0BCC = 1, 2, 0 //spoiler armed 7 = VW0810 = 1, 2, 0 //Autothrottle disarmed I enabled those too. The offset 31F4 is for pushback CONTROL -- i.e. it is an input from an application to control pushback. the pushback state, which I presume you want, is 31F0. Whilst neither have been thoroghly tested in FS2004 (they were found in FS2002), I've just checked and certainly 31F0 seems to change correctly. The spoiler armed line works fine. i tested by asrming the spoiler (which you can only do in the air) with Shift+/. Why did you list it as not working? I'm not sure why checking for 0810 going to '1' is labelled "autothrottle disarmed" -- when it is 1 it is armed. However, that doesn't see to work here in any case. Not sure why. Anyway, unless I can find a way to re-create the crashes you are getting, I really don't know how to proceed. I've not got time this week to do much on it in any case, but with no crashes all I might be able to do is re-compile, and try adding some diagnostics, error traps and so on, and try to diagnose things remotely. Regards, Pete

Only one of those will be operative -- in fact 1->12, 2->3 is a subset of the other in any case. Ouchokay, I'll check it here. If I can reproduce it I will fix it ready for the next release. For the time being please just disable the filtering. Thanks, Pete

I don't know about the RFP747, but certainly it seems you can't use an analogue spoiler axis with the PMDG 737NG series. Apparently they messed that up and never resolved it. There's a thread here somewhere about that and I think it's been discussed over in PMDG's forum with no resolution promised. Test your FSUIPC settings in a default aircraft. If they work there, the results in other aircraft are subject to that aircraft's panel messing about with the axes. Be aware, however, that FS also has the habit of deplying full spoilers if you arm them on the ground. for a full test, check the operation in the air. Regards, Pete

Further news on this: With Katy Pluta's help, I found another, possibly easier, way to fix the wrong reporting of the ServerNode -- disable network authentication on the Server. I've documented it now in the revised Sticky thread near the top of the Forum. Regards, Pete

Really? That's astounding! Look, I've found no changes in FS9.1 that affect anything other than a few things in FSUIPC -- mainly to do with weather. However, if you can reliable produce crashes with Esound in 9.1 which don't occur in 9.0, then I want to see how. Do you think you can ZIP up your Esound CFG, plus the sounds you are using (if they are all in the sounds\esound folder, then just ZIP that up please), and send it to me at petedowson@btconnect.com? Once I can reproduce a problem fixing it becomes relatively easy. Better include both the Esound.CFG with Tokens as well as the one with only FSUIPC offsets, though it will be the latter I'll concentrate on for this. Don't worry about that for now. I should be able to deal with that. It's messy but doable. I might have to get you to do the testing though! Regards, Pete

I found out what is going on, but not why nor how to get around it by program. However, you can get around it by changing your IPX/SPX configuration slightly, in Windows. In fact it may work better if you do. Let me explain. If found a program, available in all WinXP installations, which gives you a list of IPC/SPX "addresses". It is IPXROUTE. If you open an MSDOS window (run, and enter COMMAND will get you one), then enter IPXROUTE config and press return, you will get something like this: NWLink IPX Routing and Source Routing Control Program v2.00 Num Name Network Node Frame ===============================================1. IpxLoopbackAdapter 1234cdef 000000000002 [802.2] 2. Local Area Connection 5 00000000 0040f453e76c [EthII] 3. NDISWANIPX 00000000 f03520524153 [EthII] - Legend ====== - down wan line What seems to be happening, on WinXP only I think, is that this "IpxLoopbackAdapter", whatever that is, is getting in the way. The numbers you saw reported for the ServerNode are those: 1234CDEF etc. The ones we need are those for the Local Area Connection, in this case the 2nd address. I think this "IpxLoopbackAdapter" has been added to WinXP since the original release. I also think it may be slowing things down a tad, which may explain why I measure only a little speed difference with IPX/SPX over TCP/IP. That's only theory -- I'l see if I can find time to do some tests in the week. Anyway, the problem only seems to arise with WideServer if you have the same frame type running on the Local connection as on this mysterious Loopback thingy. If you let the Frame type set "auto", it will choose 802.2 and that creates the problem. The solution appears to be to assign a different frame type. I've used Ethernet II and that seems to work very well. You'll need to do this on the Server PC and on all Clients. This is how: On WinXP: -- Network properties -- -- select NWLink IPX/SPX -- -- -- properties -- -- -- -- Frame Type: select "Ethernet II". On Win98SE: -- Control Panel -- network -- -- Select IPX/SPX -- -- -- properties -- -- -- -- Advanced -- -- -- -- -- Frame Type, select "EtherNet II". I'll post this as a Sticky, above, too. If I can find a programmatic solution to it I will implement one, else I will just put all this in the WideFS documentation too. Regards, Pete

No. you posted this twice in separate threads. If you are a legitimate registered user of FSUIPC it is most unlikely you have "similar" problems -- none of the folks with "similar" problems have sent me any files to check at all yet! Please go see my reply to your other thread. Regards, Pete

Only the current version (3.411) is supported and available. It is most unlikely that there's is any sort of new problem with FSUIPC and the A/P as nothing in that area is changed. Not only that, I am not aware of any helicopters which use FSUIPC. However, if you want help, please run FS and get the problem shown, then close down FS and ZIP up the FSUIPC.LOG and FSUIPC.KEY files from the FS modules folder, and send them to me at petedowson@btconnect.com. Regards, Pete

You seem to have missed my message almost entirely! Here it is again, with the one reference to SP2 (which was only an e.g.) removed: What have you changed? What does the WideServer Log show? What protocol are you specifying? what versions of WideServer and Wideclient are you using? The error is a bit of a strange one. The program is only repeating what Windows tells it. however, it seems likely that either there's some sort of firewall problem, or something is similarly getting in the way. Regards, Pete

No, the changes in PANELS.DLL are quite small and don't affect any of this. In any case the length of a triggered sound is actually nothing to do with either PANELS.DLL, or Esound for that matter. Once Esound has issued the command to DirectSound to play a sound it has nothing else to do with it. It can get a notification when it has finished, but it doesn't normally bother as there's no need. Why do you believe there's so much difference between FS9.0 and 9.1 as far as Esound is concerned? Have you tried all these things in FS9.0 and found that they work okay? That would be quite interesting to me, and not a little surprising! I really very much doubt that. The interaction with PANELS.DLL is exactly the same as any Gauge would use -- it's the same interface exactly. The only reason it crashes when aircraft are being loaded is that PANELS.DLL calls routines in SIM1.DLL which try to access data not yet initialised. I know all about that as FSUIPC has to take a lot of precautions. The only reason PANELS.DLL doesn't care about precautions is that it is normally only being used when Gauges are loaded and running -- and by then the aircraft is loaded and the data initialised. Your reports indicated you were getting crashes in NTDLL during normal operation. that is most certainly nothing to do with anything related to PANELS.DLL. Not only that, you said you got them using FSUIPC offsets only, which excludes PANELS.DLL altogether as FSUIPC doesn't use it. In fact the only thing in Esound which isn't also in FSUIPC or any other IPC interfacing program or module from me is the DirectSound interface. If you have proven that none of these problems occur at all in FS9.0 I will be amazed. Is that what you are truly saying? Regards, Pete

As the documentation explains, user registration of FSUIPC gives you access to all the other facilities in FSUIPC. It has nothing to do with helping anyone fly, whether on-line or not. Regards, Pete

What have you changed? What does the WideServer Log show? What protocol are you specifying? what versions of WideServer and Wideclient are you using? The error is a bit of a strange one. The program is only repeating what Windows tells it. however, it seems likely that either there's some sort of firewall problem (e.g. have you updated to WinXP SP2 recently?), or something is similarly getting in the way. Regards, Pete

Ah, thanks. That saves me installing it just to see. I too am absolutely positive that it was all okay in WinXP, at one time. It was a load of testing in XP that made me add TCP/IP! Something has gone wrong in XP since it's initial release. :-( I don't know how to work around this at present, other than manually finding the MAC address as described in the WideFS DOC (troubleshooting tip 7). BTW, if your Server is running Win98SE, no matter what the Clients are running, IPX/SPX works fine with no ServerNode needed whatsoever. Win98SE also gives the correct Node details, even though they aren't really needed! Daft. Regards, Pete

Well, yes, I evidently completely misunderstood you. If those reconnections are recurring every 20-25 seconds then something, some process somewhere, is somehow getting in the way. How or why it gets out of the way, I've no idea. Sorry. You misunderstand. It is not opening several connections. It opens one, gets no response, times out, assumed that connection is bad, closes it and opens another. The only reason the Server records more than one is that its timeout, before closing its end, is longer than the clients. If I had both timeouts the same things would go wrong. It is better that the Server is more tolerant than the Client. This business of apparent multiple connections is explained clearly in the WideFS document. No, there is no mechanism in WideClient for "realising FS has gone". In fact it should stay running during any number of FS close-reopens. It does here. In my case it saves me reloading everything when I'm running successive tests on a developing FSUIPC. The log clearly shows that WideClient did, in fact, receive the shutdown request and it is that which caused it to close. Why there's a delay I don't know -- usually it is the client applications taking their time closing that causes this. There is only ever one connection at a time as far as the client is concerned. Please peruse the WideFS document some time, it does explain the apparent multiple connections at the server. I also explained it above. No, there is no such mechanism. It will close one connection and open another if there's a timeout. The server is not informed of a client connection closing. There is no mechanism for that in the Winsock server-client protocols. The server just serves anything that comes. I keep records internally so I can recognise the same client if it comes back. If it doesn't I can only wait a long time then assume it died. It isn't "for some reason". It clearly states the reason. That's what the part saying "Timed out response" is for!!! Did you miss that? PFD.EXE does not talk to FS, it talks to WideClient. That part is always maintained. There would be a jerk/stutter in any dials or reading whilst the connection is re-made. As you can see from the times on the left of the log (they are in milliseconds), the disruption each time is only about a tenth of a second. Enough for a stutter, but nothing else. I explained the multiple connections reported by the Server, and it is also explained in the WideFS.doc, which I urge you to read sometime, please. No, there is only one connection at a time. The data is being exchanged, but for some reason it is very slow to start with. Why, I have no idea. Something is going on in that PC which is doing it. Regards, Pete

Ouch! I've tried going back even to 6.22. That does the same! In fact the same wrong ServerNode (the same one you get now) is provided on all my systems for all versions of WideServer I can find. I thought this might have been something trivial, but it isn't. I've compared the code which gets this data with some old archive code I have going back two years, and it is the identical! The only change on my systems is that my Windows XP systems are now SP1 whereas when I first did tests of IPX/SPX on WinXP (and found it was problematic) this was with the very first WinXP releases. This is going to need some research. I only knew one way of getting this information, and now, for reasons presumably best known to Microsoft, that doesn't work. Ugh ... [LATER] Yes, this is definitely a change in Windows XP -- I've just tried version 5.40 of WideServer in FS2002, and that gives the same identically bad node number. On the other hand, the very latest WideServer, running on Windows 98SE, is fine! I don't know if this is a bug in XP SP1 which is fixed in SP2 -- what operating system version are you using? Regards, Pete

Not related, no, but it is a silly WideServer bug. Thanks for spotting it! Pete

Nevertheless, the Log simply shows a total inability of this PC to be used for WideFS together with PFD. Something is wrong on that PC, but what it could be is going to be a problem isolating. That sort of sequence is normal once or twice whilst FS is loading on the Server. It just means WideServer isn't getting enough time to send responses to clients in a timely manner. Though why you have a series of 4 of these at 20/25 second intervals is indeed rather strange. Something is stopping the traffic for several seconds every 20/25 seconds. That doesn't sound very FS-like -- especially if the other Clients don't show a similar pattern. Check what other processes you have running on that client. After that, however, there are no reported errors for over two HOURS! Did you have a good flight for those two hours? What was happening? Or have you merely deleted a large part of the log because it was repetitive? Then the rest of the sequence looks like FS was closed so the service disappeared. Did it? 7491828 Error on client post-Connection Select() [Error=10053] Software caused connection abort 7491843 Ready to try connection again 7491843 Attempting to connect now 7493031 Error on client pre-Connection Select() [Error=10061] Connection refused 7493031 Ready to try connection again 7493078 Attempting to connect now These next errors are from the Client program (PFD), and show that it was in an odd state: 7515750 READSTATEDATA received with bad data size! 7515750 0 ReadLocal: Offset=8C000000, Size=0008 7521031 0 ReadLocal: Offset=8C000000, Size=0008 7523687 0 ReadLocal: Offset=8C000000, Size=0008 7526343 0 ReadLocal: Offset=8C000000, Size=0008 7531734 0 ReadLocal: Offset=8C000000, Size=0008 7534390 0 ReadLocal: Offset=8C000000, Size=0008 7537062 0 ReadLocal: Offset=8C000000, Size=0008 7539703 0 ReadLocal: Offset=8C000000, Size=0008 7542359 0 ReadLocal: Offset=8C000000, Size=0008 7547750 0 ReadLocal: Offset=8C000000, Size=0008 7550406 0 ReadLocal: Offset=8C000000, Size=0008 7553109 0 ReadLocal: Offset=8C000000, Size=0008 7555812 0 ReadLocal: Offset=8C000000, Size=0008 7561234 0 ReadLocal: Offset=8C000000, Size=0008 7566640 0 ReadLocal: Offset=8C000000, Size=0008 7569296 0 ReadLocal: Offset=8C000000, Size=0008 7572000 0 ReadLocal: Offset=8C000000, Size=0008 7574671 0 ReadLocal: Offset=8C000000, Size=0008 7577343 0 ReadLocal: Offset=8C000000, Size=0008 7580015 0 ReadLocal: Offset=8C000000, Size=0008 7582703 0 ReadLocal: Offset=8C000000, Size=0008 Finally, a shutdown actually gets seen? Not sure how that got through here: 7584578 Shutdown request received! and the performance figures actually show that almost nothing was ever received from the Server: 7585187 Reception maximum achieved: 0 frames/sec, 0 bytes/sec 7585187 Max receive buffer = 2710, Max send depth = 2 My first suspicions would actually fall upon the PFD program's use of OpenGL on that PC. See if you can run something else on WideFS on that PC instead, whether another non-OpenGL part of PM or some utility -- like my own TrafficLook and WeatherSet2 programs, for instance. If they run fine, with no problems, then you need to start looking at video drivers and checking out OpenGL and IRQ clashes in particular. PM support should be able to help with that. If you get problems with any and all WideFS client programs, then it is going to be a matter of elimination of each potential contributor, one at a time -- driver and Windows settings (compare with other PCs), Network card, cable, connection at hub/switch. Regards, Pete

Hmmm. I can't really see how any of that is really likely to be anything to do with Esoundit looks like you have other problems on your system to do with sounds. That is, unless Microsoft have made the DirectSound routines incompatible between DirectX 6 or 7 and whatever is current, which seems rather unlikely. The DirectSound routines in Esound haven't change in many years and always worked fine, and the access to FSUIPC variables is done in no different a way than any other FSUIPC user would use. NTDLL is simply a main support library in Windows. If I were you I'd check your sound drivers and DirectX installation. There's certainly nothing in any of that coding I'd want to go near in Esound, it was bad enough doing the research to make it work in the first place. DirectX is about the most unfriendly, complex and difficult API to work with that could be devised and I want nothing more to do with it ever again if I can possibly help it. Let me know if you decide not to bother with Esound any more and I won't do those other changes either. It will save wasting a day or two. On the other hand, maybe a simple re-compilation will actually help, though I really can't see why. The only other alternative I can think of is for me to produce a non-DirectSound version of Esound -- one with all the other facilities intact, but the sound playing reduced to a simply "PlayWave" call -- no speaker selection, no DirectX. Maybe no looping (I'm not sure whether the simple interface provides looping). However, this is quite a bit of work as it would involve wholesale changes. I'm not really inclined to do this. It would be a *lot* easier and quicker, I think, for pmSounds to be enhanced a little. Why don'y you put your needs together and ask Enrico? Regards, Pete

No. Any program can register a "hot key" with Windows. The hot key mechanism steals the keypress from all programs and passes it to the program who owns it, ignoring all things like keyboard focus and top windows. There's a similar facility in Windows to steal the mouse. Regards, Pete

I don't know where you are looking, but I don't provide any bank details whatsoever, anywhere, as I don't sell FSUIPC. You need to go to SimMarket. Check on http://www.simmarket.com. In the latest FSUIPC user guide I did update all those details so they should be in complete agreement with what is on the SimMarket web site -- but I do provide a link too, in the document, so you can be sure. Here it is (you must have missed the whole section on payment in the documentation?): http://secure.simmarket.com/paymentoptions.php I'm sure there's enough information there, including all the International Bank codes as well as the selling company's name and address. Regards, Pete

Since it is the client which is reconnecting, there will obviously be more useful information in the Client log file. There's none here. Perhaps I may be able to advise more if you showed me the relevant log? Also, try a process of elimination -- try the PFD on a different PC, to see if it's that PC or something to do with the PFD program. If the problem moves with the PFD then it is likely to be related to the OpenGL drivers. It may be related to them even if it doesn't move, supposing you have different video cards or drivers on each PC. Otherwise, it may be a bad network card, cable, port on a hub or switch, or something not set up right in Windows. It may be conflicting IRQscheck through the complete list of potential problems provided in the WideFS documentation. But the first step is to look at the apropriate Log to see what the errors are which are causing reconnections. Regards Pete

Ah, it's just that the source hasn't been updated for FS2004. You should be able to do that easily enough. As documented in the Programmer's Guide The prime reference for all information from FSUIPC, excepting the more complex weather interfaces). In fact it is from the offset 3308: Regards, Pete

Of course not! It doesn't "trap" anything! You evidently misunderstood me. All that happens is than when a program is in an amodal dialogue, all keyboard messages for that program are directed to the dialogue processing procedures, not to the main processing window code (which is where FSUIPC could see them). FSUIPC does not use any Windows specialised hot key facilities, those which Active Sky evidently uses, for instance, to grab keystrokes no matter what program has focus. If it did it could certainly process keypresses. I did explain this, but you must have missed it. I do not really think it appropriate for FSUIPC to act on anything which may be intended for programs outside FS. Regards, Pete