Pete Dowson

Always 2 knots and 2 degrees? I've not heard of anything like that, though FS's turbulence is not terrible well implemented. Are you using FSUIPC at all? A lot of work was done within the FSUIPC wind smoothing facilities to get realistic turbulence emulated, and the algorithm used was well tested with PMDG aircraft, which appear rather sensitive to such things. Sounds like you are talking about default FSX weather settings. There are well known errors in the wind implementation in FSX -- carried forward from FS9, in fact, but probably more noticeable because FSUIPC's smoothing did work 100% in FS9, whereas it can't quite achieve that in FSX. I can only suggest investing in FSUIPC4 and using the wind smoothing facilities. They seem to have been well received. Regards Pete

There's no difference between FS9 and FSX in that area. And do the buttons actually work -- i.e. are they detected, shown in the "Test" tab when operated? And if the are shown okay, check that they are not shown as being assigned in FSUIPC. All buttons and switches can optionally be programmed in FSUIPC instead, and this takes precedence. No. That is for calibrating trim wheels and steering tillers -- axes, not buttons. You could check that tab, make sure they are all disabled. But do also check the trim sensitivity setting, on the Console page. Maybe you have set that very low, or too high? It defaults to 256, which is about right. Version 4.40 of FSUIPC is no longer supported. The minimum current version is 4.50. Regards Pete

Well, the T8 shouldn't have changed -- T8's and RP48's are assigned different groups of joystick numbers in FSUIPC. No, it hasn't come up before. And, of course, It would not always result in everything changing -- that's just bad luck. If the existing units were all in the USB chain/sequence before the last one you added, then I think none of the existing ones would have changed. Seems your setup was the reverse -- if you are using a hub for them all, maybe they are all plugged in starting at the "wrong" end in this respect. Regards Pete

I'm not sure anyone here will be able to help. I think you'll be better off in one of the SimConnect forums? Try http://www.fsdeveloper.com/forum/forumdisplay.php?f=60 http://forums1.avsim.net/index.php?showforum=255 Regards Pete

Are these all the same type of module? If not, you have a real big puzzle there as I'm sure they are all ennumerated separately, by type. If they all changed it is probable that the new connection happened to be the first in the USB scanning system, however that works. You'd probably needed really to move all the others "up" one and put the new one at the end . The problem is, of course, you don't know which socket is which in terms of how Windows counts them. This sort of query would be best addressed to GoFlight really, as they must presumably know about USB and their driver. FSUIPC can only deal with the identities it is provided, and if the new number 1 is number 1, then it is number 1. And so on. How can it know that the new number 1 is supposed to be number 4 or whatever? There's absolutely no way to differentiate like modules apart from their identity as supplied by their driver. Pete

Wasn't the example and so on clear in the document? The format 1=decrease=RX3880*X5300 is the SINGLE line format. The fact that it is complete in that line stops FSUIPC looking for any more! You need 1=decrease 1.1=RX3880*X5300 1.2=RX3880*X5300 1.3=RX3880*X5300 1.4=RX3880*X5300 1.5=RX3880*X5300 Pete

My "app" is not breaking. FSUIPC is a portal into FS. It allows you to read and write stuff in FS -- it does not know nor care what that data is. All it is doing is acting as messenger. You are breaking FS by writing your "crap", and then blaming FSUIPC for allowing it. I'm sorry, but I am NEVER going to "police" what is written and read via FSUIPC. That spoils the whole point of what it provides. I don't even know what many of the offsets do. It is up to you application writers to find out and take advantage. It has always been so and is not going to change. Pete

