Pete Dowson

Is Teamspeak on the same PC as FS? If so, you may want to assign the keypress it needs for its PTT, not any FS control. Pete

The settings in the driver are only defaults. Each application sets its own. You need to set the correct speed in the FSUIPC GPSout tab. If the speed is not specified by Garmin, the default for NMEA format is 4800. I don't know if there is one for Aviation format, but try 4800 first. Don't check ANY of the other sentence selections if you select AV400 -- Aviation format is NOT the same as NMEA, and most of the other selections there are NMEA. If your GPS uses Aviation format, that's all it will take, not a mixture. That implies that you have some software installed to talk to the unit over the USB/Serial link. Do you have to specify COM4 to that each time you use it, too? I ask because the software might be installing an "activesync" type of link which will effectively "own" the COM4 link to your Garmin and prevent GPSout getting to it. I know this happens with true USB devices. Anyway, if you search this forum for "Garmin 196" references you will certainly see that several folks have it working fine, with the AV400 format (only). Regards Pete

Not heard of Parallels. Does it emulate Windows completely? If it requires re-booting, there must be something wrong with the low level networking parts of whatever it is pretending to be Windows Winsock32. Application level programs like Wideclient do not disturb anything lower than their privilege level, so a simple restart is normally the most that is needed. In fact WideClient does its own restarts on timeputs, automatically. With this occurring after a period of time, it also occurs to me that something on that system is leaking memory or other resources till finally things clog up. Do you have a performance monitor you can check this with, like the one in Windows Task Manager? Try a process of elimination -- run only one application at a time on the client PC, see which one clobbers things. The INI file tells me nothing, unless you've been messing with it. The important information is recorded in Log files -- WideClient.log on the client and WideServer.log on the Server. I also always need to know version numbers -- FSUIPC, WideServer and WideClient. If these are not the latest (check the announcements at the top of this Forum) please try those first. Regards Pete

Okay. It certainly looks as if you have a corrupted PMDG install. Trying uninstalling it completely, then re-installing it. If there's still no joy you will have to use PMDG support. And maybe they have some updates you've not yet applied? Before you do that, you could just try the latest version of FSUIPC, just in case it makes a difference (though this is clutching at straws). Version 3.916 is available in the "Updates ..." Announcement at the top of this Forum. Regards Pete

You are using an old unsupported version of FSUIPC. Please update it if you want any support. Please browse in the Announcements above from time to time, and always before asking for help. This: indicates a likely firewall problem on the server preventing access by WideClient. You need to take down the firewall or allow the WideClient port (8002 by default) through. A Wideclient client? In that case maybe the firewall on the failing client is stopping things. Either way it is certainly a networking problem. the message "Connection refused" is from Windows. Regards Pete

The LOG file has filetype LOG. The first file you show is the INI file, the configuration settings for FSUIPC. If you cannot see the types of files you need to change your Explorer file options to stop hiding them. The log file shows everything in FSUIPC is running fine: And it doesn't show any problems with any PMDG aircraft because you didn't bother to load it, see: See? You simply had the default Cessna 172 loaded. If you aren't trying the very thing which causes an error, how do you expect the Log to show any information about it? Regards Pete

Well, FSUIPC 3.90 is most certainly completely compatible with PMDG, so I'm not sure what you've got corrupted there. That specific message doesn't mean it is a problem related to FSUIPC at all. In fact I suspect you are more likely to get the PMDG aircraft to fail if you don't have FSUIPC installed! Please show me the FSUIPC.LOG file (from the FS Modules folder). Make sure FS is closed after such an error, and paste the whole thing here. I'll certainly have a look for you, but you may have to refer it to PMDG support if I can't see anything. No, nothing at all to do with FSUIPC. If a separate EXE program crashes it contains a bug. You need to use the support for the program. And don't use any older version of FSUIPC if you want any support at all from me. There's never any need to remove anything at all when updating your FSUIPC. You simply copy the new DLL in, overwriting the old one. You are evidently completely misreading the extremely simple one-step install instructions (amounting to just "copy the DLL into the FS Modules folder.") Nothing in any of my software ever deletes anything from your computer. It sounds like you really never actually installed FSUIPC.DLL in the FS Modules folder in the first place. That would certainly explain your PMDG problem, maybe the other too! Perhaps you put it into the main FS folder by mistake? Pete

If you need it (I never knew what it was actually for!) then just put it back if you can't find a later version. I had a so-called "bad" one sent to me to see if I could reproduce the problem and so maybe find out what was going on, but it would never do its hanging trick for me -- and I don't think it does for many. Seems a tricky combination of circumstances, but we don't know what. Regards Pete

