Pete Dowson

Any FSUIPC log, any SimConnect log? Please, I need help to solve this, if it can be solved at my end. Pete

I've given up on the FS2000 crash in the options. It's something to do with the video mode. CFS2 which has exactly the same code is fine, it's just the attempt to overlay FS2000's screen with the options dialogue which causes a crash and it is deep down, about 16 nested calls in FS deeper than fSUIPC. I'm taking your advice. I've changed the Installer to only install for FS9 or FS9.1 (the two variants of FS2004). i'm withdrawing support for FS98, CFS1, CFS2, FS2000 and FS2002. It just isn't possible to support these now. Version 3.999w includes these changes. I've asked Mr. Schiratti to change the wording on his "Peter Dowson" page accordinlgy. Thanks for the heads-up on this, and apologies for the inconvenience it caused you. Regards Pete

If it is already loaded and therefore running, no, not really without its cooperation. If you forcibly unloaded it whilst it was running and had links into things it would simply cause a crash. I doubt that forced unloading would work when a program is actually running in any case. If it has a Windows procedure of its own and is processing messages then you might be able to get it to close up shop by sending it a WM_CLOSE or WM_QUIT message, but it is most unlikely that it would have its own (it will simply hook onto the main FS Windows Procedure0, and even if it did it may not act on such a message anyway, or may forward it on to FS so closing everything. This is only a "cooperative level" flag in one or other of the DirectSound calls FSX is making to Windows. You will notice that the Lua sound library I implemented has an option to play sounds whilst the focus is lost. it is not hard. To make FSX sounds operate so there would be two ways possible i think: 1. Find where, in the code, it makes the calls and patch the data it is sending to set the options correctly, or 2. Hook the calls to DirectSound and modify the parameters on-the-fly The latter would be relatively easy for 'normal' function calls into Windows DLLs, but the sounds are using a COM type interface, where these's only the one function call directly hookable (the one to create the COM object. The call to play a sound, and which features the flag (DSBCAPS_GLOBALFOCUS) which causes it to be focus-bound, is a virtual function call, using the table of functions provided via the object pointer. So it gets very complicated. The former would involve trying to analyse the code (maybe all in FSX's "SOUND.DLL"?) to see where the parameter for the call is formed and patching that. It's actually removing a bit that's needed -- the 2^31 bit, 0r 0x00008000, in the Flags for the DSBUFFERDESC structure passed to the object's IDirectSound_CreateSoundBuffer function. Analysing code using these indirect methods is no fun and can take many many hours with no guarantee of success. Regards Pete

I'm afraid I don't know VB.NET, and this way of using SimConnect is not familiar to me. I think anyway you have posted to the wrong Forum -- this Forum is for FSUIPC and WideFS support, not SimConnect. There is a SimConnect forum over in AVSIM I beieve. Regards Pete

I think the only difference is in where in the 0-16k range the changeover occurs from one position to another. There are positions which work for both -- I had to work them out in order to provided the flap detents calibration facilities in FSUIPC. I don't understand your terminology though. What do you mean by "servo-stearing" (do you mean "steering"). Why would servos come into flaps setting? It is nothing to do with FSUIPC. The offsets read from the PMDG NGX for READING of values finish at 661F. You have something else running which is setting or reading 66F2. All the range 66C0-66FF is available for general use by other programs, none of those are set or read by FSUIPC. And I say again, because you did not understand nme before it seems, the offsets listed in "Offset Mapping for PMDG 737NGX" are for reading, not writing. They are read-outs, not controls. The controls are by numbers, as listed in the PMDG NGX SDK header file. You misunderstand still. If 66F2 works for you to set the airspeed then it can only be because some other program or plug-in you are also running is reading that and sending it on to the PMDG aircraft using the correct control. There is no other way I know. Apart from your use of "servos" for flaps, which i don't understand (servos are little motors used under digital or sometimes analogue control to move things like levers, wheels or pointers)., I did understand your question, and I still do. i think that you need to use the controls to control the PMDG 737NGX. You can of course use offsets to send controls -- 3110 is used to send any control, by number, with a parameter in 3114. Regards Pete

I've managed to get FS2000 running on another PC, with XP-32 bit. I can get into flight mode and it works okay then, but it does crash a while after I enter FSUIPC Options . I'm investigating now. This may not help with FS98 though. Back later ... Pete

