Pete Dowson

If you have just downloaded the FSUIPC 3.536 Zip, please do so again. I just found out the module I Zipped was corrupted and have uploaded it again. The cirrect one bears a timestamp of about 01:16 (AM). Regards, Pete

Could you check whether you still get that initial spurious value in 030C using the Beta release of FSUIPC (version 3.536, see Announcements). I added the check on "ready to fly", but I was unable to get the bad value in the first place so I couldn't test it. Regards, Pete

This is normal. Why do you think it is a problem? It all works doesn't it? The way aircraft specific settings work is NOT the same between the two sections. With the Joystick Calibrations, the specific section is used INSTEAD of any generic section you may also have. It is one or the other. Hence the checkbox shows that. In the case of Buttons it is much more complex. Only those buttons you have re-programmed to be aircraft-specific are aircraft-specific, but any others, defined for general use, will still have their programming action operational. Hance the Button programming is much more flexible (and as a result more complex, sorry). The Key Press programming is the same. I did think about making the Joystick Calibration similar, but couldn't think of an easy way to disable calibrations and assignments which you didn't want interfering, so I made the system do a straight swap in this case. Besides which, it is a much more likely need to have a 'core' of button assignments which are applicable to all aircraft. I did think this was documented somewhere, but maybe I didn't make it clear enough. Well, I haven't seen any that have numbered buttons at all. The Windows API numbers the buttons from zero, so it is entirely logical for me to do so too. It is a standard practice going back many years now. No, not at all. It would certainly cause confusion all round. Pretty much all the sophisticated gear used to build cockpits uses numbering starting from zero, and in any case suddenly renumbering everything in an update will mean everyone suddenly having unexpected problems needing re-programming in FSUIPC options! See the Announcements above. And be careful -- joysticks are numbered from 0, andfaxes are "numbered" with lettrers, X Y Z R U V, following the Windows API and general harware practice for the last 10 years or more. I doubt if any of your joysticks are numbered thus. ;-) Regards, Pete

Is there an FSUIPC.LOG or FSUIPC.INI file also in the FS Modules folder? If so, can you show me the Log file contents please? I've never heard of a case yet where, with FSUIPC installed, you don't get a Modules menu, containing the FSUIPC entry at least. Regards, Pete

None at all for the current versions I'm afraid. I'm guessing that it's buried deep in the graphics someplace. However, if it is correctly following the rules of place and date/time, surely all you need to do is follow the same ephemeris rules and calculate it? Or have look-up tables. It's probably too late by now for FSX too, but be sure to make a suggestion to Microsoft by writing to tell_fs@microsoft.com. Just ask for programmatic access to Sun (and Moon, and Stars?) positions, giving your reasons. Regards, Pete

A crash is something which stops Flight Sim from continuing to run. Simple really. That's what this thread was about, if you check back. folks using WidevieW are/were having the WidevieW clients crashing to desktop (CTDs). When you appended your message saying you had the same, I obviously assumed you meant you had the same. Sorry. It sounds like WidevieW is not setting the local weather for all the surrounding weather stations, so as the weather changes, as the wind blows, or as you fly, you run into areas of default weather -- which is clear sky, 1013 mb pressure, etc. Maybe Luciano has not appreciated the complete revision of the weather system which took place between FS2002 and FS2004 and is still using techniques which only worked back in FS2002 and FS2000 days. At least, that is what it sounds like. It doesn't sound strange to me at all. Have a read of the very last section of the FSUIPC user documentation. That explains problems with global weather setting only. With local weather setting, you have to actually set each of the nearby weather stations, as you fly. Those not so set will initially retain default weather onlybut even that isn't static: Once weather at a local station has become localised, setting new default weather, e.g. to keep up with changes in the weather on the Server PC, will have no effect except on distant stations whose weather has not been progressed yet, as they are out of range. Regards, Pete

