Pete Dowson

Yes, with all default settings. you may want to go back and tweak some things afterwards. Or, best, make a safe copy of it (eg "copy of FSX.cfg") in case it actually doesn't fix the problem and you want everything back. Pete

So since the WideFs stuff is identical for FS9 and FSX, the fact that it worked with a different pair of computers with FS9 is actually irrelevant? You provided a HUGE repetetive WideClient log (why not just an extract -- surely all the retries aren't relevant?). But I see no WideServer log file. WideClient is only one half of the story. There are always two ends to a connection. Hmm. I find that rather hard to believe. What's going to change after three hours? Do you think a windows firewall is being beaten into submission? ;-) On both PCs? Have you disabled the default firewall in both, or at least let the relvant programs or ports through 9however that's done ... I don't really know, as i don't use a firewall between my own trusted PCs). Yes, almost certainly. No, only one problem logged.. this one: which is usually a firewall block. All the rest is only a log of its retries whilst it bashes hopelessly against that block. Regards Pete

There's no queuing system in DirectSound. You can either loop teting whether the sound is still playing (i.e. using sound.query), or, if you know how long the sound plays for, just inserting an ipc.sleep(n) between them, where 'n' is the number of milliseconds. 91000 mSecs = 1 sec). Pete

In your AppData\Roaming\Microsoft\FSX folder. You'll need to go to your main Windows drive (usually C:) go to Users, select your normal FSX user name, then follow that folder chain i just mentioned. It might be hidden. You can unhide folders using the Folder Options menu in Explorer. Flights are normally stored in you Documents\Flight Simulator X Files folder. FSUIPC has a fix for one particular crash in G3D.DLL. No others. Pete

Thanks! I've pinned it. Pete

Well, the crash is in API.DLL, which is a sort of collection of all sorts of ancillary functions used all over the place in FS, so it doesn't really give much of a clue I'm afraid. I have to say, if it isn't due to a specific add-on you've changed or installed recently then I can only think there's some sort of corruption in FS's data somewhere. Apart from a complete re-install, which can sometimes make things worse rather than better, I can only think of trying to delete your default flight, and your FSX CFG file, and let FS built a new one. You may be better off going to a Forum more dedicated to this sort of crash than here, such as the AVSIM Crash To Desktop (CTD) Forum. I think you might find a lot of suggestions there. Regards Pete

That's certainly something I didn't know about! And it should definitely be kept as reference for others. Could I ask you to please create a suitable thread with the problem and solution in the FAQ subforum for me? I think it is best coming drectly from the discoverer. When it is posted I will lock it so it stays among the top help threads. Thank you! Pete

Sorry, there's nothing I have heard of which does this. Are there any updates for the 747 you are missing? Have you asked on the PMDG support forum? FSUIPC doesn't "cure" fatal crashes. There is one specific G3D.DLL crash it does patch out, but that is almost always related to scenery, not aircraft. And it applies whether you purchase FSUIPC or not, as it is part of the standard install features. You will, in any case, need to supply more information. There is always more detail for crashes. Check the Windows application eror logs. It will tell you what the crash was and in which part of FS. You'll need to provide that information to anyone you enlist to help resolve it. Regards Pete

Well, there just MUST be something wrong with that DLL.XML which I cannot see. And if that were the case itcouldn't load 4.86 either, so it makes no sense at all. I suppose you could, as an experiment try renaming the DLL.XML and re-running the FSUIPC 4.90 installer, so it makes a fresh DLL.XML with just FSUIPC4.DLL present, but because of the 4.86 loading I can't see that being different. When you said "I did try deleting the trust line in fsx.cfg,", did you delete ALL of the [Trust] section or only one line? At least delete all of the lines mentioning FSUIPC4. The only other thing I can think is that the DLL is being 'guarded' by some virus checker somewhere, somehow. You are SURE that the DLL does actually get properly installed into the right Modules folder? Regards Pete

Please refer to the FSUIPC4 Offsets Status document, look up offset C000, and note that there's a red asterick on the C000-C3FF section Refer further down to the meaning of that asterisk, also in red where it tells you reasonably clearly what you get in that area. None more detailed, and that's all that is needed for programmers, but the first port of call is surely always the main Offsets reference documnet? Regards Pete

