Pete Dowson

Okay. I made a couple of changes. I don't know if they'll help because I'm not really sure where the problem is arising. i'm now checking the coordinates and making sure that the docked window is within the confines of FS's display. And I've separated the code more from some new code added recently to support the WideFS Lua "TextMenu" facility. I'm suspicious that there may have been some unwanted interaction there even when the latter isn't actually in use. So, I need feedback, please. download FSUIPC4932bTest and try it please. Let me know as soon as you can -- I'm on holiday from Saturday for 10 days and would like to get this sorted and release 4.933 before then if possible. Thanks! Pete

There's no "P3D release" of FSUIPC, there has just been a constant series of updates of FSUIPC4 for the last 9 years. P3D support has been included for several of those years. The "Radar Contact" window support is the same as the support for Lua display windows and so on. They are all part of the one FS facility. I don't know why you are observing a problem recently which you'd not had before, but nothing anywhere near related to these Windows has been knowingly changed for years. Maybe there is a new problem, but i would need to know more and ideally be able to reprduce it to work out why. I am going to put in checks for the Window position, making sure it is within screen limits. For a docked Window it must be within the FS window, so that should be easy enough. I can't really limit it so easily for an undocked Window as that can be moved onto other screens. There's no registry keys associated with FSUIPC. All of your settings are in your INI file and your registration is in your KEY file. There's nothnig else, and either of those files are touched by installing, except for the KEY file if you opt to re-register for any strange reason. BTW are there lots of reports of this phenomenon over in the RC forum? I would have thought there's be more reports if it was really an FSUIPC problem rather than some strange interaction causing this off-screen positioning. Regards Pete

In that case the most likely thing is something else is also controlling the throttle. Check for other assignments, both in FSUIPC and FS. If you recently had a different throttle attachment which was assigned, and now it is disconnected, it could well be related to that. If you aren't sure about FSUIPC assignments show me your FSUIPC INI file -- past its contents in a message here. Pete

I've had a quick look, and P3D2.2 is no different in this facility from P3D 2.1 or 2.0. But 2.x is different from P3D 1.4 in one crucial aspect I hadn't noticed:- the function I call to delete the AI is identical, line for line, except for one important change which I missed -- a second parameter, never actually used in any case, must now not be supplied, otherwise the return corrupts the stack! Odd that no one has experienced this problem in 2.0 or 2.1, but it must often crash those too. The fix is a bit messy, and I'm tied up tonight and maybe tomorrow, but i'll get an update out as soon as i can. It'll be 4.932b. I would still like to see the details I asked for, to confirm what I've found by inspection. Pete