There have been no changes in the weather facilities in FSUIPC for many versions now. You need to look elsewhere. Using the facilities for localised weather control added to FSUIPC for FS2004 it is extremely easy to crash FS in Weather.DLL. This is because I deliberately do not check the values being set—it is a direct route through to the weather setting parts of FS and is deliberately free for weather making programs to explore and expand upon what was known about the weather prior to FS2004. If these crashes are only occurring with WidevieW (which I don't use), you really need to help Luciano resolve it with clear reproducible examples. I really have no idea even what facilities in FSUIPC WidevieW is using, and Luciano has never contacted me about any problems. I'd be glad to advise him if he needs such advice, but there's no information and no evidence here whatsoever. Regards, Pete

It really depends on what sort of aircraft you intend to use it with. A fast response jet fighter would need a more responsive throttle than a modern heavy airliner, whose engines take a while to spool anyway and which really only take your throttle input as a guide and process it through assorted electronic and mechanical and even computerised control-check-change-apply processes. I am just finalising an interim update to FSUIPC which provides direct axis assignment and hence does its own joystick polling. I find scanning the joystick inputs at anything from 10 to 40 times per second appears more or less the same -- in other words, I can't see any difference in FS. A default based on the standard Windows "timer tick" (55 mSecs, or 18.2 cps) is certainly adequate for pretty much all purposes --- but why not make yours adjustable by parameter so that you can experiment yourself? To save a lot of time and unnecessary process switches, always compare the new value you are about to post with the last one posted. If they are the same (withing a specific "delta" value, either way), discard it, don't send it. Sending values for a difference of 1 in a range of 16384 is a waste of time. For 16384 try a delta of something like 256 as default -- again make it adjustable, and set it to the highest value which doesn't result in a loss of resolution on your engine settings. If you need ALL of the information in the larger block, then that is more efficient, because FSUIPC only has to process the one request in the data instead of looping arond doing lots of small ones. But the differences are probably not really measurable. If there are "gaps" in the large block -- information you don't need, but which may be changing -- then it would make it less efficient over WideFS because WideServer would be keeping a check on changes to values you don't care about, and generating Network traffic needlessly when they do change. But it doesn't make a lot of difference at all really, either way. When I designed stuff like the AI traffic "TCAS" tables, I provided lots of values and markers for folks to streamline their access and only read the parts that had changed, but after doing that I too found it didn't really make much difference to performance. My "TrafficLook" program just reads the whole blocks every second -- try it on the same PC as FS and also on WideFS. Of course, once a second isn't a big load in any case -- so that's another consideration. You might get better results, both in FS and in your program, if you do a lot less often than a little very often. But maybe that is less "smooth". There'll be an optimum somewhere between, but I'm not sure it is worth spending too much time looking for it, and measuring the differences may prove futile unless your PC is really overloaded in the first place. I don't really understand that question. There's no "memory" in FSUIPC as to what program wants what. Maybe you are thinking about WideFS? In that case your "Process" calls only talk to WideClient. WideClient only places requests for data not previously requested through to WideServer. WideServer remembers which Clients want which data, but only sends it after that when it changes, and it keeps sending it when it changes whether you ask for it again or not. Hope this helps! ;-) Regards, Pete

YesI do! ;-) BTW it is "WideFS" not "FSwide". Oh yes I am! It is almost 100% C, with a little bit of ASM inserted in special places where I didn't like what C did, or where I couldn't do what I wanted efficiently without it. Currently I'm using the C/C++ compiler from Microsoft's Visual Studio .NET 2003, in Native C mode. Before that I used MSVC/C++ 6, and before that Watcom C, Topspeed C, Lattice C (on the Amiga) going back to BCPL in the 70's (BCPL was a forerunner to C). Between 1963 and 1981 I also used mostly assembly code for whatever machine I was programming, though dabbling a bit in Fortran and APL. I gave Cobol I wide berth! ;-) Regards, Pete

Unless someone has changed my original C source code in preparing something for Borland, the Read and Write calls do nothing but add requests into the data area allocated as a memory file by the Open call. There would be no communication to FS or FSUIPC at all. The job of the Process call is to send a message to FSUIPC to ask it to look at the memory file and process the accumulated requests. Not at all. It is the only call which actually talks to FSUIPC. There are Process calls in the Open request too -- to obtain the FS and FSUIPC versions. Having said that, the sources for all the stuff you use in your program are in the public domain and included in the SDK, and anyone may change them. However, including the message calling part of the Process call in every single read and Write request is grossly inefficient, as each such call invokes a process change. Of all the time needed for inter-process communications, it is the process switching which takes the most -- the actual reads/writes (no matter how many) are normally accomplished well within a single millisecond, whereas the process switching and message queuing involved can be tens or even hundreds of milliseconds. I had a quick look inside the Borland ZIP in the SDK and cannot see any library that I'd recognise as such -- I don't know the filetypes BPR and DFM though. Isn't the Borland package there just a wrapper for my original C provisions? Regards, Pete