I've re-arranged some of the start-up code in FSUIPC so that it does more of its initialisations when the DLL is loaded (when entered automatically by Windows actions) rather than when SimConnect actually calls it. Maybe this will avoid whatever is clashing. It is worth a try in any case. Please download FSUIPC 4.844a and try it. Let me know please. Regards Pete

Not upset, rather puzzled is all. The Schiratti site is not mine and I don't have free access. I post all interim updates to the Download Links subforum here, in this place. I don't do fully revised documentation and Installers for every release -- there have been an average of at least one new release every month for the 14 years I've been doing this. So 3.999s is the last full installer+dox release, interim releases are posted here. I cannot make anything go wrong with it in FS2002, as i said. I don't know how to reproduce your symptoms, and have no code in FSUIPC which deals with views or graphics in any case. There's something else going on with your system which I don't know about. As for FS98, I'm afraid i've lost my copy of that. But it works fine in CFS2 for sure, and really anything before FS2002 is treated identically. However, I would be able to check the FS98 problem a bit if I could at least see logs and Windows error reports so I know where it is crashing. This needs to be with 3.999s though so it matches the current code state. No version of FS requires FSUIPC to function properly! Folks install it because they want to use it for something! I don't know what you are getting at here. Only CFS3 had no Modules folder. CFS1 and CFS2 have a similar folder structure to FS98 through FS2004, with most of the FS DLLs in the MODULES folder. I think you are mistaken there. And of course Microsoft were never making products dependent upon my program to function correctly! I don't understand where you get such a notion!? FS98 was only supported by FSUIPC for two reasons. First as a means of determining how to support FS2000, and second as a supported version of FS6IPC.DLL (which was the original FS98 add-on module) after its author stopped working on that and was recruited into the FS team. FSUIPC most certainly is NOT needed for any reason I am aware of in FS98. FSUIPC1 came out after FS2000. Everyone needing add-on support in FS98 used FS6IPC. The INI file is not touched at all by the Installer. It can pre-exist or be created as new, but that is done by FSUIPC after loading. And there are no entries in the INI file related to views or graphics. Hopefully, stop FSUIPC3 development before then. It was never supposed to be developed more than 2 years after FSX came out in any case. FSUIPC4 for FSX then FSUIPC5 for FSXI, etc. I don't mind maintaining two versions for a couple of years, but FSUIPC3 has to be frozen. It's just that i'm soft and cave in to folks' requests too easily. ;-). I hope to freeze FSUIPC4 soon s well, excpet possibly for support for Prepar3D Version 2 if that looks possible. If they change to 64-bit I will have to move on to FSUIPC5 for that. If I do continue after 3.9999z I will start with double letters in the displayed and printed version numbers -- it's just the Application readable version which can't go beyond 'z'. Pete

Double check your use of the free user offsets. I just noticed you have both of these: ipc.writeUW(0x66C0,value) ipc.writeUW(0x66C1,value) [/CODE] [font=arial,helvetica,sans-serif]The writeUW writes an unsigned WORD (2 bytes), so the write to 66C0 overwrites the low byte of the Word at 66C1. You either need to change to "writeUB" to write only one byte (8 bits) -- which is okay if the range of the value doesn't exceed 0-255 -- or choose offsets at least 2 bytes apart.[/font] Regards Pete

Right. It does sound like some sort of clash in SimConnect's loading sequence. Nevertheless I will, today, look at my code in more detail to see if I can do anything different in the very small sectiion of code leading to the Log being created -- there isn't a lot, but naturally there is the code leading to the log file being opened. All past researches have led to the conclusion that no code at all was being executed, but I've not before met the case where the Trust check was definitely completed beforehand, as it was in your case. They may be trying to deal with the case where FS is installed in the Program Files folders, which are protected against writing unless things are run "as administrator". Many add-ons don't deal with this. FSUIPC actually changes the read/write permissions on the Modules folder so that it can write its LOG, KEY and INI file and so you can install Macro and Lua files there when needed. So, that will only do the version for the most recent SDK you downloaded. If that was SP1 or SP2 there will be one or two other SimConnect.msi files in the "LegacyInterfaces" subfolder in the SimConnect SDK. Different SimConnect clients use RTM, SP1 or SP2/Acc versions of SimConnect which are all installed side-by-side. I don't know which one BGLMANX uses (the SimConnect log will show), but FSUIPC4 is capable of using any of those, usually selecting the latest. Those SimConnect installers are only really installing the external interface DLLs, the ones called by SimConnect clients and which in turn call the true SimConnect code which is integrated into the main FSX.EXE file. So "reinstalling SimConnect" doesn't really do a lot if the Side-by-Side structure is okay. The only sure way of repairing it if broken somehow would be to for example, uninstall SP2 or Acceleration and re-installing that. Except that it's SimConnect which does the loading and trust verification. The log may show how far that got. I'll get back to you later if I can find anything else to try after examining my code prior to Log creation. That is odd. Or possibly it is related to the driver version? I couldn't use the 301.xx drivers -- they had the effect of permanently reducing my fast video card to it's power-saving or overheat mode and caused FS to crawl. I don't know how video differences can be related to all this except by a change of timings which it could introduce -- i.e. certain things happening earlier or later as a result of other things also happening. Regards Pete

