Pete Dowson

It sounds like the throttle lever is repeatedly sending a different (non-negative) value to the PC. The throttle values will override the F2 (which after all is only the "throttle decrement" control -- subtracting a value from whatever the throttle is set to). If the lower part of the throttle axis has not got a small "dead" or "null" zone it could be still sending changes. There's nothing else I know of that could do this. FS does not have a separate control for reverse. It is literally just a negative value for the throttle setting. The "throttle incr" (F3) and "throttle decr" (F2) controls are capable of moving the throttle all through its possible range including reverse -- as, of course, are FSUIPC's separate engine throttle axes if you don't set NRZ ("no reverse zone"). Pete

You control your taxispeed with throttle and brakes. At the limit your maximum taxi speed is your takeoff speed, in whatever configuration you are in. How reckless are you wanting to be? I certainly don't understand where FSUIPC or anything other than your own controls comes into it. Can you explain yourself? Pete

There are two ways which come immediately to mind. The first is by using the range assignments in the FSUIPC axis assignments, on the right-hand side. However, I'm not sure this wil really do the job, as you need each of those ranges to send a variable -- something based on the parameter (the axis input value). That's rather difficult to arrange. The other way is to use a Lua plug-in. You assign the throttle axis to a Lua plug-in you need to create first, and it receives the input axis value as "ipcPARAM". It can then do what it likes with it and re-transmit it as the parameter ot the appropriate FS throttle control. I'm afraid I really don't have time to do this for you, and I am really bad at tutoring. But take a look at the Lua documentation and ask questions. I'll answer them as best I can. Regards Pete

The latest interim versions of FSUIPC, 3.989u and 4.647, feature 256 flags per Lua plug-in, and extra ipc library functions to set, clear and toggle them individually. I should point out, though, that the solution to your specific problem, i.e. would surely have been to use "luaToggle" to change the flag rather than set it or clear it specifically? The event.flag function detects any change. Regards Pete

Okay, this control is now implemented in FSUIPC versions 3.989u and 4.647, available now in the Download Links subforum. Regards Pete

As I said, one never requires to. Just don't try. Pete

Joystick #3 being the Saitek, or something else? For a button to be stuck showing all the time it must be constantly switching on and off, indicating a faulty device or connection. Which device and which button is it? Button 8 in the FS assignment dialogue is the same as a button 7 in FSUIPC (FSUIPC counts from 0, like windows, not from 1 like FS), so confirming the fault. It isn't FSUIPC or the INI, but whatever device is causing the problem. However, FSUIPC does provide a facility to ignore faulty buttons (whereas FS doesn't). It is documented in the Advanced User's guide, in the section on Button Programming, about 5th para down. The parameter is "IgnoreThese" and you provide a list of j.b pairs. In your case: IgnoreThese=3.7 This goes into the main [buttons] section of the INI, beflore loading FS. Pete

It has gone because it is no longer needed. Application registration was removed a long time ago. Regards Pete

No. I think it must have been to do with the length of the sound path, but I still haven't worked it out as more than enough space was allowed for it. There are some other changes in this sort of area, related to the Logging, which might have hidden the error rather than fixed it, so please make sure it is still okay without those two extra INI lines you added for me. Regards Pete

Didn't you use FSUIPC or WideFS with FS9 before you uninstalled it? Your previous FSUIPC3 key would still be okay. The FSUIPC4 registration is not compatible with FSUIPC3. SimMarket did offer a discount for those upgrading from FSUIPC3 to 4, not the other way around, and I doubt that the offer is still valid in any case. I think it was originally applied for the first 6 months of FSX, then extended due to the slow initial take-up of FSX. But FSX has been out now for over 4 years. Regards Pete

The information is ambiguous, so I'm not able to pinpoint the problem yet. I've made some small changes in the area I think it is related to. Please, when you get time, could you download 4.646 using this link: FSUIPC 4646 and see if you can make the error again? If so I need the crash data -- i.e. the module address, as in this part of your excellent earlier report: Leave the two extra logging lines in for now and show me the logs and [sounds] section too, please, as before. Thank you! Pete

Yes, very much so. Thank you! It certainly is NOT the usual SimConnect bug. Something else is going on there. I'll see what I can find out. Your information is very useful. Yes, that's always the best in any case unless it is too large. Thank you. I will get back to you. [LATER] On first analysis it looks like it happens when FSUIPC is trying to make a list of your Sound devices, in the INI file. Do you think you could please check the INI file, find the [sounds] section and show it to me (paste it here). Also, you can log the details it finds by adding these lines to the [General] section of the INI: Debug=Please LogExtras=x20 If you could do this before loading FS, then show me the log, please. You don't need o try to reproduce the error. In version 4.60 there were no Sound facilities in FSUIPC, which also helps explain the difference. I think there's something unexpected in the definition of one of your sound devices. If I can see wehat it is I can fix it. Thanks & Regards Pete

