Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    37,984
  • Joined

  • Last visited

  • Days Won

    158

Everything posted by Pete Dowson

  1. A known bug in ActiveSky? I don't know it, but I don't use ActiveSky. Has he determined the cause?
  2. Do you want the positions of the airport's as defined by where the visual scenery is placed, or where the AFD (airport facility data) says things are? They are distinct and come from separate types of BGL file. The airport runway thresholds, taxiways, parking spots and tower positions are defined in the AFDs. Programs like AFCAD and Trafficboard are capable of reading those and displaying maps. I have a program which scans them all and produces databases for FStarRC and for Radar Contact 3. The FStarRC file is binary, but the RCV3 one is CSV (comma separated variable format) and can be read easily. It also produces a text file giving most details, but this becomes huge. For visual scenery there used to be a number of programs around which could decode or disassemble them and provide source-type readable definitions, but I've forgotten their names now. They may not even work any more. Last I was interested in this stuff was FS5. Maybe a Google search will get you somewhere. If you are thinking of writing your own BGL decoder to get information you want, then the MS Scenery SDKs are needed. Regards, Pete
  3. Do you want the positions of the airport's as defined by where the visual scenery is placed, or where the AFD (airport facility data) says things are? They are distinct and come from separate types of BGL file. The airport runway thresholds, taxiways, parking spots and tower positions are defined in the AFDs. Programs like AFCAD and Trafficboard are capable of reading those and displaying maps. I have a program which scans them all and produces databases for FStarRC and for Radar Contact 3. The FStarRC file is binary, but the RCV3 one is CSV (comma separated variable format) and can be read easily. It also produces a text file giving most details, but this becomes huge. For visual scenery there used to be a number of programs around which could decode or disassemble them and provide source-type readable definitions, but I've forgotten their names now. They may not even work any more. Last I was interested in this stuff was FS5. Maybe a Google search will get you somewhere. If you are thinking of writing your own BGL decoder to get information you want, then the MS Scenery SDKs are needed. Regards, Pete
  4. Sorry, I cannot answer questions on future products yet. Ask again in August or so. I may have time to look at GPS programming some months *after* FS9 release, but certainly none before. However, if FS9 provides the controls (FS2002 didn't), the GPS buttons on the PFC Avionics stack could be re-programmed by the user through FSUIPC in any case. All PFC buttons and knobs can be programmed through FSUIPC, the only thing stopping the GPS being used this way in FS2002 is that Microsoft provided no controls for it at all. The Cirrus II itself, with no Avionics stack, will never be amenable to a GPS control console of course. It just hasn't got the right buttons and knobs. Pete
  5. Sorry, I cannot answer questions on future products yet. Ask again in August or so. I may have time to look at GPS programming some months *after* FS9 release, but certainly none before. However, if FS9 provides the controls (FS2002 didn't), the GPS buttons on the PFC Avionics stack could be re-programmed by the user through FSUIPC in any case. All PFC buttons and knobs can be programmed through FSUIPC, the only thing stopping the GPS being used this way in FS2002 is that Microsoft provided no controls for it at all. The Cirrus II itself, with no Avionics stack, will never be amenable to a GPS control console of course. It just hasn't got the right buttons and knobs. Pete
  6. I assume "InnerMk.wav" exists in the default sounds folder? ENGINE1_STARTER_SWITCH_POS is *always* >= 0, so there's never the change occurring which you are expecting. You need to understand the values you are testing in order to use them. Esound only triggers a sound on the condition changing from FALSE to TRUE. If it is always TRUE you won't hear a thing. Pete
  7. I assume "InnerMk.wav" exists in the default sounds folder? ENGINE1_STARTER_SWITCH_POS is *always* >= 0, so there's never the change occurring which you are expecting. You need to understand the values you are testing in order to use them. Esound only triggers a sound on the condition changing from FALSE to TRUE. If it is always TRUE you won't hear a thing. Pete
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.