Pete Dowson

No of course not! The dcumentation and announcements above have always made it very clear that you are paying for version 3 or FSUIPC, version 6 of WideFS. That means any Version 3.xx and any version 6.xx respectively! All you need to do is download the ZIPs and copy out the FSUIPC.DLL and WideServer.DLL to your FS Modules folder, and the WideClient.exe to wherever you put that. Updating is just that, one step, exactly as documented. Regards Pete

Where are you expecting such a message? It would only show that in the FS title bar -- you will only see that if you run FS in Windowed mode. There is no "message" as such, it is just status. Why are you expecting a message? If WideClient says it is connected then this "FS Commander" should certainly connect -- if it is an FSUIPC application and doesn't need direct access to FS, of course. I'm afraid I don't know the program myself -- perhaps you could ask the author or his support site about this? If you want help from me I need more information. I need version numbers of WideFS and FSUIPC, and it would be useful to see the WideClient.LOG file at least -- you will find that in the same folder as WideClient. I would also need to know how you are deciding that you are "not able to connect ..". What are the actual symptoms? What does FS Commander say? Possibly it needs the FS folder access or something else, not only the FSUIPC interface (which WideClient is certainly providing). If you want to test WideFS, try one of the additional little utilities provided in the FSUIPC package -- TrafficLook or WeatherSet2, for example. These only need the FSUIPC interface, no direct FS access. Regards, Pete

Dowload the latest from http://www.schiratti.com/dowson. I don't support old versions in any case -- see the Announcements above! What is the point of sticking to old versions in any case? Pete

Ah! Can you tell me what fixed it please? Pete

Okay, in that case it is normal for FS, it's the way MS implemented it. It isn't anything in FSUIPC and certainly nothing it its parameters. I'm not sure why you've not noticed it before. It's a very widely discussed complaint with FS2004. Your parameters for FSUIPC visibility options seem fine -- in fact they appear to be more or less the default values. What was the surface visibility set to? With 20 miles, as you stated earlier, I'm pretty sure you don't normally get a top-of-layer cloud imposed. I thought they only appeared when there was mist or fog on the surface. You could try raising the minimum visibility so that it is never low enough for the cloud to be imposed, but that way you'd never get fog either. I think the real solution won't be possible till the next version of FS. Regards, Pete

There has been no changes in the visibility options in FSUIPC for many releases. How old was the previous version you used? What are the visibility settings you have -- show me your FSUIPC.INI file. It's easy enough to change them, in any case. If you are seeing a large rectangle of "cloud" below you, which moves with the aircraft, then that is the top of the visibility layer and the visibility below that is limited. Microsoft, in their wisdom, tried to solve the "see-through from above" problems of fog by overlaying a thin cloud layer. It is pretty awful, but it means you don't have graduated visibility enabled, or you have but it doesn't start where the FS visibility layer leaves off (set to 0 to do that automatically), and/or doesn't continue to a decent altitude. The fact that you say you have a visibility layer finishing at 5000 feet seems to indicate this diagnosis. Regards, Pete

What aircraft is this with? Does it have an autobrake setting '5'? Is it the FS autobrake -- add-ons like PMDG aircraft do their own thing I thinkj. Test it with the default 737 or 747. Pete

Sounds like a graphics problem. Why do you think it is anything to do with FSUIPC? Pete

Erthe parameters in the FStarRC INI file are for you to set. I don't supply an INI file. Surely you are not copying all the paths in my example? Your system will certainly be nothing like mine. \\centre identifies the computer on which I run RC. It isn't on the same one as my FliteStar. D is the drive it is on, and so on. I cannot set the correct parameters for your system, only you can do that!! Regards, Pete

No. I spent many many hours trying to get such an option working with FS2004, and whilst it could be done it never worked in all modes of FS -- I don't know how the other programs which use transparency get it to work consistently. Possibly it must be done via Direc3D, but that if way beyond my current knowledge and the scope of a simple freeware utility. Certainly, using only the standard Windows GDI it is too inconsistent. Sorry, Pete

If you are not using FSUIPC for any joystick calibration it isn't really doing anything. Why do you think this is anything to do with FSUIPC? Have you any reason for asserting so? Were you using FSUIPC before? What do you use it for? What has the AUTOthrottle on a jet got to do with the MANUAL throttle on your props? It sounds rather as if you simply need to calibrate your throttle properly or check for a faulty unit. If you have been messing about with FSUIPC options you don't understand, just try closing FS, deleting the FSUIPC.INI file from the FS Modules folder, and loading FS again. FSUIPC will then start with all default settings. Regards, Pete