If it's a general problem, not specific to that aircraft, it sounds simply like your toe brakes aren't calibrated correctly. You need to leave a reasonable dead zone, and area before the "minimum" setting, so that not only with feet off the pedals the brakes are off but also when using the rudder you aren't accidentally pressing brakes too. If it's only with that aircraft I'm afraid you need to ask someone who knows it, or at least has it. Try PMDG's own Forum perhaps? Regards Pete

It's worth sticking with Win7, and the 64-bit version does make the most of your new setup. I just think the 64-bit FTDI drivers (most of those USB adapters use FTDI chipsets I think) aren't, er, quite ready yet. Maybe you can find later ones on their website, or the website for the make of adapter you have. I haven't really tried one for nearly a year after finally changing all three of my 64-bit systems to use the BrainBoxes device. I see on the BrainBoxes website they also do a USB adapter -- maybe that would be another, easier, solution, provided it uses their own chipset and drivers. Regards Pete

With the same USB serial adapter? Was your previous PC running Win7 64 bit? When I updated to a 64-bit operating system, first Vista the Win7, I couldn't find any 64-bit compatible serial USB adapter drivers that worked properly. Your symptoms: were typical. In fact, since I also use the full PFC centre console on the same connection, odd switches were switching and changing the radio frequencies, and manyualy controlling anything became precarious. These symptoms seemed to start after a while. powering everything off and back up again would reset everything to normal, but some time into a flight it would all happen again. I am sure it was the USB serial drivers, just not made properly for the 64-bit operating system. I changed to BrainBoxes serial ports on PCI cards (UC-235), see http://www.brainboxes.com/product/items/uc-235-lp-upci-1xrs232, and haven't had any problems since. I've put the same card in two other systems since then. Regards Pete

Sorry, but I didn't think you wanted any differentiation, just a filter for the airport. It was actually a little more code to do both! Obviously I completely misunderstood your wishes and that all you wanted was to eliminate traffic that wasn't related to the airport you were working on. I thought your suggested implementation was only done that way because you though it was easier -- which it wasn't. Your suggestion revolved around the formatting tables which are processed en bloc, for column positioning and can't come into selecting. Ask me again in a few weeks. I only did it in some spare time yesterday and it turned out to be no fun at all. I really haven't the patience or desire to plough back into that old code yet again in the near future. :-( Pete

Okay. Please try version 1.551 of TrafficLook, now available in the Download Links sub-forum. Regards Pete

No. There's no problem with the hooking. The log shows that is working okay. The only hooking errors are for the old versions of MFC -- it just logs those events incase it cannot eventually hook correctly. The problem is to do with a change in the printing formatting, which FStarRC has to analyse to extract the data it needs. On your subsequent message: As I said as soon as I saw your earlier log fragment, the issue is not as simple as a library hooking change. That isn't the problem. They've changed something in the printed report. Maybe if you could post (or email) a picture of a printed report it would help me interpret the Log file you've sent. [LATER] I've looked through the full log you sent. It seems to do fine till near the end, after it processes the destination. something is different in the formatting of the printout at the tail end of the Report. Ideally i'd like to see two logs for exactly the same route, one from 9.521 and the other from 9.530, as that would show exactly the difference which is confusing my program's analysis. Certainly seeing the actual report itself would be a start. But it's a difficult messy job without the software! Regards Pete

I have only ever had a one-off version, Corporate Worldwide. When I first bought it it was a reasonable price, but it seems to double in price every year or two. The subscriptions have always been way beyond what I'm prepared to spend and they are not necessary for simulations. That would certainly be a violation of your agreement with Jeppesen. I can't be really party to that now, can I, as a software publisher especially so. And I don't have any sites for uploads I'm afraid. Looks like the MFC90 one is okay, so it's something else they changed. That makes it much more complicated. I would have to buy the update to work that one out. Sorry. You can send me the Log zipped up (it should actually then be smal enough to attach here) to petedowson@btconnect.com and I'll take a look to see if it's anything obvious, but when they've made changes to the print format or order of printing before it's been a complex job which is pretty well impossible without the program. If I'd known there was another update so soon after I bought the last I would have held off! Regards Pete

All okay except for that line. The "AND" function logically ANDs two binary values -- in your case one is 99 (0x63 or binary 0110 0011). If the value was 100 (say), or x64, binary 0110 0100 then ANDing it with 0110 0011 gives 0110 0000 which is actually LESS than 99! AND gives a 1 where both values contain a 1, else a 0, see: 0 1 1 0 0 0 1 1 = 99 0 1 1 0 0 1 0 0 = 100 -------------------- 0 1 1 0 0 0 0 0 = 96 You use logical functions to extract and testor toggle bits. But arithmetic values you just use values! i.e if val >=99 then -- When RPM is at 99% or more (Offset 0B54/ size4/ read only) Pete

