Pete Dowson

I assume you are asking about WideFS? Sorry, I don't know their products. You should really ask them. if they only use the FSUIPC interface there shouldn't be any problem. I don't know how to answer that part. What's the actual question? I don't know or use WidevieW, but since it involves having FS running on the networked PC, it would depend on whether the values for the instruments were kept up to date from the Server PC or not. I remember in the original WidevieW product of 10 years or more ago this was an option, but I think it was cut down just to drive views, not instrumentation. See if it explains this on the WidevieW site. Pete

I've been experimenting. Interestingly, on FSX is doesn't matter which way you assign the brake axes. Using axes for brakes rather then the "keep tapping" controls (like those assigned to '.' (both brakes), F11 and F12 (left and right toe brakes) simply does NOT auto-release the parking brakes. Of course, when the parking brake is set, both left and right toe brake vsalues in FS are locked at maximum values. So, the brake axis controls have no effect. The provision in FS9 to auto-release on a brake axis control doesn't appear to carry over into FSX. I'm reluctant to change FSUIPC to do auto-parking brake release, because there can be side effects for cockpit builders. Take my cockpit, for instance. In order to apply the parking brake I have to press both toe brakes good and hard, then pull the brake lever to lock them on. If I'm not careful, moving the toe brakes again (even possibly when releasing them) could take the parking brake off again. Unlocking the parking brake is the reverse -- press hard on both toe brakes, then release the lever. I think on some aircraft the lever will drop to "off" in any case when there's enough foot pressure on the brakes, but this is a purely mechanical contrivance I think. I will consider putting an option in (INI file only) to "release parking brake on toe brake action", but it will have ot default off. Meanwhile, I'd still like to know about this "sensitivity" adjustment of yours and why it is not possible using the FS control assignment. If you wish to implement the parking-brake-off option via the right-hand side provisions in the Axis Assignments tab, and are not sure how to do it, let me know. Regards Pete

Yes -- that would only occur because you've not opted to add the publisher (Simflight) to the Windows "trusted publishers" list. Once you do this you'll never get the prompt again. Well, not "never", but till the signature expires in a few years and has to be renewed. Yes. I'm not sure whether that still happens or not with trusted publishers. I've not really looked. Only 6? You can do. How do you know which is the latest? You could delete every entry in there in any case -- FS will simply ask for them again next time you run it. No, not at all. The file is only read the once. No performance hit! Regards Pete

The term "latest" is meaningless. Please always state version numbers. I've had folks here saying "latest" meaning the latest they've seen someplace (often not even the official sources) -- one "latest" was over a year old and I spent a couple of days exchanging suggestions and reports before finally getting a log revealing the true version number! There's no relationship in FSUIPC between the toe brake operation and the parking brake. Do you mean you want/expect the parking brake to automatically release when you press the toes brakes? In a real aircraft you actually press the toe brakes and pull a lever which locks them in place. Releasing is the reverse. Is that what you mean? The end result, in terms of controls sent to FS, should be the same wither way. The "direct" method merely avoids sending the controls to FS for them to be intercepted by FSUIPC immediately, for calibration. [LATER] Checking here, on FS9 is seems the Direct brake option uses direct control into FS's simulation engine, whereas the FS controls option still uses the FS controls. I think the difference you are noticing is that FS automatically disengages the parking brake when it sees brake control action, but the direct control bypasses that. I've always used a parking brake lever in combination with the toe brakes, as described, but you've got used to just tapping the toe brakes I assume? I can deal with that I suspect. I'll think about it. Of course, you could too, using the right-hand-side of the Axis Assignments tab to send a parking brake off control when the toe brakes move "on" through any reasonably "pressed" range. Er, what sensitivity adjustments are these? FSUIPC doesn't offer any sensitivity adjustments. And all of the calibration adjustments are in the Joystick Calibration tab and apply exactly the same no matter how the controls arrive -- from FS, from FSUIPC via FS, or from FSUIPC directly. Can you epxlain what you mean here, please, i.e. what "sensitivity" adjustment? Pete

Ah, so you mean "allowed FS to load FSUIPC4" rather than actually trying to run it! Sorry, I've no idea. The only possibility I can think of is that SimConnect is not even reaching the point where it opens the log before FSX crashes. But that cannot be, either, because you said it doesn't crash till after you press "Fly Now", and certainly FSUIPC4 is loaded, connects to SimConnect, and commences logging as you've shown, all before the crash. The SimConnect log would start long before that as it explicitly shows FSUIPC4 and any other add-in modules and external programs being loaded, as well! So, I have no answers for no SimConnect log being produced. Either you saved the SimConnect.INI in the wrong place, or with the wrong filename, both of which seem hard to believe, or your FSX installation is really screwed up much more badly than we thought. Sorry. Regards Pete

No, not that I know of. Does it matter? Just choose keypresses you don't need to use in any case. I do publish lists of ALL FS controls which can be assigned in FSUIPC. These are derived from the lists built into FS, and use the built-in names for the controls, not whatever they describe in the menus. Regards Pete

Please always state Version Numbers. "Latest" is meaningless -- I've had folks saying that and after a lot of confused exchanged it turned out they really meant "latest they'd seen .." and were actually using very old versions. This is especially appropriate to PFC stuff where quite often folks get the "latest" from the PFC site, which appears to be well behind usually. You want to use them only the the fuel idle/cutoff switching, not as engine starter switches at all? What are you using for Engine Start switches, then? Why are you using FSUIPC? Are the PFC.DLL provisions not as you need? Where's that, PFC or FSUIPC? I don't remember one by that label. Do you have the Jetliner console selected on the PFC consoles tab? If that's a "similar problem" then you have no problems at all. As it says in the documentation for FSUIPC, the Buttons & Switches tab only detects the "off" to "on" transition. This is deliberate to avoid confusion. There's no point in it detecting both -- you can program both the off-to-on ("press") and on-to-off ("release" changes in same window at the same time, so what would it accomplish to change the screen on release? It would make things much more difficult with momentary push-buttons! Pete

So there was some corruption in that file. You might learn something by comparing the old with the new. They are text files containing readable parameters. Erno thank you. I used to enjoy such pursuits, but I'm getting too old for that now! I'd rather avoid it! ;-0 Good flying! Pete

There's an error. You have the path wrong: See the space in front of "Microsoft"? That is wrong, it shouldn't be there! When you say "ran FSUIPC4", what exactly do you mean? You never "run FSUIPC4" -- when installed it becomes part of FSX and is running as soon as FSX is running, like the rest of FSX. Regards Pete

Oh, right. I didn't know that. I also don't understand why, what it could possibly do for you. Weird. I've no idea why. Why not, I wonder? Everything else which needs to talk to a local program seems to be fine. Yes, but WideClient asks Windows to convert that to an IP address before it can use it. WideClient never needs to know any IP addresses on the local PC. Sorry, I've no idea why it won't connect. Maybe it is something to do with the Server end, selecting the wrong IP address. How does Windows in the client know which of the two IP addresses to use when talking to the other PC? There's no way I know for the client to select one -- that's only done in the "bind" call, which is a function of the Server, not the Client. Maybe this is something the FSXpand guys can help with? Incidentally, there's no problem with having WideClient and FS with WideServer running on the same PC. You have to change the ClassInstance parameter in the Client INI file, else the "FS98MAIN" class Window is used and only one of those is allowed. I used this trick a lot to test and develop things like the ButtonScreen, where no Client application is actually connecting in any case. For that, again, all that is needed in the client INI is the name or IP address of the current PC. Makes me wonder what the FSXpand programs do in order to require these separate IP addresses. Have yuo asked the authors about this? Regards, Pete

Why does it matter? What is confusing you? FSUIPC treats all switches the same. A toggle switch is the same as a button except that it is as if someone holds it down for you whilst it is on. The Buttons and Switches tab only recognises the Off to On change, but you can still program what happens when it goes on and when it goes off separately if desired, just as you can with a button. GoFlight dials and multiposition switches are different. But with anything connected and detected, all you need to do is operate them to see what is happening. Whilst doing the assignments FSUIPC does display an identifying "joystick number" and "button number" for you to see, so you know when it changes in any case. Pete

FSUIPC doesn't have any say in the fonts or their sizes, it uses default settings for its menus. The problem is usually due to a mismatch between modules installed for the video driver and the ones which come with the Operating System. If installing up to date and correct Win7 drivers for the video card doesn't fix it, you may wish to try the suggestion made in this thread: viewtopic.php?f=54&t=78052 Regards Pete

Strange because FSUIPC 3.93 (the currently supported version) uses the same signature as FSUIPC 4.53. Show me the Install log file, please. It's a text file, you can paste its contents into a message here. This suggestion was also posted by another user recently: Regards Pete

That spoils the previous findings, which certainly were starting to make it look like a controls file corruption! I can't think of any was the day/night situation would affect the way controls are interpreted! Weirder again, because controls file corruption shouldn't be geographically related. By this, do you mean control assignments in FS? Or did you delete the FS CFG file? If you've not yet tried this, find your FSX.CFG file and rename it. When you run FSX it will generate a new one with all defaults. Test from that base. Because of the weird interactions you seem to have with day/night and geography, I suspect that whatever was originally corrupted has caused other corruptions, making it almost impossible to properly diagnose. Because of this I am now thinking you may only get rid of the problem by a complete re-installation of FSX. However, before that, I'm just taking a look at that location in CONTROLS.DLL to see if I can see any clues there. [LATER] The crash location is nested deep into FS control interpretation. it is referring to a location pointed to by an entry in a structure which was pointed to by an entry in a previous structureetc ad nauseam! (I hate trying to hack through C++ with its multiple levels of virtual procedures and overuse of pointers). I honestly don't have any chance of tracing it back to a possible cause. The corruption could be at any level, and in any one of several files, data or code. If you have a lot invested in the current installation and don't want to do a complete uninstall/reinstall I would suggest this: [N.B. Since you are using Vista, if your FSX is installed in "Program Files" you will need to run Explorer "as administrator" to do some of the following. This is via right-clicking on its EXE, or making a shortcut for Explorer with that set in the Properties.] 1. Find and delete, or rename, the folder containing your FSX.CFG file. 2. Rename your current installation (i.e. changed the name of the main FS folder from FSX or whatever to something different). 3. Install FSX from scratch into the same place as the original. Install SP! and Acceleration too., but be sure to check it between each step. 4. Rename the new FSX folder to, say "Virgin FSX". 5. Rename your original folder back to the way it was. Don't run it yet. 6. Copy the whole contents of the main folder (not the subfolders) of the new Virgin FSX to the original. This will ensure that all of the FSX DLLs and codebase are correct. 7. Copy the whole contents of the Gauges and Effects subfolders of the new Virgin FSX to the original. This is needed because they contain code too. Test as before. If this doesn't work then I'm afraid nothing short of a full reinstall will work. Unless you are short of disk space, you may wish to keep the "virgin FSX" installation as a source of original files for repairs, or for testing things. I do this, but then I'm doing a lot of fiddling about and testing! ;-) Regards Pete