The Schiratti page always provides a link to the current latest Install version. Between every complete re-issue (documentation etc etc) there are always many interim updates and those are ALWAYS hosted here, in the Download Links subforum, along with lots of other stuff. Your second link above is direct to the relevant thread in the Download Links subforum, that's all. it would be a good idea for you to explore this Forum a little -- you never know, you might find other useful things. Yes. it's only its entries in the Registry which are non-standard and cause FSUIPC problems which I had to work around. Pete

Well not really, because the thread title doesn't actually cover your subject. Why not start your own thread with a more appropriate title? The "loader" is actually "mentioned" in the Installation document included in the ZIP. It is almost never useful. It was only ever provided as an "in case" provision, to avoid loading conflicts with other DLLs. Did you try without the loader? Were the symptoms the same? If FSUIPC actually gets loaded (as can be checked by the existence of a new LOG file) then the loading has already been done so the loader would be irrelevant. The only recent problems with a log which stopped there were due to a bad device installation, one for a "Razer Nostromo Keypad". The problem, an erroneous Registry entry, caused FSUIPC's joystick scan (only performed for registered users) to go into a loop. This was corrected in version 4.902. Generally if you have a problem with FSUIPC (and it is actually running, as seen from a Log file), it is a good idea to see if there is an update. So, please go to the Download Links subforum and get the current interim update, 4.907, and see if that helps. Oh, first, I'd try removing the Loader from the modules folder and re-running the 4.90 Installer so it fixes the DLL.XML file. THEN put the version 4.907 into the Modules folder. Regards Pete

There is no way FSUIPC by itself can do that. In fact as far as I know it isn't possible to have electrics and avionics on in the C172 without the switches being on. You most definitely have something very odd going on there. FSUIPC is passive. It just does what it is told. And I certainly wouldn't even know how to make it do what you are describing. Pete

The "weather at aircraft" area ax C0xx provides all the information which FSUIPC can obtain when reading weather at the aircraft position. It provides some or all cloud layer information. By only reading C288 and not the base altitude of that one cloud layer you are utterly confusing yourself. You should not pick out "C288" by itself, it is part of a structure defining a cloud layer, and that cloud layer contains some turbulence information. If the aircraft was in that layer, that turbulence information would affect 0E88. In fact the code in FSUIPC to set 0E88 loops along the number of cloud layers checking the aircraft altitude with the cloud altitudes in order to set that value. (Here it has to use an estimate of the cloud height, based on its type, because, alas, FSX does not supply this detail). How may more ways can I explain it? you seem not to understand the New Weather Interface data structures. Sorry they are only provded in C/C++ terms, but surely they are still reasonably clear? Pete

Yes of course, if there;s room. The complete list of Lua files is read each time. The only reason a new one won't show is when the list is full. Only 127 can be accommodated for assignments. Pete

What's wrong with that? C288 is the first cloud layer entry (out of 16) in the weather table "at the aircraft". Your aircraft is on the ground. Is the cloud layer on the ground? You are making no sense! 0E88 is in fact derived in FSUIPC by it scanning the cloud layers to see if the aircraft is in one and if so that shows its turbulence value. So 0E88 will only reflect the layer you are in. Why is that a "discrepancy"? I get the feeling you completely misunderstand something here. There is only one source for all these values, the METAR string read from SimConnect, which you can easily monitor yourself. The weather tables and all the weather offsets, EXCEPT the X/Y/Z wind components at the aircraft, are derived from that one source. Why do you think this results in "discrepancies"??? :-( They are not standard METARs. You need the SDK reference. The length is the length of the METAR string (obviously?), the spurious layers removed are layers which are identified as "spurious" because they are very very thin (sometimes zero feet), or feature almost exactly the same values. These sorts of rubbishy METARs settings don't normally occur if you are using default weather sources, but they do get generated, and get worse and worse, when using external weather programs -- unless those programs use the only really safe weather setting mode, "Global". The spurious layers generate because of bugs in the FSX weather interface. Pete

