Pete Dowson

There is absolutely no way that simply registering FSUIPC can mess anything up at all. Only you can do that. If you don't make any setting in FSUIPC than the registered version acts absolutely identically to an unregistered version. All registration does is release the user facilities for you, and then you are fully enabled to make any mess you like! If you've done that then just delete the INI file and read the manual before doing anything else. On the other hand,, if you registered using an illegal pirated registration, or for some reason you have your computer's system date set incorrectly, before your purchase date, so making it look illegal, then FSUIPC will not function correctly unless you delete the registration or correct the system date. Pete

No, not by whether a window is showing or not. If you want multiple uses for the same button you need to program conditions, like having another button pressed at the same time or not, and so on. There's a lot about conditional button actions in the Advanced user's guide. Regards Pete

Yes, you certainly have some serious connection problems. The data is blocking up as shown by these errors: However, the WideServer log is only half of the story. Maybe the Wideclient log will show something more helpful? You always need to look at both ends of the connection, not just one. Last time I saw errors of this type I found I had a failing Network Adapter. Replacing it fixed it. Another possible cause is real memory becoming overfilled on either PC, such that the TCP/IP driver in Windows cannot get enough buffer space. Maybe something you are running has a memory leak? Pete

Aircraft or profile specific assignments ALWAYS operate when that aircraft or profile is current, even if they don't do anything. There's only one table of operations in use at any time, and that is constructed according to the current aircraft or profile. Whether a Window is open or closed makes no difference at all. When an aircraft is loaded all of its gauge files are also loaded, and it is the code gauge files which operate the controls, NOT the graphics in any window. In fact it would completely wreck the whole idea and point of FSUIPC's macros if the gauge graphics had to be visible for them to work -- you might as well use a Key2Mouse program instead (or even a real mouse). Most folks use mouse macros to interface hardware to aircraft and don't want the screen cluttered with software representations of hardware they have in front of them (or overhead, for that matter). I don't know what the problem is you want to "solve", but I suspect you are mis-identifying it. Perhaps you'd like to say what it is you actually have a problem with and want to solve? Regards Pete

And all this with all aircraft, or only that one? What other things are running? For instance, I note a reference to "vasFMC" in your INI file. As I say, you need a process of elimination to see what is causing that mess of things. Pete

If there's only a problem with one specific add-on, you really need to go to their support. You will need to provide more details in any case -- especially clarifying the statement in the title of this thread "starboard engine goes full thrust below 500ft alt" (?). What does that actually mean, and is that the sum total of your "odd effects" which otherwise you say no more about? Altitude above ground? So, on the ground? And as soon as you get to 501 ft the thrust cuts? And how on Earth can the altitude affect the thrust? They are completely unrelated. Sounds like you have some add-on doing wonky things. Try a process of elimination. Stop everything running except default aircraft, then go from there. I'm sure it cannot be anything to do with an FSUIPC update, unless the wonky add-on was only working because of some bug now fixed in FSUIPC. Regards Pete

Hi Kosta, Why not use the Lua sound library functions? Surely easier and more readable, and include sound device selection as well as volume, placement, looping, and stopping? Regards Pete

This says it all: FSUIPC itself isn't affected by any virus checker or firewall, but SimConnect most certainly is, and problems with that will affect FSX running and all SimConnect clients, of which FSUIPC4 is but one. McAfee is known to have been problematic with FSX for over three years. Norton and AVG (including AVG Free) are okay, as virus checkers, and the default firewall in Windows is okay too. Regards Pete

It wouldn't be similar. All the battery extension time facility does is add back a portion of the main battery voltage each time FS deducts any. It would be reasonably easy to implement a utility program to do this, or even write a Lua plug-in program, but I don't feel it is a proper part of what is really an interface program, a box of tools to help connect things and make them work. I'm sure that if it were at all in demand someone would have done one. In fact I think most of the add-on instructor stations you can get have some such facility. And there are those utilities which do other things too, like FSPassengers, which I'm pretty sure has a random failure generator -- quite a sophisticated one I think. http://www.fspassengers.com/ FS FlyingSchool also does similar stuff I think. If it operates through FSUIPC it should function pretty much the same on FSX. I think there are quite a few. Just googling for "FS railures random" I found two pretty quickly, but one was pretty old I admit: at http://www.hermit.supanet.com/ : FS-FAILURE FS Utility - Tested on FS2K, should work on any simulator supported by Peter Dowson's FSUIPC (v2.0 or higher). Fixes FS's pre-planned failures by creating random system, radio, engine, and instrument failures based on probability settings. V2.0 2nd September 2001 at http://www.fspilotshop.com/product_infots_id=1395 : Living Sky -- In flight emergencies Our program, In Flight Emergencies for FSX adds even more to the realism. You can fumble through key sequences to turn on a vacuum, pitot, or brake failures; but how real is that... you know what's coming, and have likely made all the preparations prior to even hitting the key sequence. With In Flight Emergencies you won't know what's coming until it actually happens! That second one is specifically FSX (using SimConnect). I really feel this is an APPLICATION not a tool enabler or fix. so I'd prefer to leave it to specific programs like the ones I've mentioned. Regards Pete

