Pete Dowson

Hmm. My thoughts about Negating one of the values isn't going to work. Your results show that the Accelerator and the others are working in opposite directions to each other in any case, no the direction of change is already correct. the problem is that the ranges overlap so much. Let's see. Assuming we use the pre-calibrated values, not RAW, we have Pressed In: 16383 Let out: -16384 versus Pressed In: -16384 Let out: 16383 whilst we want the first to be 16383 to 0 and the second to be -16384 to 0 I'm not sure how best to tackle this. It needs more thought. I'll get back to you. Regards Pete

Your registration doesn't just apply to 3.85 but to any version 3.xx. The current supported version is 3.90, so you should consider updating in any case. You will need to if you want any further support. Regards Pete

You are not actually copying the DLL into the FS modules folder, then. It would overwrite the (very) old version It sounds like you let FS install into its default place in Program Files, which of course are all protected in Vista. That's quite messy. Because FS2004 is not Vista aware, and doesn't obey the rules of a Vista program, the Vista system actually keeps the folders for FS elsewhere. What you see in Explorer isn't the real Modules folder but an aliassed one. I think you can get around this by running Windows Explorer by right-clicking on it and selecting "Run As administrator", then copying the new DLL over the old one. Pete

Please give me the minimum and maximum values you see in the "IN" box on the Axis assignments tab, both with and without the "RAW" option selected, and state which are with the pedal pressed and which released, Thanks, Pete

Okay. so why the business about separation from the wheel? It will be a different axis in any case, so ignore the wheel axis? It seems a bit over the top to have to insert another controller board? Three? Ah, is this a set with clutch as well? Maybe they don't default to having two of the pedals on one axis, then? Is there any reason why the Profiler won't do the job satisfactorily for you? Not necessarily "not possible". Let's see ... in FSUIPC you can certainly assign both axes to the same Rudder control. That isn't a problem. The problem is that they will both share the same range of values -- presumably, in Raw terms, 0 to 255 or similar? And you can only calibrate them as one, so you can't get one operating the negative range and the other the positive. So, if you had a facility in the FSUIPC axis assignment, to NEGATE the values there, to give 0 to -255 (as opposed to the more usual "reverse", which would give 255 to 0), wouldn't that work for you? You would calibrate the positive side using one pedal and the negative side using the negated pedal -- both in the Rudder calibration section. I could do that quite easily if you think you could use it. I don't know where I'd fit the new checkbox needed, but i'll take a look. Meanwhile, can you see what RAW and Calibrated values you get in FSUIPC's axis assignments for the two pedals you want to use, please? Let me know so I've a good idea what I'm dealing with. Also, since you'd have to test this yourself for me, let me know if it is FSUIPC3 or FSUIPC4 which you need first. Regards Pete

As I understood only after the last message, yes. Since my PFC driver doesn't support those buttons except on the Jet Cockpit, it definitely seems as if they've wired them to the same socket as the usual AT Disconnect buttons. Codes are not single bytes. You mean 9C 00 and 9C 01 respectively I assume. This is the same code used for the AT Arm toggle switch. It is indistinguishable in the software. I thought I made myself clear in the last message, where it suddenly dawned on me, as I clearly said, that you were talking about the switches the other way around, and that, indeed, PFC had wired your switches to the reverse of what I would have expected, especially compared to the Jet cockpit, which is the only instance documented, or that I have seen, where both sets of switches are available. I am clear on this now, but it seems you are still nowhere near convinced by my explanations? I will have to tell PFC clearly that if they make such odd one-off (?) modifications without informing me, they must be prepared to support the driver nuances that arise. This has taken a lot of mine and your time needlessly. I am not amused. This is finished now. Please, if you have any more queries pursue them with PFC. Regards Pete

