Pete Dowson

Sorry, I have absolutely no idea. I have no program which is in any way related to flight videos, or even graphics. I think Luciano must be mistaken. Regards, Pete

Something doesn't make sense there -- PFC.DLL depends upon FSUIPC and will not work without it! What "older combination"? You've mentioned nothing about that! All you said was you were using FSUIPC 3.22, which is out of date. You didn't even mention PFC.DLL originally. Please re-check with version 3.30 of FSUIPC. I cannot investigate any problems with older versions. Regards, Pete

There aren't any keystrokes related to whether Advdisplay's window is cleared. It sounds like something is actually writing to the AdvDisplay control offset when you operate the landing light switch. If you disable AdvDisplay, so the ATIS shows in the normal FS text display, does it still occur? If so then it may not be the FSUIPC offset but some direct action into FS. You could also test with the utility ShowText (in the AdvDisp ZIP) to see if the text clears there too -- that reads from the FSUIPC offsets. Is this only with the PMDG 800/900? If so, please report it in as much detail as you can to PMDG. I suspect it should be very easy to find and fix once they know about it. Regards, Pete

Sorry, I don't understand what you mean here. Can you explain? Certainly, all versions of FSUIPC, and FS6IPC and FS5IPC before it, going back about 10 years, have provided access for applications to induce failures, it is simply part of the interface it provides to FS. What do you mean "hidden"? It is simply a module installed in the FS Modules folder. Go take a look, in explorer. You'll see it! It is not hidden. Also, if it is installed there will be an FS Menu item for it -- Modules - FSUIPC. Check that. If it isn't version 3.30 then it is out of date. Download a new version from http://www.schiratti.com/dowson. You misunderstand. FSUIPC does nothing unless told to by an application or add-in DLL or Gauge. This is especially true if you have not registered it. It is then simply a passive interface for other programs and add-ons to use. Regards, Pete

No need for a cursor any place. It isn't used as there is no text input. Have you disabled FS's programming for the hat? You need to go into FS Options-Controls-Assignments, find where the Hat is programmed, and delete the assignment. Otherwise the two will be conflicting. Then program all 8 directions in FSUIPC. They will be numbered 32 to 39 clockwise from forward. Ugh. The keyboard facility is really only provided for support of those add-ons which need keypress combinations to work correctly. For FS there are controls for almost everything (and some added by FSUIPC). Use the FS Controls side of the dialogue, and find the View controls. There will be a lot to choose from, but this is the normal view sequence for the hat: VIEW_FORWARD VIEW_FORWARD_RIGHT VIEW_RIGHT VIEW_REAR_RIGHT VIEW_REAR VIEW_REAR_LEFT VIEW_LEFT VIEW_FORWARD_LEFT Regards, Pete

PMDG installs a DLL into the FS Modules folder, which is always running. Try removing that and re-check your frame rates without their aircraft. Check the FSUIPC Log file, as I suggested. Also make sure you are using FSUIPC version 3.30. If not, please update. Is that an external EXE or a DLL or Gauge? If the latter, then that's more activity to affect frame rates. Regards, Pete

Yes, you can set failures through WideFS and FSUIPC. I don't know of any ready-made programs offhand, but I bet there are some around. Try, for instance, the FS Instructor link on the http://www.schiratti.com/dowson page (right-hand side). That may do them. There was also this news item about a year ago: but the link it gives seems to be dead now. Do a search of likely places or ask around in more forums. Regards, Pete

No, not directly. I've no idea how they are produced. Aren't they tied to specific events? If you can cause the event, then the effect will occur I epect. Are you saying that if you could program gauges you could induce effects from them? If you can tell me how they would do that maybe I can find out how to do it too. I'm completely lost here. What "keys" are these? Not keyboard keys it seems. Is this something realted to how FX are defined? Regards, Pete

Very peculiar! Did you move My documents before, or after, installing FS? I wonder if this is a Win98 or Me thing? I'm using WinXP so it may be different. Something to remember though! Thanks Jose! Regards, Pete