If the distance is not too far, i.e. the points are close enough to regard the intervening Earth's surface to be pretty flat rather than spherical, then isn't that merely a matter of simply right-angled triangle trig? How did you determine the distance -- wasn't that by similar assumptions, then using pythoagoras? Otherwise it gets more complex for both, as you need great circle calculations for the distance and some spherical trig for the angle. Regards, Pete

I think the program became payware before I started the accreditation system. Abacus Software own the license I think. It certainly would have done with FS2002 and the version of FSUIPC which was available at the time. You are talking about an add-on program with is at least three years old, probably four or five. Assuming it will work with FS2004, yes. Either that or get the Author to apply for a freeware licence for it, which would probably also need permission from Abacus. I would not dare provide access to a commercal program without the author's permission, especially when that might violate some other commercial arrangements. Sorry. If you are using FS2002 or earlier you can do that. You would need to find a version 2 FSUIPC. Most programs like the one you are talking about would have been packaged with a suitable version of FSUIPC in any case. Regards, Pete

Download the FSUIPC SDK from http://www.schiratti.com/dowson. It is all in there. Pete

Thanks. I've released it now in the "Interim Versions" announcement above. Regards, Pete

When you say "often", can we get that more specific? Isn't it only when reloading FS after you have closed it sometime before, in the same Windows session? There are no items relevant to FSUIPC loading other than the FSUIPC.DLL file. The other changes you make cannot be at all significant. The message only arises, on loading FS, if there is already a copy of FSUIPC running in the system. This can occur for one of three reasons: 1. There are actually multiple copies of the FSUIPC.DLL in the FS modules folder. This can only happen if you ever rename the module. NEVER rename the module. 2. If a copy of FSUIPC.DLL, renamed or not, is placed in the main FS folder as well as or instead of the FS Modules folder. 3. Finally, and the most likely, if the previous session of FS is not actually fully terminated. It may look as if it has closed down -- no window, for instance. But check the Windows process list (Ctrl-alt-del, Process list), and see the FS9.EXE process listed. The last can happen when one or other add-in program you have installed (module or gauge) has failed to terminate when FS terminates. This leaves the whole process still running, in the background, on your PC, including FSUIPC.DLL. As an example, one earlier version of ActiveCamera for FS2004 did this -- it never terminated correctly, leaving an invisible copy of FS9 actually running all the time. If this is the case you can recover by closing the FS9.EXE process in the Task Manager's process list, but you'd best be trying to determine what add-in component is causing the problem. Regards Pete

Hi Michael, Found it! A very old error for sure. Please try the attached PFC DLL version 1.993. If this is okay for you too I will put it up with the Interim releases at the top of the Forum. Thanks for your help, Pete PFCDLL1993.zip

Further on this: Hurrah! I can reproduce this. It appears to be irrelevant whether throttles are mapped -- in fact the phenomenon is completely independent of the quadrant assignments, once it occurs. It is obviously a corruption in the 1st Slope table (after the default linear setting, that is), as it affects that #1 slope selection identically on any axis to which it is applied, not just aileron! The interesting thing is that it is not due to the action of selecting a quadrant setting with mapped throttles, nor even using it subsequently. The problem only arises if such a quadrant is active when FS is first loaded. So it is something to do with initialisation of the slope tables. RightI have a lot of clues, now to dive into the code! ;-) Regards, Pete

I'm afraid I don't know their software. What sort of "assignments" can you do? If you cannot test values in FSUIPC offsets then I don't think you can use it. You'd need to be able to differentiate between 0 (off), 16383 (hex 3FFF, green) and any other value (red). Regards Pete

Okay -- that's good information. It indicates a corruption in the table for the one curve. With your INI (now received) I should be able to locate that and fix it. For now, use one of the response curves that works! ;-) Regards, Pete

