Pete Dowson

Even if it didn't work, it is part of my job to make it work. That's what technical support is about. I don't think there's ever been anything which "hasn't worked" for long -- I fix things as fast as I can, usually within a day or so. Bug fixing is always top priority, as I loathe having any of the horrible little critters in my programs. Pete

So far all software developers have found that the free SDK and all the support they get is well worth the price of registering FSUIPC as a User. A program does not become a "freeware" application just because you write it for nothing. The point of providing free keys to freeware applications is so that your users, those to whom you are going to supply your wares, do not have to pay for FSUIPC -- after all, they may not need anything from me at all. However, if you are insistent, and do not come back for much support nor requests for additions to FSUIPC, then I could arrange a freeware application key for you. You would be the first such developer, so disappointing, and I would not like it to become a precedent. Please read the Access Registration document in the SDK. I'll need information -- send details it lists to me at petedowson@btconnect.com. Note that it may not work in debug mode (I know VB doesn't, but I don't know with Delphi). Regards, Pete

Sorry, I do not know this quadrant. What's "MEL"? How are its controls assigned in FS? If FS sees them in its assignments, then they can be seen in FSUIPC -- perhaps you are looking on the wrong pages in the FSUIPC Joysticks tab? How many separate engines does it handle? Elite has never once consulted me about their use of FSUIPC, and they've used it and the SDK for their commercial ventures without any agreement or thanks or payment, yet they continually blame it for all of their errors. I am therefore not really very favourably disposed to support their products at all. However, if you can investigate these assignments a bit more and tell me how things are connected to FS then maybe I can assist you. Regards, Pete

But didn't the wording "you can apply a fixed brake pressure here, or else use the byte at 0C01 to apply brakes emulating the keypress" suggest otherwise? It is explicit in saying that 0C01 (for example, here) is an alternative to this, after all. Regards, Pete

Well, the first looks to be simply that WideServer wasn't ready: As you see, the connection was okay after WideClient was running for 71 seconds. The error after 9 was probably simply because the Client couldn't connect to the Server whilst FS was still loading, or not even loaded. The other error: was obviously where FS had been closed down. The shutdown request has been seen, but the Client takes that as a request to close client applications, that's all. Regards, Pete

I think that may be a PM PFD problem. At least, there was something exactly like that happening to some folks with the CDU. Have you asked PM support? HmmmWhich ones do you think are "interesting"? Does the log end there, BTW? Regards, Pete

I don't know the latter two, but please update to the current FSUIPC (3.44). I really cannot support old versions. Sorry, I've no idea. All that FSUIPC does when you click on the FSUIPC entry in the Modules menu is open a dialogue -- a standard, run-of-the-mill dialogue window using standard windows tools. Maybe something you've installed has corrupted or changed part of Windows itself? The main library module used is COMCTL32.DLL. Regards, Pete

It is a function of FSUIPC. It emulates exactly the way those locations worked in FS98 (and, in fact, how the keypresses (F11, F12) work). The whole point of FSUIPC was originally to provide FS98 compatibility in FS2000. Those locations are still emulated for backward compatibility. Yes, of course. Just set the brakes directly. The brakes are operated at offsets 0BC4 and 0BC6. Regards, Pete

1. You are using an out of date version of FSUIPC. Please only ever use the latest. I cannot support old versions. Current is version 3.44. 2. Did you bother to look at the log? Somehow you have entered your user name and email address, but no valid user key. You are not user registered, therefore your program cannot gain access to FSUIPC for anything other than checking the version number. Here, look: and You are repeatedly reading these things approximately every 110 mSecs, which merely fills the log with these illegal access reports. You need to register your FSUIPC with a validly purchased user Key. You also should update to version 3.44. Regards, Pete

What does the FSUIPC Log file show (close FS first, then show me). Are you using a user-registered FSUIPC? If not, your program should be getting an unaccredited error. If so, maybe there's a problem with your user key. Have you tried using FSInterrogate and FSUIPC IPC logging as I suggested? Pete