I have no idea how to make it work with an Ipaq. I have one and gave up. GPSout is written to send data out on a COM port, following the NMEA 0183 specification exactly. If you have suitable hardware and software it works fine. Mainly this would be another PC running a PC moving map program. I know some folks have made it work on some GPS devices, and maybe someone has it working on a PDA, but I suspect the latter is certainly very difficult. I think the "active sync" program, used to keep you PDA up to date etc, gets in the way, even if the USB connection can be made to look like an ordinary COM port. You probably have to delete/stop or even uninstall it. Regards, Pete

Have you got it repeating? Have you programmed it to do the same action on press and release (for a toggle obviously the second will cancel the first). Have you got conflicting actions programmed on the buttons some other way, such as through FS? If you go to FSUIPC's Logging page you can enable button logging and see if the presses are actually all being seen by examining the Log. Regards, Pete

No, unless you are using an old version with a non-English FS (in which case it won't be able to erase files, but it will still save them), there is nothing stopping it working except the parameters you set in its CFG file. Check that. Regards Pete

If it is for a TCAS instrument display then you could probably reduce it a lot more. I don't think they are supposed to be quite that quick, are they? Pete

Yes, just assign a keypress or button to the PTT controls, in the drop-down in the relevant pages. There's a control to set transmit ON and another for OFF. For a button or key you'd assign one to the press and the other to the release, and keep it down whilst talking, just like the real thing. If you are using FSUIPC 3.52 or later and WideFS 6.51 then there's nothing else to do. Regards Pete

First question: what is the "Process" call for immediately after the Open, with no reads/writes to do? I don't think that will be valid. Did you try using FSUIPC's IPC read/write Logging, to see exactly the end result of your work? These facilities are included to make development and testing a lot easier, you know. Please use them. Where did you arrive at the size of 3008 bytes to tell the Open2 call the size of your buffer? Why define it as 4096 and not use the last 1088 bytes of it? Have you checked the arithmetic at all? The TCAS_DATA structure is 40 bytes long. You want to read 96 of them96 x 40 = 3840. You also need to allow 16 bytes per read/write and 4 for the terminator, so just for that one read the buffer needs to be 3860 minimum. If you checked the dwResult of your FSUIPC_Read attempt, the error number would have told you. It is quite useful to look at error returns, especially when something doesn't work as expected! ;-) Regards, Pete

So, you have FSUIPC already. There's only one current FSUIPC, no "standard" and "non-standard" FSUIPC -- if you think that then please refer to the user documentation again for a brief explanation of the registration system. I would still recommend you visit the Schiratti page from time to time to download the latest versions. You can also find lots of information in the Announcements and "stickies" at the top of this Forum. All the sellers (there are three at present, but the other two are very specialised) deal with all of the sales and registrations themselves. I am not in that loop. I spend all my time (more than all it seems, sometimes) doing development and tech support. Regards, Pete

FSUIPC does not (currently*) deal with axis assignments -- they are done in FS Options-Controls-Assignments. For axes FSUIPC merely manipulates the axis controls you assign in FS. As for buttons, it depends what the CH control manager does. Sorry, but I don't know it. If FSUIPC can still read the buttons through the Windows joystick interface then it will see them, if not it won't. Why not try? [* I am looking to add facilities to FSUIPC to allow direct axis assignments without FS knowing about them. But it won't be soon]. Regards, Pete

Okay, then in that case the problem you have is certainly nothing to do with FSUIPC. The only real difference between 3.52 and 3.53 is that it accepts new 2006 registrations. I really don't know enough about those parameters to analyse that for you, sorry. If you only suspect a CFG file error then simply delete it and let FS make another. You may have to go and set your FS options again, but that doesn't take too long. Your [OldModules] section contains a load of stuff that probably should never be there: [OLDMODULES] FSSOUND.dll=1 HOSTSB.dll=1 SOARRec.dll=1 GFMCP2k4.dll=1 FSUIPC.DLL=1 GAUGES.DLL=1 A320Pic.dll=1 AdvConnect.dll=1 FSConnect.dll=1 sbtrans9.dll=1 Most certainly FSUIPC shouldn't be there. Adding those makes FS bypass the simple version number check in the modules. If any of those modules are specifically for FS2002 and before they may play havoc, so you certainly want to be sure they are correct for FS2004 BEFORE adding them into this section. Wasn't there an FSUIPC.Log file produced bt the way? Pete

Key2Mouse is simply converting keypresses to mouse movements and button clicks. It knows nothing about any devices. GoFlight indicators and displays only work with normal Goflight assignments, or by using my free GFdisplay program (http://www.schiratti.com/dowson), where you can make the do almost whatever you like. However, add-on aircraft indicators for non-FS things may not be easy to find, and probably impossible, so the best you might be able to do is prohram FSUIPC to not only send the keypress but also toggle/set/clear bits in the free FSUIPC offsets provided for this (documented in the GFdisplay docs). It gets a bit complicated though -- to make a button do two things in FSUIPC you normally have to edit the INI file (details in the FSUIPC Advanced User's guide). Regards, Pete

FSUIPC can only offer what FS simulates and provides. There has never been two batteries in FS -- in fact a second battery is optional even on 737's. What is an ERJ doing with two? ;-) There's no APU in FS, it isn't simulated and there are no switches for it. Not sure what you mean by "t/o config". Add-on aircraft can add a lot of stuff that isn't already in FS, and they each do it in their own different way. I'm afraid FSUIPC cannot have special programming built in for each and every new aircraft some programmer may devise switches and indicators for, all different! Check the documentation for your ERJ. Are there keyboard shortcuts for any of those switches? If so, you can certainly program FSUIPC to send those keyboard commands when you press GoFlight buttons or operate GoFlight toggles. If the switches are only controllable by mouse then you'll need something like Luciano Napolitano's "Key2Mouse" program to operate the mouse from keyboard presses, then program the latter in FSUIPC. If the ERJ uses FSUIPC offsets for its switches and so on (which is very unlikely) then, yes, you can make custom controls in FSUIPC to actually change bits or values in those offsets -- there's a series of "Offset ..." controls for this. Project Magenta's implementation is all controllable in this way, but it is almost the only add-on which is so completely controllable as far as I know. Regards, Pete

Yes, of course. It is only the FSUIPC_Process that actually does anything - the Reads/Writes are simple data procedures in YOUR program (as you can see from the source). Most of the time the Process takes is in Windows -- process switching away from your process into the FS process (or WideClient process). FSUIPC or WideClient themselves process the message and return to you with the requested data very quickly indeed, once the message is actually received. Typically well under 1 millisecond (I used to have performance checks which reported whenever it took longer than 1 mSec, which they rarely reported, but the checks actually took longer than the rest because they used Windows performance measurement techniques which were themselves quite consuming). Then there's another Windows process switch back to your process. Most of the normal time you might see is due to that process switching and message queuing. Any extra time you see on occasion will be when some other processing is being done as well. This is called "timeslicing" or "multiprocessing" and is what Windows is all about. Please do a CTRL_ALT_DEL and look at your process list. All of those running processes need attention at some stage, and now and then several will contrive to build quite a big delay. A process performing a call or return to another is one of the main opportunities for Windows to give time to others. Yes, but you can't actually guarantee that on an operating system like Windows. This is why FS itself suffers occasional jerks. The best you can achieve will be by setting up a Windows profile which has every service and process you don't need stopped. It is easy enough to stop things like Windows' XPs file indexing, marking files every time they are accessed, and doing a whole host of other things, but I am not the right person to tell you how. There are some helpful hints about somewhere. Regards Pete

What version do you consider "new" please? I always need numbers. And what was your previous version? Do you really mean Fsuip, not Fsuipc? Does it add things itself to the oldmodules section? I've never heard of such a capability! FSUIPC cannot in any way affect how FS decides to treat other modules -- by the time FSUIPC is loaded, so are all the other modules. If FS is rejecting some of your add-on modules it is more likely that it is the EXE for FS which had been changed. You haven't tried installing a "cracked" version recently and got the wrong file, by any chance? Whatever the original cause, it sounds very much like you have a corrupt install of FS2004 on your hands. What does the FSUIPC.Log file say (if you managed to run FS, the Log will be in the FS Modules folder). There's information near the start of the log which may help. Regards, Pete