There's an option I incorporated for that which according to testers worked fine. have you tried it? It is listed in the Button Programming section of the Advanced Users guide (around page 19). It is called "EliminateTransients". Not if an application or assignment is requiring this. It isn't a value being passed which changes views, it is a control -- same as you pressing a button or key to do it. But FSUIPC doesn't do anything like that by itself in any case. If FSUIPC intercepted and stopped such controls you wouldn't be able to change views at all. I don't think you'd want that in any case. What selection menu where? If the yoke is causing transient button pressing, which I believe was the problem, then the button it is pressing is obviously assigned somewhere to some view control. You are evidently not un-assigning that button somewhere. In that case you obviously have the culprit button so assigned in FSUIPC. Try simply deleting the button assignment in the FSUIPC.INI file. No. Yokes cannot send "variable offsets". It is a known problem where it sends a short-lived button press. It is so short-lived it cannot possibly be from a human -- that is why the EliminateTransients facility works. There is also an "IgnoreThese" facility for Buttons, also described in the Advanced user's document (same page in fact), but you do need to know which button it is first, and you would then lose the use of that button for other things -- like the views you appear to have assigned it for! Why not first try going to FSUIPC's button assignments and seeing which button it is which appears without you pressing it, when manipulating the yoke? Pete

You mean 9C 00 (AT off) and 9C 01 (AT on) I think. The TO/GA buttons should give 9C 00 (off) and 9C 08 (on). The second value is actually a bit-field, so 09 would mean both on, and there are other bits used for anti-ice and EICAS switches. Despite my statement that I understood, I have evidently misinterpreted pretty much most of what you said it seems. I thought all this exchange was concerned with the extra buttons you had on yours for TO/GA? From what you now say, it seems that this: was really meant quite literally -- that the TO/GA buttons, the lower ones, were actually being switched by my AT Disco / TOGA option! That is the complete surprise to me as that option is designed to switch the AT Disco buttons, not the TO/GA ones which normally don't exist on the Jet console. Therefore I now believe the entire confusion is due to those two pairs of switches being plugged into the wrong sockets under the quadrant -- or at least, wrong in comparison with my understanding and how they are plugged in on the Jet cockpit. In other words the PFC driver is seeing your TO/GA buttons at the AT/Disco buttons and vice versa. This is why I said: and continued on discussing, to my mind, the supposed problems with your TO/GA switches! :-( Never mindI'll harangue Eric about all this next time I see him! Regards Pete

Surely the pedals and wheel would be separate axes in any case? Generally the wheel is the X axis, or aileron and the pedals are either two separate axes or one (Y) according to Logitech driver settings. Why would you need a special controller? And what do you use for elevator? Strange. What about the other pedal? On my Logitech Formula Force EX the wheel is X but the pedals can be set either to be one axis (Y) or two separate axes (Z and something else I don't recall). I think most driving pedal sets allow either one axis for both pedals (because some driving games do require that), but also allow them to be separated for more sophisticated simulations like GP4, so you can hold brake and high revs simultaneously. Certainly the current Logitech drivers for my pedals provide both options, and can automatically select the mode according to the program being run. Sorry, I've no idea what that's about. How can you possibly make one single pedal into a useful rudder control if it is not made self-centering? You need to be able to have it neutral with no pressure applied, so you need it sprung down half-way. Regards Pete

Version 3.85 has been superseded by 3.90 and is no longer supported. As it clearly says, the version of FSUIPC you now have installed is so old that it does not even recognise the 9.1 update of FS2004, and is therefore telling you that your FS is incorrect for that version, which it is. If the check was not there and that ancient FSUIPC was allowed to carry on running it would give you inexplicable crashes instead. I don't think that would be preferable!? When FS2004 came out there was no knowledge of the 9.1 update as it didn't exist then. So the version of FSUIPC then could not check for a 9.1 release. All it can do is see if the FS version number matches what it should have been -- the message you see clearly states all this! All you need to do is stop using a 5 year old (at least) version of FSUIPC and install the currently supported one. I expect that really old 727 add-on is the true culprit -- it must have a really bad installer which doesn't even check that you have a later version of FSUIPC before overwriting it with such an old one! Pete

Well it certainly must be possible, because other programs do such things, but the whole area of Internet access from programs is unknown to me so it would mean taking the time out to investigate and learn new stuff. I'm not adverse to that, but generally find it more useful to get on with FS related developments. I'll certainly bear it in mind and might be able to fit it in one day. Thanks, Pete

Must be related to the aircraft. As far as I know the AP doesn't use the rudder at all. And I would never have noticed because I never fly outside the cockpit. I'm not sure why you are posting this here. Seems more something for general FS9 users. try the FS2004 Forum? BTW if you ever do want to report something about FSUIPC I will need the version number confirmed, not just "latest" which is pretty meaningless. ;-) Regards Pete