I don't know Delphi, so I don't know how it evaluates something like height * 3.28084 / 256 but I'd use (height * 3.28084) / 256.0 in C, just to be sure. Does "round()" take a floating point number then? Again, in C IAS / 128 would give an integer, not floating point -- you'd need IAS/128.0 for that. Please try using FSInterrogate in parallel with your program, to see what it is getting -- it is very usefull as it shows the values in all sorts of formats (and, by coincidence, it is also written in Delphi). Your "0" for ground altitude may actually be correct for all I know. And use FSUIPC's IPC read logging so you can see what FSUIPC is actually supplying you. These debugging aids are there to help! Regards, Pete

Sorry, I don't do that. You might find it somewhere else on the Internet -- do a search -- but I don't want to hear about anything regarding older versions. If you have problems with the current version, please explain them here. Regards, Pete

Sorry, I think you are more likely to get answers to that over in the FS2004 Forum. This really is the wrong place. Regards, Pete

If it can only write one location, or is limited to 1, 2 and 4 byte values, then, it isn't actually your ability in question, is it? It's a limitation of the software driver you are using. It seems a very odd way to implement joystick axis control. Are there others using this method? It basically bypasses everything and acts like an external autothrottle control. I don't see how any aircraft implementation would work with that except using FS's own A/T. Or maybe you can program it to detect the A/T engagement and suppress inputs then? As far as special Airbus thrust values, I really don't know anything about those. You will certainly need to discuss that with Enrico. Regards, Pete

Of course. You always had that choice in any case. Regards, Pete

If it only writes to offsets, try writing the controls as I suggested. Pete

Quite honestly, I am totally lost :? , so I assume it must be 100% a PM issue of some sort. Are you writing a program to read your throttle levers and write the calibrated results direct to FSUIPC offsets? That direct method of throttle control would be one used by non-FS auto-throttle implementations as well, so it will get very tricky. Are you writing the auto-throttle code too? If, for some reason, you are just wanting to bypass normal joystick axis assignments and driver calibrations I think you still need to use the same controls -- either AXIS_THROTTLEn_SET with parameters -16383 to +16383, or the older FS98 compatible ones, THROTTLEn_SET. If you need to do this via offsets then do so via the two 32-bit values at offset 3110. Regards, Pete

You don't actually need static IP addresses to use WideFS. All you need is to tell WideClient (via the INI file) the name of the Server PC. You gave each of your PCs a name when you installed Windows -- the names are also shown in the Windows Explorer, and in WideServer's own LOG file after you've run FS with WideServer installed. By using a server name rather than an IP address you are leaving it up to Windows to translate it for you. That's fine for WideFS. The advantage of having static IP addresses is not really related at all to WideFS. It is to make FS itself, and some or all applications, run "smoother". With dynamic IP addresses, things take just a little longer whilst addresses are resolved. Additionally, the occasional enquiries, by Windows, sent to the "dynamic name server" (DNS) to convert IP addresses or vice versa, can cause noticeable stutters, especially in FS itself. These tend to manifest themselves as several stuffers over a period of perhaps a second or so, at regular intervals. This was actually a much bigger problem on Windows 98 than it is now on Windows XP, so it may not bother you at all. The complications which can arise with Internet access and fixed IP addresses are something to do with routers/modems and the way they are configured. I don't know how you access the Internet, but my ADSL modem needed some changes to operate in fixed IP address mode. I just followed all the instructions in its documentation. I can't say I understood them all, I'm afraid. Regards, Pete