It is part of a large data area for many FSUIPC-maintained values, and, yes, it is all zero to start with. It should be zero if the aircraft has never been airborne, but that does depend on my code seeing the "aircraft on ground" flag. If during initialisation, that flag is zero then there is a possibility that an uninitialised value from FS itself is being copied in, at FS load time. The same value would also be seen in 02C8 though, albeit transiently. I'm not sure if there's a way I can prevent that -- if the user deliberately starts FS with the aircraft in flight then I have to do this in any case. Quite honestly, I never expected folks to want to know the touch-down V/S before they've even been flying. That would probably be too late if this is occurring during FS initialisation. I don't think FS's monitoring starts that early even if it was enabled on the previous session. If the aircraft has never been airborne to you or your user's knowledge, what would be the use of this value? I must admit I am rather bemused here about what the problem really is. If it is just some sort of initialisation problem then I could probably try to delay its update until FS is "ready to fly". this is some seconds after it looks ready, for safety, about the same time, for instance, as I start up WideServer. Regards, Pete

And no filtering, just in case, please. Regards, Pete

The units are 256 * metres / sec in any case, as they are for 0ffset 02C8. -59999 would convert to -12.8 ft/min. If this is after you have done such conversion, how does it end up with such an interesting number as 59999? Do you limit it? The location 030C is not in FS, it is local to FSUIPC, and it is only updated whilst in the air. As soon as the aircraft touches the ground, the last value written there is left untouched, until you are next airborne. On FS2002 and before, it is copied from 02C8 whilst in the air. On FS2004 (only) it is copied from the place in FS where 02C8 in mapped -- somewhere within FS's SIM1 private sim data. No, as the data source is the same as for 02C8, and in any case the value isn't touched whilst on the ground. Why not use FSUIPC's own monitoring facilities to log the values both in 02C8 and 030C? See the Logging page, right hand side. Log as type S32 to the normal Log, then compare the results from the two locations on during a landing. Don't enable this logging too long before the landing as the log will get rather large. Log the "aircraft on ground" flag too (0366, as a U16) so the moment can be seen. Regards, Pete

That's the sort of thing which would give the results Michael is getting. On my Jetliner yoke the left side of the aileron is playing up too -- jitters up and down a bit near the centre of the left side movement. I have proven it is definitely the hardware input -- I think it needs a new pot, or at least a clean in there somehow. I don't currently use it for real flying only testing, so I've not asked PFC about it yet. The one in the 737NG is fine. Phew! That doesn't sound good. Their build quality is usually very good indeed -- you must have been very unlucky! Were any of those other things responsible for jitter in the aileron, though? Surely that was all down to the pot? Regards, Pete

Well, I've tried all sorts of things and cannot make anything go wrong here. I am using a slightly later version of PFC.DLL, but the changes are only in relation to PMsystems and overgead switches in the PFC 737NG. I definitely need your PFC.INI so I can check with the same options and selections. Tell me also: 1) which user config in your setup you are selecting 2) using Throttles R12, R34 or just forward thrust 12, 34? 3) Flitering on or off? 4) Slope selected or flat? You say that the little dot on the Slope depiction zooms off the wrong side, but that is manipulated by the driver. Please watch the "input" value for the aileron, the first figure under the little "RVS" checkbox. Does that undergo similar sudden changes? If so, then it is definitely something on the hardware side, as that is reflecting the raw input. Let me know these things, then we'll try logging to get hard data. I attach PFC DLL 1.992, just to be sure we are using the same version. Please do the tests with this from now on. (Note that the Version Info on this build says 1.991 -- there's no difference, both were internal builds on the same day). Regards, Pete pfcdll1992.zip

What version of FS? What version of FSUIPC? Check the FS Modules folder, look for a file called "FSUIPC.LOG" -- show me that. By "installing" and "upgrading" FSUIPC, what do you actually mean? The entire process for both events consists purely and simply of copying the FSUIPC.DLL into the FS Modules folder. Do NOT put it into the main FS folder. In that case it was NOT "FSUIPC.DLL" which you "uninstalled", since there is no other change made by FSUIPC -- if it is in the FS Modules folder, it is loaded by FS, if it isn't, it isn't. It is as simple as that. You probably "uninstalled" something needed by FS, one of its own modules (maybe "FSUI.DLL, the FS User Interface?). Most DLLs in the Modules folder are part of FS and needed by FS. And what EXACTLY is the 'result'? FSUIPC does very little by itslef. Simply copying the DLL into the Modules folder installs it, but if nothing uses it , it does very little. Certainly nothing to stop FS running. Please describe EXACTLY what you are doing and what you see, and show me the FSUIPC.LOG file, otherwise I really cannot help you. There are many thousands of users who simply copy in the DLL and forget it. It is not a complicated thing to do! Regards, Pete