How strange! I am not aware of any clash between those two. I've always had both running in my system. Is FSUIPC actually started? You can tell by checking if there's a Log file produced. If there is a log file, please show it to me. A SimConnect log might also be informative. No, the "persistence" thing is to get past the trust checking. If you've got that version already trusted that particular bug shouldn't occur any more. No. No. The FSUIPC4.LOG, if it is actually produced will tell me whether FSUIPC4 ever gets started, and if it does then I need to see where it has got to. As I said above the SimConnect log could be useful -- there's a thread on how to make one of those in the FAQ subforum. I'm not sure that's a good idea. Why are you doing that? Well UAC is just a nuisance. You shouldn't need to turn DEP off. I never have. The certificate should certainly have already been in Win7. And there's no point playing with the InitDelay until we know whether FSUIPC is actually starting. How did you do that? And which of the three versions? Regards Pete

Okay. So far my progress on checking this, with FSUIPC version 3.999v, is as follows: FS2002:: runs okay. Tried all default aircraft in all view modes, can't make anything go wrong. FS2000: had a job installing this, and it hanges on loading before I've even installed FSUIPC. I think it might be incompatible with Win7-64 despite selecting compatibility modes. CFS2: runs okay with FSUIPC 3.999v (see log below, with weather logging enabled). CFS1: Won't even install on Win7-64. FS98: i'm afraid I've lost my disks so cannot reinstall this. Must have been thrown out in a clearout a while back. If i'm to debug your problem with this I need details, like logs and Windows error reports givng module offset -- but using 3.999v, not 3.999s. Regards Pete Log from CFS2: ********* FSUIPC, Version 3.999v by Pete Dowson ********* Running on Windows Version 5.1 Build 2600 Service Pack 2 Verifying Certificate for "L:\CFS2\MODULES\FSUIPC.dll" now ... SUCCESS! Signature verifies okay! Running inside CFS2 User Name="Pete Dowson" User Addr="petedowson@btconnect.com" FSUIPC Key is provided WideFS Key is provided Module base=61000000 LogOptions=00000001 DebugStatus=255 44797 System time = 07/08/2012 20:23:21 44875 L:\CFS2\ 52031 System time = 07/08/2012 20:23:28, CFS2 time = 20:23:26 (20:23Z) 60563 AIRCRAFT\F4U1A_CORSAIR\F4U1A_Corsair.air 60625 Aircraft="" 65844 SITUATIO\defgnd.flt 66109 Clear All Weather requested: external weather discarded 68688 Advanced Weather Interface Enabled 68688 Not patched ADVDRV.DLL since offsets don't match! 68688 SIM1.SIM patched for more accurate altitude holding 141609 FS98 Pressure=1013.2 mb 141609 FS98 Wind0: ground (56ft) to 99940ft AGL, dir 0M, vel 0, gust 0, turb 0 141609 FS98 Vis: range=60sm, (raw value=6000) 141609 FS98 CurrTemp at PlaneAlt=62: 15C 144469 WeatherOptions set, now 00000001 (timer=0) 144469 LogOptions changed, now 00000013 (LogExtras=1) 144953 ### FS2000 Global Weather Active (allows external control) ### 144969 >Change: FS98 Pressure=1013.2 mb 144969 >Change: FS98 Vis: range=150sm, (raw value=15000) 144969 >Change: FS98 Tstorm: type=0, from 0ft to 0ft (+/- 0ft), cover 0, turb 0, ice 0 144969 >Change: FS98 Cloud1: type=0, from 0ft to 0ft (+/- 0ft), cover 0, turb 0, ice 0 144969 >Change: FS98 Cloud2: type=0, from 0ft to 0ft (+/- 0ft), cover 0, turb 0, ice 0 144969 >Change: FS98 Temp2: to 0ft, Day 0.0C 144969 >Change: FS98 Dewpoint Control: disabled 144969 >Change: FS98 Precip Control: disabled 144969 >Change: Pressure=1013.2 mb (Target is 1013.2) 144969 >Change: surface wind: to alt=100000ft AMSL, dir=0T, vel=0.0, gust=0.0, turb=0, shear=0, var=0.0 144969 >Change: Visibility[0]: range=60.0sm (96561m), from=-1490ft, to=100000ft 144969 *VIS* SM: Min=0.00, MaxRny=10.00, MaxOvc=20.00, MaxCld=20.00, MaxClr=60.00, Upper=60.00, FT: LwrAlt=6000, UppAlt=25000 144969 Results: Visibility[0]: range=60.0sm (96561m), from=-1490ft, to=100000ft 218625 Results: FS98 CurrTemp at PlaneAlt=518: 14C 291656 Results: FS98 CurrTemp at PlaneAlt=502: 14C 337875 Aircraft="" 340188 SITUATIO\defgnd.flt 341172 Clear All Weather requested: external weather discarded 342203 ### FS2000 Global Weather Active (allows external control) ### 342203 >Change: surface wind: to alt=1000ft AMSL, dir=0T, vel=0.0, gust=0.0, turb=0, shear=0, var=0.0 342203 >Change: Visibility[0]: range=50.0sm (80467m), from=0ft, to=10000ft 342203 Results: surface wind: to alt=100000ft AMSL, dir=0T, vel=0.0, gust=0.0, turb=0, shear=0, var=0.0 342203 Results: Visibility[0]: range=50.0sm (80467m), from=-1490ft, to=100000ft 342203 Results: FS98 Vis: range=50sm, (raw value=5000) 342203 SIM1.SIM patched for more accurate altitude holding 347172 >Change: Visibility[0]: range=50.0sm (80467m), from=-1490ft, to=100000ft 347172 *VIS* SM: Min=0.00, MaxRny=10.00, MaxOvc=20.00, MaxCld=20.00, MaxClr=60.00, Upper=60.00, FT: LwrAlt=10000, UppAlt=25000 347172 Results: FS98 CurrTemp at PlaneAlt=62: 0C 350297 Broadcasting Weather Changed: 00004000 350516 Results: FS98 CurrTemp at PlaneAlt=62: 15C 378469 >Change: Visibility[0]: range=50.0sm (80467m), from=-1490ft, to=10000ft 378484 >Change: Visibility[0]: range=50.0sm (80467m), from=-1490ft, to=100000ft 425766 >Change: Visibility[0]: range=50.0sm (80467m), from=-1490ft, to=10000ft 425797 >Change: Visibility[0]: range=50.0sm (80467m), from=-1490ft, to=100000ft 435141 System time = 07/08/2012 20:29:51, CFS2 time = 14:30:14 (04:30Z) 435141 *** FSUIPC log file being closed Memory managed: 0 Allocs, 0 Freed ********* FSUIPC Log file closed ***********[/CODE]

