Pete Dowson

Yes. I use Win7 64-bit and have done since the first Beta releases. They are, like FS, still 32-bit programs, but they do not depend upon anything which changes between 32-bit and 64-bit operating systems. The only stuff you really need to check on are drivers for your hardware - the motherboard, the video card, the sound card, and all the peripheral bits and pieces. These days most current hardware has updated 64-bit drivers, but it is best to check first, especially if you have any older parts, and even collect the drivers you need. Regards Pete

Hmm. What a strange idea! So what are the keyboard short-cuts for each "detente"? Right-clicking on the screen image of the throttles, you mean? Does that cause any FS controls to be sent at all (find out by enabling FSUIPC "event" logging first, then doing the right-clicking). If so then maybe you can program those as part of the zone selection for the throttle axis assignments. Additionally, if there are no keyboard short-cuts for each selection, you could instead read the axis values (in FSUIPC's assignments tab) which correspond to the centre of each of the detente sections, and then, in the axis assignments in FSUIPC, program 4 zones which send "AXIS THROTTLEn SET" controls with the parameter set to that central value. Having done that you can de-assign the left-hand axis assignments and just rely on each zone sending the right value. Regards Pete

Yes. I really can't think of any other explanation. I see. Sorry, I didn't know they were programmable. RAW mode is okay if you do have precise control. I don't know. What is different? Note that in FSUIPC3 I use the Windows "joy" interface for both axis and button scanning. In FSUIPC4 I used DirectInput for axis scanning and the "joy" interface for button scanning until recently -- 4.60 uses DirectInput for both. I changed because some devices gave problems when using the different interfaces. Regards Pete

I had to look that one up -- as far as I can see, yes, it is. But try it to make sure. Yes, as they do now with FSX's EXE.XML and DLL.XML, the ways to autostart EXE and DLL's in FSX. Unfortunately there's no such thing. There's always a fool which will prove that. ;-) No. Not only that but to get anything loaded in FSX means editing those XML files -- much more error prone and fussy than an INI! Except on FSX, where the DLL.XML needs editing, same as FSUIPC.INI really. Of course your installer could do such a job. Well you can get around that by building in both the mechanisms for FS9 and FSX into the one module. They don't conflict. You'd have two entry points, two initialisations and terminations, depending which FS it was. Regards Pete

No, that's wrong. The Gateway and Preferred DNS fields on all your PCs should contain the IP address of your router -- the same IP address as you have to use to access it to set it up. Regards Pete

How are those detente's implemented in the aircraft? Are they really just values of the throttle input, or special controls, buttons or keystrokes? You don't have any detentes on your throttle quadrant, so whatever you do with that you'd have to remember of mark the positions in any case, wouldn't you? If you merely want the throttles to send keystrokes or other controls, you don't calibrate them as axes with continuous values, but assign the appropriate controls to ranges of throttle movement on the right-hand part of the Axis assignments tab. Don't the aircraft makers supply any helpful information to throttle quadrant users? It can't be unique to Saitek. Everyone with an analogue throttle will be asking the same questions, whether they use FSUIPC or not. So surely the makers have answers? I've never used an Airbus model either, and must confess I've really not much interest in a completely automated fly-by-wire (even button-pushing?0 experience, as good and European as those Airbus's may be. Maybe the throttle quadrant isn't really needed and you really only need a 4-way switch? You can program an axis to act as a multiway switch -- that is via assignment of zones as I mentioned. Regards Pete

Good! The calibration Tab offers a sync facility. You can set a number of positions which are all to have the same throttle value in FS -- it uses Throttle 1 as the measure, the yardstick, then matches the positions on the others for as many points as needed -- usually not more than 5 or 6 I've found are adequate. Then it simply interpolates between those points. It gives pretty good results. Try it. Regards Pete

