Pete Dowson

Is pmSounds still a freeware item? The key should work for the version it was generated for -- if it doesn't then maybe a new one can be made. Have you asked PM support? It is really their province. If you want me to investigate please try again, close FS, then show me the FSUIPC.LOG file (from the FS Modules folder). Regards, Pete

You always need to calibrate well first in Windows' Game Controllers. FSUIPC is only providing the "finishing touches". Also, check that you have FS's settings correct first, too. The Sensitivities slider should be up full (hard right) and the null zone slider full left. I don't think there's ever any ideal settings which you can copy from one controller to another. The whole reason there's any calibration in the first place is because of all the variations from one unit to another. That said, you should find it helps with airliner control to use of of the slopes with a flattened centre -- gives you more control where you need it. The flattened centre slopes are those with positive numbers in FSUIPC 3.50 (numbers weren't shown before). Regards, Pete

Hmmmnot sure I understand. But if it asymmetric inputs which are the concern, there is a switchable FSUIPC option to equalise them all. It's the "throttle sync" hot key, in the Hot Keys page. You can program a key press there, and if you have one, a button to send in in the Buttons page. The "IN" value is what FSUIPC is seeing coming from the control. How your control is producing maximum reverse at full forward I don't know. Have you got some other drivers doing this? If this is only with the specific aircraft, try checking the option at the bottom of the 4 throttles page, to stop FSUIPC processing the old THROTTLEn_SET controls. Maybe they are being used by the aircraft's thrust management asystem. I know you need that for the Feelthere ERJ 145. Certainly not the -4096, but even calibrating it for the highest positive you get won't help if you push the stick into the -4096 zone. There's no way FSUIPC can distinguish that from a negative number, because it is one! If your quadrant does this even for standard default aircraft, then I would say it was faulty --- it means there's a bad contact or a short at one end of the travel. In that case get it replaced. Regards, Pete

Not true, apart from the new facility to make them aircraft specific. None of the columns have been changed since about version 2. The headings are different in each page depending on the axes concerned. The separate throttles page (page 3) has always been as you say. You follow the instructions, step by step. This is no different from any version over the last four or five years. What is the problem? Regards, Pete

WideFS 5.40 is too old and not supported. There's no "free" WideFS. Regards, Pete

With Squawkbox 3 it is all taken care of in that program. With Squawkbox 2 you need AIBridge by Jose Oliveira. There's a link on the http://www.schiratti.com/dowson page. That's all I know I'm afraid. There's no other magic, it just works as far as I know. Regards. Pete

Neither FSUIPC nor WideFS know anything about either IVAP or cpFlight equipment. I'm sorry, but I have absolutely no idea how they communicate and know nothing about them whatsoever. If cpFlight blame FSUIPC/WideFS let them show that to me. I think you need them to provide more information to each other -- maybe cpFlight can talk to IVAP or vice versa? I really cannot support other folks' software or hardware, especially stuff I have not got and know nothing at all about. Neither have ever supplied me any information about any of this. Pete Dowson

As I said before, the Log shows the SB3 modules connecting to FSUIPC okay. The KEY file you sent shows you are using an illegally generated FSUIPC access key. Where did you get it? You are not listed as a registered user and you are breaking the law by using this counterfeit key. Unless you have an excellent explanation I will be reporting this This will no doubt be the entire reason for your troubles. I cannot tell any more because the Log you show here, and the one you sent by email, is not complete. I asked you to run FS, get the problem, then CLOSE FS before getting the Log. I cannot do anything with an incomplete log. You need to close FS first. Pete

Well yes, they are both controlling the pitch and roll, but you don't assign them both that way in FS. You have to find two spare axes which you aren't otherwise using 9e.g Prop Pitch 3 and 4, perhaps, or some others). Assign the second set to these in FS. Then you find the reference numbers for those two axes (in the FS Controls document I supply) and tell FSUIPC about these, editing the FSUIPC INI file as described in the section I referred you to. FSUIPC sees both sets of control inputs and sends only the "largest" deflection on to FS. That's it. They are still both connected all the time. You do need a good central "null zone" so that when one is left alone tit doesn't interfere with the other being central too. You shouldn't get conflicts as they are different inputs. If your controls generate spikes (they shouldn't) you may find the FSUIPC flitering removes them. In any case a good centre null zone should stop any interference if the other controls are left alone. Regards, Pete