Must be related to the aircraft. As far as I know the AP doesn't use the rudder at all. And I would never have noticed because I never fly outside the cockpit. I'm not sure why you are posting this here. Seems more something for general FS9 users. try the FS2004 Forum? Regards Pete

I just downloaded SceneGenX here and it works here too. But in that case how does it work on that PC with 3.81? Or are you saying you didn't re-check with such an old version? Regards Pete

strange. Can you enable FSUIPC's IPC read and write logging (on the Logging tab), then try SCENEGENX and close FS. Show me the Log (or send it to me Zipped if it is too big). Regards Pete

There's no change which would have done that unless that program simply doesn't like the version number! What are the version number(s) of these "older" FSUIPCs it works with? The interface is the same for all programs, so if it doesn't work for that it wouldn't work for any, which is patently not so, in general. Are you a Registered user? If so, try removing the FSUIPC.KEY file from the FS Modules folder, to make it temporarily unregistered. Then try your program. If that then works, you have a registration problem. ZIP up the FSUIPC.KEY file and send it to me at petedoswon@btconnect.com and I'll check it here. Regards Pete

Amazing that they add these things and don't tell me! And if that was 4 years ago that was about the time I was adding the jet cockpit stuff, I think. I don't think you are reading my messages -- I did understand you perfectly as you will see. I also suggested this: "Maybe you told the PFC driver that you had a 737NG cockpit last time? Which you seem to have missed? I most certainly haven't changed anything to do with any switches on the jetliner (or jet cockpit) for years, so I've no idea why you see any difference. If the hardware is okay, then it surely must be some setting you are omitting, such as the console selection? [LATER] I just checked my code. As far as I can see (I cannot test on your hardware from here), I do have code in place to send the switches to FSUIPC even if it isn't a jet cockpit selected. The differentiation comes AFTER the sending of buttons to FSUIPC. And, as I say, nothing has changed in this area for years -- and it's the same on PFCFSX.DLL as PFC.DLL. Soare you sure the buttons are working correctly? Use "Test" mode in the PFC driver to see if they register on the right-hand side of that option page. Maybe the plug has come loose in the socket below the quadrant? So you did get the TO/GA buttons working? Can't you explain what you did to "fix" things, then, please? Regards Pete

How are they assigned -- direct or via FS controls? Have you disabled your controls in FS? Are you using some other software like Saitek's control program? What did you change to bring this about, or have you never had it working? Always test with default aircraft first. If you are using a fancy add-on aircraft it may be interfering. And please always quote VERSION numbers -- what version of FSUIPC? Pete

I didn't need the screenshot. That message isn't one of mine. evidently one of the things you are getting FSX to load is an FSUIPC client application. Perhaps an aircraft panel or a DLL. It seems most unlikely that whatever says it can't link to FSUIPC was quite happy linking to it when it wasn't even there! There aren't different versions for registered and unregistered users, there's just the one which offers more or less facilities. If you were using FSUIPC before, without registration, how can you be sure that FSUIPC was the last addon you added to FSX? Something is obviously trying to use it and failing. Don't you know what you've added to FSX? What was FSUIPC doing for you BEFORE you registered it? It must have been there for a reason, for something you are adding or using. Something loaded by default evidently -- maybe your default aircraft panel? No, that is very bad. When you find out what it is I should contact the author and complain about that. If the only change between before and after is that you registered FSUIPC, then there's a good chance that the registration is in error. Check that by temporarily removing the FSUIPC4.KEY file from the Modules folder. If you then don't get that message, then your key is bad. Either it is not a legal one, but one generated by a pirate key generator, OR it is one purchased AFTER the date your PC is set to. So, check your PC's system date, make sure it is correct. If it is correct then Zip up your FSUIPC4.KEY file and send it to me at petedowson@btconnect.com and i will check it here. Regards Pete

