Pete Dowson

This version is really very old (getting on for two years!). I cannot support old versions. Please download the latest from http://www.schiratti.com/dowson. Current is 3.50, though later today version 3.51 should be available from the same place. You seem to have turned Weather logging on. Please don't unless there is some problem with weather that you are looking at. Unfortunately, the aircraft problem you have is not resolvable with any freeware (or payware) access key. This is the reason: 380922 Client Application: "fs2002" (Id=332) 380922 C:\Program Files\Microsoft Games\FS2002\fs2002.exe 380922 Product="Microsoft Flight Simulator 2002" 380922 Company="Microsoft Corporation" 380922 Illegal read attempt: offset 0B78, size 4 FSUIPC is indicating that the PROGRAM making the illegal call is FS itself. This means that the Gauge is using an external method to link to FSUIPC. This has NEVER been legal or correct, and such a gauge cannot be accredited. This has been the case since soon after FS2000 came out, so I suspect this aircraft, or at least some of the gauges in it, date from FS98 or early FS2000. You have two choices. Either pay for FSUIPC user registration, or do something with that aircraft (AIRCRAFT\L100-30B\c130.air). Either not use it, or find the culprit gauge and remove it. This is a helpful clue: If you look in the Aircraft's PANEL folder, you will find a Panel.CFG file. Load it into an editor, like Notepad. The parts you are selecting with Shift+1 to 4 will be indexed near the beginning. From there, looking through, you can find the part which Shift+4 should operate. It will have a number of Gauges listed for loading. One of those will be performing the illegal access to FSUIPC. That's because FSUIPC only shows the error message box the once, so you know it is rejecting all calls from the culprit gauge. The log may still fill with its illegal entry attempts, however, and whatever it is that it is trying to do will not be working. Judging from the locations it wants to access, the gauge is some sort of fuel monitor, possibly also a re-fueller/jettison control? This should make it easier for you to find and remove. If you do remove a gauge remember to renumber the entries for any following gauges -- they need to form a single sequence. And please update your FSUIPC.DLL before coming again. Okay? Regards, Pete

Offsets do not "correspond" to controls. Offsets are generally values, controls are, well, controls. You can send any controls through FSUIPC via offset 3110. There is a list of controls provided in the FSUIPC.ZIP file. Regards, Pete

Have you checked the obvious -- does the mixture lever actually work in FS? If not then it sounds simply as if you have the Sensitivity set to zero. Look in FS's Options-Controls-Sensitivities. FSUIPC will only see what FS sees. Pete

Can you be more specific? What is he reading for this, and how? Here I can set either Cloud or Wind turbulence in FS's weather dialogues and read it out through FSUIPC's interface. I can also set these values through WeatherSet2, though the Wind ones tend to be changed (mollified) by FS quite quickly after they are set, depending on the overall weather conditions around. The cloud turbulence 'sticks' better. Regards, Pete

Have you calibrated the Reverser axis in FSUIPC and forgotten to select the option to have it only operate for jets? By default the mixture axis is used for the reverser. Pete

Show me it then so I can interpret it for you. Normally it is pretty clear, but if not then I can help, given specifics. By the way, I too have never designed aircraft, panels, gauges or scenery, and I know very little about them. Your best recourse for any add-on aircraft which won't run is the author, as he is the only person who really knows what it does, what it consists of. All I can do is try to help you identify which part of which aircraft might be responsible, but even then some are written in ways that even that is impossible without trial-and-error, disabling each gauge in turn. Just show the log, we'll take it from there. You must surely know which aircraft is responsible, as the error will only occur when you try to load it. Regards Pete

What is AirnavFS live traffic? Is FSUIPC support needed for it at all? These are things you need to ask the author really. FSUIPC doesn't make any weather for you to turn off. It is only an interface for other programs. Please read the documentation I supply. Weather programs setting FS weather through FSUIPC will take care of themselves normally. Why not refer to their documentation? They should tell you what they do and how to use them. I've no idea, but it isn't very likely unless they need FSUIPC and don't have accredited access. Regards, Pete

Okay -- all's well that ends well! ;-) Pete

What were the precise controls you assigned? If they are definitely what you say, then they will be operating the fuel cut/idle levers just rear of the thrust levers. Where are you looking? No. Does Ctl+Shft+F1 cut the fuel and Ctl+Shft+F switch it on, in your Jets? These are the default assignments in FS (and have been for many many years). They operate the controls called MIXTURE LEAN and MIXTURE RICH, respectively. They are for all engines. There are also separate ones for each engine, named MIXTUREn LEAN etc, where n is the Engine number 1-4. Regards, Pete

