Pete Dowson

No. not really. All the included PM controls do is use the facilities in PM -- as documented on the PM website. If there is no "toggle" then there isn't one to map onto in any case. The best thing to do in such cases is either to use the button flag facity to conditionally change what your button does on alternate presses, or to use the Offset controls provided to alter the PM offsets directly. After all, the listed PM controls merely map directly through to PM offsets, nothing more. Pete

My email is petedowson@btconnect.com. But I won't be in a position to discuss anything now till my return on January 9th. Pete

Sorry if you think it was "rude". I see nothing rude. I just state what is the case, plain and simple. Assuming you mean a "joystick buttno" not a "joystick key to a button" (because I cannot make sense of that), then that is exactly what "KEYSEND" is all about, and it is documented in the WideFS documentation. No. How would you for a button? Please re-read the chapter on assigning in Buttons and Switches, because the drop downs operate exactly the same there as in keys. The only difference is that you can choose to assign keystrokes on one side or controls on the other. Assigning controls is via the drop downs in he control assignments side. I honestly cannot imagine how you cannot see this. It's a first, really! Pete

No where did you mention FSX nor FSUIPC! Look back at what you posted! Why think that was clear? Pete

Not sure why you posted here. Are you alking about FS? In which case which version? In FS9 and before you simply set your default start-up flight to "Previous Flight" which is saved when you close down. In FSX you'd need FSUIPC which saves Previous flight for you because Microsoft forgot to do it. Pete

Sorry, that is not my gauge. I've never made any gauges at all. I thoink you need to look elsewhere. Pete

Why the recycle bin? 4.60 is out of date and unsupported. Please use the current version, 4.674. The "current folder" probably needs setting by your VBS file, unless you are running it from that folder (not sure about that though). If you make a shortcut to a program you will see, in the Properties of that short cut, both the Link to the program itself AND a path, labelled "Start in". Normally you want the "start in" path to be the same as where the program is, but not always. MakeRunways needs to "start in" the main FS folder so it can identify the version. In DOS terms the "start in" folder is the "current folder" and is set by a command like CD. I don't know how it is done in VBS. As for thinking it is FSX, all MakeRunways is doing is checking for the presence, in the current folder, of these EXE files, in turn: Prepar3D.exe ESP.exe FSX.exe If none of those are present it assumes FS9. (If Prepar3D.exe is present it reads its version number to see if it is 1.x or 2.x). It seems yu must have some such exe in whatever is the 'current path'? This then determines where it looks for the SCENERY.CFG file, which for FSX should actually be in the ProgramData\Microsoft\FSX folder. Pete

I don't know what sort of mess your system is in, but there is no way any recent Installer will be able to put an 20 month old version into your FSX folders. It sounds either as if you have more than one FSX installation and you aremixing the two up, or you are using the wrong installer altogether. I suggest you do a search of your system for old copies of the FSUIPC4 installer and delete them , for starters. Then see about sorting out the FSX folders. I note you've not bothered to show the Install log. The only way it can possibly get there is if you, or someone else using your PC, put it there from the Installer ZIP file. There are three or four files there, the Installer, the installation instruction document, often a "changes" document, and the Loader DLL. You probably blindly unzip and copy everything without reading the instructions. Pete

I don't know VBS, but the first thing to do is view the file called Runways.txt which is produced. This is a complete log of what it did. Most importantly it will tell you which "scenery.cfg" file it used to locate the sceneries. It determines this by firstly identifying the version of FSn/ESP/P3D from the relevant EXE in the current folder, so determining the correct path to the Scenery.cfg folder. Pete

The trouble is that you don't actually say how this is done now. What actions do you do now which are different from that list? There is no problem with pressing key combinations and keys in the way you want, but if those keys don't do what you want, what's the point? I tried to explain this lack of information last time. You want key presses to do something, but it's that something I would need to know. How do you do that something at present? That would just be by having the Ctrl+Shift+H combination set a Flag, which is tested for the other actions. But flags and compound buttons are for button assignments, not keypresses. And in any case, surely it should not be needed? Somehow whatever the keys do when you are doing it normally must be switching modes in any case, but until we know how and what that mechanism is there's no way to work out what you want to do. Compound buttons are for buttons. You are using a keyboard. I suspect, at this stage, it would be better to read about the aircraft mechanism you are trying to use, and describing it here so I can understand what currently possible action you are trying to accomplish differently. [LATER] I've been trying to think how I might help even without knowing what the end result of the key assignments is intended to be. Just purely on the subject of "conditional keypress", there are only two ways of doing that. either using a Lua plug-in program, or by setting a value into an FSUIPC offset (by assigning to an Offset Byte Set, or more likely in your case, Offset Byte Togglebits control with a parameter of, say 255), then have two key assignments for each of your NumPad keys, one testing the offset for non-zero and the other for zero. for example, suppose you used the free user offset x66C0, preceding the key assignment encoding in the INI by B66C0=0 then a space, will make the key assignment only operate when 66C0 is zero. B66C0!0 does the opposite. Thus you have two different key actions depending on 66C0 which you can reverse (0 to 255 to 0 etc) using your other key combination assigned to "offset byte togglebits" with offset x66C0 and parameter 255 (or xFF). Of course 66C0 needs to be zero to start with, but it will be unless you have something else already using it. Regards Pete