Shouldn't this have been added to your older thread about the same subject? It would have been clearer had you done so. I'm not sure I understand. Are you saying that assigning one button (to what?) makes all of your axes flutter? [EDIT AFTER READING MORE] This could be a result of using RAW mode on analogue inputs -- the button scanning probably interferes electrically with the analogue readings on the axes. In RAW mode you are bypassing all of the joystick driver and Windows efforts to give correct readings. RAW mode is used for programmable digital inputs. Can you explain what it is you are trying to do with your axis assignments in FSUIPC? Look at this one example: First of all, you have selected "RAW" mode. WHY? That is really only ever useful for software-controlled axes, like those on EPIC cards, used to set things like radio frequencies, altitudes and headings, where the value being assigned to those things needs to be unmolested. Never try using RAW unless you have a really good and understood reason! That could easily be the first cause of your problems. With RAW mode your incoming values are bypassing Windows and driver calibrations and ignoring all smoothing throughout. Furthermore they limit the incoming values to a range of 0 to 255 or -127 to +127, whereas FS needs -16384 to +16383 for most axes. Normally read and processed axes give that sort of range, especially after correct calibration. It is also possible that your devices are not limiting the RAW values they send to 0-255. If they send a value which exceeds the 8 bits for RAW mode the upper bits will be lost. So a value increasing from 255 to 256 will go from 255 to 0 in one little movement or flutter. When using a programmable source of values, like an EPIC card, the software controlling the values would be limiting the values. Worse, the "Delta" of 0 or 1 will make every little jitter on the axes amplify to quite large movements -- with only 255 maximum values, a real flutter of 1 on your axes will translate into a change of 128. Second, you've assigned this axis to both controls 66421 and 66424 (Axis Propeller1 and 2), which is fine, but then you ALSO used the right-hand zone assignments facility to assign control 65769 (Prop pitch Incr) to the range -127 to 0, and 65771 (Prop pitch Decr) to the upper range (0 to 127). WHY? What on Earth do you think that will accomplish? Everything appears to be in conflict! This analysis appears to apply to every single axis you've assigned! To be honest I cannot see any sensible purpose in anything you've done in the axis assignments. You seem to have gone overboard in using it in the most non-standard and peculiar way. I would suggest that your best solution would be to delete all of the Axis assignments from the INI file and start again. Just because I provide facilities for doing strange or unusual things, it doesn't mean they have to be used, and especially not without understanding the consequences. Please just follow the simple paths as explained and illustrated in the documentation. You should also delete all of the JoystickCalibration sections and re-calibrate all axes, because the current settings are based on that -127 to +127 range. Don't forget to delete everything BEFORE loading FS, not whilst FS is running. regards Pete

Yes, it looks like Windows is getting your server name "raven1" translated into the IP address " 208.67.216.132". Checking this via the Internet it appears to be an Internet address belonging to "OpenDNS" in California: I've no idea why or how this happens -- it will be related to settings in your router. But the easiest way around it is to give WideClient the "ServerIPaddr" parameter instead of the Server name. Each of the PC's on your network will have it's own Local IP address, probably starting 192.168 or similar. Use that. If it isn't fixed, fix it to an IP address of your choice first. See this thread from a few days ago: viewtopic.php?f=54&t=80033 Pete

Maybe. For FSX there's only offset 8320, which does have limitations as stated in the FSUIPC4 offsets status document. Regards Pete

The "base" field in the Monitor dates back many years to when FSUIPC allowed viewing into the data areas of not only FS's GLOBALS.DLL but also many of the other interesting FS modules, like SIM1.DLL. However, there is no GLOBALS.DLL these days nor "local data" as such. As FS was gradually re-written in C++ things got encapsulated in the new object-oriented method (ugh). Most "offsets" are mapped into different places, many in FSUIPC itself. In fact in FSX and ESP all of them are in FSUIPC. There is only one unchangeable "base", reflecting that. I left the field there in case I ever needed to extend beyond the current 16-bit limit (65kb). No. It refers to the FSUIPC SDK. (The FSX SDK was written by Microsoft. FSUIPC is not a Microsoft product). Please browse the Announcements here in the Forum, or view the list of downloads available on the Schiratti site. Regards Pete