Sorry, no. I really can't see how it is possible for there to be any relationship whatsoever between landing lights and AdvDisplay's FS message interception. When "AdvDisp stops showing any data", what data are you expecting? Is it being displayed in the FS text lines instead? Perhaps it is the program you are using which displays data through Advdisp which is failing? Just disable AdvDisp (modules menu) and see if the "data", whatever it is, displays in FS's text lines. If not, it isn't AdvDisp which isn't working, but the program or whatever which is providing the "data". You can also try another source of messages for Advdisp to show, such as ATIS (if enabled in AdvDisp's menu), or enable some Monitoring in FSUIPC's logging page -- one of its options is to direct text to the FS adv display lines. AdvDisplay should intercept those too. Finally, once you have narrowed it down enough to describe it precisely it would be worth reporting this on the PMDG site as it could be a symptom of something wrong in the new 737-800 panel code. Regards, Pete

There should be no measurable effect on FS performance whatsoever. If you noticed any with your aircraft using FSUIPC it will either be because it is actually doing more (as with any sophisticated panels, you don't expect them to perform as well as the simple ones), or because it is not registering its access correctly and causing multiple module searches in memory to identify it -- the FSUIPC Log may indicate if that is happening. In the latter case, yes, user registration will stop that happening -- but the aircraft's programming should really be fixed in any case. Registering FSUIPC as a user gives you access to many options, but doesn't in itself make FSUIPC do any more work, or any less. Obviously, if you enable options they will become active, but they are almost all event driven actions, not continual processes. The only continual processes in FSUIPC are those for populating values for applications to read which are otherwise not made available in FS's globals DLL. Even then they are actions triggered by events -- in this case a new frame, or the "nth" new frame, where the value of "n" varies according to the priority of the variable type -- primary flight indications like AI, VSI and ASI are refreshed every frame whereas many of the engine indications like vibration and hydraulic fluid pressure and temperature are refreshed far less often. But, in any case, all those actions are being performed whether or not you user-register the program. They have to be in case any application needs to read them. A lot of thought goes into the design, to ensure minimal impact on performance, and it is written in a mixture of tight C code and Assembler for best performance too. I've never managed to measure an impact or more than about half a frame per second, and just enabling, say, the visibility limits, gives you back a lot more than that straight away (though I must admit the view distances have less effect in FS2004 than they did in FS2002 and FS2000). Regards, Pete

Well, only if you want to keep the old copy for some reason. If you simply copy in the newer DLL it will replace the previous one -- Windows folders can only contain one file with the same name. you may get a prompt asking if you want to replace it -- you simply confirm. Do you? I think you misread it. Here's the relevant text: See "for many months"? There cannot have been many months passed in this case. You merely copy the new DLL in, it replaces the previous one, everything else stays the same. You only need to re-register if you reinstall Windows or move to another PC. Regards, Pete

Hi José, On my test and development system my "My Documents" is on a different drive altogether, but FS2004 seems to manage okay -- the Flight Sim folder is there with its Flight and WX files. Best, Pete

You might get better results posting this question on the FS2004 Forum. Personally I've not heard of behaviour like that, but I would guess that it's related to drivers -- video or sound. Regards, Pete

There are two other tests you can do here. Both ESCape and Enter should do something in the dialogue even if you don't see any text. Here, pressing ESCape is the same as clicking the Close (X) Icon top right, and closes FS tidily. Enter or Return operates the "Fly now" button (which I know you don't see), and effectively re-selects your last selection. Can you try both of those to see if they operate? Finally, there was a change in 3.22 to the way FSUIPC polls joystick buttons which did affect some folks adversely (not in any way like your problem though). I did fix this in 3.30, but just in case there's anything going on related to that, please try this: Edit the FSUIPC.INI file, find the [buttons] section, and add the lines: PollEpicbuttons=No PollInterval=66 Do this without FS running, then load and run FS and see if the problem still occurs. Let me know please. Regards, Pete