You would do, if that's what the value was. It is nothing to do whether it's a "USHORT" or whatever, you are letting the variable type confuse you all the time! It's the way you (YOU) view the number, whether in decimal or hex or whatever. FSInterrogate can show it in decimal, if you like, but then it wouldn't be so easy to read as a frequency, because it is encoded as BCD, which means it reads easily in hex. Equally, you are sure to be able to view numbers in your debugger in hex too, if you wish. All programming tools have options to view numbers how you want, whichever best suits their use. A "single"? What is that? Do you mean a 32-bit floating point number? Ugh! WHY? What on Earth is a "single" 11.2 supposed to represent? It isn't even remotely like any valid frequency in any case, even if it was a 16-bit BCD encoded number, which it most certainly is not, as a 32-bit floating point number! If you want a frequency of 111.20 you write 0x1120 (or presumably &H1120 in your language). All this is clearly documented, and not only that you can actually SEE it all in FSInterrogate. There is no excuse! Offset 0x034E is a two-byte (16 bit) value, representing the COM1 frequency in BCD. If you are trying to set it to some weird value, quite unlike any frequency it can possibly accept, then the result will be unpredictable. It will certainly NOT "break" FSUIPC. It shouldn't crash FS, but it could -- in some places, writing rubbish will certainly have a good chance not only of crashing FS but possibly corrupting your FS installation! This is not "FSUIPC breaking", it is YOU trying, for some weird reason, to crash or corrupt stuff inside FS. Remember, FSUIPC is merely your gateway to the innards of FS. If you want to completely wreck things you can, but don't expect help. You have a responsibility, as a programmer interfacing to FS. You are responsible for the data you write. If you are going to experiment writing rubbish to assorted offsets then do NOT ask me for any more support. It is a complete waste of my time, and I'm not going to keep lecturing you about it. Just follow the rules, write valid data, don't experiment using floating point where it most certainly is not used, nor vice versa! Sorry, but I'm not going to answer any more in this vein. I'll answer reasonable questions, but not stuff involving daft experiments writing rubbish data just to see what you can break. :-( Pete