I don't have any "download site" apart from the Download Links subforum injust above. It looks like you've installed the FSUIPC4 Loader DLL. Why did you do that? As mentioned in the Instructions it is just a possible way round certain very unusual clashes which cause FSX to crash on loading. It has no bearing at all on cases where FSUIPC is not even being loaded. Please remove that and run the Installer again. If it stil doesn't load we need to find out why. Try to get a SimConnect log -- see instructions in the thread in the FAQ subforum. Also check the [Trusted] section of your FSX.CFG file and delete any FSUIPC4 or FSUIPC4_Loader entries -- you may have denied Trust at some point, and this is remembered in the CFG file. Pete

Where did you go to get this bad download? there's no whaere I know of. the best source s are here, in the Download Links subforum, or over in the Schiratti.com page. Both links point ot the correct downloads. I don't know anywhere you can get 2 year old versions, but if you remember where you went please let me know! As I said, there is never any need to delete the contents of the Modules folder -- FSUIPC's installer simply replaces anything unless it is LATER in date. So either your DLL.XML is corrupt, or Simconnect is hosed. That looks fine. Can you show me the FSUIPC4 Install log? That might be very relevant. Pete

You first need to update to a supported version -- 4.927a or later. I've no idea what that is. Do you know how to do that without using FSUIPC? Okay. Obviously I'd need to know what that is in the first place. How do you do it without FSUIPC? Which keycombination is that? You already pressed and released one combination. Do you mean doing the same thing again? i..e press and release? You've done something already? If you can explain what you actually need to do, i.e. what actual keystroke, mouse operations, or controls, are needed to do what you want to do, then perhaps we can work something out. but I don't know what the output of all these actions is intended to be, so i can't say how to achieve it! If it is possible using other methods, maybe, but you need ot say what those are. Pete

If it is only to set the AP heading then I just tried. As I said, to set the AP heading hold there are two controls: Ap hdg hold and Ap panel heading hold. So, I tried both (as in fact I thought the OP might).. Ap panel heading hold just sets the AP heading hold on or off. It doesn't change the heading itself. Ap hdg hold sets the AP heading to the current heading, and sets the hold action on. Pete

[Moved from FAQ subforum to the Support Forum so it can be answered] I don't know. 99% of those listed for assignment are FS controls, listed from the list provided by FS in its Controls.DLL. Have you tried any? I can see both Ap hdg hold and Ap panel heading hold. I don't think they do the same thing, though it may depend on the aircraft. There are also on, off and set versions of these. If there isn't one to do the job it would be an easy short Lua plug-in to implement it. Pete

Got them. I see that the original one, the one creating the problem, was actually made with the original RTM version of FSX (AppVersion=10.0.60905). Not sure if that is really significant, but things did change quite a bit with SP1 then SP2. Other differences which could be relevant: 1. The Sound is off in your new one ([Options] Sound=False). Maybe a sound driver problem, but this is unlikely. 2. The current camera in the Active Window.1 is different -- I wonder if the old GUID is pointing to a corrupted camera file? 3. The Weather was set in the new one to the fair weather theme, not to real weather. Now bad weather files can definitely cause internal corruption, AND it may well only happen, or happen more often, with FSUIPC running because FSUIPC is constantly asking SimConnect for the weather data so that it can supply this to applications on demand. I'm thinking, therefore, that it is either a corrupted WX file, the onle associated with your old default flight, OR a corrupted Wxstationlist.bin file (in the same folder as your FSX.CFG file). For safety I would delete both if I were you. FSX should create a new wxstationlist.bin, but otherwise just copy over the default one from the Weather folder in the FSX installation. I would have suggested #3 earlier, but the thing which misled me here was the symptomyou were getting. The most usual thing to happen with couurpt weather data is an FSX crash, pure and simple, and soon after loading. Regards Pete

