Pete Dowson

All FSUIPC does is call the Save Flight facility in FS -- exactly the same as when you press ";" and enter a name. It simply automates that and provides the name. Other add-ons can detect when a flight is being saved and then save their own files too. I'm afraid I've no idea whether ProATC/X does such. But because, for autosave, FSUIPC instigates the saving (obviously as it ia automatic on a time interval), how would it be able to do anything with ProATC/X. Seems the shoe has to go on the other foot doesn't it? Regards Pete

Well I am 70 this year, so I'm joining you! Sorry, you need to update to 3.999y5 too. Same problem. there's only one check for both FSUIPC and WideFS registration. Neither FSUIPC nor WideFS can be held responsibnle for that. Neither know anything about any other product DLLs and certainly never delete anything there. So you are sure that you are now using 3.999y5? In that case, please show me the FSUIPC.LOG file. You can paste it into a message here. Make sure FS is closed first. Regards Pete

Sorry, i don't understand. Are you saying it is no use unless you have control of the console window too? The only reason I separated that is that it would be more work. I can't just create it and kill it so easily. The things being logged are trivial in comparison. Why would you need console logging control? Surely, if running in Windowed mode you'd leave the console on in any case. In full screen mode you can't see it in any case. Pete

Not that I know of. There's a "reload aircraft" FS control you can send, but that just reloads the current aircraft. The only way I can think of doing it would be to create a flight (eg save the current flight with your own chosen name), edit the FLT file to put the name of the aircraft you want loaded in, then load that flight. Not at present. It would be reasonably easy to add such, though, via an offset with bit values for each option. Not the console selection though. I could enable the rest to be manipulated in the next update to FSUIPC4 (only) if that would be useful. Regards Pete

You appear to have a lot of redundant stuff there. Please delete all the lines from the first one !1=1[General] to Console=No inclusive, so that the first line is now [JoyNames] All that stuff is being ignored in any case, but it will remain confusing should you ever need to adjust something there. Then, please update your FSUIPC. You are still using 4.703 which has not been supported now for a long long time! The earliest supported version is 4.853, and even that is soon to be replaced. No, you only need to press the "Reload" button in the Buttons tab. There are reload buttons for all assignment and calibration tabs so you can play with the INI file and test things out. You don't need to keep reloading FS. Pete

Well, a Lua plug-in automatically started with FSUIPC (via "ipcReady.lua " for example) could certainly do that. The Lua plug-in facility was specifically added to FSUIPC in order to allow this sort of on-going enhancement without me having to continue to mess with the main code. After all, it is becoming quite long in the tooth now, and increasingly likely to become buggy if I have to mess with code I've long forgotten! Regards Pete

Yes. That's what WideFS is for. WideFS extends the FSUIPC interface over a Network of PCs. Ah, well, of course the WideClient part of WideFS only runs on PCs under Windows (XP or later). To talk to other types of computer you'd need to run a program on the Server to do the interfacing for you. You could certainly do it pretty easily with a Lua plug-in. Please see the examples already provided in the package in your FSUIPC documents folder. There's a master/slave example, for instance, using TCP/IP to slave a Networked copy of FS from another. Half of that would be a start. Regards Pete

You posted the same question twice. Please see my answer to the earlier posting. Pete

The state of VRI buttons aren't detected. When you press and release they send only one message. So "press" and "release" really have no direct meaning in relation to the button pressing. What happens instead is that alternate press/release cycles set an "on" state and "off" state, like a button used for a bedside light switch. So, you probably had it right first time, assuming you want to set 66C0 to 1 or to 0 alternately. Yes, that means the full cycle is two press/releases to go from 0 to 1 and back to 0. Isn't that what you want? Else what exactly do you want? If you program both press and release to set 1, you would need some other button or method to set it to 0. Regards Pete

Well, I am amazed! Great detective work on your part! It seems incredible how "helpful" Windows is (NOT!). Thank's for explaining it so clearly. I think I shall add this snippet to one of the FAQ's already in the FAQ aubforum. Or, actually, it would really be better coming from it's discoverer. Could you do that, please? Think of a suitable title and post your solution to the FAQ subforum? I will then make sure it is pinned. Thank you! Pete

Good. That's a relief! Pete

No rudder really then? If you don't leave them all connected, then it will be best, BEFORE assigning anything, to select the joy letter mode of identifying devices -- there's a chapter on this in the User Guide. If you don't do this then things will certainly go wrong at times -- the numbers used are assigned by Windows and are only fixed whilst the device is connected. Yes, it is easier, less confusing, and more efficient. The FS controls are supported because there are some add-on aircraft which need them. Best to make a default set of assignments suited to your devices, and ONLY make profile-specific assignments if really necessary. This is usually when switching from, for example, prop controls (with mixture and prop pitch lervers) to jets (with extra throttle controls or things like steering tiller, reversers and spoiler), or to helicopter controls (completely different) or maybe yoke for Boeing airliners and joystick for Airbus. Set the defaults initially to suit the aircraft type you fly mostly. Regards Pete

