Pete Dowson

As I said, but it crossed with your second message, I changed to the Shell fonts in order to fix the few cases that get reported where the dialogue tabs don't fit in the window at all -- where they are actually 50% too big! At least this problem is not critical like that. You can use it still without any problem really. it just looks bad. Regards Pete

That's weird. Not seen that before. Seems that the "Shell" fonts in some versions/updates of Windows are slightly larger than the specific Arial ones I was selecting before. I expect you could fix it by changing the windows style or font (not the font size which should be irrelevant), but if you are getting that with default fonts I shall have to widen the edit boxes a little. I only recently changed to the Shell fonts in order to fix the few cases that get reported where the dialogue tabs don't fit in the window at all -- where they are actually 50% too big! Could you do me a favour please? Check every TAB in FSUIPC, see if there are any others which don't fit? Thanks. Well, I'll try to fix it, but luckily it isn't crucial and won't prevent you doing what you want to do -- unless it loses even more than a half or one digits, that it. So, please carry on for now. When I've got full information on which fields it might affect, I'll make another update. Regards Pete

That's okay. I've found it. it was a silly bug introduced with my additions for the [Auto] macro/Lua execution facilities, which occurred BETWEEN the latest release and the last main user release (4.53 or 3.93). So at least it hasn't gone out on general release yet. So, thanks for getting me to fix it before I do make a general release. Interestingly, if you did have [Auto] aircraft-specific sections as well, the bug would never occur -- which is why I didn't see it. Natually, to test the new [Auto] facilities i was using them to their fullest! BTW the full aircraft name displayed in the Axis assignments tab is wrong, and that's a long-standing minor bug. I'll fix that too. All parts should display the matching name, whether that be full, short or substring. I'll be posting updates with these things fixed later tonight. Look out for them in the Updates announcement. Thanks again, Pete

Well, yes, or interpret "many months" to mean "many months". I try very hard to maintain compatibility so that any old, now disused, parameters are ignored or even deleted, and any changes ones are renamed. But it may not always be possible -- hence the warning in the document. Incidentally, the gap between 3.90 and 3.93 is 6 months, which isn't "many" in my book. Sorry if you lost your settings through such a misunderstanding. Regards Pete

Something's been changed, then. What did you change? When you say your "system" locks up, do you mean the wrole system -- do you have to do a system reset/power down? If so, then it has to be something wrong with the hardware, or possibly the drivers for the joysticks. At what point, exactly, does this "lock up" occur? What's the last action you take? Can you access and use all the other FSUIPC tabs in the Options? And, for FSUIPC support, I need to know the FSUIPC version number. If it isn't at least 3.93 then please update first. There's also a 3.945 in the "Updates & Goodies" announcement above. I wouldn't suppose anything like that would make any difference at all. You'd need to uninstall to get drivers re-installed. Regards Pete

Why would you delete your INI file? That contains all of your FSUIPC settings! I hope you made a backup! There's never any need to delete anything when updating FSUIPC, unless its an upgrade from FSUIPC 1 to 2 or 2 to 3, or similar giant leaps. You only want to delete your settings when you want to start again with all default settings, or possibly just to diagnose a problem -- but then you should keep a backup unless you really do want to reset all the options, reassign all the buttons and axes, and re-calibrate. A new INI file will only be created when you run FS, not just by installing. So something changed things for you? There's no way things change by themselves, unless the hardware goes wrong -- but you said the button still worked. If things are working, the INI file is there and working too. Regards Pete

Version 3.90 is old and unsupported. Please check the "List of Current Supported Versions" Announcement. After updating to 3.93 you may also wish to get right up to date and overwrite that with 3.945 which is available in the Updates & Goodies announcement. By "quit" you imply you had it working once. So, what did you change. That'll be the clue. Sounds like you have some other assignment for Spoilers, perhaps an Axis, which is trying to set the spoiler too? Please update, then come back if you have more questions. Regards Pete

The "latest version" being what number, exactly, please? A lot of folks say such things, but "latest version" really means nothing without stating the numbers. Can you show me a picture of the first TAB, the "About" one, so I can see for myself? I ask this because in two different cases of this problem reported only recently, both were fixed by the updates I posted. If you are using 3.945 as I suggested, and still have the problem then I am completely mystified. Why would the changes fix other folks' systems and not yours? Pete

Good. Thank you for letting me know. Good flying! Pete

Sorry, then you missed some important points: The Updates & Goodies announcement contains the very latest version, but you need to get the main release, 4.53, from the main download site. The List of Current Supported Versions tells you I don't support versions earlier than x.xx (4.53 in this case). Regards Pete

Don't even try registering 4.20. it's very very much out of date and totally unsupported. you need to download 4.53. That's a load of nonsense brought about by folks not bothering to read Announcements nor obtaining the current version. Download the 4.53 ZIP, read the installing and registering guide inside. Regards Pete

