Pete Dowson

You only show part of the story. There will be a different point at which the change of flaps is made in each direction -- there's no "specific" value for each, but a range. For example, I've just calibrated an ordinary throttle axis as a flaps control. With the default 737 I get: Min = -16193, Max = 16192 (same as you!) Increasing IN OUT = Flap Decreasing IN -16193 0 0 -14567 -14026 2047 1 -10232 centre -12129 -9691 4094 2 -6439 centre -8065 -5898 6141 5 -2104 centre -4001 -1563 8188 10 1968 centre 202 2476 10235 15 6032 centre 4252 6540 12282 25 10096 centre 8318 10604 14329 30 13652 centre 12128 14160 16376 40 You see that because there are 8 intervals between the 9 flap positions, the average "space" per position for a range of 32385 (-16193 to 16192) is 32385/8 = 4048, which is approximately shown by the ranges used and the centres thereof. The two ends will half the range one way (complementary ways), as clearly seen. I don't know why you are expecting things to change on a 2048 increment, it could be up to 4096 at the extreme, for a clibrated range of -16384 to +16383. Really, I think, as I stated before, that you are expecting this to work in a way which was never intended. The idea behind it was that you calibrate the LEVER to suit the sim, not calibrate the sim to suit a pre-made notched lever. I think that is your only problem. As far as I can see there are only two possible solutions, one is to write a program to convert your specific range of readings into specific flap selections, using FSUIPC interface (or waiting till I have time to add such a facility), or to replace your potentiometer by a rotary switch with 9 different fixed or trimpot resistors, calculated to get near the centre of each flap position range. Regards, Pete

You only show part of the story. There will be a different point at which the change of flaps is made in each direction -- there's no "specific" value for each, but a range. For example, I've just calibrated an ordinary throttle axis as a flaps control. With the default 737 I get: Min = -16193, Max = 16192 (same as you!) Increasing IN OUT = Flap Decreasing IN -16193 0 0 -14567 -14026 2047 1 -10232 centre -12129 -9691 4094 2 -6439 centre -8065 -5898 6141 5 -2104 centre -4001 -1563 8188 10 1968 centre 202 2476 10235 15 6032 centre 4252 6540 12282 25 10096 centre 8318 10604 14329 30 13652 centre 12128 14160 16376 40 You see that because there are 8 intervals between the 9 flap positions, the average "space" per position for a range of 32385 (-16193 to 16192) is 32385/8 = 4048, which is approximately shown by the ranges used and the centres thereof. The two ends will half the range one way (complementary ways), as clearly seen. I don't know why you are expecting things to change on a 2048 increment, it could be up to 4096 at the extreme, for a clibrated range of -16384 to +16383. Really, I think, as I stated before, that you are expecting this to work in a way which was never intended. The idea behind it was that you calibrate the LEVER to suit the sim, not calibrate the sim to suit a pre-made notched lever. I think that is your only problem. As far as I can see there are only two possible solutions, one is to write a program to convert your specific range of readings into specific flap selections, using FSUIPC interface (or waiting till I have time to add such a facility), or to replace your potentiometer by a rotary switch with 9 different fixed or trimpot resistors, calculated to get near the centre of each flap position range. Regards, Pete

You didn't attach any CFG file? Pete

You didn't attach any CFG file? Pete

Hmm. I don't know. That does sound wrong. Which aircraft is it? I'd like to reproduce it here if I can. Can you list the flap positions for me so I can set it up the same here, please? And also, if you can, the range of inputs for each output that you are getting. I'll certainly check to make sure there's not a bug in FSUIPC. It seems unlikely as the code is the same for each movement, it is only a simply calculation. Pete

Hmm. I don't know. That does sound wrong. Which aircraft is it? I'd like to reproduce it here if I can. Can you list the flap positions for me so I can set it up the same here, please? And also, if you can, the range of inputs for each output that you are getting. I'll certainly check to make sure there's not a bug in FSUIPC. It seems unlikely as the code is the same for each movement, it is only a simply calculation. Pete

Ah, by linking it by wires, yes. But it is still the client computer playing the sounds so it still needs a sound card. Of course it still seems to me that re-mixing the ATC into the general FS sounds spoils much of the whole point of running RC on the client. Pete

Ah, by linking it by wires, yes. But it is still the client computer playing the sounds so it still needs a sound card. Of course it still seems to me that re-mixing the ATC into the general FS sounds spoils much of the whole point of running RC on the client. Pete

No, you describe something different. Yes, this problem was reported before I went on holiday, and fixed in WideFS version 5.50 as soon as I got back. Please always make sure you are using current supported versions then it will save unnecessary messages and misunderstandings. If you look to the top of this forum I maintain a list of current supported versions there. Pete