None at all -- I used 4.52 whilst it was current, on Win7 RC Ultimate 64. You should at least update yours to the current fully supported version, 4,53, please. After installing that you may wish to update the DLL itself to the latest interim update, 4,546, from the Updates announcement above. To avoid problems with some add-ons I always advise overruling the FS installer's default install path, and instead selecting something outside the the Program Files folder. For FSX I would suggest something simple, like C:\FSX. If you have two hard drives, maybe choose the non-system drive for FSX. Regards, Pete

You need the GoFlight GFDev.dll module installed, in a place accessible to FSUIPC. The GoFlight driver installation used to install it in the same place as GFconfig.EXE. Isn't it there? FSUIPC finds it there by reference to the registry entry for the GFConfig install path. If you can't find it, there's one in the Updates and Goodies announcement above. For FSX you can put it in the FSX modules folder, but do NOT do this with FS9. Try it in the GFconfig.EXE folder, or else in the main Windows folder. Regards Pete

On two separate Network devices? Or on one? If one the one device, how do you do that? And why can't they talk locally using the normal special local IP address -- 127.0.0.1, named "localhost"? That's the usual way to do that. That's how SimConnect connects with its clients on the same PC as FSX, for example. I don't see why it should. It's a client, so it never needs to know and never uses the PCs IP address -- it only has to find the IP address for the Server, the FS PC, and then only for the TCP and UDP protocols, not IPX. Maybe the problem you are seeing is the other way around -- the Server broadcasts not being seen? Have you tried telling the client the ServerName or ServerIPAddr explicitly, in the WideClient INI file? If you do this you need to specify the Protocol too. Regards Pete