As usual, I need information. If it crashes citing FSUIPC then there is more information attached to it. That information is ALWAYS needed as it gives me the location of the crash and the error type! Also please supply the complete FSUIPC log up to the point of the crash. Again, a 100% requirement. Not supplying such info with the initial report only succeeds in delaying a fix, if there is one 9i.e. if it isn't something I can't get around in P3D And you have no information either? :-( Pete

Why have you posted this under the thread title "FSUIPC and EZDOK"? Folks who do actually know Bodnar boards and might therefore help you won't be looking at this thread with such a title. Please always think before you post. I think you misunderstand. FSUIPC is not a hardware driver. It is an interface into FS for applications, including third party hardware drivers. As far as I know the Bodnar INPUT boards are standard USB boards which emuiate joystick devices, Both FSUIPC and FS support joysticks with up to 8 axes, 2 POVs and 32 buttons. If your board has more than this then the others would need to be dealt with by a separate program, or by a Lua plug-in, programmed using the com HID functions. For outputs, to indicators, lights and displays, you'd certainly need to write the driver yourself, maybe as part of that Lua plug-in. You might get more help over in the myCockpit forums where there are a lot of Bodnar users. See http://www.mycockpit.org/forums/ Pete

It's nothing really to do with either FSUIPC or EZDOK, but simply loss of keyboard focus on FS. You can stop FS pausing on lost focus -- it's one of its Settings options. But to get the focus back on FS you would need to click on its window after you've finished with EZDOK settings, which are in a separate process (hence the loss of focus on the FS focus). Pete

Do you mean there's no response at all to any movement in that lever? If so, then it sounds like a wiring fault. FSUIPC cannot fix hardware which isn't working correctly. Its calibration facilities are just a more precise way of doing what FS should do in any case --it isn't essentially different. And in any case, you always first need to calibrate in Windows (the game controllers app, or properties for the device when selected). As the saying goes, "rubbish in, rubbish out". Better calibrated rubbish is still rubbish I'm afraid. Regards Pete

My PFC and PFCFSX drivers are for the serial port PFC models, no longer made -- all of their new equipment is pure USB. There is a PFCHID driver for the USB consoles and throttle quadrant, but their current yokes and pedals are normal USB joystick devices and need nothing extra. And yes, my FSX stuff all works with specific supported versions of P3D -- they rely on FSUIPC for the interface, so you'd need to see the release data for FSUIPC to check versions supported. Thanks Thomas. Does A2A know their modelling is so far out? Regards Pete

I think you need to deal with the A2A folks about this, then. I am pretty sure that you can change parameters in the Aircraft.CFG file to alter aileron and elevator (and rudder) effectiveness. Perhaps you can experiment and apply your practical knowledge to the problem, then, when you have it right, inform A2A of just how wrong they have it and how to put it right. This isn't my arae of expertise so I'm not the one to advise on aircraft modelling. All I know is that it is wrong to attribute the blame to the controls and there's no way of making them truly more sensitive without penalty, such as limiting the amount of movement you can apply. Obviously if the whole range of the control input were applied only to the central region of surface movement, then , yes, a small amount of yoke movement would yield a bigger amount of surface movement. But that wouldn't make the reaction of the aircraft less "sluggish" -- the actual speed at which the aircraft reacts to the surface changes is to do with the modelling. BTW re-reading your original post, I see this is in error: I just checked, and slope 15 is the least sensitive in the central area, as clearly indicated by the central flattening. If you want a faster response in the centre, then the negative slopes, down to -15 are obviously the ones, as the steep centre slope shows. Of course, in order to maintain the complete range over the yoke movement, you pay for this will less sensitivity at the extremes. I've not tried any A2A aircraft, so I can't compare. I learned to fly in a Cessna 150 and 150A, and also flew a Cherokee for a bit. But because of my Retinitis Pigmentosa (only discovered when having my medical ready to go solo) i never could proceed to a license. That is why, all those years ago, I resorted to simulation. Pete

You should absolutely NEVER need anything out side the normal slope by more than a little flatness, to actually LESSEN sensitivity a little near the centre where otherwise you get a tendency to over correct. Really the linear response (0) is what the aircraft designers have designed for. The properly calibrated yoke will deliver the entire range from full up to full down elevator and full left to full right aileron. The rest is up to the aircraft model. A fast fighter jet or an aerobatic stunt plane will give you a much more sprightly and immediate response than a large airliner or prop. If you aren't happy with the modelling, find a better model, or revise your thoughts as to what feels correct. No yoke will be any different in this regard. It isn't the sensitivity of the yoke, it is the behaviour of the aircraft. Pete

Delete all the old files (go by file date), leave only those listed in the INI - or simply delete them all if you don't really want to resume flying from any. Then tell me EXACTLY in what circumstances you get one left over from the 10 in future. Otherwise there's really nothing I can do. As I said, the facility has been working for everyone else for over 15 years and i'm not about to change anything now without good and proven reason. Pete

The files are all FLT, WX and FSSAVED files? Really? There's no way FSUIPC wouldn't delete those unless you've deleted the INI file on occasion, which would destroy its ability to erase them because the list of the last 10 would be gone. FSUIPC doesn't actuall save any files, BTW, it simply calls the FS facilities to save them, sane as you can via the ; key or the menus. They will all say "saved by FSUIPC" in the comments because that comment is provided to FS. Pete

It isn't FSUIPC keeping those. It is keeping 10, those 10 shown above, all for Friday. Maybe you aren't looking at the FLT/WX files but some files saved by some other add-on aircraft? FSUIPC can manage those for you too, but you have to give it the details of their names and locations, as documented. Pete

The mouse button press was always optional, and in fact added later than mouse look. There are assignable controls to turn on/off/toggle mouse look, as documented. Please see the drop-down assigments list for buttons or keypresses. Pete

Why are your autosave files kept for a long time? I have autosaves made every 3 minutes, with a maximum of 10 saved. After 30 minutes flying the ones older than 30 minutes old are gone! Please explain to me what you are doing which results in such confusion, then maybe I'll understand, because at present it does seem to me extremely strange. The autosave system in FSUIPC is the same as it was in the separate Autosave module for FS204 and actually dates way back to FS98 days, i.e. 16 years, with no one ever being so confused or wanting it changed in the way you are suggesting. Pete

Well, I didn't anticipate people accumulating or saving these for so long. A week seems more than ample when the whole idea of Autosave was to allow a previous position to be reattained after a crash (aircraft or FS or PC crash). And the old ones are deleted as new ones are created, only saving a certain number (10 by default). Surely you aren't using autosaved files as starting positions dating back more than a few minutes, or hours. Why isn't a week enough? If for some strange reason you do want more definitive dating please just look at the date of the file.. Pete

Well, the log is incomplete as you stasrted a New Log, so lopping off the initialisation, and you didn't close FS beforehand as I asked. Nevertheless, as far as it goes it shows everything is correct. The very last part, before you stopped it (rather than close down) shows RC displaying: <MEVEL>38m/25./0 1-Ground on 13522 Main-0. I'm sure that window is actually somewhere off screen -- check your INI file again for the Radar Contact window parameters. Maybe they are also being stored in your flight, the one you are loading to start with? Check that. The ones there may override FSUIPC's settings (the Window is an FS window and it really controls where it goes). The section in the FLT file will be similar to the one in FS's INI file, if it is there. Somehow I think you've had some sort of problem, with Windows being mispositioned (maybe a corrupt FLT file) and the bad parameters have stuck around. Pete

Cryptic numbers? Like what, please? I use no cryptic numbers, only day and time, so you know how long ago your restart will take you. DDD HHMMSS, day of week, hour minute second. How much easier could it be? Pete

These options are good: but the Radar Contact window position seems to be set to a rather unlikely place: Those numbers are: top left x, y and horizontal and vertical size. The vertical start position at 14417 pixels would place it well off most folks screens. Are you maybe using multiple screens and changed since it last worked okay? Try deleting that line altogether so it comes up in its default size and position to start with. If that works I won't need to see the Log. Pete

Go to the FSUIPC menu, Logging page, and enable both Key/Button and ipc Write logging. Run the test you mention above, but otherwise keep the session short otherwise the log will become too large. Close FS. Then find the log file (in the Modules folder) and if it isn't too large, paste its contents into a message here. If it is large, ZIP it up and send it to petedowson@btconnect.com. Oh, best too to show me your FSUIPC4.INI file please, in case it is related to settings. Also please list all other add-ons you are running with FSX at the time. Pete

There is a keyboard focus issue with running P3D 2.2 in full screen mode. It is not focus on the RC4 window -- that isn't a separate window which can take the focus: the keystrokes are intercepted on their way to P3D itself, so the keyboard focus is with P3D. But initially when switching P3D to full screen mode it appears to lose its focus. Clicking on it with the mouse once will restore focus and should enable you to continue. The focus problem with P3D 2.2 should be reported to Lockheed Martin. It needs fixing for sure. There's another recent thread on just this problem, which is the only reason I know about it. I didn't connect the two issues (RC4 and keypress assignments in general) until now. Best if all users affected report it to L-M so it gets fixed sooner. See the thread entitled FSUIPC Key stroke commands Pete

Nothing in FSUIPC has changed in regard to these facilities, except for the recent addition of assignable controls to toggle them on and off (see FSUIPC4 History document, item 9 in the 'New Facilities' for version 4.93). Unless disabled by an INI file option, the centre button has always been used when kept pressed to operate the mouse look option (panning in the virtual cockpit), but the mouse move option, when enabled, has always used the wheel, in both directions, for moving the eyepoint back/forth and left/right, without the need to press the button. Obviously the wheel cannot simultaneously be used for other things. To use it for other cockpit functions you must disable the 'mouse move' facility, maybe by turning it off by assigning a button or keypress to "Mousemove option toggle". The mouse move forward back and left / right are part of the same facility. You cannot realistically expect those functions be separated. You just need to toggle the option off when not needed and on again when needed. Pete

Please see the download links subforum. Where you download FSUIPC updates I put a link into the P3D thread where the hotfix is buried. I've pleaded with L-M to make it part of the normal user account downloads oage all to no avail. Well, FSUIPC doesn't touch any files at all outside of its own set -- LOG, KEY and INI. And I don't believe that any aircraft does (or even can) modify its own CFG file, so I really don't understand what you have going on there. If the brakes are still working correctly on all other aircraft then I can only assume that either something has somehow got corrupted in the aircraft files (in which case reinstall it), or there is a problem with it that was always there but you've not noticed it before. The indications from P3D don't tell you what is going on with the brakes exactly enough in any case. You could try logging the axis values in FSUIPC. If you run P3D in Windowed mode, temporarily, and enable FSUIPC's console log, you'll be able to see the axis values change in real time. The red brakes messages on screen (assuming you've not suppressed them) show "brakes" when both left and right pressures are the same, and "differential brakes" when they are different. Regards Pete

Sorry, no. It wasn't me that tweaked it. Pete