There is nothing in FSUIPC which prevents batteries being turned off and there never has been. Something else is doing that. There isn't even any option to do that in FSUIPC. If it is different with or without FSUIPC running it is because you have something installed which is dependent upon FSUIPC. The battery life extension option is not at all related to the battery switch. It merely maintains voltages, or lets them lessen more slowly according to parameter, when the battery switch is on. It cannot possibly stop the battery switch being turned off. Pete

BTW, I don't know why you are using a function, unless it is for programming practive. Your program: --Plays the master caution warning WAV file when the test button is pressed-- function warn(warningchime) Sound.play(warningchime) end warn("E:\\Program Files (x86)\\Microsoft Games\\Microsoft Flight Simulator x\\sound\warningchime.wav") is actually identical in effect to: Sound.play("E:\\Program Files (x86)\\Microsoft Games\\Microsoft Flight Simulator x\\sound\warningchime.wav") and to play it three times you could just do: Sound.play("E:\\Program Files (x86)\\Microsoft Games\\Microsoft Flight Simulator x\\sound\warningchime.wav") Sound.play("E:\\Program Files (x86)\\Microsoft Games\\Microsoft Flight Simulator x\\sound\warningchime.wav") Sound.play("E:\\Program Files (x86)\\Microsoft Games\\Microsoft Flight Simulator x\\sound\warningchime.wav") Pete

There are no files of mine called "FSUIPS", so it sounds like you are looking for the wrong thing. If there are no copies of FSUIPC.DLL in either the FS Modules or the main FS folder, then it cannot possibly run and therefore cannot possibly give you any message. If there is a proper installation of FSUIPC.DLL in the Modules folder, and nowhere else, then the only reason you can possibly get a similar message (referring to FSUIPC, not FSUIPS) is that FS9 is still actually running from the previous session, so there's an FSUIPC still in memory. This can happen if something is preventing FS from closing normally. Check via the Windows Task Manager, and if necessary delete the FS9.EXE process. If FSUIPC.DLL is actually running without existing anywhere then it is either some sort of miracle, or you have more than one FS installation and you are looking in the wrong places. Regards Pete

Why? It would be easy enough with a Lua plug-in accumulating say 100 values over a given period and doing a little calculation. Were you IN the cloud with the turbulence at the time? If you have questions about what weather is coming from where, try the weather logging facilities in FSUIPC (logging tab). You'll see that actual METAR strings being received as well as their decoding. There's no way. Every piece of data is obtained in whatever way is necessary or most efficient. It is different in every version of FS and different for most of the values therein. The documentation of how it is done would be pretty much the entire source of the IPC interface in FSUIPC. What is it you need to understand other than FSUIPC obtains the data which is documented? In FS98 it was not even mapped. FSUIPC like FS6IPC before it merely was merely a portal into a DLL in FS called "GLOBALS" (only 2kb's worth then), which handily stored everything anyone wanted into or out of FS. Nice and simple. Then FS2000 came alone and most was still that way, but some data became hived off into different modules. That's when "mapping" started, bringing disparate areas of FS memory into one imaginary memory sequence. That continued into FS2002, but much of the data then became unmappable because it either didn't exist as such, and had to be derived or obtained via procedure calls, or it was part of some almost impenetrable "black box" which I had to hack into to find the right places to hook code into to get stuff. All this rewriting in FS, from nice straightforward assembly code to tortuous object-oriented C++ "classes" (black boxes) cam to a head with FS2004 which cost me many many 100's of hours of work and brought me to the point where I was ready to give it up. But then Microsoft appeared to realise the benefits of the sort of thing I was doing and called me over to Seattle to discuss it. That's when "SimConnect" was born and releived me of most of the hacking I would have otherwise have baulked at. Now probably 90% of the data in FSUIPC4 offsets, other tthan that related purely to FSUIPC facilities, is derived from SimConnect variables, asynchronously (because that's how SimConnect works), and kept for synchronous application access in FSUIPC memory (now 65kb). There is still some hacking, but much less than in FSUIPC3. So, if you want to know more about the data and where it comes from and how, best take a look at the SimConnect SDK. Regards Pete

