Pete Dowson

No, FSUIPC 3.xxx works on all versions of FS from FS98 onwards,, up to and including FS2004. It must be an old version of FDC, then, because some version of FDC has most certainly been accredited, and has a built in access key for FSUIPC 3. Maybe it was updated for FS2004? FSUIPC 3.44 works on FS98, FS2000, FS2002 and FS2004. It will also provide some features on CFS1 and CFS2, but not CFS3. Regards, Pete

If you calibrate the separate throttles in FSUIPC, the AXIS_THROTTLEn_SET controls are changed to THROTTLEn_SET controls so you can use the reverse range. The single AXIS_THROTTLE_SET control is left alone. Your 2 but only for individual throttles. FSUIPC does not support reverse on the single throttle -- you have to map it to the multiple ones. I think this dates from FS2000 where even the single THROTTLE_SET did not give reverse. The separate Reverser axis provided by FS operates using the THROTTLEn_SET controls too. BTW I'm not sure whether all those events will be trapped by the Panels trap facility, because on FS2002 and FS2004 I am calling the Event routine in SIM1 for some of these things. It depends where it is hooked. Regards, Pete

Thanks Rob! I didn't know all that stuff. Very useful. Nice to learn something every day! Regards, Pete

Yes, it was issued to the author on 9th August 2003, and as far as I know it was incorporated into the program for automatic access, and so needs no manual entry. It must have worked because that was almost 17 months and there's been no queries since then. Maybe you have an out of date version? Regards, Pete

Aha, that makes 3! I hope so. They've not arrived yet, and I have some chores to do, but I will check them later tonight. Thank you! [LATER] AhI see you attached them instead of emailing. Okay, they were short enough. Thanks. Pete

There's no known problems with 3.3 and FDC. The only problem I know of was with Windows 2000 only (not XP), and was certainly fixed in an FSUIPC version long ago. I suggest you contact FDC support. Regards, Pete

The formula I use in TrafficLook is very approximate, being normal plane trigonometry. That'd be reasonably close for near waypoints, but progressively worse as distance increases due to the curvature of the Earth. Also, I think my formula would be pretty bad anywhere near the poles (> 60 degrees N or S). // Everything in double floats, angles in degrees, result is True not Mag double Wrk = cos(PI * (fabs(MyLat+WayLat))/360.0)*(WayLon-MyLon); double Bearing = (MyLat == WayLat) ? 90.0 : (180.0 * atan(fabs(Wrk/(WayLat-MyLat))) / PI); if (MyLat >= WayLat) { if (MyLon >= WayLon) Bearing = 180.0 + Bearing; else Bearing = 180.0 - Bearing; } else if (MyLon > WayLon) Bearing = 360.0 - Bearing; If you want accurate bearings for longer distances or for anywhere in the world, you need spherical trig. Then I'm rather lost. You can find formulae on the 'net but you need to search. Regards, Pete

I don't know how you've got your clients set up to respond to Shut Down requests, but if they aren't so configured you can now make the logs include a performance summary by configuring a Hot Key in WideServer to send a shutdown request. Then only things configured to shut down will. But, honestly, I don't want logs unless there is something BETTER or WORSE, or anything suspicious. Else I'll be overwhelmed and not get anything done! :) Regards, Pete

Strange. No one has mentioned anything to me about any such reports. I have no idea what would prevent the electrics being operative in their cockpit -- I would expect them to know about that. If they thought it was FSUIPC you'd expect them to contact me about it. I have a contact inside PMDG and I am copying him both of your messages and asking what is meant. I see there is also this: I don't know Paul at all, but have you contacted him, as it evidently didn't fix your problem? Are you using the same PMDG aircraft on FS2002 and FS2004? I didn't think that was possible! Are you using FSUIPC 3.44 on both FS2002 and FS2004? I'm pretty sure that the FS2004 versions of the PMDG aircraft are a good deal more advanced than the FS2002 versions. Well, I haven't, sorry. But before you go back to PMDG, some clarifications. Are you running FSUIPC as a registered user? If so, see if the PMDG works when you remove your FSUIPC.KEY file from the Modules folder. If it does, then your FSUIPC access key is not correct. Zip up the KEY file and send it to me at petedowson@btconnect.com and I will check it thoroughly here. Regards, Pete

I'm just putting it all together now. Details will be in the announcement and in the ZIP read me. Hopefully, the details I need you to colllect will be in the log. If not, I have a really bad problem. The thing is, though, because I will be trapping the errors things may look okay. Or they may not. You will have to check the logs on the Clients at intervals, or when anything is supsicious. Regards, Pete

Yes, thank you! My deductions were correct in respect of the list of "routes" in IPXROUTES. I shall go ahead with the changes to WideServer so that they will be listed in cases like your Server too. Thanks again. I will be releasing an interim Beta (6.442), for both WideServer and WideClient, later today. I'll put them as an attachment to an Announcement, above, if you would like to try them. Full details will be included. Regards, Pete