No, sorry. It does sound rather odd. But I've done no work with FS2004 for several years now. All the FSUIPC3 updates have been for user facility enhancements, not any more foraging in FS9. Regards Pete

Yes. Pete

I'm not clear why you'd even think of FSUIPC? Are you setting these things in the FS Weather menu? Why would FSUIPC be involved? Regards Pete

"Flights" don't link to FSUIPC or WideClient! And none of my software contains such a message! So you need to find out what program or add-on is telling you this -- it isn't FSUIPC or WideFS or FS itself, but something you are running or have added. You need to work that out then ask their support what is wrong with it. Regards Pete

That is NOT a good idea. Plug them in to separate ports and never swap them about. Assign specifically in FSUIPC's axis assignments and it will take care of the swapping for you. Calibrate specifically as well to suit the different controls and different aircraft. Disable joysticks in FS. That's because there were no Profile facilities in 4.40. There's a whole Chapter about them in the 4.50 user guide. Yes, in general it does matter. There are facilities in FSUIPC 4.50 to keep track of your controls in case you do move them -- you'd need to enable that if you want to use it. FSUIPC would then refer to your controls by letters, A, Betc (or whatever you choose). This is possible, but it isn't as good as simply leaving them plugged in. Aren't the wires long enough for you to leave them connected but shoved out of the way, under your desk or somewhere? Best to use the Profiles. Set up one profile for one set of controls, using your favourite aircraft for those, then ditto for the other set. Thereafter assign each aircraft you fly to one or the other. This won't work very well if you don't keep them all plugged in. You'd probably have to close FSX down and restart it each time you changed, in order to get them recognised again. If they are left connected everything becomes automatic according to which aircraft you load. Regards Pete

There are no notes with FSUIPC which explain the Lua language -- you need to refer to their website where the documentation is pretty good. The FSUIPC notes only describe the additional library functions provided by FSUIPC. What is actually confusing for you? I need to know about things like that so I can write clarifications into it. That is the only way I can improve it. Where are you reading that a 1 will disconnect the rudder? That is bit number 0. According to the offsets list the bit for the rudder is bit 2, in other words 2^2 or value 4. Okay. There are two different ways of doing this. You can make a rather complex loop to watch the button and do the timing of 9 seconds. Doing it this way you can have just the one Lua program and call it "ipcReady.lua" so that it runs when FS is ready to run. If it is programmed with the actual button number you want to use then you don't even have to assign anything to it -- it will run and loop continuously, sending a value to offset 310A whilst the button is pressed, sending 0 when released, and sending nothing otherwise. It would "sleep" most of the time to avoid impinging on FS performance. However, much easier to program would be a simple loop setting the offset, assigned to your button in FSUIPC, which tests not the button but a flag, which is set by assignment when you release the button. This simpler solution would look something like this: [EDITED ON 5th MARCH to correct omission of last line] seconds = 9 -- counter for 9 seconds while ipc.testflag(0) == false do -- loop until flag is set (all flags are clear when a Lua program starts) if seconds == 9 then ipc.writeUB(0x310A, 4) -- update the offset every 9 seconds seconds = 0 -- restart the 9 second counter end ipc.sleep(1000) -- give up the processor for a second seconds = seconds + 1 -- count that second end ipc.writeUB(0x310A,0) -- restore the rudder operation before exit Save this as, say, "NoRudder.lua", then assign your button press to "Lua NoRudder", and its release to "LuaSet NoRudder" with parameter 0 (for flag 0). Written this way it could take a second after you release the button before you get the rudder back. If that's no good, reduce the sleep time and increase the count proportionally. For example a sleep of 100 milliseconds would need a count of 90 to get to 9 seconds. Okay? I hope this all makes sense to you? Regards Pete