Pete Dowson

Are you being economical, like using 8 bits per byte for 8 switches, 1 byte for values up to 255, 2 for up to 65535, etc? No, not just commercial, but for any application, freeware or others, which will be made available to all. Private uses don't need separate areas to avoid calshes because no one else will use the software. No, because it may well be assigned to something which affects you one day. Best to use areas already allocated to something you are never going to use, such, for instance, those assigned explicitly to Project Magenta. Regards Pete

The apparent presence of more than one copy of FSUIPC running most usually occurs when the previous run of FS is actually still running, in the background, with no windows showing. This is caused by one or more threads hanging in what is known as a "deadly embrace", and seems to occur quite often with some add-ons. So next time it happens, call up the Windows task manager, and look for a Process called "FS9.exe". Terminate it forcibly from the task manager. That's an entirely different matter, and really more related to the hardware driver for the throttle quadrant. There should never be any reason to have to revisit FSUIPC options when changing planes. Maybe I need to see your FSUIPC.INI file. Regards Pete

The best way is a combination of both. You want your local hardware display updating as rapidly as you turn the knob, otherwise, due to latency of FS accepting the change, you will almost always overrun your intended values, but you also want the displays to respond to changes made other ways, in Fs: i.e. either by loading new flights or simply by the A/P or FMS controlling the values. I've always done it by mainitaining a local value (i.e. one local to the program controlling the hardware), and updating that as quickly as you are turning the knob, and sending the changes to FS at short intervals (eg 100-200 mSecs), but ignore FS read values until there's a significant hesitation in the changes from the hardware. Otherwise keep the display up to date from FS values. This avoids the lag but allows the display to show what FS is actually using when you aren't actually changing it. you can read and write any of the values you are likely to want to handle. You need the FSUIPC SDK, which contains the list of data (offsets) you can read and write, and some interface modules and examples in different languages. You could also try using a plug-in, written in the Lua language, which would also certainly allow this sort of thing. Regards Pete

Only with those, not with the aircraft for which you have specific assignments and calibrations? i.e. All those look pretty similar to the generic [Axes] and [JoystickCalibration] sections, so it's pretty strange if it only affects specific generically-treated aircraft. Hmmm. Weird, it sounds almost, but not quite, like FS's default time-interval based movement, but gone wrong. It might be worth changing FS's axis mode (the STICK_SENSITIVITY_MODE=0 parameter, as recommended in the FSUIPC User Guide). I see you are assigning to FS controls, which can make things a bit less efficient: Try changing the three affected axes to "direct to FSUIPC calibration", to see if that helps. Regards Pete

There are several ways of doing that, but fewer if you have the button set to do "gear toggle". It will involve editing the FSUIPC INI file in any case, so if you show me the [buttons] section from that file I can be more specific. Regards Pete

I've always used RC4 with timed AutoSaves without any problem. Perhaps you have the interval set too tightly, preventing a successful save for RC? (It calls the same routines in FSUIPC as AutoSave). I have mine set to 3 minute intervals, with a cycle of 10 saved files max, thus allowing a restart for anything in the last 30 minutes. Regards Pete

The FSUIPC SDK contains interface modules and the lists of offsets. For VB.NET you'd be wise to use Paul Henty's .Net module. Regards Pete

FSUIPC is always intended to be backward compatible, so that even today's FS9 version (FSUIPC 3.99) should be okay with FS2002, FS2000, FS98, CFS2 and CFS1. Conversely, a program written to work with FS2002 and earlier should work with FS2004 using FSUIPC3 and FSX, ESP and Prepar3D using FSUIPC4. If not I'd like to know why. As Paul says, the Lua plug-in facilities should make it pretty easy to do what you want. Regards Pete

Doesn't VRInsight provide facilities? I know it may use FSUIPC, but you don't need to purchase FSUIPC to use the VRInsight devices. I'm afraid I don't know that panel. If it can have actions assigned in FS itself, then it can also be so used in FSUIPC. Why not install FSUIPC in any case, and read through the User Guide to see if you want to buy it or not? You might also get better, specific help with that panel over in the VRInsight support forum. FSUIPC does not need an internet connection, and is not specific to a PC, only to a User. You can install it on any of your PCs, no problem. Regards Pete

Please refer to the offsets list, supplied in the FSUIPC SDK. Search for "fuel" or "tank" and you'll find the fuel tank capacities and proportions filled, separately for each tank. For FS9 and before you would need to add them up, but in FSX there are also separate totals in gallons and pounds. Regards Pete