If it simply the display which is wrong, then the video driver is the prime suspect. If Windows doesn't report it as "not responding" then it must still be processing messages and the like. So you may be able to close it more tidily by clicking the close window button/icon (x in top right corner or active window). Also, see if it the same in both full screen and Windowed modes -- i.e. try the other, the mode you are not using. Well, before you work around it, if it looks like some interaction between the aircraft and FSUIPC is responsible, please do send me that Log as I described. Regards, Pete

If you choose a different aircraft first, via the Aircraft menu, does it still occur? This may show whether it is a result of some activity in the advanced aircraft panel code, or actually something which has been corrupted by that code -- in the latter case you'd expect it still to fail even if you changed to another aircraft first. When you say you have to close FS forcibly (Ctrl-alt-del), is this because FS is solidly hung? i.e. not responsive to anything at all? If it is okay after changing aircraft, I can check the activity the aircraft has with FSUIPC at the time if you will do the following (with 3.30 installed please): 1. Just before exiting the flight which will cause the hang, go to the FSUIPC Logging page. On the left check the IPC Read and IPC write logging. On the right enter offset 3364 as type U16 and check the "hex" option, then, below, check the normal log option. 2. Ok out of the FSUIPC options, then (with a couple of seconds gap) press ESC and exit the flight. 3. If it hangs as before, close FS, find the FSUIPC.LOG file in the FS Modules folder, ZIP it up and send it to petedowson@btconnect.com with some brief explanation. Meanwhile, this also sounds rather like a video driver problem. Possibly the only reason it happens with one version and not another is that the memory arrangements will be slightly different, or the timing between one even and another is slightly different. You could probably get different results too by re-ordering the modules in the FS modules folder. There was one other instance of this reported here someplace -- but this time when using Active Sky 2004, not specific aircraft. It may help if you compared notes with the other user. Possibly you have the same video card and/or driver version? Or maybe there's something else in common you can identify? Regards, Pete

You have the wrong idea. A debugger helps you get your code correct in the first place. You shouldn't have to add "debugger" functions. You compile your code in Debug mode and run it under debug control. That way you can do things like single step line by line and see exactly what is going on, where you are going wrong. If you really thing that you are so good that you can get code 100% right first time and therefore don't need to use such facilities then I think you should go back to programming school and learn more realistic programming techniques. I just think you should learn programming before you attempt to program rather more intricate things than the simple "hello world" examples. I am not trying to tell you not to program, but your unwillingness to even try to understand the code that folks like Bob have volunteered makes it seem as if you need to retreat a little and bone up on the language you've chosen to use. This is really your problem. You completely misunderstand what you are attempting to use. You do not see FSUIPC. There is no "working with data" in FSUIPC. It is all in the VB code which you have and which is provided by Bob. You can throw all that away and write your own if you like. None of it is fixed or essential, it is there to help, not hinder. The ONLY part of the FSUIPC interface which is in that code is the call to the SendMessageTimeout function, which is a Windows API, and the data format to which it refers, which is primarily defined in the C headers, as they have been since FS95 about 10 years ago. All of the rest is code to manage YOUR data, not FSUIPC's, and it was developed and supplied voluntarily by Bob and others to help. That's all. Folks have contributed what they can, and their contributions have helped very many folks over the years. You are the first to have been so ungrateful for their efforts. It would be different if the SDK was a commercial effort with rewards for contributions, but it isn't. I think we should end this thread here and now, as it is obviously not helping you, and frankly it is now wasting too much of my time. As it is I can only attend to the computer for short periods until my eyes repair, and I should be helping others who are possibly a little more receptive. Sorry I couldn't help you more. I did try, honest. Good luck, Pete

Thanks -- it's all a little better each day. I've just got to get my brain re-programmed to make the first operated eye go back the way it was. It seems to have stuck in a mode trying to match my short-sighted eye, except that it didn't do a very good job anyway. It took two weeks for it to change last time so I suppose it'll be two weeks to change back again. Meanwhile I seem to be able to manage one-and-a-half eyed. :wink: Best regards, Pete