What about my other points? Have you no replies? [JoyNames] AutoAssignLetters=No 1=Saitek Pro Flight Rudder Pedals 1.GUID={E1D20B50-5A53-11E1-8001-444553540000} 0=USB Game Controllers 0.GUID={88769DC0-EC99-11DE-8004-444553540000} You have these default assignments, to your yoke only by the look of it: [Axes] 0=0X,256,F,65763,0,0,0 Axis ailerons Set 1=0U,256,F,65762,0,0,0 Axis Elevator Set 2=0V,256,F,65763,0,0,0 Axis ailerons Set Why two axes both for ailerons? And you have default calibrations and mappings for those and a lot more. How? [JoystickCalibration] LeftBrake=-16384,16383 RightBrake=-16384,16383 Spoilers=-16256,16384/16 Flaps=-16383,16384/16 Reverser=0,0 Aileron=-16384,0,0,16383 Rudder=-16384,0,0,16191 Throttle=-16384,16192 Mixture=-16380,16380 Elevator=-16384,0,0,16383 MapThr1to234=Yes MapThr12to34=Yes MapThr12to123=Yes PropPitch=-16384,16383 The Cessna assignments seem to be a mixture of FS controls and direct controls. why mixed? Also there are assignments for a non-existent device 2. [Axes.cessna152] 0=0X,1,F,65763,0,0,0 1=0Y,256,F,65762,0,0,0 2=0Z,256,F,65765,0,0,0 3=0V,256,D,23,0,0,0 4=1X,256,F,66387,0,0,0 5=1Y,256,F,66388,0,0,0 6=1R,256,F,65764,0,0,0 7=2X,256,D,4,0,0,0 8=2R,256,D,6,0,0,0 [JoystickCalibration.cessna152] Aileron=-16380,0,0,16380 Elevator=-16159,0,0,16224 Rudder=-16384,0,0,16255 PropPitch=-16384,16383 Mixture=-16254,16320 LeftBrake=-16383,16384/16 RightBrake=-16383,16384/16 Spoilers=-16383,16384/16 Flaps=-16383,16384/16 Reverser=0,0 SlopeRudder=-1 Throttle=-16380,16380 The 747 controls even more so, but with some real oddities: You appear to have selected the older axes not the current "Axis ..." controls. Also it has assignments for a device 2 which doesn't appewar to exist according to the scanned device list! [Axes.74710] 0=0X,256,F,65695,0,0,0 Aileron set (this is the older control, not the current FS "Axis" control) 1=0Y,256,F,65694,0,0,0 elevator set (") 2=0Z,256,D,22,0,0,0 3=0U,256,D,4,0,0,0 4=0V,256,D,23,0,0,0 5=1X,256,D,7,0,0,0 6=1Y,256,D,8,0,0,0 7=1R,256,F,65696,0,0,0 Rudder Set (this is the older control, not the current FS control) 8=2X,256,F,65697,0,0,0 Throttle Set (") 9=2Y,256,F,65767,0,0,0 Prop pitch set (for a 747? Huh?) 10=2R,256,F,65773,0,0,0 Mixture Set (?) The FA18 assignments are all to FS controls: [Axes.FA18] 0=0X,256,F,65763,0,0,0 Ailerons 1=0Y,256,F,65762,0,0,0 Elevator 2=0Z,256,F,65765,0,0,0 Throttle 3=0U,256,F,65762,0,0,0 Elevator 4=0V,256,F,65763,0,0,0 Ailerons 5=1R,256,F,65764,0,0,0 Rudder Seems you have two ailerons and two elevators, but no brakes assigned. I think you've made a bit of a mess, do you see? Without assigning "direct to FSUIPC" you won't be getting FSUIPC to arbitrate between the pairs of controls, so they will conflict. I expect this is your problem. Quite honestly, you seem to be making more and more of a mess. Perhaps you could epxlain what it is you are trying to do. Why all these differing assignments? How many control devices do you have -- only two seem to be connected, so what it the problem with doing basic assignments just the once and use them for all aircraft? In the end I suspect you'd be better off deleting your INI file and starting again. Regards Pete

Okay. That's the same as using FS for assignment. Please tell me the names of the controls you assigned -- there are several variants, each suited to different needs -- and some need different settings. You would generally find it much less confusing and, in fact, more efficient, to assign "direct to fSUIPC calibation" unless you do not want to calibrate for some reason. Perhaps you need to show me the INI file too. But please concentrate on my comments above first. Since it makes no difference to FSUIPC, this is exactly why I think you are still confusing yourself, as you did before. Let me see the INI file as you have it now. If you only ever assign to FS controls, and use the same controls for every aircraft, you would probably find it much easier to assign in FS itself. You can still calibrate in FSUIPC. I've no idea why you are trying to make things more complex. Do you need different controls for each aircraft? If you use the same controls for each, why are you assigning the axes "profile specific"? You would be better assigning them once and for all, non-specific, don't you think? Pete