One or both includes a Gauge which accesses FSUIPC, and it has not got an access key. Your FSUIPC is not user-registered so you don't get automatic access for every program. Please read the earlier parts of the FSUIPC documentation for details of registrations and access. Really stuck? Did you not even bother to follow the suggestion in the error message and look at the FSUIPC Log file for details? It will often be possible to identify the culprit gauge from that. Then you might be able to find the proper key, if it has one, or be able to eliminate that gauge if not. Pete

The FSUIPC you supplied in your ZIP is certainly version 3.50, but the version you have installed in FS is most certainly 3.40! You either have two FS installations and you are looking in the wrong one, or you are not following the very clear installation instructions for FS modules and placing them in the FS Modules folder! Well, you must look to find what is blocking WideClient access to your server then. If there is no WideServer LOG file in the FS modules folder, then you have NOT installed WideServer -- that would certainly prevent WideClient connecting! PLEASE PLEASE READ the installation instructions for my programs. They are very short. They predominantly consist of "copy the DLL into the FS Modules folder". You have evidently not done this simple one-step procedure! Regards, Pete

If it says it is 3.40 it is 3.40. Please update to 3.50 (or wait till tomorrow (Friday) when 3.51 will be released). I cannot support version 3.40. You must update! I would also need to see the WideServer Log, but at first glance "connection refused" is most likely to be due to a firewall. Pete

WidevieW should be doing that itself, surely? I think you need to talk to WidevieW support. I'm afraid that, though I used to be a WidevieW user back in FS98/2000 days, I have not been now for a long time, not since Matrox came out with three screen support in the Parhelia video card. No, certainly not. WideFS is for data between one FS PC (the Server) and client PCs not running FS at all. But I am pretty sure that WidevieW does need FSUIPC installed in each copy of FS. Regards, Pete

JeppView FliteDeck is new to me. I have FliteMap. Can you tell me more? I did look for details of their Electronic Flight Bag a few weeks ago but found nothing more than some marketing spiel and no useful technical data or pricing and so on. Talking with friends at PFC I got the impression that it wasn't really ready yet. Well, it is quite unnecessary, but if it helps me buy my own Jeppesen stuff, and you do really feel generous, then you can always donate via PayPal. It goes to my email address petedowson@btconnect.com. But I won't be offended in any way should you not, so don't worry! ;-) Regards, Pete

Yes. Are you writing a Gauge with the FS panels SDK? If so, check the gauge variable ADF_SIGNAL_STRENGTH. I think the signal is okay if this is greater than 50.0. There only appears to be a variable for ADF1, however. If you are talking about an external program, or anything via FSUIPC's interface, then check offset 3300 -- there are separate indicator flags for good reception on ADF1 and ADF2. Regards, Pete

You are okay writing a program to change FSUIPC offsets, but not okay for a couple of lines of parameters in the INI? How odd. I'm not sure I can explain any better than I have done in the documentation -- if I could do I would have done so, to save having to write more tutorials here all the time. Conditional button parameters are the same as ordinary ones except that immediately after the "=", instead of a "P" (for Press") "U" (for 'up' or release), "H" (for Hold) or "R" (for repeat) they have a C, then the P or U or R (no Holds) and the details of the condition button in parentheses (). The format is quite explicit in the documentation. Can you please re-read the section entitled "compound button conditions" and tell me what you don't understandit is the only way I can improve it so that I don't get repeat questions all the time! Thanks & Regards Pete

The work is mainly in the syntax analysis for the parameters and in restructuring the tables to allow variable length parameters. I certainly don't re-parse the INI file every time buttons are pressed, it is all fast table look-up. The problem with variable length stuff like strings is that I need to do one of: 1) allow for the maximum string as a parameter in all possible button positions (something like 2048 x 128 extra reserved bytes), or 2) have a fixed allocation area of n bytes (eg 1024) into which all strings are placed, and use pointers or indices to access them from the table. Once the space is used up, discard further messages (mark the lines as in error in the INI file), or 3) dynamicaly allocate strings from the heap as needed, but otherwise as (2). This is the easiest, but the one I like least. I deliberately keep heap usage as low as possible in all my FS modules because it can affect performance more than anything, especially when Windows has to tidy the heap to get the needed space. All this would be easier too if it could be done once and for all when FSUIPC is first started, but unfortunately I discard part of the tables (that part assigned specific to the current aircraft), and re-parse the INI for a newly loaded aircraft. So some strings may stay, some may go. this makes alternative (2) look difficult unless I use two areas, one for global and one for aircraft-specific. Admittedly, none of this is really complex programming, but in the context of already rather complex working code, I would rather re-write the relevant parts of it than try adding all this stuff into it. Things have grown over the years and have got messy. Each new addition makes it worse, and more likely to contain errors (as you can see by checking my "bugs fixed" in this area over than last many releases). This is why I said it would be a lot of work. I didn't say complex or impossible, just a lot of work. You can certainly do it the way you have illustrated. Do it that way for now, remind me to consider extending the syntax at another time, certainly not before February please, and after that it depends on what else may need to be done. As I said, until you mentioned it there has been absolutely no requests. If there had been it would have been on my list and may have got in before I froze FSUIPC for another few months. Regards Pete