Well, the only changes which would have touched such areas were those for the Profile system. So, that leads me to the next question: Profiles were introduced in version 3.90 and 4.50 (both February 2009). That's nine months ago. Do you think that you wouldn't have noticed the problems in that time, perhaps due to not updating until recently, or not making changes in those areas of your INI configuration till recently? In other words, when were you absolutely sure the behaviour did not exist, and with which version(s)? If you can recall such information it would be of great help. If i can tie it down specifically to the Profile changes it will be quicker for me to locate and fix the problem. Regards Pete

This is after you deleted the sections with the full aircraft name? Obviously, once those are there it will match them preferably in any case. With all your experience, if this were a bug affecting all substrings, wouldn't you have noticed the problem before? There are/were a lot of folks using this. Maybe it's only related to the very short substring (only two characters)? I'll check that here -- but it will have to be late tomorrow now as I have a hospital appointment in the morning (very important. My eyes are deteriorating daily now). Maybe you could check with a slightly longer substring, just to see? Hmm. Interesting. It should be consistent as they get the data from the same place, or should do. I'll check into that too. No. I can't do that, much though I'd like to. I'll look into these things. It just seems so weird to have them coming up now, after all this time and with such a lot of exposure. You yourself said you have a lot of experience with the facilities, so how come this just comes up now? Strange. I am gradually having to reduce my working time on the PC due to my eye problems. But before I have to stop altogether I must fix things that don't work correctly! ;-) Regards Pete

There's no difference with FSUIPC on Win7 64 bit. Are you using FSUIPC to assign or calibrate or both? So, what is it you are asking about FSUIPC? (Incidentally, there is no "FS9 calibration"). What does this "numbers on the left" and "numbers on the right" mean? There's no where I know in FSUIPC that works like that. Did you find the User Guide for FSUIPC? If so, did you find the section on Joystick Calibration? Did you read it and follow the steps? Seems that many folks dive in without knowing anything about what they want to do or how to do it. Decide: "if I have perfect results without FSUIPC, why am I using FSUIPC?" If you want to use FSUIPC for some reason, maybe you should not also be using CH Manager? That's seems to be a sure way to get confused judging by other users messages here. If you do want to use both I think you should head over to the CH Hangar (http://www.ch-hangar.com ) and take Bob Church's advice. There might also be something useful in the "FSUIPC Guide for CH users" sticky thread, near the top of this Forum. If you want help, you need to be a lot more specific please. Are you assigning in FSUIPC or in FS? If in FSUIPC, what are you assigning to, and in which mode? When calibrating are you following the numbered steps, and if so at which point are you saying things go wrong? Which part specifically is it you don't understand. Referring to numbers not moving doesn't help, especially when it seems you are looking for them to move where they don't. Regards Pete

It is only logged because we have "extras" logging enabled to get more information about the mouse actions. It means that, at the time it was requested, SimConnect could not supply weather information for a specific location. It may be able to a bit later, or it may simply be a weather station which hasn't been populated specifically. With Extras logging I log all Exceptions returned from SimConnect. (There are other logging options which log everything sent to and returned from SimConnect!). Nothing to worry about. Regards Pete

It's due to a mismatch in the font size computations in Windows and the COMCTL32.DLL, and it has plagued me for several years, as it only affects a handful of users per year and I could never reproduce it. However, recently I found a solution published on some deep-down Microsoft website, and applied that, and according to folks who have tried it, it works okay! Always check for updates, preferably before posting, because very often your problem would have been known and fixed beforehand. You can check for updates by simply looking in the Announcements at the top of this forum. Regards Pete