No. It follows on from "... maybe your method makes more sense. I don't know from what you describe." In other words I don't know if it makes sense -- or, rather, I didn't until you just explained more. Regards Pete

If the device is on COM8, then COM8 must be the first port. You are probably not telling SerialFP2 to search again. Also do check that VSPE is actually saying that the pair you are asking it to create are 'Ok'. I'm afraid I cannot support either VSPE or SerialFP2 as both are by others and outside my control. All I can advise and document are what works for me and others. On your subsequent post: This has absolutely nothing to do with any assignment of COM ports. This is saying that FSUIPC cannot get Windows to run SerialFP2. Evidently you've moved it or have got the parameter wrong in the Programs section of the INI file. I suggest you look for the program and make sure it is where you are telling FSUIPC it is. Regards Pete

I hope there was a really good reason to reinstall everything. In general most SimConnect problems seem to arise from attempted reinstalls. Does the 'panel' show your pair operating okay? Er, hold on. COM5 and COM6 are both virtual ports -- you just said so!! How can FSUIPC talk to your device on COM5 when it is a virtual port? You are trying to give both ends of the linked pair to FSUIPC. What does SerialFP2 use? And how can FSUIPC see the device? You never thought about what was going on? Why assign ports at random? You need to apply some logic here, and maybe refer to documentation supplied. The path of signals must be Device port to FSUIPC, virtual port out of FSUIPC into a virtual port on SerialFP2. Please please please review the documentation I provided, which is replete with diagrams explaining all this! Pete

Delete the FSUIPC INI file so you start with a clean plate. Run FS to get a default INI produced. Then edit it just to set "UseProfiles=Yes" (you might also set the [JoyNames] option for auto-assigning letters to devices too whilst you are there). Load up one of your aircraft for which you want to use the "Stick" Profile. Go into any of the options you want for that profile and (i.e. axes, buttons, calibration or keys) and click on the Profiles button. Enter the new Profile name ("Stick" or whatever). Do all the settings for that, and then do the same, selecting Profiles (it will know which one now) for the other three. Do the same for each profile. Now, when you select a new aircraft and click on Profiles you will get a list of existing profiles, and you can assign it to one (or create a new one as you like). Regards Pete

Fixed in 3.989d, now available in the Updates Announcement. Regards Pete

No. If these are profiles for a single aircraft, they are not exactly profiles are they, but very "aircraft specific". You need to decide whether you want different settings for each and every aircraft or a set of reusable profiles. Additionally, if all those were to be usable by the same aircraft, the profile name "Custom Set X" would have to be the same, not 1, 2, 3, 4. The aircraft is either referenced in the section name (for "aircraft specific"), or via the [Profile.] section which lists the aircraft assigned to that profile. I really cannot envisage any other scenario and so I am rather confused about what it is you are trying to do. Profiles are assigned to aircraft and those assignments are saved in the appropriately named [Profile ...] section. Yes, almost -- but you only need assign an aircraft to a profile once, not separately for each type of setting. That's the whole point of it all. It is supposed to make it easy -- which it would be if you simply followed the documentation and used the user-interface facilities. I'm really not sure why you are intent on doing everything in the INI file. It was never intended to be edited manually for such straight-forward and oft-needed uses. Of course it does. ALL of the settings for FSUIPC are in the INI file. But you shouldn't need to worry about any of that for all the simple things you are talking about doing! Of course, in all of the axis and button assignments. But you can use Letters instead of Numbers and FSUIPC will match them up by name. Please do refer to the documentation on this. I cannot reproduce it here! If it isn't connected it won't be there by number, but the letter assignments stay. Why are you so bothered about the INI file? Why not just use the User Facilities which have been designed to solve all these sorts of problems. It seems a bit like instead of referring to the documentation you are diving straight into the INI file and trying to configure everything there, without really knowing what you are doing. Please just use the lettering facilities which are designed explicitly to get around this sort of problem! Regards Pete