Either loop on the Sound.play three times or simply make three copies of that line. It would, however, be more efficient to make the WAV longer with the three copies included. I don't know what you are doing. You don't even have to exit FS let alone re-boot! Just press one of the "reload" buttons on the Buttons, Keys or Axes tabs. Pete

If there's no message asking if it is okay to load it, then SimConnect must already have read something which tells them not to. In the days when FSUIPC4 was signed this would have been by the Publisher (SimFlight) being already listed as "untrusted" in the Registry, as seen in Internet Explorer. But with an unsigned module it doesn't know the publisher, so that can't happen. It can only really happen due to a reference in its FSX.CFG. So your experiences are absolutely puzzling. Does the SimConnect log show any reason why it won't load it? (See the FAQ subforum for a thread about enabling the SimConnect log). Well, being signed that won't generate the prompt as to whether you want to load it or not, but it is subject to the publisher being trusted -- and the signature being valid. One day GlobalSign will maybe catch up and get the revocation actioned. I can't support older versions in any case. The signature omission should make things simpler, less error prone, not more so. Very few add-ons are signed, so FSUIPC now just joins the rest. And do I understand you've already tried a SimConnect log and it doesn't even mention FSUIPC4? That's as if it isn't in the DLL.XML and therefore is simply not even looked for. Me too. GlobalSign, the signature authority, said the revocation would take place within hours. It happens through Microsoft updates, so maybe it takes longer. Someone also said the publisher updates only occur once a week. However, I've been accepting all windows updates on my test PC ever since and the revocation still hasn't occurred. Makes me feel like a fraud, so I'm not happy about it! However, the only reason we went this way is that somehow the signature was being used by rogues to sign virus laden installers, giving SimFlight a bad name. That's supposed to be prevented by the revocation. If SimFlight feel strongly enough about it I'm sure they'll chase GlobalSign about it -- that would happen if there were more accusations about malware. ...as of course it should have done weeks ago! Regards Pete

You'd need to measure the frequency and amplitude of the fluctuations to determine the strenght of the turbulence. I really can't think of any other way. Perhaps start by measuring the peaks and their frequency. I see you misunderstand. Not since FS98 days have the offsets actually mapped into real FS variables. All of them in FSUIPC4 are part of a data area inside FSUIPC which is populated by reading SimConnect variables plus a lot of derived values computed for compatibility with previous FS versions. Yes, but it seems you will have to do it by analysing the results. You are not provided with some simple measure, which probably doesn't exist at all in any case. Doesn't it say that? Except at weather stations you can only read, from Simconnect, the specific weather at a particular position -- Lat, Lon and Altitude. You can ask for that anywhere yourself. The automatic reading of "weather at altitude" is from the same sort of request to SimConnect as that but with the aircraft's Lat/Lon/Altitude. It is that data which is used to populate most of the other "at aircraft" weather offsets. Of course it comes from SimConnect as a "extended" METAR string, and I'm pretty sure it won't contain anything about your thermal effects. So, what isn't actually clear? I don't really know what you are confused about. Regards Pete

Are you using FSUIPC for your buttons? You can assign buttons to the autopilot control in FS itself, or in FSUIPC. All 'Z' does is send the autopilot toggle control to FS, just as your button could do. In FSUIPC the autopilot toggle is called "Ap master". I don't remember what it is called in FS, but just look down the list till you see what the Z key is assigned to. Of course, using FSUIPC, you could also make your button send the 'Z' key, but this is less efficient that assigning directly to the control you need. Regards Pete

Yes, but no facility to read those settings at all. I expect you can only read the result, which is most likley in those wind elements I mentioned. Well, not strange to me, because I don't think it is a function of the weather engine, which is striving to reproduce only the weather from the METARs. I think the thermal facility is coded just as an 2effect" on the aircraft, probably via the local wind X Y Z components. Certainly it is by using these that such effects have been obtained by add-on programs, like those doing catapuld launching and arrestor cables. And some of FSUIPC's own turbulence effects (used when wind smoothing kills the FS ones) acts using these three values. I think you are wrong there. Certainly it would not manifest in the prevailing wind data at all, but I'm talking about the active wind X Y Z components at the aircraft -- it is those which makes the aircraft shake in the different directions. These are simulation values not weather values. Regards Pete