So FSX actually hung, you could not close it? Because if FSX was closed the log would show this. And how is the second message, where you showed a newly started Console Log, related to the first? You managed to enable the console log in the options even though you could not open the options? It does not make sense, don't you see? You seem to have only answered some of my questions, not all. For instance in the second posting SimConnect had most definitely hung. Was that the only time? And why show the console log, why not the log in the folder which must have the same data as it is written there first? There is nothing in a FLT file that can directly affect FSUIPC. The problems were certainly in SimConnect -- a missing message from it, and a complete hang. I don't know if there is anything in a FLT file which could do that. I don't know if I'll have time to look, but, yes, do post both the original and the new FLT files. Regards Pete

First, please update your WideClient -- 6.94 is pretty old now. The oldest supported version is 6.995. The Client is not receiving any Broadcasts from the Server. This may be because you have the two PCs in different workgroups. The Client log is only half of the story in any case -- there will be a WideServer log in the FS Modules folder, if FS is running and WideFs is enabled. Please do take a look at the network configuring assistance in the WideFS User Guide. You can provide WideClient parameters so that it isn't dependent upon working broadcasts if you really need separate workgroups. Pete

I'm a bit puzzled by this. I see the second Menu opening here: 101931 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 101931 Ready Flags: Ready-To-Fly=Y, In Menu=Y, In Dlg=Y 101931 ### MENU: ST_DLGMODE received, stt->dwInteger=1, dwMenuEvent=15 101931 ### MENU: ST_DLGMODE: fInScanJoy=0, fInOptions=0 103147 ### MENU: PropertySheet call returned 1 103225 ### MENU: ST_DLGMODE: ending dialog mode 103662 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N Then the third one, the one which did not work, 6 seconds after you closed the previous one: 109949 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 but the following two lines, occurring 2 and 4 seconds later, both indicate the same SimConnect event being received by FSUIPC before it has a chance to open the dialog. Did you only click the menu once, or three times very quickly? 111946 ### MENU: EV_MENU [15] received: dwMenuEvent=15, fInScanJoy=0, fInOptions=0 113459 ### MENU: EV_MENU [15] received: dwMenuEvent=15, fInScanJoy=0, fInOptions=0 The last line you show shows that Simconnect is actually telling FSUIPC that it is in dialog mode: 116454 Ready Flags: Ready-To-Fly=Y, In Menu=Y, In Dlg=Y but FSUIPC4 never gets the message ST_DLGMODE back from SimConnect which tells it that SimConnect (and FSX) is now ready for the Options Dialog to be drawn. Is there NOTHING in the log following that last line? I can't believe it if so, especially from what you then posted afterwards. Why have you cut the file short? It really doesn't help! :-( In your subsequent message you show part of the Console log instead of the actual Log file. Why? The console log is only a display of what is sent to the log file itself. Did you not check the log file at all after the menu failed? The whole report is now very confused, because: Console Started ... How on Earth did you start the console if you couldn't get the menu to open the options screen? Then this part of the "console log" (which is only a copy of what is sent to the file0: 175220 ### MENU: PropertySheet call returned 1 175283 ### MENU: ST_DLGMODE: ending dialog mode 175688 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N 178668 Starting everything now ... 178683 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N shows the menu opening successfully in any case, before a very puzzling "Starting Everything Now message even though the earlier part already contained: 101088 Starting everything now ... That message occurs only in one part of FSUIPC which is executed just the once. So I can only assume those two log fragments are NOT part of the same FSX session! So, please, can you actually wexplain what you were doing? And why truncate the log file? I really would always want to see the whole log, and not something copied from a console log on screen. Finally, this part: 225983 **** No SimConnect events or states being received! Re-connecting now 226076 SimConnect_Open succeeded: waiting to check version okay 236076 **** No SimConnect events or states being received! Re-connecting now 236170 SimConnect_Open succeeded: waiting to check version okay 246091 **** No SimConnect events or states being received! Re-connecting now 246185 SimConnect_Open succeeded: waiting to check version okay 249555 Memory in use: 1396Mb, Avail=2700Mb 256122 **** No SimConnect events or states being received! Re-connecting now 256216 SimConnect_Open succeeded: waiting to check version okay 266200 **** No SimConnect events or states being received! Re-connecting now 266309 SimConnect_Open succeeded: waiting to check version okay definitely shows that SimConnect has hung. Something in your system is wrong. I suspect SimConnect corruption, or else it is getting mired in some other application which is stopping it responding. Please PLEASE PLEASE always show me a complete Log file in future, one from beginning to end, not fragments. I'm not sure what to suggest for your next step. You could try to get a SimConnect log. There's a thread in the FAQ subforum which explains how to do that. This may well show what other things are going on which could do something like cause SimConnect to stall. However, it will be a large file, so you'll need to ZIP it up and email it to me (petedowson@btconnect.com). However, please now don't expect much before Christmas, and maybe not a lot after, until January 10th, as I'm away. If you wat to try to fix things yourself then the first step would be to rename your DLL.XML and EXE.XML files, re-run the FSUIPC4 installer so it generates an DLL.XML which only runs FSUIPC and no other SimConnect add-ons. Then add the SimConnect add-ons back one at a time. Or you could do similar by editing the DLL.XML and EXE.XML files if you know how. Pete

Okay, good. I know 4.927 crashed EXACTLY as per your original post when running with SP2, and that was the precise problem fixed in 4.927a and of course 4.927b, as in fact your success now proves. If it crashes at all it is 100% consistent because it was due to a hook in the wrong place in SP2 (okay in Acceleration -- the two API.DLLs are different). So, I think you'll be okay, and I suspect the original post was a mix-up and actually using 4.927. However, if you do get a crash do post both the Log file and the Windows crash data. Thank you, Pete

Well of course you can get around that by deleting or renaming the DLL first. However, the difference between a and b is very small and related to a very very old bg which only semed to matter with one specific INI file so far. Certainly the error you mention is exactly the one which occurred in 4.927 and was fixed in 4.927a. But as a test you can of course try the original work-around -- setting the InterceptTextMenu parameter to 'No' instead of 'Yes'. However, before you do that please paste in the failing FSUIPC4 LOG file so I can see what is going on. Also I need to know what version of FSX you are using. Full control? Of what? FSUIPC4.DLL is loaded as part of FSX. It is the process which has permissions, not one small part of it. Regards Pete

The problem is a corruption in the part which is supposed to be loading something called "FeelT". I guess there's a chunk mussing -- it's probably supposed to be a FeelThere product. To get the file working you need to delete these lines: <Launch.Addon> <Name>FeelT </Launch.Addon> But then you will need to see about reinstalling whatever FeelThere (?) program it was. I really don't like XML. One error in the formatting results in everything else following being ignored. In this case it's the lack or a closing </Name> tag, so the XML process simply can't work out what is going on and gives up/ Regards Pete

Ouch. What happened to the new lines and all the < and > characters which are so important? Has the editor you used done that, or is it really like that? I don't even see FSUIPC4 mentioned either! Here's mine, for comparsion: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>Object Placement Tool</Name> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Mission Creation Kit\object_placement.dll</Path> </Launch.Addon> <Launch.Addon> <Name>Traffic Toolbox</Name> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Path>E:\FSX\SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll</Path> </Launch.Addon> <Launch.Addon> <Name>Visual Effects Tool</Name> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Special Effects SDK\visualfxtool.dll</Path> </Launch.Addon> <Launch.Addon> <Name>Flight Recorder</Name> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Path>Aerosoft\Flight Recorder\AS-FlightRecorder.dll</Path> </Launch.Addon> <Launch.Addon> <Name>FSUIPC 4</Name> <Disabled>False</Disabled> <Path>Modules\FSUIPC4.dll</Path> </Launch.Addon> </SimBase.Document> If you can't post a readable copy with all the characters intact, try renaming it then rernning the FSUIPC4 installer. It will generate a clean one with only FSUIPC4 listed. If that works then it is definitely your DLL.XML which was at fault. But I can't figure out why from what you posted above. BTW you didn't say if your P3Dv2 was okay. BTW, looking back at the Install log, you did have one failure: Looks like you had the User Guide open when trying to install. you'll need to make sure you don't have open files when you install. Pete

And does it work okay in P3Dv2? The Install file looks okay, but the lack of an FSUIP4.LOG file means that FSUIPC isn't being loaded. The first suspect is the DLL.XML file which may be corrupted. Despite its filetype this is an ordinary text file, so see if you can paste it here. You'll find it in C:\Users\Colin\AppData\Roaming\Microsoft\FSX\ Pete

Not sure what your "module" button is. Do you mean "Add-Ons"? What changed yesterday? If FSUIPC4 cannot add its menu via Simconnect it either means FSUIPC4 is not actually being loaded and run, or it is being loaded but is failing to connect correctly to SimConnect. Check for an FSUIPC4 Log file in the Modules folder. if one is being produced each time you run FSX, then FSX is being loaded and ryun. Show me that log (you can paste it here). If no log is being produced then FSUIPC4 is not even getting loaded, which either means it isn't in the DLL.XML file correctly -- a reinstall should fix that unless the DLL.XML file is correct -- or it means your Simconnect installation is corrupted. You fail to mention the version of FSUIPC you are using. that's always important to know. Another log file which might be helpful is the FSUIPC4 Install log. Paste that into a reply too. Pete