But that isn't because of the fix in 6.441. The two client logs show everything good: PM: and MARCUS-OFFICE: So the only change which could have done this is your setting ApplicationDelay=6. Really, this is odd, as it should not be necessary to slow the programs down like this, at least not on Windows XP which is quite good at multi-tasking. It is as if you are using Win98 on that client. It may simply be this Application delay. It makes every access by each of the programs take AT LEAST 6 milliseconds. Maybe you can try reducing it. Experiment with it both lower and higher. The other thing you can try is increasing the new parameter "SendScanTime". This defaults to 10, limiting block send rates to 100 per second at most. You could try that a lot higher, say 50 (limiting to 20/sec). If that does no harm, leave it like that and reduce the ApplicationDelay again. Some balance of the two might help. Sorry, I cannot be more specific. The changes between 6.41 and 6.44 were tested over a reasonable period, including many interim test releases on the PM forum/Newsgroup, and things looked like they were just about optimum. There's something rather different happening somewhere on your system, but why and where I really have no idea. The "multiple connection" thing isn't important -- that is merely a result of something else. Always look at the logs and "feel" the performance. Summaries at the end like the two you have now are good -- a reasonable average frame rate and a low max Send Queue is what you want to see, and if you can smooth the stutters so much the better -- as I say, try adjustments in those two parameters, ApplicationDelay (as low as possible, preferably 0), and SendScanTime (10-100 is a reasonable maximum range to try within). Regards, Pete

This is why I suggested your user key may be invalid. It is the only reason I know of. Your program won't work on an unregistered FSUIPC at all in any case as it has no valid access key, but it (and many other client programs) will fall less predictably with a bad user key. I note you've not yet sent your KEY file to me for checking. Why not? ZIP the KEY file and send it to me at petedowson@btconnect.com. Regards, Pete

You are getting really bad blockages: Over 200 !!!! The fact that they take so long to start sounds rather like something has a memory leak somewhere, and clogging up things completely. You don't say yet whether you tried the ApplicationDelay=6, nor have I seend any logs from 6.41 for comparison -- possibly you were getting enormous Send Queues in 6.41 as well. This has probably only just come to your notrice effectively because, with the bug in WideClient, it was no longer recovering. Otherwise they'd eventually cause bad stuttering and maybe poor response. The bug was only that, once you get your huge send queue, it never recovers. The fix won't solve the problem which you have, which I would guess was also happening on 6.41. Something is certainly very wrong somewhere in your system. The log from your "MARCUS-OFFICE" PC was good and how it should be: Something is wrong on the other Client, for sure. But whether it is a program or hardware or driver I'm afraid I have no idea. That's where I would start a process of elimination. Regards, Pete

Hmmthat's a question for Enrico. Seems a bit strange not to be able to do that. Anyway, on your original problem, the one with the continuous "Send Queue over 100" failures, I found a bug in WideClient which, if such an error occurs once, it can then keep recurring forever -- the timing of the reconnection was interfering with the timing of the send queue being cleared (these things are tricky, being in different threads now). In other words, although you shouldn't have got a send queue as large as 100 in the first place, once you did get one so long, the bug in WideClient activated and made it much worse by not recovering. I attach a revised WideClient.exe (version 6.441) to be used instead of 6.44 -- the only change is this fix. I'll post this in the PM Newsgroup/Forum too. Regards, Pete WideClient6441.zip

Not if you only change the FS settings for the Slew mode axes. They are separate -- separate controls in fact. FS does not make a distinction between slew mode and flight mode, it simply only processes the flight mode controls. Regards, Pete

No, almost none of that at all! Where do you get any of that from? Just set the ClassInstance to 2, then find a way to get all your application programs which want to use FS on that PC to use classname "FS98MAIN02" instead of "FS98MAIN". The last part is the difficult part, as it may be a programming change. That is why I said you have to ask the program authors. If they don't change the program they will be trying to access the read FS, not WideClient! Pete

Where's the end of the log? It is important for you to close FS before getting the Log, please. Where did you get your FSUIPC user key from? It doesn't seem correct as far as I can tell. I can check it properly for you if you like -- ZIP it and send it to petedowson@btconnect.com. There is a FlyTHY Flight recorder program with an accredited Key, but it has the Product name "FlyTHY Flight Recorder v1.0", as requested in August 2003. The same Key cannot work with this changed. Regards, Pete