BrunoBL Posted October 20, 2004 Report Posted October 20, 2004 Hi Pete, I finally got my hands on a few rotary pulse switches from Alps, and started playing with an MCP panel and radios. All is going fine, but I came across a strange behavior in NAV1. For these quick tests I am not programming anything (and shouldn't need to) as FSUIPC interface seems to have all the facilities to the internals I am interested in. The trouble is with Nav1 Radio Fract Dec. (decrease decimal part of NAV1 receiver frequency). This facility seems to behave exactly like Nav1 Radio Fract Dec Carry, and sets the frequency integer to the next lower value when you go "below zero" on the fractional digits. Since there is a specific "Carry" version of this facility (and since both "Inc" and "Inc Carry", on the other hand, behave as axpected) it seems something is awry. Maybe FSUIPC is looking at the same locations for both facilities? I didn't try to program NAV1 directly using FS2004 offsets. As I said, at this point I only tried using FSUIPC dialog faciilities for this. Best regards, Bruno.
Pete Dowson Posted October 21, 2004 Report Posted October 21, 2004 Maybe FSUIPC is looking at the same locations for both facilities? FSUIPC doesn't look at any location for built-in FS controls. All it does is send the control to FS, the rest is up to FS. There are many additional "pseudo-FS controls" added by FSUIPC (and more coming in the next version), but those certainly are not any of those. The same applies to NAV2 as well, by the way. Furthermore, the same happens when using the mouse on the radio stack -- try it! Interestingly enough, COM1 and COM2 are okay in this respect! It looks like a bug in FS specific to the NAV radios. Regards, Pete
BrunoBL Posted October 21, 2004 Author Report Posted October 21, 2004 Pete, The same applies to NAV2 as well, by the way. Furthermore, the same happens when using the mouse on the radio stack -- try it! Just did. You know, I think I never even noticed that it behaved this way in the default panel. I guess I had to look at this with the critical eye of testing a new radio panel's wiring to see it. Interestingly enough, COM1 and COM2 are okay in this respect! It looks like a bug in FS specific to the NAV radios. Go figure. Naturally, diferent people are coding diferent parts of the product. In situations like this, the diferences stand out. There are many additional "pseudo-FS controls" added by FSUIPC (and more coming in the next version) Wow! ...You wouldn't care to tell us a bit about them, would you? :D Best regards, Bruno
Pete Dowson Posted October 21, 2004 Report Posted October 21, 2004 Wow! ...You wouldn't care to tell us a bit about them, would you? Well, so far I have added: Offset Byte Cyclic Inc Offset Byte Cyclic Dec Offset Word Cyclic Inc Offset Word Cyclic Dec These four operate on specific FSUIPC offsets and allow cyclic changes between zero and an upper value. They complement the existing Offset Inc/Dec facilities but deal with cases where you need to make a choice with only one button instead of two to search up and down. Then there's a set of controls to handle the current in-use COM1, COM2, NAV1 and NAV2 frequencies (separate inc/decs for whole and fractional parts). These are for single display type devices like the GoFlight GF45 and GF46 modules, ones with no way to show both standby and in-use values. Finally, for Button programming only (not Keys at present) I've added a conditional facility based on reading FSUIPC offset byte, word or double word values. The reasons for these choices will be clear when I release the GoFlight display handling program I've developed and am testing now. This complements the FSUIPC GoFlight button programming facilities. Regards, Pete
BrunoBL Posted October 21, 2004 Author Report Posted October 21, 2004 Pete, It is interesting to see how a one-man product like yours never ceases to be improved. Somehow you manage to put out version after version and still personally provide online support. You said in another thread that people have to do other things like sleep and eat. I wonder how you manage to do it all. Then there's a set of controls to handle the current in-use COM1, COM2, NAV1 and NAV2 frequencies (separate inc/decs for whole and fractional parts). These are for single display type devices like the GoFlight GF45 and GF46 modules The radio panels I am building will (for the time being) also be of the single-display (no stby freq) type. I managed to get away with it by setting the radio type to not having a stby frequency in the aircraft.cfg file, as you suggested. Works like a charm, and I don't even need the displays actually working (they aren't assembled yet), since I see NAV1, NAV2 and ADF frequencies in Project Magenta's ND and they get updated as I turn the respective rotaries. Cool. for Button programming only (not Keys at present) I've added a conditional facility I don't use a lot of joystick buttons. Most of my inputs are via a keyboard encoder. But the "at present" bit makes me feel I could hope for conditional keys facilities too... :wink: Best regards, Bruno.
Pete Dowson Posted October 21, 2004 Report Posted October 21, 2004 But the "at present" bit makes me feel I could hope for conditional keys facilities too... :wink: I'll have a look when I've finished testing what I've done to date. If it is easy I may slip it in on this next release, but otherwise it may slip. It will get done though. Regards, Pete
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now