The few times this has occurred before it has most often been due to a faulty version of an FS module called Actigate.DLL. Check your FS Modules folder. Just remove it temporarily when registering. It this isn't it, the only other one I know of which has occurred and been proven is a Kensington mouse driver. If you use one of those you may need to uninstall it and use the regular Microsoft driver. Finally, failing both of these, please list any other Add-On DLLs you have installed in the Modules folder. Not the normal Windows ones, the add-ons. Maybe there are others which interact badly. Someone thought PMDGoptions.DLL caused a similar problem on their system, but I never got confirmation of that. Also, start FS with a default aircraft not an add-on, just in case. Regards Pete

The best way in both cases is to monitor the Activity counter at offset 0x337E, which was invented for just this purpose. Note that you should probably also check 0x3364/3365 to see if there's a good reason for 337E to remain static for any time. In the end a timeout would be the last check assuming 3364/5 remained non-zero with 337E unchanging. When FS is in a modal dialogue nothing else in the process is running so you have to allow many seconds sometimes for user activity in menus. Regards Pete

The Lua plug-in called "display vals" is just an example of a plug-in which displays things on screen. There is no "display on screen of the Lua plugins" -- no index to Lua plugins on screen, if that's what you mean. All Lua plug-ins found in the Modules folder are available for assignment to Buttons or Keys. They can be found in the control assignment dropdowns, with control names "Lua ...". Just activate the dropdown in the usual way, and press the L key to get close (or L U A is reasonably quick succession). For example you can run the "display vals" plug in by assigning a key or button to "Lua display vals". There are also LuaKill and other commands to stop a plug-in and set or clear its flags. The only Lua plug-ins which are run automatically are those named ipcInit.lua and ipcReady.lua. I can only advise you to please read the two documents telling you about Lua plug-ins and what they are, what they do. You seem to be misunderstanding things quite a lot. Best to read about these things before trying to use them. In particular I refer you to the paragraphs commencing "When there are Lua files in the modules folder, FSUIPC adds a number of new controls for assignment .." in the section entitled What is provided in FSUIPC for Lua programming? Regards Pete

Yes, but all of Steve's data files were made in 2003 and were applicable to assorted add-on aircraft at the time. I'm actually using Bob Scott's PMDG 737-700 file, which specifically matches the PMDG 700 I am flying. That's important -- match the data to the performance characteristics of the aircraft you are actually flying! The problem, as I keep explaining, is that the default 737-800 in FSX is a poor (read "bad") model. No one has made a proper data file for it to fly in PM as far as I know -- probably because it isn't worth it, it is such a bad aircraft. Well, probably the best they can do is to try to advise what bits of the file to change, or more likely to alter some stuff in the default Aircraft.CFG file. Really you need specialist advice from an FS aircraft modeller, someone who knows about these things. There's no one in PM who models aircraft, though Thomas Richter, who was associated with PM for a while, is quite good in this area. The advice you may get is to find a better FSX aircraft to fly. None of the default ones for sure (except maybe the GA props). That's my advice too -- as you'll have seen in each of my replies. Regards Pete

RealityXP what? Isn't that a badge for lots of panel/gauge products from the company run by Jean-Luc? [Ah, I see you clarify that at the end]. Wow! Certainly FSUIPC4 itself makes no changes to the system itself. The only things it touches outside of the FSX Modules folder are the DLL.XML file, in order to ask SimConnect to load it, and a small private entry in the Registry to record Registration. Neither can impinge on anything else, and certainly nothing permanently at all. Does that program use the joysticks? Does it use DirectInput? I wonder what it could possibly be changing to clobber FSUIPC4's button scanning. You are saying that it IS only the Buttons tab affected, aren't you? Not the axes assignments, Joysticks calibration, Keys assignments or any of the others? The only thing mildly different about the Button assignments tab (in relation to its normal actions) is that it is scanning for activity on any possible "joy" device (i.e. all from 0 to 15, not just those already assigned), and it will also be looking for the EPIC USB device in case that is attached. EPIC devices are one of the 16 "joy"s, but return the word "EPIC" to a special request code (-1) which is ignored by other devices. You might want to try inhibiting this. Maybe the checking being done for EPIC presence is somehow invoking something set by RealityXP. Try adding PollEpicButtons=No to the main [buttons] section of the INI file. Perhaps the RealityXP program installs a special "joy" type device (as a software hook perhaps) which gets this EPIC query and, well, doesn't return for a while. If this makes no difference, you need to report this to RealityXP. It may be a Win7 incompatibility someplace in their code. Regards Pete

But the log only shows you trying the default created macro. And it definitely shows that FSUIPC called the apprpriate routine in the panel's DLL. If it had no result it means the default mouse action (a left click) is not enough. Have not not yet even started to experiment with the mouse action, as I advised? I cannot experiment for you, I do not have the aircraft. I've told you this before. Please review the User Guide section on Mouse Macros again. You are surely not reading far enough. Look for example at the boxed section entitled Variations for Mouse activated switches which might be made to work by editing the Macro file Regards Pete