What's the matter with you? I'm only trying to help! What's wrong with me explaining how to do things? That is surely not an insult, as you have obviously taken it! I won't bother trying to help if that's how you react! :-( That's a typical symptom of having power management in Windows turning off the power to the USB ports. Go into Windows device manager, find all of the USB hubs and devices with power management tabs, and turn those options off. Unfortunately some versions of Windows default them on -- Microsoft trying to be "green" I suppose. That is NOT the INI file, but the LOG. The INI file is where all your FSUIPC settings are stored. The LOG contains details of things that happen in this session of FS. They are different files. INI files are obviously kept between sessions to retain your settings. In any case it is irrelevant, because your problem is not related to FSUIPC in any case. "More responsive" might mean "less accurate". How do you measure "accuracy" with an analogue throttle lever? Are you noting the resulting RPM for each position or something? Sounds like your throttle is equipped with a log potentiometer instead of a linear one. Or you have set such a slope in FSUIPC, or that sort of response is programed into the modelling of the aircraft in FS. The default FSUIPC slope is linear. If your actual throttle is producing an exponential curve then you'd need to adjust the slope inversely to counter it, if you think that is unrealistic. Maybe, however, it is more a function of the aircraft modelling? Simply making multiple attempts doesn't necessarily help at all, at least not of its own accord. It is surely always best to read the documentation and simply apply what it says rather than blindly doing the same wrong things all the time? To change the response curve in FSUIPC (to make it non-linear) the only way is to use the "slopes" option in FSUIPC. You can choose a slope which counteracts the apparently incorrect behaviour of your throttle device. Certainly you might need to adjust it a little and try it till you find what suits you. If these are the "multiple attempts" you refer to, then how else do you expect to be able to adjust to your particular liking? Pete

I think Win7 is a good system, certainly the best Microsoft has produced since Windows 98. I've no idea why you are having so much difficulty, nothing you report seems to make sense. But have you tried discussing it over on the PM Forums in MyCockpit? http://www.mycockpit.org/forums/ . There's are lot of PM users there, and many Win7 users too. Regards Pete

Well neither the flight plan nor the fonts are anything to do with FSUIPC, WideFS or the connection to FS. You'll need to ask PM support about that. The fonts would be part of the installation, the flight plan is a matter of filesharing and the NetDir business in PM. Well that conflicts with you saying "most everything is working", because if what pmFileCheck says is true, nothing would work. Again giving the lie to the pmFileCheck report. It sounds as if you are getting really mixed up with things "running as administrator" or not. Just don't run ANYTHING "as administrator. It should not be necessary for anything. Stop confusing yourself! Sorry I can't help, you appear to have all my part working. Regards Pete

For FSX you do NOT use the separate module "GPSout" -- FSUIPC4 has the GPSout facility built in and available to all registered users. The configuration is done from within FSUIPC's on-screen options, as described in the User Manual. Otherwise the details will be as in the other threads. I seem to recall that the connection will probably need a serial port cable. From what I've read there I thought that the USB connection doesn't support positional input to that model, but the serial cable allows Aviation mode input (AV400). Regards Pete

That's not really a good reason for implementing it as a DLL. You can do what you want to do by having it started and ended automatically by a parameter in the FSUIPC INI file in any case -- see the chapter on "Programs: facilities to load and run additional programs" in the FSUIPC Advanced Users guide. Writing a program to run in the same process as FS means taking great care to avoid affecting its performance. You don't have the benefit of windows operating its timesharing capabilities, nor will your code necessarily run on a different core. You also have to take great care not to crash FS through any mishandling or using non-reentrant library or FS facilities. It's a lot more work. It depends on whether you are talking about FS9 and before or FSX. For FS9 and before, loadable DLLs are like Gauges but with filetype DLL instead of GAU. Try writing a gauge in C and you'll get the idea. For FSX you'll find information on your questions in the SimConnect SDK. Regards Pete

But, I repeat, you can calibrate in FSUIPC even if you assign in FS. Please re-read my previous message, especially the text in Big Red letters! No. I do not recommend mixing things. Why do you want to assign ONLY the prop pitch via FSUIPC? What is it you cannot do with FS calibration and FS assignments? And if you are using 6 or less axes on eavch controller, why not do it all in FSUIPC if that's what you want? I get the feeling you don't understand anything I'm saying, or that you are omitting something very significant somewhere! This exchange is getting rather futile! :-( Pete