PFC make the equipment for several other suppliers too, but in every case the protocol is specific and proprietary to that customer. In some of the units there was an internal switch to change between the proprietary protocol and the PFC protocol, but I am pretty sure this doesn't apply to the Jeppesen units. By all means check with PFC though -- http://www.flypfc.com. Regards, Pete

Well, certainly the 03F2, 04F4 and 04F6 offsets are FSUIPC offsets used by PM, so I assume FSBuus talks to FSUIPC for these, but I don't know what the others do -- they all seem to have 0 for an offset. Not really. it is obviously specific to the FSBus system. Good. But wasn't drivers one of the first thing suggested? What about that business of closing some SVCHOST processes? Wasn't that your earlier solution? Regards, Pete

Sorry, I don't really understand that. Does FSBUS sends "offsets" (values?) to FS2004/PM? How does FSUIPC see these and what should it translate them into? This sounds a bit mixed up to me. If you have a button then you can program a button press in FSUIPC to operate any of the documented PM controls -- just enable PM in the FSUIPC Buttons page and you will see a list in the dropdowns. All the PM ones start with "Pm". Some take parameters -- these are mostly listed in the Advanced Users guide for FSUIPC, but for a more complete set you normally need to refer to the FSUIPC Offsets documentation on the PM site. If FSBUS writes to FSUIPC offsets directly, then you don't need to program anything in FSUIPC. Just look up the offsets for PM in the PM offsets documentation, from the PM site. I don't really know. Most of the bit-twiddling controls always had to have the MCP.EXE part of PM running for the Boeing things to work. Whether the more general GC controls by parameter (via offset 04F4) used to need the MCP I don't know, but Enrico said he was making it all independent in any case. I think he did this for the Boeing suite some time ago, but I cannot attest to that. Amd for the Airbus stuff I'm afraid I haven't a clue. In the end, if you cannot work these things out by experiment, I'm afraid you need to talk to the PM folks. Erno. At least, in the case of the Boeing suite, if you have no MCP part of PM running then you have no PM autopilot. All the automatic flight control code is in the MCP module. The graphic front end with the knobs on it is only the control panel -- I don't have that displayed, it is minimised. I use the Aerosoft hardware MCP. Isn't this similar for the Airbus series? Surely the FCU isn't merely a control panel, doesn't it contain the clever bits too? If not, where are they? They certainly aren't in the CDU or GC. Do you mean to FSUIPC, or does FSBus use its own interface inside FS2004? Sorry, which delay was that? Another thread? And which driver, please? Regards, Pete

The copy of FSMetar I have here works very well with 3.30. It is FSMetar version 1.53 and it is quite recent. I think there was a problem with the earlier versions -- it wasn't obeying the handshake protocol for setting local weather stations correctly. That was fixed in 1.53. Without the fix it sometimes sets weather stations okay, sometimes not, and sometimes only global weather is set. There's probably some small timing differences on your system between using 3.22 and 3.30 which shows this up, but I think it is quite likely that even with 3.22 on your system, FSMetar is not, in fact, setting all the weather it thinks it is doing. Check the FSUIPC LOG file with Weather Logging enabled -- you will probably find numbers of "Override" messages where subsequent weather station settings override previous ones. Regards, Pete

Do you mean the auto-throttle? If so, this will be because of jitter in the axes -- FSUIPC cannot cure that (though I am looking at implementing some smoothing and filtering in a later version). If you cannot fix this by using better quality or cleaner pots, the usual way is to define larger idle and dead zones, normally at the extremes, and 'park' the levers there when A/T is engaged. Well, FSUIPC won't be adding any jitter, that will certainly be from the source. If you are using one of the add-on panels which does its own A/T implementation, not using FS, then the more probable reason is that the panel is using the regular single throttle control and you are using the two separate ones -- the panel may not be correctly overriding those as it probably is for the single control. Without a fix from the panel authors the only way will be to park the throttles then -- only changes in input will affect things, not a static input value. Regards, Pete

There's no such release as 3.33. Please check the FSUIPC Log file. Regards, Pete