Your question, then, should probably be directed to Project Magenta support, as it is their autopilot making this mistake. However, I can guess that the answer will more or less be as I have already told you. The FSX 738 is a poor model. What will make it behave worse with PM's MCP is not using a tailored Aircraft characteristics definition in the FMC folders -- have you got one designed for the way that aircraft performs? I've not seen one. The best data for the PM FMC/MCP seems to be for the PMDG model. You may wish to visit the PM (unofficial) forums http://www.mycockpit.org/forums/forumdisplay.php?s=884 . Regards Pete

Where have you clicked that? not in my program? It sounds like your encoders are seen as buttons in FS and are being automatically assigned to default actions. In Fs or in FSUIPC? You aren't giving me any information. Are you using FSUIPC? If so, just delete the INI file from the Modules folder, or edit it and delete the [buttons] section from it. But if you aren't assigning those actions, the ones you don't want, in FSUIPC, then none of that will make any difference at all. You'll need to tell FS to disable the joystick inputs or at least delete its assignments, individually. Assigning in FSUIPC cannot override assignments in FS -- both actions will occur! Regards Pete

Well the default models are pretty bad in any case. After initially trying the default 738 when I first got FSX I abandoned it as pretty hopeless. I currently use the PMDG FS2004 one transplanted to FSX (without its panels ,etc, as I use Project Magenta). Is it YOU levelling off you are talking about, or the autopilot? I assume you mean the A/P as it is 100% normal for a 737 to be on A/P. However, if it is you, manually flying, then it may simply be the trim is too coarse. Trimming is all important. In general, you or A/P, the other normal problem causing overshoot is too high a climb speed for the weight -- the momentum is greater than the autopilot can cope with. And that default 738 is ridiculously overpowered in the first place. It climbs far too fast -- at FL350 climb rates are quite low because of the thin air. Don't forget, also, that the A/P you are using was really designed for a Cessna. The fiddle factors to make it attempt to control heavier planes are just thatr, fiddle factors. This is why decent third party add-on aircraft like PMDG, LevelD and even Ariane replace the autopilot with their own. Using Project Magenta I am of course also not using FSX's A/P. Oh. What is the PFC MCP connected to? In other words, what autopilot are you using? Regards Pete

You can have as many sequential functions as you like, within reason. It is a matter of having multiple conditions. You missed the line in the Section I pointed you to saying With 16 conditions based on 16 flags you can actually have 65,636 combinations. More than enough, I think! ;-) Very good. You could of course combine those by: 5=CP(F+15,30)2,0,C1005,3871 ;Joy2 But0 flag toggle on Joy15 But31 if But30 already set 6=P2,0,C1005,3870 ;Joy2 But0 flag toggle on Joy15 But30 Before I go on, a bit of explanation. I'll call the two button flags 30 and 31. The first time through you get Flag 30 set, 31 still unset. Next time, though, because 30 was set, 31 will be, but 30 is then unset. Next time 31 remains set, and 30 is also set Finally, 31 is unset as is 30. So the cycle is: 30 not 31 -> not 30, but 31 -> 30 and 31 -> not 30 nor 31. Using this: 7=CP(F+15,30)(F-15,31)2,0 C65957 ;Joy2 But0 Fuel Selector Left 8=CP(F-15,30)(F+15,31)2,0 C65958 ;Joy2 But0 Fuel Selector Right 9=CP(F+15,30)(F+15,31)2,0 C65956 ;Joy2 But0 Fuel Selector All 10=CP(F-15,30)(F-15,31)2,0 C65955 ;Joy2 But0 Fuel Selector Off See, you can cycle between 4 choices with two flags (similarly 8 with 3, 16 with 465536 with 16). Regards Pete

Unless you are simulating such failures yourself you won't get anything like that. You can build up quite a lot of systems actions using Lua, of course. But FS doesn't in itself. The nearest you'll get to a generator failure is an electrical failure, but by the time you get that you won't see the indications because you'll have no power. Of course you could light the Generator warning just to indicate they are off when they should be on (e.g. when the engines are 'combusting', if we are talking about engine powered generators). If you are using a more advanced add-on aircraft then they may simulate subsystems and their failures -- for example the PMDG and Level D airliners do. But then you may not be offered access to their variables as they are in the business of selling the complete system including screen-based panels. They'll be the extinguisher bottles, to put the fire out. When used you should get a warning as you'd need to refill them on the ground. Again, FS doesn't simulate the fire control subsystem at all. Only the fire warning when an engine is on fire. There's no extinguishers in FS! I have the complete fire subsystem implemented in my 737NG cockpit, but that's because Project Magenta's "pmSystems" simulates it along with many other subsystems. You have to subtract the ground altitude, of course. ;-) But if you are low enough to be within range of the ground radar altitude system on the aircraft then you can read the radar altitude at 31E4. After all, isn't that what the GPWS system uses? Why not use the same? Regards Pete