Good. Thanks for letting us know! Pete

Just caught this before departing on holiday. If FS default keyboard shortcuts do something you want to program on a button, just enable Event logging in FSUIPC, use the keyboard short cut, and view the resulting event in the FSUIPC Log. It'll give you the correct name there. With FSX in windowed mode you can even use the FSUIPC console log option so you can see the results in real time, whilst you press the keys. Regards Pete

It won't be anything to do with an upgrade to 3.99, assuming you've installed it correctly and you are not using an invalid registration. Check the FSUIPC Log in the FS Modules folder, see what that says. And if it is a registered install, try removing the FSUIPC KEY file. If that makes things work then you either have a bad registration, or the PC's system date is incorrect, before your purchase date. None of that is really particularly relevant to FSUIPC. I am just leaving this moment for a holiday. Back June 1st. So apoloogies for any delay in further replies. Pete

It's the place for support of my modules, as documented. You are making a mistake, then. All three fields must be correct and as originally issued. There's been no change whatsoever is the way it is checked. Or maybe you are trying to use a WideFS6 key for WideFS7 or vice versa? I'm just leaving, this moment, on holiday. Back June 1st, so sorry for any delays in further replies. Pete

Good. i wonder if it was related to access permissions on the FS Modules folder. The FSUIPC installer sets those correctly, but possibly you did the previous install manually. Glad you sorted it out and thanks for letting me know. Regards Pete

Those are really entirely to user taste. Seems odd to me to have surface visibility allowed up to 100 sm whilst upper only 50 -- isn't that the wrong way around? surely you expect to see a lot further once aloft? in FSUIPC3 I always had much lower surface visibilties related to weather, with the defaults as shown (e.g. a max of 30 even if clear weather). Then graduated visibility up to around 20,000 (I fly airliners) at 100 sm or so. If you fly GA you might want a lower upper threshold. Regards Pete

No, it's a bug in SimConnect, in FSX. It's actually relatively rare (i.e. infrequent), so you are a bit unlucky. But I've never yet heard of any case where it isn't overcome either by simple persistence, or by ensuring nothing else is loading at the same time. Did you try that? BTW, More details of the error you get might be useful. The usual one looks like this (the version number might be different of course): With this, persistence is by clicking "Yes" each time, till it works okay. Then it is okay forever after. But, looking back, I see you described it like this: so what does your error actually show? Are there any details, or a button to click to get some? does it give any details in the Windows Event log? It might be worth getting a SimConnect log -- there's an entry in the FAQ subforum about that. You can paste the log into a message here. Please note that I am off on holiday after today (from 19th May to 1st June), so apologies for any delays in further replies. Regards Pete

LIQT wasn't set in any case. Are the others which were actually listed as being set inside or outside that "200 nm" range? When you say the clouds are re-drawn, are they the same cloud layers that were there before? I always thought the (same) cloud redraw problem occurred whenever the weather was being set anywhere, but maybe Active Sky manages it okay? Mind you I've not used FS9 for many years now so maybe I'm remembering incorrectly. FSUIPC doesn't draw clouds, except for the option to add a cirrus layer -- but didn't you say you had the FSUIPC weather options off? Regards Pete

It can only be one of two things: either you are making a mistake entering the details (best to cut-and-paste), or you have purchased the wrong key -- possibly one for FSUIPC3 instead? If you are Jim Short with a purchase on May 7th then the latter is certainly the case according to receipts sent to me by SimMarket. Incidentally, you do not download FSUIPC from SimMarket -- it is available on the Schiratti site with updates here in the Download Links subforum. Regards Pete

Did you forget to check the Weather logging option in FSUIPC? There's no weather logged at all. Regards Pete

Still, there's no way FSUIPC can be making ASE send changes when it doesn't want to. Sorry, you need to look elsewhere. You could enable Weather logging in FSUIPC. when this anomaly occurs, close FS and check the log, see what weather inputs and changes are recorded there. If it is an ASE problem I would think this information would help. If you want me to look at it then paste a suitable extract here showing where it is occurring. Note, however, that I am on holiday soon until June so I may not get to it till then. Regards Pete