No, you describe something different. Yes, this problem was reported before I went on holiday, and fixed in WideFS version 5.50 as soon as I got back. Please always make sure you are using current supported versions then it will save unnecessary messages and misunderstandings. If you look to the top of this forum I maintain a list of current supported versions there. Pete

I don't use it at all. I tried it just once, way back in FS2000 days (or was it FS98? Can't remember, sorry). But I don't like being on the telephone for extended periods. I'm still using dial-up. Almost no time at all except short test runs. Too busy. Pete

I don't use it at all. I tried it just once, way back in FS2000 days (or was it FS98? Can't remember, sorry). But I don't like being on the telephone for extended periods. I'm still using dial-up. Almost no time at all except short test runs. Too busy. Pete

But that's only because you've done it wrong! That part's okay. But that is wrong for WideFS. The built-in RWon and RWoff controls in FSUIPC are being transmitted in the Server. You don't have RW running in the Server. you are trying to use KeySends. So you program FSUIPC to send a KeySend with parameter 1 for press and a KeySend with parameter 2 for release. Please read the documentation again, it should become very clear to you that FSUIPC controls are for the SERVER. For WideFS you use KeySends -- with parameters to tell FSUIPC what KeySend numbers to send. That's why you define the correctly numbered KeySends in the Client INI. The numbers relate!! This is explained in the WideFS documentation as well as the FSUIPC documentation. Pete

But that's only because you've done it wrong! That part's okay. But that is wrong for WideFS. The built-in RWon and RWoff controls in FSUIPC are being transmitted in the Server. You don't have RW running in the Server. you are trying to use KeySends. So you program FSUIPC to send a KeySend with parameter 1 for press and a KeySend with parameter 2 for release. Please read the documentation again, it should become very clear to you that FSUIPC controls are for the SERVER. For WideFS you use KeySends -- with parameters to tell FSUIPC what KeySend numbers to send. That's why you define the correctly numbered KeySends in the Client INI. The numbers relate!! This is explained in the WideFS documentation as well as the FSUIPC documentation. Pete

I you have WideClient loading the program for you you shouldn't need the Class Names as it can determine the correct window -- assuming you are using the latest WideFS, that is. Use Run or RunReady. How do you activate a DLL from WideClient? I can only load EXEs. Hmmm. The normal method WideFS uses is by replaying recorded events. You can also try PostKeys. But both effectively send WM_KEYDOWN and KEYUP messages. If SB is reading the keyboard by more direct methods, not by processing messages, then it will be a problem. Pete

I you have WideClient loading the program for you you shouldn't need the Class Names as it can determine the correct window -- assuming you are using the latest WideFS, that is. Use Run or RunReady. How do you activate a DLL from WideClient? I can only load EXEs. Hmmm. The normal method WideFS uses is by replaying recorded events. You can also try PostKeys. But both effectively send WM_KEYDOWN and KEYUP messages. If SB is reading the keyboard by more direct methods, not by processing messages, then it will be a problem. Pete

Press ALT M F to get into FSUIPC option. Select the Keys page. Set it to use your F12 press to send KeySend with parameter 1 (say) on press, and parameter 2 (say) on release. Then, in the WideClient.ini on the RW PC add the Keysend 1 and 2 definitions for RWon and RWoff, respectively. That's all. This is all exactly as described in the documents. What is the problem with those, please? >>But i can't make head nor tail of instructions. I have put ActiveKey=Yes and KeySend123=Rwon in both ini files and nothing happens. << What is "KeySend123"? Where do you get that from? What do you mean by "both ini files"? Surely you only have one Pc with RW running? You are not making any sense. Pete

Press ALT M F to get into FSUIPC option. Select the Keys page. Set it to use your F12 press to send KeySend with parameter 1 (say) on press, and parameter 2 (say) on release. Then, in the WideClient.ini on the RW PC add the Keysend 1 and 2 definitions for RWon and RWoff, respectively. That's all. This is all exactly as described in the documents. What is the problem with those, please? >>But i can't make head nor tail of instructions. I have put ActiveKey=Yes and KeySend123=Rwon in both ini files and nothing happens. << What is "KeySend123"? Where do you get that from? What do you mean by "both ini files"? Surely you only have one Pc with RW running? You are not making any sense. Pete

