Pete Dowson

I don't see why -- by all means experiment, though. My main testbed (not my flying PC) here is a lowly Athlon 2000, much slower than yours, so if anything a too-fast polling rate should cause more damage. Not sure it is worth doing that, after all you said the problems occurred on both machines in any case, didn't you? Or not? Regards, Pete

Only if you convert them to COM ports (serial ports) by buying a pair of adapters. Pete

Ouch, that sounds like something is really wrong with the pedals, or their driver. All I can advise really to to go over to the CH Hangar: Report this there, see what they say. Bob "Sticky" Church, the world expert on joysticks and especially CH stuff cvisits there, so you'll be in good hands. Regards, Pete

No, they work fine together, or so I am told. FSUIPC doesn't really care at all about what happens to the values before they get through to FS's simulation engine. Remember, FSUIPC is not dealing with the joystick inputs themselves, it is dealing with the values FS is just about to use, just before it uses them. All that happens is that when value the IN value gets to the value shown in your "Max" box, FSUIPC makes the OUT value 16384. Similarly, it makes the OUT value equal to the minimum FS requires (e.g. -16383) when the IN value is less that or equal to the value shown in the "Min" or "Idle" box, whatever it may be labelled. For any values in between, it scales them to fit that complete range. That's it. Very simple really. Are you sure you have actually asked FSUIPC to calibrate (i.e. the left most button says "Reset" not "Set")? What are the values in each of the boxes? Maybe if you took a snapshot? You could also show me the Joystick calibration section of your FSUIPC.INI file. Regards, Pete

If you want to calibrate axes in FSUIPC you just need to follow the steps ennumerated in the documentation. The "IN" values are not important, it's the "OUT" values which are sent to Windows! In your examples, moving the levers so that the 7040 or the 15500 shows in the "IN" box, and pressing the "Set" button over the "Max" box will calibrate that end. I'd advise setting it a little lower so you can always achieve maximum even when there's some variation due to temperature and so on. Take care of the idle end too -- you need to allow space that end as well. Just follow the steps. You'll get there. The input values don't matter too much -- though for maximum sensitivity you need to make sure FS's sensitivity slider is set high too. Your readings of 7040 and 15500 are typical and fine -- in fact the 15500 is very good, most unusually high. The values from my Saitek wireless control device, which I use for testing, are almost all less than 7000 but it is easy to calibrate to full range in FSUIPC. Regards, Pete

Two things there: 1) I may not have tried for long enough then. 15-20 minutes is a long time for a developer writing and testing programs. It sounds like I would have to do a real flight too -- I was just checking things statically. Do I really have to have everything going? 2) The accesses Esound is making into FS are occurring all the time, so it can spot the changes. All that is happening differently when a sound is triggered is just that -- the call to DirectSound to make the sound occur. So it certainly sounds (excuse unintentional pun) like it's somehow related to the sound subsystem. Also, so I could definitely hear if your sounds were being triggered or not, I turned the FS sounds off (Q). Do you still get crashes with FS's sounds off? What version of DirectX are you using? I'm on DX 9.0c. But the PC I'm testing on (the only one with all my debugging aids installed) only has an on-board sound system, an Avance AC97 chipset I think. The drivers for that date back to March 2002. Regards, Pete

Hmmm. It did here -- but I admit I tried changing the Frame type first. When Katy suggested the Authentication, I put the frame type back to Auto and disabled Authentication, and it was okay. But maybe changing frame type altered something else more permanently. Hmmm. Yes, even though they say "auto detect", it doesn't appear to successfully do so. I have mentioned that. But I'll do some more tests with Authentication. Maybe I'll change the wording to "try this, but if not, then ...". You've lost me there. How do i see if I have one and then remove it? Isn't a bridge something that joins two Networks? Is the original slow/reconnecting start-up fixed too now? Regards, Pete

Hmmm. Are they all with complex add-on panels, do you know? You are the only one reporting this to me, that's all I have to go on. If others have anything to add they should really come here. I don't have time to scan other places. I'm not sure how the small changes I made (and they are indeed very small -- just one line commented out, to stop it comparing the name of the new aircraft loaded with that of the previous one) can really affect the normal use of the program, but I will try to reproduce it here. Regards Pete

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