So you have 8 axes altogether. you can use them all with FSX or ESP, through FS or FSUIPC assignments, but if you are using FS9 or earlier you can only use 6 if you choose FSUIPC. Which 6 I'm not sure. You'll need to test. No, I never said anything like that!!! You can use FS for all assignments, or FSUIPC (for 6 per card on FSUIPC3, 8 per card on FSUIPC4). I really wouldn't try mixing them if I were you. The only sure way to avoid FS auto-reassigning is to completely disable the controllers in it. BTW If you are using a prop or turboprop (hence I assume the need for the prop pitch controls), what about the 4x mixture or conditioning controls? Ouch! Sorry, but it seems you are very confused. How did that happen? We were talking about assigning things, not calibrating them! You do not have to assign in FSUIPC to calibrate in FSUIPC!. You never have had to! The axis assignments were a much later addition to FSUIPC and were primarily intended to allow folks to have different assignments automatically selected (eg stick or yoke as appropriate) for different aircraft (not possible in FS without reloading), and also to allow multiple assignments to the same controls with automatic arbitration -- for dual pilot and copilot controls, for example. There are other tricks you can do with FSUIPC axis assignments too, but for straight-forward assignments there's absolutely nothing wrong with using FS for this. Regards Pete

I know nothing watsoever about them. Never heard of "dial". Is that a POV Hat type connection? The windows "joy" API supported by FSUIPC3 (and versions of FS before FS2002) supports 6 analogue axes and one POV. DirectInput supports 8 axes and either 2 or 4 POVs (I don't recall which. offhand). If they are all analogue axes, to use all 8 you'd need to be running FSX or ESP and FSUIPC4 -- or else do your assignments in FS, not in FSUIPC. Apart from any POV implementation I don't think it matters much what you connect where, because you assign them in FS or FSUIPC accordingly. They are all just axes. But if you want to assign only in FSUIPC and you are running FS9 or before, two of the possible 8 axes won't be recognised. Just avoid connecting anything to those., or else assign everything in FS instead. Except for the POV, there should be no difference whatsoever. They are merely analogue axes supplying continuously variable values. Providing you see varying values when you move the control, that's all that matters. Regards Pete

So it is nothing to do with FSUIPC, or any of my software? Why the title to this thread mentioning FSUIPC 4.6 then? No, nothing at all. Sorry. No. I don't know your hardware, I don't have a motion platform, it isn't something I do. Sorry. You need to talk to your suppliers, or at least someone who knows a little about the software you are using. I think you've maybe come to the wrong Forum? :? Regards Pete

But why would you need to? Just don't run WideClient "as administrator" either. If you used the WideClient INI file "Run" or "Runready" facilities to start them, as recommended, you wouldn't have any worries in any case. Regards Pete

It certainly sounds like you've not assigned them correctly nor calibrated correctly. Why quoting figures from the assignments tab? They aren't relevant unless you are programming special actions for Zones (on trhe right-hand side. And do not change the delta unless you have understood it and need to for a special purpose. Looks like you've simply not actually done any calibration. Please follow the very simple and amply explained NUMBERED steps in the User guide, in the section about Calibration. And nothing of what you've said would explain how your toe brakes are operating your nosewheel (i.e. rudder -- FS doesn't actualy have a nosewheel). That must surely be down to an incorrect assignment. Regards Pete

It should do, at least according to the documentation I have from GoFlight. Are you sure they aren't effectively the "off" positions -- FSUIPC's Buttons & Switches tab only detects "off" to "on", but you can still program the off part ("release" too. Please use the Button logging facility, operate each switch and button oin turn (keep a note of the order), and show me the log and the sequence. Didn't I say before, that FS doesn't simulate jet ignition coil selection? What would such a control do if there's nothing inside the software to react? Regards Pete

Well, if you also don't have multiple assignments to the same axes in FSUIPC (which is actually possible to accomplish), then you have something badly broken. Those inputs cannot be generated spuriously by anything in FSUIPC or in FS. They are either because of multiple assignments or something very wrong with your devices or their software drivers. Good luck in finding the causemaybe it will need a removal and re-installation of devices and even FS or Windows? Regards Pete

No. Switching the autopilot on by itself does not necessarily enable altitude hold. You have to engage the modes you want on the autopilot too. Check FS help.