In FSX I can read the realism setting (it's available in an offset), but I can't change it. It's an improvement over FS9 where I could do neither! ;-) Regards Pete

Is GameSpy the system supported by FSX natively? I know FSX is supposed to support multiple-user cockpits, but I know almost nothing about it. I always thought it was really designed for use in a local network rather than via remote connections. Again, I don't know fshost at all so I can't really comment. Well, you could do that, but I wouldn't like to think what the latency would do to a pilot trying to control the aircraft. If the remote copy is merely acting a co-pilot, checking systems, switching radios etc, then I don't see why there'd be any problems. I do supply a pair of Lua plug-in programs with FS, demonstrating the ability of the Sockets facilities in the Lua interpreter to have one copy of FS slaved to another, over a Network. Doing that over the internet, possibly with a Server program intervening, shouldn't be so difficult. You need to add a lot more data of course if the instrumentation is to match correctly too, and maybe to make it work both ways. The Lua method was done as a test, a demo, and isn't that efficient for a production program, being interpreted. But it allows easy prototyping. Not sure how WideFS comes into it. That's merely an extension to the FSUIPC interface. Surely you'd be using the FSUIPC interface directly? Or, for FSX only, probably SimConnect which would be more efficient for you again (FSUIPC uses SimConnect). You might even be able to use SimConnect directly over the Internet -- it is TCP after all. As far as WideFS TCP/UDP ports, they are as defined in the INI file. Only 8002 and 9002 by default. But as I say, I doubt that this is at all relevant. Regards Pete

If your differing needs affect things other than FSUIPC's axes, buttons, keys and joystick calibration sections, then I may understand a little more, though generally things like weather, geographical settings and so on are selectable quite readily by what Flight you choose to load. If you are changing other things, like scenery density, involving parameters in the FSX CFG file, then maybe your method makes more sense. I don't know from what you describe. Regards Pete

There is no difference between the separate GPSout.DLL you used with FS9 and the one built into FSUIPC4. There are the same. Maybe you have the wrong serial port, or possibly some other program (like the PDA's own service program) has taken control of it? I assume FSUIPC is running okay? Have you checked the FSUIPC4.LOG file -- if it has problems getting the data from SimConnect then it cannot service the GPSout facility. Also, you do not mention the version of FSUIPC4. If it is earlier than 4.60 please update. Regards Pete

Sorry, I don't understand that. There's no similarity between selecting flap positions and operating the Gear, which is merely up or down. Furthermore, the Gear was a case where there's no axis facility in FS -- the example was how to apply a hardware axis to other switching control events. Both FS and FSUIPC support a flap axis and you can assign to it directly. I don't think you are assigning your flaps lever to the flaps axis, that's why. I've no idea what you are assigning to, but only axes are "calibrated". You see no calibration for Gear operation, do you? Do it in the same way as assigning any axis. You are confusing on/off or up/down toggling controls with axes. Pete

Hmm. Strange. Yes, it's a bug in the user interface. It is actually changing the parameter in the INI file, and the option should stick okay -- until you visit the options screen again! :-( This bug must several years old! I'll fix it immediately. Look for an update in the "Updates" announcement later today. Regards Pete

Without seeing the code I don't think anyone can help. Maybe that version of UIPCHello is so old it does not know about FSX and therefore needs that Sim Name adding? Why not try debugging it yourself? Your C/C++ compiler must have an associated debugger, so you can see what is happening there. Also FSUIPC includes Logging facilities. You should find the IPC read and write logging options incredibly useful when debugging your programs. You can even have the Log shown in real time on screen, using the Console Log facility, if you run FSX in Windowed mode. Regards Pete

They are not linked, they are simply separate facitlies. There are 4 different facilities each of which can be aircraft-specific or profile-specific, or generic:Buttons, Axes, Keys, JoystickCalibration. Naturally, once an aircraft is assigned to a Profile, or is subject to aircraft-specific assignments, in any of these, the other sections will also use sections with the same aircraft or profile name if you select the specific or profile option in those sections. You seem to be comparing the older, original method of making specific assignments and settings -- i.e. by aircraft name (this is called "Aircraft Specific") with the newer, easier to use, "Profile" system. You choose one method or the other. You can't mix them. You can't, and there's no possible reason for it. It sounds like you are mixed up between aircraft-specific settings and Profiles. Having a Profile called "FSX Cessna Skyhawk 172SP" makes no sense because that's a specific aircraft name. Your Profile should be called "Stick Aircraft" if you want it to be easily assignable to any such aircraft. Regards Pete

"They" is the install log, as displayed on screen when you Install FSUIPC, and saved in your FS Modules folder. Please refer to the Installation guide included in the ZIP alongside the installer. Pete

Depends what FSX data you want. In general it is a job for two programs -- one in the FS PC interfacing to FS via FSUIPC or SimConnect, getting the required data and sending it on a selected COM port, and another program in the computer or device you are connecting the serial cable to which can read and process that data. If you are only interested in position, speed, direction, altitude, then the first program could be omitted -- you could use the FSUIPC built-in GPSout facility to do that job for you. There's even a simple text mode you can select if the NMEA and Aviation formats aren't suitable. Without more information that's about all I can say. Note that after this evening (Saturday 18th) I'm off-line till Friday 24th. Regards Pete