So you assigned these items okay? Where, in FS or in FSUIPC? And to which specific controls -- FS controls or Direct to Calibration? What do you really mean by "impossible to calibrate"? Please explain. I cannot see what you see, you must tell me. Did you never have anything assigned and calibrated before? Have you only just got these controls? Pete

It doesn't appear to be a value provided by FS at all. I don't think it even features in the Aircraft CFG or AIR files (but I might be wrong on that -- it's just that I don't see such a value). Maybe it can be computed from other aircraft factors, but my guess is that the gauge you mention used some sort of database or look-up table for each aircraft model it supported. Regards Pete

Okay. Progress! If anyone still has a problem with FSUIPC4's MouseLook facility not working, or working inconsistently, please download this interim version and try it. Let me know, please: FSUIPC4859pTEST.zip It's taken two days solid to find a work-around which seems to fix the issue when the FSUIPC loader is used. I'm hoping that the issue experienced by some even without the Loader is similar so that the same fix works for that too. Let me know. Regards Pete

If anyone still has a problem with FSUIPC4's MouseLook facility not working, or working inconsistently, please download this interim version and try it. Let me know, please: FSUIPC4859pTEST.zip It's taken two days solid to find a work-around which seems to fix the issue when the FSUIPC loader is used. I'm hoping that the issue experienced by some even without the Loader is similar so that the same fix works for that too. Let me know. Regards Pete

Sorry, but you'll need to explain a little more. I've no idea what you are talking about. I really can't help unless you say exactrly what you are doing and what you are trying to do, and what you think is not correct. Pete

That isn't a default aircraft. I can't find a single instance of the button in any of the defaults, which is why there is no related FS facility. If that button does actually work in the aircraft you are using then I assume the makers have provided a means of using it? You can do all sorts of things with a Lua plug-in. It's a programming interface built into FSUIPC with all sorts of facilities. I was only suggesting that, if the implementation in FS was not to your liking, you would probably have to suppress the FS sound altogether (delete the sound itself) and play/slience your own when you wish, by whatever criteria you choose. Maybe the makers of the add-on you are using will be able to advise on what their implementation does? Possibly it isn't relying on the default FS behaviour? I'm afraid I don't know many add-on aircraft. The FSUIPC facilities specifically relate to FS internals. There are lots of examples provided in the package, and many others provided by users in the User Contributions subforum. Please read the Lua documents provided in your FSUIPC Documents folder and see the examples. It is all explained there. The Lua libraries allow all sorts of things to be done. It's a flexible way of expanding FSUIPC's facilities without having to write external programs. Pete

Well, sorry, but I didn't tell you that. I know from some reports here that some folks have had success with joystick devices not disconnecting when assigned in FSUIPC, but I don't know if that applies to Saitek things. I don't think you delete anything in P3D, only disable controllers -- one setting to change. Maybe there's some Saitek software running? Or their driver is installed incorrectly? Probably best not to use any of their software. I think your best bet is to ask in the Saitek support forum. I'm afraid I cannot support their devices myself. Regards Pete

I doubt that installing the Airbus changes FSUIPC's INI. That wouldn't make sense. Regards Pete

I couldn't resist having a quick look before retiring. The access violation offset points to the FSUIPC4 entry point! None of my code has been executed yet! Ouch! I've made a re-compiled copy with slightly different compilation options. Could you try it please, and let me know? fsuipc4859nTEST.zip Thanks, Pete

Those are really default settings, so you've not really done any specific calibration. You do really need to make sure there's enough dead area at each extreme -- most pedals (and yokes) do not necessarily always return the "ideal" values when you take your foot off, so you'll get turns when you don't want them. -16383 is the minimum possible, and +16384 is actually one GREATER than the max possibly (16383), so that's all wrong. Please do read the step-by-step guide to calibration in the FSUIPC user guide. It tells you precisely what to do. I cannot recomment a slope as it is entirely dependent on your pedals and how you use them. It is also very dependent on the aircraft. You probably need to turn down some of the aircraft realism sliders to start with -- the full right settings make things far too sensitive with most aircraft. To make the rudders less sensitive in the central area, but allowing you to nudge them a little this way and that, you'll need to narrow or even get rid of that dead zone (-512 to 512) and instead choose a slope with a flattened central area -- but not too flat. Experiment. Pete

Actually, yes, you are the first to ever report an Access Violation problem during start-up. None of the others are access violations, or at least none that were reported with sufficiant information. This is all very useful information and will help me immensely to work out what is wrong. Interesting that you made it start with a default INI file too -- the INI file is processed before the Logging is started, and it would otherwise be possible that some mangled entry is the culprit. You've already eliminated that as a possibility. It's getting late here now but I'll look at this first thing in the morning. Regards Pete