4976 (decimal) is identical to 0x1370. They are the same number, the same set of bits, they are indistinguishable, just different ways of stating the exact same number! The bits are 0001001101110000. That's the binary you actually read. It equals 0x1370 in hex and 4976 in decimal. Decimal is to base 10, hex is to base 16, binary is to base 2. If you are going to do any programming you must learn to understand a little about numbers! Why don't you use FSInterrogate and look at what it returns -- it shows you hex and decimal? You'll soon figure it out by actually looking at what you get! You don't really need to do any "hex conversion". The digits are there already. That's what's so easy about "BCD" (Binary coded Decimal), you need no conversion to get character forms, except for shifting the bits out. The bottom 4 bits are "0" which gives 0. the next 4 bits up are "7", the next "3" and the next "1" -- hence 1370. Just shift out 4 bits at a time and convert them to characters by adding the character '0'. What's "bugging" you? I don't understand. Breaking FSUIPC? !!!!! HOW!? Please, I need all the information, dumps, logs and so on if you are managing to break FSUIPC. What are you telling me? :-( FSUIPC cannot and never does "decide" what or what not to "output". It outputs nothing at all. Please explain! nothing you are saying is making any sense! Why don't you use the TOOLS provided? FSInterrogate, Logging and so on. There's absolutely everything supplied that you need. All you seem to say here is that you've no idea what you are doing and that you are breaking FSUIPC? I really do not like that! :? Pete

Only with identical units -- the numbers depend on the order in which they are enumerated by the GoFlight driver (GFdev.dll), which probably depends on which USB socket they get plugged into. Different types of module have different reserved joystick numbers in FSUIPC so they wouldn't get changed. Not with GoFlight units -- in the current versions of FSUIPC you can assign LETTERS to named Windows joysticks (0-15), but the GoFlight units are numbered according to the GoFlight driver's designations only. it would be a darn sight easier to swap the USB plugs over than to edit the INI file, of course. BTW this sort of problem must apply to GoFlight's own assignment system? As far as I can tell identical modules are indistinguishable except via the USB connection. Regards Pete

I think you misunderstand. The 10000 altitude option you are using doesn't change anything you may have set in the weather system except the upper altitude of FS's lowest visibility layer. It isn't touching anything else, so without knowing how you have the rest of the weather set up it is not possible for me to comment further. If you want FSUIPC to deal with your visibility all the way up you need to think about using the graduated visibility facility. Otherwise you'd need to see the complete weather status -- maybe the output from WeatherSet2, or the weather logging in FSUIPC. Also, you have visibility smoothing enabled, so whatever the current visibility is, above the lower restricted level, it will take a while to establish itself at your set rate of 10% change allowed per second. Numbers are more meaningful here than pretty pictures, which are not measurable. I cannot "see" what is going on with your pictures, and I most certainly cannot estimate the seeing distance -- maybe you can better if you have a map of the area. BTW, what exactly is that the "75nm" you have in the "FS menu"? Is that in the scenery visibility options, or something in the weather? I've not really used FS9 for years, and certainly not changed FSUIPC's weather handling in well over 4 years, and I'm sure it still works as it used to, to everyone's satisfaction. I just wish i could do the same for FSX. Maybe you just need some clarification? The question you need to ask is, if FSUIPC was doing nothing, would you be seeing 75nm above the top of the lower visibility layer (which I think defaults at something a little less than 10000, but i may be wrong)? Since FSUIPC is not supplying a layer nor any restriction above that layer -- excepting for the smoothing of course -- I am a bit bemused about what you would be expecting it to be doing? Regards Pete

Okay. Versions 3.905 and 4.505 of FSUIPC are now available in the Updates Announcement, and contain these extra Lua facilities: ipc.macro which executes any named macro (or Lua program or control) ipc.btnPress ipc.btnRelease ipc.btnToggle which operate on a specific virtual button (0-287). More details are given in the changes list in the Announcement. Regards Pete

Okay. Versions 4.505 and 3.905 are now available, in the Updates announcement, and they include this facility. Pete

No no no! You misunderstand! :-( In version 4.50 of FSUIPC, there are NEW FSUIPC controls to operate the EFIS directly. For the default A321 you do not need to make macros! The same facilities may work for the FeelThere version too. Or else you can use the added LVar facilities, as I said a couple of messages back (you ignored that?). Please please DO read the release notes (History document) and see what is being added. I am doing all this work and you are ignoring it! You should be able now to assign directly, no messing about! I have still no idea whatsoever what you meant by "update window.dll". It means nothing to me. Window.dll is part of FS. How are you "updating" it? Please do read what I write. I feel I waste a lot of time repeating myself. :-( Pete

No burden for me. All you need to do is edit the INI file to make the button click send the same thing 5 times. Easy! Yes, and the same answer applies. In the Macro file use the multiline macro facility to repeat the same call. You could do a 10 times repeat there without fear as the macro calling will be 100 times more efficient than using keyboard presses. You can have two macros in your macro file, one for 100's inc and and for 1000's. That would enable you to select one or other for assignment. BTW, for rotary encoders which send alternate button presses and releases on each click, you should always program the same thing on both "press" and "release". Then you get one action per click instead of every other click. Regards Pete

Very strange. I've really no idea how or why it calls Window.DLL. In that case there was no point in creating the macros. The reason for the TAB test is so that you can tell whether it will work -- and you found it didn't! Sorry, I don't understand that part. Upgrade what? Did you try the new EFIS facilities for the default A321 yet, to see if they work on the FeelThere variant? Regards Pete

I don't know of any reason why not. It is "FSUIPC" by the way, not "FSCUIP". I think you need to find out more about these "unknown errors" -- if YOU don't know them, who does? How do you even know they are errors? The formats for read and write are identical, but you have to be sure they are legal frequencies. not all possible BCD values are valid frequencies. NAV ones go up in .05's, COM one's go up in .025's so the last digit goes 0, 2, 5, 7, 0 Pete

Window.DLL? Really? That seems very odd -- virtually all gauge functions use PANELS.DLL. Did you test these macros before naming them, using the Tab facility, as documented and as prompted on screen when making them? Incidentally, why don't you name them something more obvious, like "NDmode-" and "NDmode+"? And shouldn't they be part of your "A320CFM_feelThere" macro file, along with the others for the same aircraft? Having to find and select a macro in the drop down list by the name "window:JOY65_3_SW" seems a bit, er, deliberately obscure? If i were you I'd name things in terms you can relate to properly, like "A320" for your macro file (how many A320's have you got, after all?), and useful names for the actions inside, normally the same as the labels you'd like on the switches. If they don't work in the TAB test then you shouldn't have bothered to name and save them, as they won't work. As the documentation clearly says -- TAB test them first! I assume you are using FSUIPC version 4.50? If not, you should be! In that version there are added FSUIPC controls for the default FSX ND mode and other EFIS selectors, which certainly apply to the default Airbus. Maybe those will apply to the FeelThere version toodid you try? Otherwise it is possible that the gauges in this aircraft panel will respond to gauge "L:variables", or LVars. Use the facilities provided in the latest FSUIPC version (4.50) to list the Lvars and see if there are some you can use. Regards Pete

Well, those edits work fine here. When I said that was before I looked at the code. I can't actually do it that way, at least not without major upheaval, so I'm doing it differently. I'm still showing when there are more than one choices (e.g. in this case as "1 of 4"), but to try the different ones you have to repeat the mouse click. So the procedure will be (in version 4.505 or later) 1. Mouse click 2. TAB to test 3. If it works, okay -- name the macro and press Enter to move on 4. If it doesn't work, and the text shows "1 of 2" (or more), etc., click again, return to step 2. I'll do this in FSUIPC3, for 3.905, as well. Regards Pete

No, you've not missed anything. I've had a look at this, and it appears all 4 switches call the same routine in the PMDG code. This is referenced in the Macro by "R1". I've looked at the mouse rectangle tables, and there are 4 entries for the same routine - R1, R2, R3 and R4. The trouble is there's no way I can find for FSUIPC to determine which is the 'correct' one automatically, though it can tell there's more than one choice. I'm looking at changing the "TAB" test to show how many entries there are, and then so that each time you press TAB for the same mouse click, it looks for the next entry with a match, cycling around. Then you can find it by pressing TAB till you get the correct response -- and save that. Meanwhile, in this particular case, you can fix it yourself by editing the Macro file. Change the R1 to R2 for engine 2, R3 for 3 and R4 for 4. Regards Pete

Okay. The log shows everything is okay. I suspect you are running FS9 on Vista, and for some reason you are running it "as administrator", which gives it elevated privileges. For FSUIPC you should only do that to Register. Running FS9 normally, without those privileges should be fine, and then everything can connect to it. However, some folks make the mistake of allowing FS9 to install in the default place -- Program Files. This, in Vista, is a bad idea because all folders in Program Files are protected, and FS9, not being "vista-aware" like FSX, is badly affected. The solution, of running it in elevated mode, works, but if you do that you will have to run ALL FS client programs in the same way -- i.e. "as administrator", because Vista prevents privileged programs sharing data with non-privileged ones. All in the name of protecting you from yourself! :-( Regards Pete

Good! How are you programming it? This is by assignments to keystrokes defined in the PMDG software, isn't it? Do they provide a method for fast changes? For regular FS aircraft, or any not doing their own "thing" with the autopilot like PMDG, I would suggest FSUIPC controls which affect the A/P offsets, but this doesn't apply to PMDG. so if they don't have a fast inc/dec method then I don't know how you could do it -- it would be a bit much sending the keystroke combo 10 times for each click, probably simply overflow the keyboard buffer. How does it behave when using the mouse on the gauge? Have you considered using the "mouse macro" facilities in FSUIPC, rather than keystrokes? They are a lot more efficient, operating directly with the gauge code. You might find a better solution there. Regards Pete

Good, glad it was that easy! ;-) And thanks for the thanks! Pete

StrangeI'm thinking, then, that it is the power-saving setting on your USB ports. Go into the Windows device manager, find the USB stuff, and turn power management off. There's no other possible explanation I can think of. The power management in Windows turns off most of the power to USB devices when they are inactive for a time. Best switching it off. Sounds like you weren't assigning it to the correct control in FSUIPC then. The hat is a POV control and can either be assigned, in FSUIPC, as a set of 8 buttons, or as an axis. For smooth movement (in 3D cockpit mode) assign in the Axis assignments to "Pan view". Then it is almost the same as assigning in FSX -- not quite as smooth because of timing through SimConnect, but pretty good. If that's all you assign in FSX, best assign in FSUIPC instead, and disable joysticks in FSX altogether. Regards Pete

In all cases I know of in FS (all versions and all aircraft) fuel cut off is by Mixture Lean/Mixture Rich. You have something assigned which is forcing the mixture to stick at one or the other - lean for cutoff, rich for idle. In that case it is probably an assignment to the mixture control, or the mixture axis in FSUIPC. It would be easy enough to see in the INI file. You've probably only got mixture assigned for two of the engines. Pete