Now I can understand what you want to do, perhaps you will allow me to suggest what I think would be a little tidier method which uses existing facilities and doesn't need a special offset: Why not simply make the software set or clear one of the virtual button bits (offsets 3340-3363), then, in FSUIPC INI, make the action of your PTT button conditional upon that button? It is detectable in FSUIPC as if it were a real hardware button or switch. If you do really want to stick to using an offset, then those in the range 66C0-66FF are deliberately free for users to use as they wish. Regards, Pete

Can you tell me what this method was in FS2000? And why is using FS's indication in 11BA like "cheating"? Isn't the 11BA method derived all the way through from FS98 and before? This isn't a subject I know at all, but if you are good at physics I expect you could calculate G forces using the assorted accelerations in offsets 3060-3088 and 31C0-31D0, together with the total mass from 30C8. G-force operates with different strengths in different directions, but you have all the information there, surely? Pete

First of all, did you update to PFC.DLL 1.989 as I advised? There have been a lot of changes. Also, I don't believe you have yet stated what operating system you are using. As far as the restart facility is concerned, I wasn't planning to take it out, but it is a sort of last-ditch thing. Really the reason for the problem should be determined and fixed. The fact that a COMMs restart fixes it indicates that my first guess (that the PFC driver was losing its calls from FS) was wrong. When that restart facility was first put in it was to help someone whose set up was becoming non-responsive after a long period: 8-12 hours or so. Long-haul flights in real-time. We never actually got to the bottom of it, but I've actually re-written the lower level routines a couple of times since then and it didn't recur as far as I know. Maybe he re-installed his operating system or upgraded to WinXP. Checking the PFC DLL documentation, you'll see this in the History (version 1.70): The automatic restart is only implemented on Win2K/XP and is controlled by the AutoRestartTime parameter. If you are using WinXP (which I would advise in any case) then maybe you should be using this? The automatic restart actually does an identical thing to the facility you are wanting to use, but it doesn't work on Win98/Me. Yes. Offsets 3200-320B, as documented. It's a bit complicated, as you need to send KEYDOWN messages for each key press, in the correct order, then KEYUP messages in the reverse order. You may find it easier just to toggle a virtual button bit (see offset 3340 ff) and then program that button in FSUIPC to send the keystroke for you. I know it sounds rather round-about, but it works and is pretty easy to do, not to say more flexible as you can re-program the virtual buttons any time and using all the power of the FSUIPC button programming option. But before you do anything, please do try the latest version of the DLL. I have had no instances of control response dying for a very long time. Regards, Pete

Okay, as you wish. I hope you find a solution that satifies you. I would be looking for a way to offload the panel stuff rather than the graphics. I know Project Magenta is a little on the expensive side, but it is one possibility. There is "FreeFD" which may help. There may be other programs which help unload everything but the outside view from the main machine. Regards, Pete

I don't understand the last part -- is that a failing of WidevieW? But the other parts are irrelevant. You surely don't use RC to set the transponder -- you set that using your control on the main FS PC. It is up to widevieW to relay everything about the aircraft status to its client, is it not? If it doesn't you might be in some trouble, but you could set the transponder on the WidevieW client instead if WidevieW isn't overwriting it. Obviously if WideServer is running on the WideClient PC you'd use the keyboard on that PC. Run FS on PC #2 then. Use PC #1 fpr something else, maybe as another WideFS client. Regards, Pete

No. That would be a huge amount of work, and no one has ever remotely suggested anything like that. The message facility in FSUIPC is used via the offsets -- see 3380 and 32FA. You could write an application to do what you want. The facilities have been there since FS2000 days. They are used profusely by many programs. Pete

There isn't such a feature that I know of. Do you mean the Hot Key option to restart the PFC driver, PFC.DLL? All that does is close down the COM port and re-open it, basically similar to restarting FS as far as the PFC controller sees. I don't think it is really needed any more. It was added when there was some suspicion of problems with serial port drivers for Win98 and Me. The only way to reset the PFC hardware is to pull the power and power it up again. What sort of problems are you having that needs such a thing? What for? What are you trying to do? Pete

Hmm. Me? Announce on AVSIM. I don't announce anywhere. Oh, a quote from the release notice for the version of AdvDisplay which has been on pre-release here for weeks? Er ....why? Sorry, I have no idea what you mean. The messages come from programs which send them to offsets in FSUIPC. There has been a "white messages" option in FSUIPC (see Technical page) for many releases. All that the addition in version 3.51 does is allow the application to operate that option via the offsets. What are YOU thinking of? Pete