For a couple of years FSUIPC has supported multiple flight controls connected simultaneously. This facility is used for cockpits with both pilot and copilot yokes or sticks. Both are operational at the same time, and FSUIPC takes the maximum deflection for the two. This is described in the section entitled "Multiple Joysticks" in the Advanced User's document inside the FSUIPC package. The facilities for aircraft-specific button programming has been in FSUIPC for a while. the new facility in 3.50 relates to the "Joysticks" options, i.e. calibrations, mappings, and so on, not the "Buttons" section. So, yes, the new facilities do help more, in that you can calibrate the two control sets separately, making those calibrations aircraft-specific, but FSUIPC does not actually deal with axis assignments - in fact it knows nothing about them, as it deals entirely with FS controls not joysticks as such. In other words, you still need to get your controls assigned via FS -- using other control numbers for one set, as described in the advanced users guide for multiple joysticks. You could have been using that system for years, and it can be very workable. The ability to calibrate separately for different aircraft just adds icing to the cake. :-) Regards Pete

It's actually stated in the documentation. See the beginning of each of the Keys and Buttons programming sections of the Advanced User's document, thus: Okay? Pete

If none of them are processed then noe of them are processed. It means what it says. The figures in the IN and OUT boxes won't matter. As long as all of the top left buttons in each section read "Set" then FSUIPC is not touching any of these things. If it says "Reset" click it to make it say "Set". Then FSUIPC is out of the equation for sure. Another way is simply to delete your FSUIPC.INI file (in the FS Modules folder) and letting it make a new one witthout any of your options set at all. If you have slew problems then it isn't FSUIPC doing it. You CAN use FSUIPC to calibrate the slew axes separately, and a lot of folks do solve problems that way. But it won't cause problems where it isn't involved. Regards, Pete

It might be a good idea to put quotation marks aound the C:\ paths. It shouldn't make any difference, but I am always suspicious of paths containing spaces. Can you find out from the makers what files they are trying to load, please? It may simply be they way they load files -- WideClient will load the program but it is up to the program to find its files. It may be looking for them in the WideClient folder because that is the "current" folder. Programs should really not assume this and instead should find out where they've been loaded from, but ancient MSDOS type practice was to assume these two paths were the same. Try placing WideClient and its INI file in the FsClient 4.3 folder and running it from there. The other way would be to make a short cut and run that from WideClient instead. You can specify the "current path" in a shortcut. I really don't think this is any change in WideFS. Regards, Pete

Button braking in FS should be "feathered". In other words do NOT press and hold for lighter braking, just press and release, over and over. That works and is the same as tapping on the keyboard "." key. Proportional analogue braking requires a dedicated axis. There are no facilities to switch axis use without going into FS's control assignments. FSUIPC does not handle assignments, it doesn't even handle the axes, only the control values internal to FS. Regards, Pete

I do not understand how just switching to the second yoke is changing the calibration of the first one. that just is not possible in my software -- the values stay set to whatever you set them to. So it must be a hardware problem. Either your switch is faulty, or switching it causes the controller hardware to go funny. If you only mean that calibration on one doesn't suit the other, then you will need to get the yokes better matched. There's really no way at all PFC.DLL can tell where the values are coming from so it cannot make any different adjustments. They use good quality potentiometers and there should be little if any mismatch. Something is wrong on one of them. I'd talk again to PFC if I were you, in either case. Regards, Pete

FSUIPC doesn't touch anything to do with that unless you calibrate your slew axes in the Joysticks section in its options. What do you mean "just the default setting"? If you haven't calibrated slew axes in FSUIPC it really isn't anything to do with your problem. Regards, Pete

Sorry, I am not fully understanding you. Are you using a switch to completely change over all connections between the two? Or are they noth partially connected at the same time? I really have no way in the PC to distinguish between two different axis reports for the same numbered axis coming from the same PFC controller. I suspect you need to get your yokes as closely matched as possible in the first place. They should really not be so different in any case. It might be a good idea for you to discuss this with PFC themselves. A better solution may emerge. Regards, Pete

No, that is not a Log fle, that is the INI file. I have received files from a "Joseph Janica". I assume they are yours? If so, then I cannot access the KEY file because you didn't ZIP up the files and the KEY file is prohibited because they can be Registry files too. Please always ZIP files when sending them. The Log shows the SB3 modules connecting okay: 32109 Module [M1] identified = "sbmpjoin9.dll" 38000 Module [M2] identified = "sbmod9.dll" 38000 Module [M3] identified = "sb3gaugebridge.dll" 38000 Module [M4] identified = "sbtrans9.dll" I don't know if there should be any others. Unfortunately, the Log you sent is only a partial one -- you need to run FS, get whatever problem it is you think you have, then close FS, THEN ZIP up the FSUIPC.LOG file and the FSUIPC.KEY file. the INI file is not at all relevant. Anyway, from the little scrap of information you've supplied so far I see nothing wrong. The SB3 modules are present and connecting. I think you will need to describe your problems in much more detail before we can proceed. If it is simply that you cannot make SB3 work for you, then I'm afraid you are really in the wrong place -- I don't use SB3 and don't know anything about it. Possibly you have some multiplayer problem, in which case it isn't involving FSUIPC at all. You will probably have to go to SB3 support. Regards, Pete