It sounds like you need to go through the correct procedure to get things going. This isn't an FSUIPC matter. Check the overhead panel. You need at least the batteries on to start with. Also, in case you have the avionics switch in FS off by default, go to a default FS aircraft which shows an avionics switch, and make sure the avionics are on BEFORE loading the 737NG. It may be loading with FS is a situation where the PMDG doesn't have an operable switch. These are only suggestions. With a complex fuly simulated cockpit like the PMDG series you do really need to study the manual. Also try asking others. I believe there is a PMDG forum? Sorry I cannot be more specific. Whilst I do have the PMDG 737NG series, I don't actually use their panels, but Project Magenta instead. Believe me, with pmSystems providing the overhead, it can be just as complicated to get things going until you know what you are doing! :wink: Regards, Pete

Ah! Do you know, I've only just found that! :oops: I could have sworn the first one was the one I replied to first. Strange. :? Unfortunately the logs aren't helpful, except that I note that you are still using TCP/IP. I have switched over completely to IPX/SPX now, on an all WinXP setup. Have you tried IPX/SPX? I could't tell whether the crashed WideCliet had actually done much before crashing. It would have been more useful to see the WideServer LOG after FS had been closed, as the performance information is at the end. So it "crashed to desktop" with no message, nothing? Weird. I've not had anything like this before with WideClient, so it must be something in the very recent changes. I am putting together another interim test version (6.442, both Server and Client) which will log more performance data, and which also changes some of the defalut parameters again as a result of feedback. I am adding error trapping to WideClient so hopefully I will get a chance to see some details of this crash. This time, in case I forget anyone, I will be putting up the replacement modules as attachments to an Announcement here. It will be later today, so please look out for it. I'll include details of tests needed and results to be returned. Thanks, Pete

Okay. I'll look to see if I can change over the "fix control accelerations" option to work from that PANELS call instead then, though it won't be as easy as doing it from a Gauge. FSUIPC is running all the time, but the panels stuff normally has to be mde and unmade each time a Panel is loaded/unloaded. However, I'll delve into it and see where to place a more permanent hook. Thanks! Pete

Hmmm I wonder if they are calling the SIM1 event execution routine directly. I do the same for most of those things I want to be efficient -- the Panels "Trigger Key Event" system is rather inefficient really -- PANELS does decode them but in nearly all cases all does with them then, these days, is forward them on as WM_COMMAND messages to FS98MAIN, and the WM_COMMAND routine in the Window Procedure then calls a routine in SIM1 which decodes them all over again. In Fs98 the PANELS routine's tables did actually point directly to the GLOBALS values -- and writing those was effective, as SIM1.SIM (as it was) would be monitoring those values and acting on them. This is why FS6IPC was relatively simple compared to the agonies I have to go through in FSUIPC.. FS2000 was a mix of that and the SIM1 calls, but by FS2002 and FS2004 it had almost completely changed, yet the same table decoding is in place in PANELS.DLL. I suppose I should be grateful as it enabled me to deal with the things I needed to deal with in an evolutionary manner. Regards, Pete

"Stopped" as in "Hung"? Not crashed, no error messages, nothing? How did you terminate it, via the Task Manager (Ctrl-Alt-Del)? Sorry, I cannot find them anywhere. Do you mean in this thread somewhere? The only log extract so far was the WideServer one which I analysed for you. I'll probably send a revised WideFS build tomorrow (Thursday), with more logging, and maybe some error trapping. Regards Pete