Well, possibly. But I still don't understand how it freezes WideClient, unless that's only with AS and that is somehow stuck in a tight loop with WideClient. Does WideClient freeze with RC too? Could you try a client program which doesn't need any file access to the Server. If you have none, try TrafficLook or WeatherSet2 (see the Updates and Goodies announcement if you've not got those). If WideClient freezes with either of those, there's a Network problem for sure. If not then the other problems are more likely basic access permissions on folders on the server -- you need to share them more effectively. Regards Pete

How strange. It sounds like something has become corrupted. Even more sounding like corruption. Thanks. I'll have a look to see what's at that part of CONTROLS.DLL. But, meanwhile: This strongly implies a corrupted flight file -- possibly the FSSAVE or WX files, which are both binary files and have little in the way of protection should they be corrupted. If avoiding any saved flights which may have been saved on or after 16th October also avoids the problem, then I would suggest simply discarding them. Do a test first: move ALL of your saved flights out of the Flight Simulator X Files folder, save them someplace safe. And don't let FSX load any of them, not even the default. Try to recreate the flights you want from scratch instead, saving them as needed. Try to get to the same situations as crashed before. Let me know. With binary data corruption, especially in the WX files, the results in memory can be literally anything. It could simply cause a bit or byte to be changed in one place which then goes undetected until that's executed, and then not even that may crash but simply corrupt something else. I've known this to happen with bad WX files ever since they've existed. The reason the problem may be exacerbated with FSUIPC running is that it is requesting the weather be read regularly, so it can populate the offsets used by applications. The WX file data is processed by SimConnect into METAR strings which are "safer", but a corruption in the original data can do the damage in the process. Let me know. I'll have a look at the crash location in CONTROLS.DLL in the morning, see if there's anything that might suggest differently. Regards Pete