I have no idea and I don't know how you expect me to have one. The aircraft is not mine, I do not know its innards. I don't know how they've written it so that these things happen. I don't even have it here to muck about with. I was only trying to help you experiment to find a solution. The only other way would be for you to hack into the code and work it out yourself. it might not be possible in any case. Logging the real mouse operations and emulating them seemed to be a good idea. I don't know why it doesn't work - maybe it needs the screen coordinates on one of those lines (which of course we cannot supply with mouse macros. You might be able to find a solution by experimenting with other combinations. You've only tried two or three so far. I've tried to suggest ways, but I cannot solve it for you. You have to do that yourself. I've no other ideas for you. Pete

Ah. So you are really talking about normal joystick buttons. Windows doesn't control polling rates -- that's up to the application. This is assigned in FSX or in FSUIPC's buttons tab? To which controls? So you are using FSUIPC. Have you left FSUIPC's button poll rate at its default (the PollInterval parameter)? If you assign in FSUIPC you actually get a default 40 polls per second -- more than the nominal FSX rate of 6 per second. Have you compared assignment in FS with that in FSUIPC to see? No? So what was this all about: "it would seem that FSUIPC4 is event driven, updating only when there is new data or a change in data state." That is most certainly only about reading data from FSX. Writing data to FSX is certainly completely unrelated to FSX data change rates. However, this: "Thus updates are dependent upon the simulation or FSX frame rates." is true for FS gauges on screen. Obviously they cannot be updated more frequently than the graphics can be changed. The polling (which is "I" only, not "I/O") is not at all dependent on frame rates. It is specifically set and adjustable, as documented (such parameters are covered in the Advanced User's guide). However, it is a lot more frequent than FSX's polling rate, without adjustment. Yes, but I don't think that will influence the gauge update rate in FS, if this is what you are observing. And it sounds like it is. One thought. most rotary encoders pulse "on" for one click and "off" the next. So to have an increment per click you need to program the same control on both "press" and "release". Have you done that? Another thought: FSUIPC does throttle repeats to a certain extent if they build up a big queue for processing in FSX. It does this deliberately so that when you stop turning the knob, (or pressing a button with Repeat enabled) FS doesn't carry on doing the increments that have piled up. I don't provide any option to remove that, and I don't think I should else you'd get overshoots quite a lot when FS gets busy. The ability for FS to process updates is dependent upon its workload -- certainly frame rate is one indicator of that, so a faster frame rate will get more increments done quicker. What sort of performance are you seeing? There are also slow gauges and fast gauges -- well written ones, and badly written ones, smooth ones and jittery ones. You might need to make choices. Regards Pete

No, sorry, I don't understand that at all. What, something in Windows thinks it is dealing with a non-existent program? If it thought FSUIPC.EXE was to be run, you had a parameter somewhere telling something to load it. I really don't think Windows invents program names. Next time you'd best take a screenshot. I'd like to see that! Regards Pete

Why is that? You can use a multiplier and a divisor, as documented in GFDisplay.doc. So you have GFdisplay running on the FSX PC? That's good. See my news about Lua at the end of this reply. The reason for the "bad multiplier" error is that you are only allowed one multiplication and one division. You have three numbers and three operations and you've introduced parentheses () which aren't recognised either. You are simply not folowing the very basic format laid down. Use *360 /4294967296 (i.e. do the computation 65536 * 65536 yourself instead of asking the computer to do it every time). Even faster and more compact, do that division yourself and end up with just: /11930464.71111 Also, on that D0= line, you declare offset 0580 to be both type "U16" and type "F64". It cannot be two types at once, and in fact both are wrong in any case -- 0580 is 4 bytes long, or 32 bits, so it is clearly a U32 type! On the D1= line you have the wrong formula in any case, so you aren't being careful enough to read the information. To start with 02A0 is SIGNED (the mag var can be negative as well as positive!) so it is type S16, and if you do *360/(65536*65536) you will get zero as the biggest number in a 16-bit value is only 65535! Please take more care, read what is written, do not invent your own formats, and always think about what you are doing and what the documents mean. There seems to be a lot more errors in other lines. Please do check them yourself. Check what you are doing against the defined formats. Incidentally, I plan to discontinue support for GFDisplay as soon as I've added GoFlight display capabilities to the Lua plug-in capabilities of FSUIPC. I'm working on that now. It is a much more powerful programming environment, and there are books on Lua programming so it saves me doing the tutorials! ;-) Regards Pete

Well they are the same as what the real mouse action seems to do, so that's whjat I would have thought would have worked. Strange. Maybe there's no way to do it then. Regards Pete

You'll need to say a little more than that I'm afraid. Rotary encoders are simply knobs which are turned to create signals, which then have to be interpreted by some software to create appropriate actions such as increments or decrements. How you do that will determine whether there's any noticeable "delay". And how are you measuring this delay? Do you mean you turn a knob and some seconds later something in FSX changes? What is the data, what is the route, where are you seeing it? But that's all about reading data FROM FS, not writing to it, which is what you must be doing with an encoder, surely? And of course it doesn't update values in the offsets when they don't change -- that would be a silly waste of time. Naturally. The higher the frame rate the more smooth the flying too. I'm not sure of the relevance of that. Apart from possibly increased frame rates as you already suggest? Reading and writing of what, exactly? You give me nothing to go on here. Sorry. Pete

Yes, you miss installing "GPSout.DLL", and editing its own configuration file. Before FSUIPC4, WideServer, AutoSave and GPSout were all separate modules, all installed into the FS modules folder. Take a look at the usual download website. Regards Pete

If it's the message I think you mean, this is usually because your previous run of FS hasn't actually terminated. The windows may have closed and it looks like it's finished, but look in the Process list in Windows' task manager (Ctrl-Alt-Del) and you may find FS9.exe still listed. delete it if it is. The only other possibility is another copy of FSUIPC.DLL placed, incorrectly, in the main FS folder instead of the Modules folder. Regards Pete