FSUIPC doesn't "correct" trim errors. It sounds like your rudder trim is not zeroed. Find the rudder trim wheel and adjust that. It should be on the rear of the centre console. I am very sorry, but FSUIPC simply does not "fix" everything in the world. It is mainly an interface for other programs to talk to FS and get information from it. The user facilities are useful, of course, but they only do what you ask of them. If your rudder trim is not centred FSUIPC is not going to be able to detect this and compensate for it. Regards, Pete

Ahbut that had the same problem, some problem not explained and started as if it were a continuing discussion from something else. Ah well. :? :? Pete

No, FSUIPC doesn't care where FS is installed. The only thing different about that tab is that FSUIPC will be scanning buttons as soon as you enter it. Sounds like something in the joystick area is hanging. Do you have a log or a fragment of one (FSUIPC.LOG in the FS Modules folder)? Check the Game Controlers part of Windows Settings. Maybe you have some old joystick driver still installed which is causing a problem when interrogated? BTW I always need to know what version of FSUIPC it is you are using. That is paramount information. Iyou may also like to try version 3.50 which is now the official release. Regards Pete

What is this about please? It is sitting alone with nothing else preceding it to expalin what you are talking about. :-( Perhaps you meant to post it somewhere else, in relation to something perhaps? Was it at all important? Please think a little before you post. This does just waste time and space. Regards, Pete

Well, yes, of course. But this won't concern the program unless you have some sort of interdependent loop going on some place. Well, you seem to be looking at it the wrong way round. You build your panel and populate it with switches and indicators. The switches result in changes being sent to FS (well, some of them -- not all. see ** below). The indicators are there to indicate things, and for those (not all, again) you'd be reading from FS. But just because you write something does not mean you have to read something. You implement whatever it is that is neded to perform the function -- change things in FS or display something. ** If you are thinking in terms of a full airliner type overhead you will find that FS doesn't, in itself, simulate much of it for you to influence or gain indications from. You'll need to work out your own logic and keep your own data for much of it. This is what pmSystems does for, for instance, the APU (not simulated at all in FS), and which Thomas Richter, for one, has been developing quite sophisticated pmSystems logics for. If you are realy out to do all this yourself, separately, good luck. I still don't really understand what you are asking here. It would read them when it wants them, but no more often than they are likely to be changing. Anyway, the individual reads don't do anything, as I said. Only the Process does anything anyway. That's quite unlikely, but it depends. If you write to the transponder code and read it back it will normally be what you've just written. If you write a reduced throttle setting it won't influence the N1% or RPM readings until the simulator has simulated something. Whilst FSUIPC is processing the reads and writes nothing else is happening in FS -- luckily they are all done in a very short time. There's always going to be a lag in any case in anything which is simulated -- things actually are like that in the real world too. If you reduce the throttle in a real aircraft, the effect may seem instantaneous but there's enough milliseconds in there to make it very much non-instantaneous. You should never expect anything instantaneous. Why would you? If you ever intend the program to run on a Client PC over WideFS you've got the Network latency in between as well. That could be hundreds of milliseconds. Regards Pete

Why would it want to? What are you trying to do? What are these other values? I'm not really understanding your question. All you have to realise is that the ONLY call which actually does anything is the FSUIPC_Process() call -- the others are simply manipulting data for you, to make life easier. The code for those is in your program (the sources are all provided as well, so you can do your own thing). Since FSUIPC_Process actually calls FSUIPC, it will involve a process switch by Windows. In fact there will be at least two before your program gets control back -- one from your program to FS, and the other back again. Since each such switch can take many milliseconds, it is those which need to be kept to a minimum. None of the others matter. So, the technique would be to have a cycle in which you issue all the FSUIPC_Read and FSUIPC_Write calls you wish to do, in the order you want them executed, and then make on FSUIPC_Process() call to get them executed. Do all this once per cycle, keeping the cycle time to something reasonable so as not to detract noticeably from FS's performance. There's little point in trying to go faster than FS's frame rate, so a 55 mSec cycle (the typical Windows timer tick of 18.2 per sec) would be fine for that sort of performance. Of course you would do it much less often when you did not need anything domne. Not really, but that's a program design thing, depending on what you want to do. Be aware that by having multiple threads accessing the same data (your program will only have one shared data block for the transfer of the data) you risk data corruption unless you use semaphores or something to ensure serial access. You would be makingl ife much more complex than it would need to be. Regards, Pete

Any call to CreateWindow will have parameters relevant to your window only. There is no point in me showing you a call to CreateWindow! If you have no reference wmaterial with your compiler system (!!!), look these things up on the Internet, or better please go and buy Charles Petzold's book on Programming Windows and look up how to write such programs. I am not a teacher and this is not the place. Sorry. I have bought many books on programming and on Windows and use them constantly. Just look these things up please. Pete