Hanging? There's not been a single case of WideClient actually hanging in six years. How are you determining this? And then how do you remove it? Are all the applications running still responsive, just WideClient "hanging". Quite often an application can "hang" in such a way that it makes WideClient difficult to close -- you have to try to remove the hung applications. I don't really know what you mean by "gone from that system" -- if this means spontaneously closed, then there will most certainly be a Log file which should be checked to determinate the reason. In fact, even in the unlikely event it is hanging, there will still be a valid Log file which can be examined BEFORE you run it again. Are you using WinXP or Win98 or what on those Clients? Please describe more exactly what you mean!! You have me greatly concerned. As I say, what you appear to be describing has not happened at all before. And you have not provided any information whatsoever. Note that NO FIDDLING WITH ANY PARAMETER CHANGES will make things less or more likely to hang or spontaneously disappear! You are wasting your time and mine hoping for that. Information -- a better description for a start -- is absolutely needed. The Logs ARE important, ignoring them helps not one bit. :( :( :( :cry: :cry: :( :( :( Pete

Yes, I know. This sort of things has been going on with assorted panels for some time, and not only in FS2004. I think the 767PIC for FS2002 also had such problems occasionally, but it depended on the speed of your PC. The "fix control accelerations" option in FSUIPC clears down the internal FS acceleration timer when it sees a control arrive into FS which is different to the previous one. The acceleration should really only occur if there are successive controls for the same thing (as, for instance, incrementing the heading), but Microsoft didn't bother to check for this as, with their methods, such fast different controls arriving wasn't likely to ever occur. This 'fix' has worked in the past with all such panel problems, but possibly the XML access methods aren't going through the same route, so FSUIPC misses them? For instance, FSUIPC cannot see controls which result from keypresses, only from button presses and calls to the PANELS "trigger key event" routine. Both of those give rise to a WM_COMMAND message to FS's main Window, and FSUIPC intercepts these. Regards, Pete

There's nothing in FSUIPC which will have anything to do with either throttle cutting out, or distinguishing ground or airborne operations. You say "on any aircraft", but are any of those actually default FS aircraft? Have you tried default aircraft? Are you using multiple throttle inputs, or just a single throttle? If the latter it certainly sounds as if you have something added into your FS installation which is doing this, possible because it is trying to do something else like deploying spoilers or operating autobrake? I think you need to (a) check it with defaults, and (b) investigate what you have installed which may affect more than one aircraft -- e.g. another DLL in the FS Modules folder, other than FSUIPC of course. Regards, Pete

By restarting them without checking the Logs, we can never know what happened. I assume the application programs were restarted too? The fact that one was off for 9 minutes actually implies that something hung rather than any Network problem occurred. Regards, Pete

Did you try setting the SendScanTime to, say, 50, instead, as also suggested in another message? The way you say that, you had "one failures" which lost two clients, but you didn't -- one of the clients (PILOT) went off-line for over 9 minutes! The other was half-an-hour later and was the MCP off for less than two minutes. Unfortunately, when WideClient has a problem it logs it in the WideClient Log, so what you've shown tells me nothing other than that 6 clients connected okay, then: 4044328 Error 10054: client socket disconnected at Client: removing (skt=2560) 4044 seconds into the session (67 minutes) one disconnected, then: 4577422 Incoming connection Accepted ok (skt=2588) 4577453 Connected to computer "PILOT" (skt=2588) after another 533 seconds (nearly 9 minutes!!!) re-connected. Then: 5840859 Error 10054: client socket disconnected at Client: removing (skt=2552) 5916703 Incoming connection Accepted ok (skt=2580) 5916734 Connected to computer "MCP" (skt=2580)[/quote] The same with another client, in the 97th minute with it, too, reconnecting after some time -- only 76 seconds this time. What were the Clients doing in those 9 minutes (Pilot) and 67 seconds (MCP), respectively? Normally, if there's a disconnection, they will reconnect within the second. Haven't you looked at the Cliient logs at all? It seems rather odd to only show the Server end of things when whatever happened obviously happened on the Clients. It means "client socket disconnected at Client", as quoted more or less direct from Microsoft documentation. In other words, Windows has told WideServer that the Client disconnected. Regards, Pete

Hmmm. I use a router too, but it doesn't add that "Internal" entry in IPXROUTE's list. Strange. Something is obviously installed in that PC which isn't on any of the others I've met. Never mind. I am changing WideServer so that it will list the alternative ServerNodes in the Log. The correct one, normally, for IPX/SPX links from clients wil be the "LAN" connection one, generally with a Network Number of 0. I don't need to actually send you a test version because you've already run IPXRoute and shown the results. The only test which would be useful, please, is if you could put the ServerNode I decoded for you into your Client INI (just put a ';' in front of the current line so it is easy to re-instate afterwards). i.e. ServerNode=0.0.12288.31364.35279 If that works then I know I'll be listing the right ones when I do issue the next WideFS update. Thanks! Pete

It is nothing to do with FSUIPC -- unless you calibrate the spoiler in FSUIPC it doesn't even see it or know you are using it. This happens with most aircraft in FS2004 if you operate the spoilers on the ground. What happens is that the axis value passes through the "Arm" position, and FS incorrectly automatically deploys the ground spoilers (100%) when it sees them armed and the aircraft on the ground. It did happen occasionally, with some aircraft, in FS2002 as well, but it is much more frequent in FS2004. I think it is an FS bug. The answer is not to operate your spoilers until airborne. You wouldn't normally in any case, except on a Rejected Take Off (when it should be automatic on most modern aircraft, I think). Regards, Pete

That's always been a symptom of some complex panels, which send many many controls to FS all the time and cause the FS control acceleration to operate. FSUIPC cannot actually fix the panels, but enabling the "fix control acceleration" option in the Technical page has so far always managed to defeat the panel bug. Regards, Pete

I've just got around to looking at this, but I cannot make it go wrong. I'm sending an email so you can reply with any attachments which may be useful for me to see what the problem is that you see. Thanks, Pete