In that case you certainly need to calibrate the minumim with the lever pushed forward a little. You should be doing this in any case (it is one of the numbered calibration steps in the instructions). Without a little "null" area at each end of the movement you cannot guarantee to reach 0 or full. And in this case it sounds very much like the lever is running off the measured area of the hardware and either dead shorting or coming to a place where it is disconnected, so calibrating there will lose a lot of the intended output range. That's a hardware thing. It may even be a fault on that lever, but nevertheless it can still be overcome by correct calibration. Well, all of those show you've simply not followed the instructions for calibrating. Having -16384 and +16383 as minimum and maximum is NOT calibration. There's no room for jitter, no room for hardware differences, nothing! There's really no point in using FSUIPC for calibration if this is what you want -- you'd be far better off just using FS itself. Please follow the steps listed in the User Guide for calibration. There is no way any properly calibrated axes will ever have the maximum maximum and the minimum minimum. Regards Pete

The check is being done at a higher frequency than the slow/fast boundary, and it should be fast enough, easily, to see all changes (i.e. it cannot miss a complete on-off-on cycle). Therefore simply noting the time between detected changes and seeing if that is less than or greater than the "FastTimeLimit" will do the job. It doesn't need to know the exact time between the rising and falling edges, only how long it is between it noticing the changes. (The "Time" value being given to the poll function is a system supplied elapsed time in milliseconds). The poll rate is independent of other threads and activities in FSX, but it is subject to getting processor time. On a multicored PC this shouldn't be a problem, though some activities on a PC can lock out the processors. Certainly when FS is loading a new flight it could be starved of processing time because FS will be using as many cores as it can get then. But really nothing should affect normal rotary operation in any significant way. It can only "drag down" FS performance a touch (probably unnoticeably) if you make the poll rate ridiculously high. Don't make it more than 200 times a second, for instance. 50 or 100 should be fine. 50 should be far faster than you can turn the knob and that's all that is needed to stop it missing changes on the incoming signals. Well, yes, sort of. But you can only have one "ipcReady.lua" plug-in. There are two ways to do this, one more efficient than the other: 1. Rename this one something like "Rotary3031.lua" (for button numbers 30/31), and create a new ipcReady.lua containing only this line: ipc.runlua("Rotary3031") Then for any other rotaries, make a copy of the Rotary3031.lua, changing the name appropriately, and the button numbers within, and adding another ipc.runlua line to the ipcReady.lua. Note that there are several lines needing a change for each rotary: First, the pair of button numbers signalled from the device: cwise = 31 --Button number for clockwise turn ccwise = 30 --Button number for counter-clockwise turn then the "virtual" buttons being signalled to FSUIPC affects these lines: fast = 1 ipc.togglebitsUD(0x3340, 1 + fast) fast = 4 ipc.togglebitsUD(0x3340, 4 + fast) Those values are for virtual buttons 0-3, for one rotary, and use bit values 1,2,4,8. Correct the "B" to a "D" where highlighted first (that was a typo in the original). The main changes would be as follows, for each of up to 3 extra rotaries. Replace the red parts by: Virtual buttons 4-7 (bit values 16,32,64,128): fast = 16 16 + fast fast = 64 64 + fast Virtual buttons 8-11 (bit values 256,512,1024,2048): fast = 256 256 + fast fast = 1024 1024 + fast Virtual buttons 12-15 (bit values 4096,8192,16384,32768): fast = 4096 4096 + fast fast = 16384 16384 + fast This will work and is easy enough, but it is a bit inefficient as you'll have as many separate timers running and Lua threads running as you have rotaries. I wouldn't use this method for more than 4 rotaries if I were you. Too many timers, and an unnecessary number of threads. OR 2. Change the current program to handle as many rotaries as you wish, using tables of numbers and loops. More complicated, but more compact and efficient than lots of little plug-ins. If you plan on having more than, say, 3 or 4, then let me know and i'll knock up the more advanced version. I'm going on holiday Wednesday eve and won't be back till June 1st or 2nd, so whilst i can probably make one for you before I go I probably won't be able to test it. Best done when I get back really. Regards Pete

Ah okay, I see. So it is effectively controlling what ASE sends to FS. If ASE isn't sending those changes, I wonder why this user is seeing them? FSUIPC doesn't apply any changes itself, and especially not to clouds. Of course it can limit changes (as in smoothing), but not make any. I think I see why you suspect it might be something peculiar to his specific system. Something odd with some settings someplace? Must be a coincidence that he's only just noticed after updating from FSUIPC 3.98 to 3.99. Thanks for the explanation. Pete