I'm sorry, but it cost me over 400 Euros to update to the last one and I'm certainly not updating again so soon. Maybe in another 2-3 years. It's nothing to do with "moving" things. The libraries are installed in windows. It's to do with which compiler they use to compile with. And logs can easily be pasted into messages here. They are simple text files. [LATER] The log won't tell me what Library versions they use. You'll need to find out. If it is only that which is changed then I should be able to fix it easily enough. Go to www.sysinternals.com and download ProcExp. When FliteMap is running, run ProcExp, find and select the FliteMap process in the list, and look through the list of DLLs it uses. You'll find the MFCxx.dll there. Let me know and I'll build an FStarRC for you to try. [EVEN LATER] Cancel that ... your log shows MFC90.DLL is the one, like the previous release that I now have. Pete

You are making a mistake then. Nothing changes. you must spell your name and emails EXACTLY as in the registration, as well as the key. There are no problems you can have with FSUIPC which would be fixed by "removing it" and "reinstalling it" because "it" only consists of the one DLL and replacing the DLL with the same DLL changes nothing. Regards Pete

So, something changed. Did you unplug your devices and reconnect them? Were they connected to a USB hub which was perhaps powered off when you started? It sounds simply as if the devices have swapped their Windows identity numbers, so jumbling up your assignments. FSUIPC contains a facility to deal with that. It is called "joyletters", where you can have letters assigned to the different devices, and assign functions according to those. Then FSUIPC automatically reads the descriptions and unique "GUID"s associated with each device and ensures the correct one is reassigned to the same letter each time, even if Windows reconfigures them or you connect them differently. The documentation contains details of this facility, and you can set it do assign letters automatically. Meanwhile, if you cannot sort your mess out you would need to delete the INI file and start again, but enable the joystick lettering before you start assigning. Regards Pete

It shouldn't happen in the first place, and in fact rarely does. This is why it is more important to gather information on those few occasions when it does. Regards Pete

Just coming back to this question. It's quite a story. When Windows Vista came out and folks installed FS9 in the Program Files folder (the default), Windows actually made aliassed folders for FS which could be written to, because FS9 is not "Vista-aware" and needs to write to its own folders. Normally all Program Files folders are read-only, except for Installers and others running in "elevated administrator" mode. Programs installed in and aware of Vista's rules installed their data in "ProgramData" or "AppData" folders instead. These are the modern Microsoft rules (which, incidentally, I detest, because it means the system disk gets full and fuller as more data is generated). At this time I had no installer for FSUIPC. There was no need -- WinXP and previous versions of Windows had no file access problems affecting FSUIPC, so simply placing the DLL into the Modules folder was a doddle for any user. With Vista, however, problems started arising straightaway, because, although FSUIPC was duly writing its files, the LOG, INI and KEY, into the Modules folder, users, in general, could not access them. Vista was showing them the aliassed non-writable folders and not the real ones. The only way to access the real ones was to run Explorer "as administrator", to give it elevated privileges. To get around this I changed FSUIPC to detect Vista and then save its files into the Flight Simulator Files folder. (Not the ProgramData or AppData folders which, in my opinion, are too difficult for users to find easily, so defeating the object). Later, when I had to make an Installer for FSUIPC4 for even more critical reasons, I did one for FSUIPC3 too. Both installers make the FS Modules folder fully User read/write accessible, so solving the original problem. Hence, a newly installed FSUIPC3 or 4 on Windows 7, for instance, uses the modules folder for all of its files. However, i did not dare change it for Vista users, because anyone updating their copy of FSUIPC would find their previous setting and registrations apparently lost -- and anyway they would have been used to looking in the Flight Simulator Files folder for these. Most folks, in any case, using FS9 on Vista, set the Compatibility option for XP emulation in any case, and in this case thjere was no problem and FSUIPC used the Modules folder even on Vista. Now, to come to your case: from your Log, this line: Running on Windows Version 6.0 Build 6002 Service Pack 2 indicates that, though you installed Windows 7, you have set FS9 to run in Windows Vista (Service Pack 2) compatibility mode. I think this is a mistake for FS9. Windows 7 is actually quite clever, more so than Vista was, and automatically runs FS9 in Windows XP compatibility mode even if you don't specify this, UNLESS you override that by the compatibility setting. So, I think you'll find that things will revert to normal if you remove that setting. Right-click on the short cut for FS9 (or the FS9.EXE), select Compatibility, and uncheck the "Run this program in ..." (or select WinXP SP2, its best setting, instead of Vista, its worst). You'll also want to move those three files back to the Modules folder before running FS9 again. Regards Pete