Not sure what you mean. There are some Menu facilities to do something like that, little used if at all for many years. But have you defined the Actions with names for the WideClient menu, as documented? If you always want to load AIBridge on the server, why not use the Run Program facilities in FSUIPC or WideServer? Sorry, I don't fully understand that either. You mean you have SB running on the server, or is it on the Client? Surely the big advantage of having it on the Client is that it has its own keyboard and avoids conflict and possible focus loss on the FS PC? Not being an SB user at all I'm lost here. Sorry. I hope someone else can jump in. Are you programming KeySends in the Client to send keystrokes to SB? There's no facility to turn FSUIPC's keyboard interception on and off, so your idea of having the keyboard in two modes won't work that way. For each key you program for SB or whatever you'll have to assign the regular FS control to it as well, when the flag is off. All the controls you can use in FS are assignable in FSUIPC too, but once FSUIPC is told to intercept a key, it intercepts it. You mean you assign keypress A to Keysend with a parameter of 1 in the Keys page? You aren't trying to edit the INI file directly for this, are you? There's no need. This is where you lose me again. What's "SBkey.dll" and where is it running? What do you mean "via". Doesn't SB in the Client accept keystrokes? Pete

Not sure what you mean. There are some Menu facilities to do something like that, little used if at all for many years. But have you defined the Actions with names for the WideClient menu, as documented? If you always want to load AIBridge on the server, why not use the Run Program facilities in FSUIPC or WideServer? Sorry, I don't fully understand that either. You mean you have SB running on the server, or is it on the Client? Surely the big advantage of having it on the Client is that it has its own keyboard and avoids conflict and possible focus loss on the FS PC? Not being an SB user at all I'm lost here. Sorry. I hope someone else can jump in. Are you programming KeySends in the Client to send keystrokes to SB? There's no facility to turn FSUIPC's keyboard interception on and off, so your idea of having the keyboard in two modes won't work that way. For each key you program for SB or whatever you'll have to assign the regular FS control to it as well, when the flag is off. All the controls you can use in FS are assignable in FSUIPC too, but once FSUIPC is told to intercept a key, it intercepts it. You mean you assign keypress A to Keysend with a parameter of 1 in the Keys page? You aren't trying to edit the INI file directly for this, are you? There's no need. This is where you lose me again. What's "SBkey.dll" and where is it running? What do you mean "via". Doesn't SB in the Client accept keystrokes? Pete

Right click on the desktop and select "Properties". Then choose the Appearance tab, and press the Effects... button. Uncheck "Show window contents while dragging". Pete

Right click on the desktop and select "Properties". Then choose the Appearance tab, and press the Effects... button. Uncheck "Show window contents while dragging". Pete

FSUIPC isn't looking for anything. It doesn't care at all. It is Flight Simulator you are sending the values to. FSUIPC is really just a passive interface. The current FSUIPC flaps facility is, of course, intented to be used the other way round. You calibrate the lever to suit FS, not FS to suit the lever! Odd to use a pot for fixed number of detentes. Surely fixed resistors and a multiposition switch would be better? You choose the resistor values to get the desired result -- probably equal values despite the differing values of the flap angles. Otherwise if it is working evenly but with too low a change, either the pot value is wrong (have you tried different values?) or you need to calibrate it differently -- include only the active section, for instance, leaving bigger null zones, so spreading the range and increasing the difference. I still think more precision is possible with separate fixed resistors or maybe trimpots. Otherwise, you can do something similar to EPIC, write a little program to read the axes, convert inputs according to a table, then write them directly through FSUIPC. If you still need something done next year, when I may have "conquered" FS9 , ask me again and I'll look at adding a look up conversion table facility (only via the INI file). Pete

FSUIPC isn't looking for anything. It doesn't care at all. It is Flight Simulator you are sending the values to. FSUIPC is really just a passive interface. The current FSUIPC flaps facility is, of course, intented to be used the other way round. You calibrate the lever to suit FS, not FS to suit the lever! Odd to use a pot for fixed number of detentes. Surely fixed resistors and a multiposition switch would be better? You choose the resistor values to get the desired result -- probably equal values despite the differing values of the flap angles. Otherwise if it is working evenly but with too low a change, either the pot value is wrong (have you tried different values?) or you need to calibrate it differently -- include only the active section, for instance, leaving bigger null zones, so spreading the range and increasing the difference. I still think more precision is possible with separate fixed resistors or maybe trimpots. Otherwise, you can do something similar to EPIC, write a little program to read the axes, convert inputs according to a table, then write them directly through FSUIPC. If you still need something done next year, when I may have "conquered" FS9 , ask me again and I'll look at adding a look up conversion table facility (only via the INI file). Pete

The date/time is not produced or in any way tampered with by FSUIPC, it is only exposed for applications to access. The time is given by FS with Seconds, and Hours and Minutes on a 24-hour clock. Two sets of hours and minutes are given, one Zulu (UTC or GMT) and the other Local Time. The date is given as a Year and a Day number in the year. The application would be calculating the actual month and day of month from that -- it sounds very much as if it has got those calculations wrong! I'd report it as a bug if I were you. I think there is a bug in FS which makes the day number one out -- i.e. one day, not 45 days out. It doesn't always occur, and is probably due to a mix-up over whether Jan 1st is day 0 or day 1 in different parts of FS. Pete