Zotac Amp2 GTX 580 with 3Gb memory running on an i5-2500 PC watercooled and overclocked to 4.8 GHz. i use nVidia inspector to set all the graphics settings ideal for FSX, and the frame rate limiter in that program to 30 fps. That gives me very smooth flying everywhere with dipping down to perhaps 20 fps at places like UK2000 Heathrow with full AI traffic and heavy weather. (20 fps in FSX is better than 20 fps in FS9, by the way). I can run frames unlimited but whilst that gives over 100 fps most of the time it makes it much more varied, and the WideFS links to the other 6 PCs involved in driving the cockpit are better with a smooth supply of data. I've not used FS9 since FSX came out. Far prefer FSX. Might move to Prepar3D if their Version 2 supports DX11 properly. Regards Pete

There's a key to the entries at the front of the document. Yes, sorry -- mis-type. Pete

Really? Not sure how you read that from my words. Thanks, but really I've got no problem with the drivers I have now, only with some later ones -- it's related to the overclocking of the video card. The later driver effectively resets all the clock values to nVidia base defaults, not to the overclocking provided (by default) on this card nor my subsequent extra clocking. It's as if it is swtching to "safe" or "overheat" mode. It appears to happen to a small number of folks, not just me, as far as I've found out via a thread on the AVSIM FSX forum. I'm not worried about it. The drivers I'm sticking with work wonderfully and I get great frame rates and good quality images. It's just that I am used to keeping all my drivers up to date and had to revert this time. I only mentioned it as an example of sometimes needing to chose a different earlier driver rather than the latest to get around a problem. Regards Pete