No, the current supported version of FSUIPC4 is 4.53. Version 4.50 is not supported. What "communications check"? The one in PFCFSX? Where's its log? Ah. I'm pretty sure Elite use a different protocol, not the default PFC protocol used in FS. Did you specify FS when you bought the controls, or Elite? I suspect that they are set for Elite protocol. They may or may not be switchable -- you'll have to ask PFC. You show an FSUIPC4 log, but off course FSUIPC isn't involved it handling your PFC controls, that is all in PFCFSX. Regards Pete

Not sure why you needed to buy FSUIPC. What PFC controls are they? Don't they come with any documentation? if they are the serial port type then they need my PFC driver, which has its own documentation and setup procedures. PFC controls are top quality and top price, so I assume they come with some support? Regards Pete

Right. We knew the data format was AV400 from previous users' attempts. Shame about the USB connection. Regards Pete

Sorry, I don't understand the question. It doesn't make sense. What do you man by "byte 2" and "byte 1"? The value will by in a specific offset, a specific byte. Why do you think the offset will change, that the value will sometimes be in one place and sometimes in another? They don't move about, otherwise they'd be impossible to use! The document you are looking at will define the offset -- that's it. Only the one byte or word, not two different ones! Regards Pete

No, not even you really. You said "when i fly suddenly they stuck(most of times)". I'm afraid I've no idea what that means. Regards Pete

It results from a mismatch between a video driver's COMCTL32.DLL and the Windows graphics settings. If trying a later or older video driver doesn't help, then the answer is to select a different windows font size. Right click on the desktop, select Personalise, then Display. Try "smaller (100%)". That works for me in all circumstances. Pete