4.4 is certainly not supported, only 4.52 and later. All versions do actually have (important) version numbers! The dates aren't really useful (especially future ones like the 14.11.09 you quote! ;-) ). The very latest increment, an update for 4.52, is available in the usual Updates and Goodies Announcement at the top of this Forum -- currently 4.523 from last week. Each update fixes and adds things. It is always best to try the latest, and ALWAYs use the latest when running tests or providing logs etc. Strange. The file is ALWAYS produced, and when you close the hung or crashed program, Windows should (always does here) finalise (close) the log file. You can also always read the log file even whilst it is open and being written to. I wasn't really expecting it to record "faults" as such as it won't know what they are. I was hoping it might indicate to you what item of equipment, or what driver more likely, was messing your system up. Looking at the log extract you provide: Have you reconnected a joystick device? Are you actually pressing and releasing buttons that fast? That's 17 presses or releases in 11 seconds. If it is logging button presses, and you have no joysticks or devices with buttons connected, there is evidently something wrong with your system. You need to look in windows device manager and see what "rogue" device it thinks it has got. We aren't interested in key presses. Only buttons. Is that really the complete INI file you appended? It seems to be missing some very important parts, like the section listing Joystick names. Or is it from an old version of FSUIPC4? I really cannot help if you provide logs and INI files from old versions, sorry. It was the Joystick name section which might tel us what rogue driver you have. Please do come back and let us know how you get on. And do use the latest version. Thanks, Regards Pete

That's for direct calibration in FSUIPC's Joysticks tab. You need to go and do that next. Check the "REV" button in the calibration area BEFORE calibrating. Pete

Multiple actions on one button? It means adding lines to the INI file -- it cannot be done directly in the Options dialogue. Oh, you want a sequence of actions on one button, not several simultaneous actions. Yes, you can do that too, but it also needs INI file editing, and the use of Button Flags. Have a look at the section in the Advanced User's Guide called Sequences, combinations and mixtures. come back after you've read that and thought about it if you have any more questions. I'm not good at giving general tutorials but I can answer specific questions when you've had a think about it. Regards Pete

Well, they turned out to be a solution for some advanced cockpit designs, especially those by PMDG. Quite fortuitous really, as I had originally designed the facility to help operate the menus in a separate little utility program altogether, one that appears to have fallen by the wayside. Please check the complete list of FS controls supplied, either in the Modules folder (for FSX) or within the FSUIPC ZIP file for FS2004. That lists all of the FS controls by the name you use to assign them directly in the FSUIPC Buttons or Keys Tabs. Most are reasonably self-explanatory, though there are a few obscure ones (Kohlsman, for instance, refers to the Altimeter pressure setting). If you aren't sure, then for many of the functions you can find out the control name by enabling Event logging (in the logging tab in FSUIPC), then operating the thing in question, and examining the FSUIPC Log file, in the FS modules folder, to see what event was logged. the name will be given there. If it doesn't register as an event then it is likely to be a local gauge function which you cannot program on buttons. Regards Pete

Why do you think you need to use "mouse macros". What FS panel are you trying to operate which doesn't respond to normal assignments or keystrokes? For most aircraft there are regular controls for all of these sorts of things. I really have no idea why you are trying to do things this way. there are perfectly good FS controls for virtually everything. Folks have been using FSUIPC to assign to such controls for 10 years now. Mouse macros are a recent addition purely to get over problems with some recent and specific advanced FS panels which have non-standard autopilots and such. All of the default aircraft respond quite happily to regular FS controls -- they were designed by the FS team, after all. Many of the controls are even assignable in FS itself, without FSUIPC assistance. There are almost no places on any default panel on which mouse macros will work. This is actually mentioned in the documentation. What I cannot understand is why you rush into complex matters to try things not meant for what you want to do without first looking at all the easy stuff, which does work and has worked for many years!? Regards Pete

Same here. I'm using Win7 RC1 65-bit version on two systems with FSX and FSUIPC4, and excellent results. Can you clarify this please. You get into FS options, press the Buttons tab, then you never get out? If so, it sounds rather like a bad joystick driver, possibly one for a joystick no longer connected. Have you checked Game Controllers? Incidentally, you always need to state the actual version of FSUIPC. Please enable Button logging in the Logging tab before going to the Buttons tab, and showing me the log you get. Also show me your FSUIPC4.INI file No, it does sound like something, some rogue driver, is either hanging, or continually signalling a button change, so fast that FSUIPC's scanning never returns. I've known that to happen with, for instance, old Game Port drivers -- even though there's no game port on the backs of modern PCs, the game port drivers still manage to cock things up quite well. Regards Pete