As a test, make a safe copy of the FSUIPC.INI file, then in the original delete the [MacroFiles] section. Run FS and see if the section is regenerated. If it is then show me the macro file you are concerned with, because if the file is recognised the contents must be bad. Otherwise close FS, and show me the FSUIPC.LOg, the Install log and your current FSUIPC.INI file. You can paste them all into a message here. Make sure FS is closed first. Pete

Even in the FSUIPC4 offsets document (which is for FSUIPC4 not FSUIPC3) it lists that offset as being not operating. The "No's" do appear in the right hand two columns. Take another look! Yes, that's the base reference. The FSUIPC4 one shows the changes or additions for FSUIPC4 (i.e. for FSX, ESP and P3D). Evidently not. But knowing 1 G at Sea Level is 32 ft/sec/sec it isn't a hard conversion. There is also a G force offset somewhere, but i don't think that's so accurate. Regards Pete

No, not at all. I just answer your questions and hope I'm helping. Why do you think I'm offended? Not all nVidia drivers are bad, and the recent ones which are bad for me are working extremely well on other folks' systems. It's complicated. And I'm afraid i don't know about the ATI etc ones at all. Sorry. Pete

But the event.lvar function was not added until update 4.841! The current interim update is 4.844. See the Download Links subforum. Pete

The very latest nVidia drivcers are a mess, actually, at least on my system (they reduce FSX frame rate by about 75% on my system). I had to backtrack. So it isn't necessarily "later" I mean by "new", but "different". Alt+Enter switches back and forth. Pete

Dates in my country are always day/month/year. But where are you thinking dates are "recorded"? I don't understand your reference I'm afraid. You never said anything about "wrong dates", at least not in this thread! [LATER] Ah -- you mean your comment in red later in the Log file? Sorry, didn't see that. If the log was for 6th August, isn't it obvious that the date is correct as day/month/year? As an English made program it is naturally going to be that way in any case. Pete

So the macros are in the folder, and listed in the INI file, but, what ... not listed in the assignments dropdowns? Can you explain what you actually mean by them notbeing 'found'? No. Replacing the same stuff by the same stuff will change nothing. If things are missing but still there then there is obviously a mystery to solve. i need to know now what you actually mean, please. Have you actually tried assigning to any of them, for instance? Regards Pete

Did you download new drivers or use the one supplied on a CD with the card? As I said, there is nothing that can be done in FSUIPC. It is a graphics incompatibility between FS and full screen mode which is only fixable with drivers. If you refuse to try other drivers, just switch to windowed mode to access the options. I think Windows automatically sets it into compatibility mode because it sees it is not a Windows 7 program and doesn't obey Windows 7 rules. FS9 long predates this operating system. If you installed it into the default "Program Files" folders it will also be aliassing the folders because all Program Files folders are protected from being written to even by the programs installed there. Win Vista and Win 7 programs are supposed to put all changing data in "ProgramData" and "AppData" folders, like FSX. Pete

I'm very surprised you found no mention as it used to be a very common problem. This is ALWAYS due to bad or out of date video drivers. You can either try to fix it by updating or changing video drivers, or by using FS in Windowed mode instead of full screen (or by just changing to Windowed mode to access the menu, then back again afterwards). No. The email address is not used as an email address, only as a means to identifying you more uniquely. Names are not unique, believe it or not! You could use your house address or something else like age and mother's name, but the sales website is only geared up to use email addresses and that makes it a lot more straight-forward. But your FS is running in XP compatibility mode. That identifies the operating system as XP as far as FS9 and FSUIPC are concerned. Pete

Certainly sounds like you are using a version of FSUIPC which preceded the event.lvar function addition. Check the FSUIPC log -- it will log the error in the function is not there. Pete