Pete Dowson

I'll point it out to the SimMarket manager. I agree that "Marty" doesn't appear to be reading what you wrote. Pete

"Previous Flight"? Neither FSUIPC3 nor AutoSave save such a flight. That's an automatic action by FS. FSUIPC4 does do a "Previous Flight" because it seems FSX is not so considerate. Since it is supposed to be simply a "fix" for what Microsoft omitted, it's on FSX exit, same as FS9 does. The filenames already contain the day and time. This has been the same now for 12 years or more. I'm not about to change such a standard. If you want to see the date and year it is easy enough in Explorer. Hmm. Interesting idea, but more complicated than it sounds. The aircraft titles FSUIPC sees are not restricted in length and can contain characters not allowed in filenames. How would you suggest the filenames be formed given this problem? What if throwing out unwanted characters and abbreviating the names to sensible lengths made them less distinguishable? Consider those folks with 10 or 20 different paint jobs of the same aircraft. Regards Pete

Ah, I thought you were pointing to the compiler errors you listed, i.e. But all you are saying is that you can't read a byte at offset 0238. which just provides the local Hour (0-23)? I've no idea what all that means -- is "Byte()" supposed to mean an array of bytes? Is "(&H238, 10)" supposed to mean you read 10 bytes? What's the 10 bytes from 0238 got to do with TCAS? Sorry, I'm obviously confused -- that just seems to be about getting time and date information! What lines do you have which do actually work? Maybe you need to compare what does with what doesn't work to see what the difference is? Why did you post that code fragment originally, as it seems to have nothing at all to do with your questions? So, why, then, are you listing those errors? I'm not clear what your first post was about at all now. There seems to be no information here relevant to your questions, only information showing a fragment of code with compiler errors?. Pete

I can't help you myself as I know nothing at all about VB. Surely the compiler errors themselves are telling you what you are missing? I mean "Connected" to start with must be a variable you declare, set and clear as appropriate. And evidently you are missing the most important parts, the links to the main interface routines (FSUIPC_Read, FSUIPC_Process). I don't know what "FSUIPC_Get" is -- must be peculiar to the VB implementation. I assume there's a lot more code someplace that you've not posted. I mean you haven't even opened the link (FSUIPC_Open) in that extract! Have you tried the examples? They worked when posted by the volunteers who did the VB part. Also,all of the interface source is provided so if you know VB well enough you should be able to sort things out quite quickly. If you don't know VB then this area is probably not the place way to learn. Unfortunately the title you've given to this thread isn't very useful to attract the right folks to reply. Shouldn't you have used something like "Trying to use VB2008 to interface to FSUIPC, need help"? Regards Pete

Right. I've made some drastic changes (up till the wee hours), and even simplified things a bit in the process. Both UI and run-time action for the brake axes should now follow the same path through the code and therefore give the same results, which themselves seem okay now according to my testing. Of course I could be wrong, I have been twice before already, so please try 4.709b and let me know. Regards Pete

This is a bit belligerent, isn't it? Why? I don't think being an OAP is an excuse, if you mean by that someone over 65 -- I am 68 myself. All we wanted was information so we could help, so we asked questions which you continue to avoid answering for some reason which is completely beyond me. :-( Pete

Really? That's odd. there are thousands of users without any. Sounds like ou are confused about what you are doing or what is happening? And if it's been happening for two years, why so long to report any of tihs? It is NEVER necessary to "reinstall" FSUIPC4, because the only part which IS the FSUIPC4 program is the DLL module itself, which doesn't change (except between versions). Replacing something with an exact same something accomplishes nothing. If the DLL itself became corrupt (because of disk errors or some malware trampling on programs), it wouldn't run at all as its signature check would fail. Sorry, but it does really sound as if you've made a mess of configuring it, and are getting profile settings loaded which you yourself have set and since forgotten. If you don't know what you've done wrong I suggest you simply delete the INI file and start again. Everything is in that file. There's nothing mysterious or hidden going on. You can see it all for yourself. "The bug"? Which one of the many you seem to be accusing it of? Without any information -- such as Version number of FSUIPC4, version of FSX, and most importantly log files showing the problem, there is no way I can possibly help. If FSUIPC ceases to operate the things you expect it to do it may well be a SimConnect stalling problem. But the log would show. The information is there. Why not look? If you are not using at least version 4.70, then please don't come back until you've updated. There are also later versions here in the Download Links subforum. After installing 4.70, try that. I've no idea what you mean here -- there's no reverse zone on that quadrant, only a button. But in any case I cannot (will not) support Saitek devices. Try their support. They use FSUIPC without permission or payment. Regards Pete

Er...it sounds as if you are terribly confused! The keypress Shift+/ is a default FS keypress. Unless you've re-assigned it in FS itself, It makes FS send itself the Spoilers Arm control. FSUIPC does have some assignable Hot Keys (in the Hot Keys tab), but the only keypress recognition facilities otherwise are for sending FS or added FSUIPC controls. There's no point whatsoever assigning the Shift+/ keypress to "Spoilers Arm" in FSUIPC because FS itself already does that! If you are really talking about assigning a joystick button you should assign to the FS control, not to a keystroke, which is a bit pointless and inefficient when all FS is going to do is convert it to the control you could have assigned in the first place. Evidently. What do you think you mean by "which keys that FSUIPC doesn't intercept"? Sorry, but that makes no sense to me. FS itself has Shift+/ assigned to Spoilers Arm. Unless you've deliberately gone into FS's assignments and changed it. If you enable Event Logging in FSUIPC it will show the events which Fs is using. That doesn't mean FSUIPC had anything to do with sending them. Even if you remove FSUIPC altogether, Shift+/ still sends SPOILERS ARM, unless, as I say, you changed the default FS assignments! Pete

The shift / key press isn't an FSUIPC shortcut, it is an FS shortcut. FSUIPC doesn't interpret Shift+/ , FS does. So I don't know why you are even referring to FSUIPC at all here. It isn't involved. I think you must be using the Spoiler Arm control on the ground. This makes FS deploy full spoilers as if the aircraft had just landed. Try it in the air. Regards Pete

the brakes treatment is very different, and not only because it is centreless. The original code handles brakes for FS98 via the 0x0C01 and 0x0C00 single byte offsets, which have the values 0-200. These are incremented by pressing the brakes button (.), and build up faster the quicker it is pressed (or if held), and die down over time. The brake axis treatment added by FSUIPC back then had to retain the pressure the axis was providing, so it became quite convoluted. For compatibility across versions since then all that original method is still retained and applied back to FSX's true axis support. The brake axes are unique in this regard, and the route the values take is quite different from all the others. I'm working my way through it now. Regards Pete

Ouch! I don't think i can support windows 2000 with any current versions. I've no idea, but it seems likely. There are so many new facilities since XP. I definitely support XP (from SP1), Vista, and Win7. There's probably some facility now needed which didn't exist way back then, but identifying it would be a bit of a problem. Pete

Hmm. there's something strange going on here. I've tried with the release-built version and I also get the same discrepancy, yet the debug-built version, the one from which i showed the logs, shows the same in the GUI as in the log. I'm not understanding this at present. That's one problem with delving through n-year old code, especially at my age! Sorry! I'll take a longer look. Back in a few days, hopefully!... Pete

With your exact parameters (but no filtering) and all three ways of assigning tested, I get matching OUT and logged FS values, every time, within 40-80 units (that's the granularity of the braking values, which runs 0-200). I've checked it with slopes as divergent as 15 and -15. I really can't do any more. I don't understand why it appears not to work for you, but logically, now, there is absolutely no way around the slope processing. I changed the logging in 4.709a so you could see for yourself. If you have Axis event logging you should see the same as I. Here I have that set, and also I am monitoring the FSUIPC offset sohing the actual brake application in FSX (which is measured from 0 to 16384, not -16k to +16k, which explains the difference). I'm logging, in each case, the last few "notches" to full application (IN = +16383 in this case). the max in the INI is edited to 20480 as in yours. The Log shows IN and OUT values, exactly as would be shown in the Calibration dialogue, and you can see that the OUT value corresponds with what is sent to FS. The actual application in FS is rather different because of the different range (0-16k instead of -16k to 16k). So, where are you logs showing the opposite of this, something you are saying isn't working? Left brake assigned in FSUIPC to FS control "Axis Left Brake Set" ================================================================= Slope = 4: 1581953 *** TOE BRAKE AXIS, Left set = 169 (IN=15360, OUT=11304) 1581953 *** AXIS: Cntrl= 66387 (0x00010353), Param= 11304 (0x00002c28) AXIS_LEFT_BRAKE_SET 1581984 Monitor IPC:0BC4 (S16) = 11609 1581984 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.7085272059 1583578 *** TOE BRAKE AXIS, Left set = 163 (IN=14848, OUT=10320) 1583578 *** AXIS: Cntrl= 66387 (0x00010353), Param= 10321 (0x00002851) AXIS_LEFT_BRAKE_SET 1583609 Monitor IPC:0BC4 (S16) = 10685 1583609 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.652183173508 1584015 *** TOE BRAKE AXIS, Left set = 158 (IN=14336, OUT=9502) 1584015 *** AXIS: Cntrl= 66387 (0x00010353), Param= 9502 (0x0000251e) AXIS_LEFT_BRAKE_SET 1584047 Monitor IPC:0BC4 (S16) = 9915 1584047 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.605134604695 1584765 *** TOE BRAKE AXIS, Left set = 177 (IN=16383, OUT=12614) 1584765 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12614 (0x00003146) AXIS_LEFT_BRAKE_SET 1584797 Monitor IPC:0BC4 (S16) = 12840 1584797 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.783690093614 1603250 Sim stopped: average frame rate for last 21 secs = 38.1 fps Left brake assigned in FSUIPC direct to FSUIPC calibration "Left Brake" ======================================================= Slope = 4 1806547 *** TOE BRAKE AXIS, Left set = 169 (IN=15360, OUT=11304) 1806578 *** AXIS: Cntrl= 66387 (0x00010353), Param= 11304 (0x00002c28) AXIS_LEFT_BRAKE_SET 1806609 Monitor IPC:0BC4 (S16) = 11609 1806609 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.7085272059 1806844 *** TOE BRAKE AXIS, Left set = 174 (IN=15872, OUT=12124) 1806890 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12123 (0x00002f5b) AXIS_LEFT_BRAKE_SET 1806922 Monitor IPC:0BC4 (S16) = 12379 1806922 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.755575774714 1808031 *** TOE BRAKE AXIS, Left set = 177 (IN=16383, OUT=12614) 1808094 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12614 (0x00003146) AXIS_LEFT_BRAKE_SET 1808125 Monitor IPC:0BC4 (S16) = 12840 1808125 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.783690093614 Left brake assigned in FSX to Left Brake ======================================== Slope = 4 2089797 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450) 2089828 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET 2089859 Monitor IPC:0BC4 (S16) = 12688 2089859 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.774395106871 2089890 *** TOE BRAKE AXIS, Left set = 172 (IN=15684, OUT=11796) 2089953 *** AXIS: Cntrl= 66387 (0x00010353), Param= 11795 (0x00002e13) AXIS_LEFT_BRAKE_SET 2089984 Monitor IPC:0BC4 (S16) = 12071 2089984 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.736756442556 2090875 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450) 2090906 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET 2090937 Monitor IPC:0BC4 (S16) = 12688 2090937 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.774395106871 I really don't see there's anything else I can do for you. Everything I've checked shows it works as intended. If you are using a slope like +4 or +15 then the top end is going to be pretty similar. You can see the real changes the Slope effects near the brakes-off level -- the area you are intending to affect in any case! Your "20480" artificial limit provides are real limit of about 12-13k, which is correct. (16384/20480) x 16384. If you want to limit it to 9k you'd need the upper limit set to (16384/9000) x 16384 = 29826. If you still think it is wrong all I can suggest to you is that you write your own algorithm in Lua, as a lua plug-in assigned to your brakes. Regards Pete

Okay, all reasonable. I just wonder why no one discovered that the slopes facility was inoperable on the brake axes before now? Must have been like that for many years! ;-) Regards Pete

Okay. Versions 3.997a and 4.709a work here with your data. Regards Pete

There's no such thing as a "registered" version. You download the Installer for FSUIPC4, and during Installation you optionally register it, as explained in the Installation and Registration document included in the Zip. You either use it registered or unregistered, there aren't separate versions. And how did you do that? The downloaded package contains an Installer. You MUST run the installer. You don't personally put it into the modules folder. If there's an FSUIPC.INI file (your "configuration settings") then you have already installed it and run it, and it is probably working, as that file is made by FSUIPC when it runs. There is never a desktop icon for FSUIPC. Why should there be? It may well be, but so far you've not told us anything useful at all! I repeat Ian's questions for you, perhaps you could answer them this time, please? Then we might get somewhere. What is not working exactly? What are you expecting it to do? What exact version of FSUIPC are you using? Registered or unregistered? Have you tried reading any of the instructions at all? The installation and registration guide would have been in the ZIP you downloaded. The User Guide is in the folder "FSUIPC Documents" in the FS Modules folder. Regards Pete

You are using Filtering? That takes several sequential readings and uses a computed smoothed value. It will be counteracting any changes is slope to a certain extent, and it will certainly make it impossible to compare "OUT" vlaues displayed in the calibration tab (which obviously cannot be smoothed) with real resulting values sent to FS. Filtering is generally a bad idea -- it was originally added for a gentleman in Malaysia who's PC's power supply was so bad that filtering was the only answer to any sort of control. Generally, it isn't needed for any recent devices unless you are is a very variable environment (temperature and humidity-wise) or have very worn or dirty controls. [LATER] Just doing some experiments, I get the same sort of results as you, even without filtering, but ONLY when the maximum calibration point has been "fiddled" (to 20480) as you have. Evidently there's something in the real-time computations which is assuming that, for slope computation purposes, the max cannot be more than 16383. I can't afford to spend a lot more time on this this week. could you possibly explain why you need any slope manipulation on the brakes axes? I'm pretty sure they weren't even added to such axes originally (and when they were, they obviously had no effect as I found out and fixed earlier today). As the only user of slopes on brakes, it would be useful to understand the reason for it. If I can fix it easily I will do it sooner though. {LATER STILL ... ] Okay, I see what happened. I inserted the slope application call in the wrong place -- it is using uncalibrated, not calibrated values. Hence it was ignoring your artificial 20480 max value. I can fix it pretty easily, but I can't build and upload a new version till tomorrow. It will be 3.997a or 4.609a, dated 22nd June 2011. Regards Pete

Not acording to my logs, nor monitoring the brake offset to see how much it is operating. This is with assignment to the FS brake axis control, and it is working perfectly correctly. Maybe it is related also to how you are assigning the brakes? I don't think you ever told me that? Are you using FSX assignments, or FSUIPC to FS control (and which ones?) , or FSUIPC direct to FSUIPC calibration? I won't have time to re-investigate for a few days now. but more information is obviously needed! Regards Pete

Seems that slopes have NEVER been applied to the brakes axes. Same in FSUIPC3. Probably no one ever thought of using them on brakes. Fixed in FSUIPC 3.997 and 4.709, now available in the Download Links subforum. Pete

Can you show me the FSUIPC4.LOG file please? Pete

Er, I use PMDG's 737. What files are necessary that they don't supply? Admittedly i use the 737 in FSX and with PM not their gauges, but still, on my test machine, where it remains intact, I've not noticed anything missing. I'll have a look. As <ILSHdg> nnn.nnn. </ILSHdg> presumably? [NEXT DAY] Okay, done. I've converted it to Magnetic. Download version 4.46, available now in the Download Links subforum. Pete

Sounds like a problem with the Saitek drivers. You might be better off posting in the Saitek support forum. Regards Pete

Whether those L:Vars are just places where the gauge code stores values, but doesn't read changes in them to switch things or not, is impossible for me to say. Sorry, you need to experiment, or seek help from the authors of the gauges. On your subsequent message: Yes. Unfortunately multi-line macros with L:Vars aren't possible. Well, you can do that, but if you are having a Lua program you might as well have it contain the L:Var writing directly rather than go through the more complicated troute of invoking a series of macros to do the same things. BTW have you browsed through the various examples in the User Contributions sub-forum? There are a lot of areas where others have already done the work. Regards Pete

Shame there aren't keyboard shortcuts. Pete

Just bit encodings of the options, like REV, FILTER, NRZ. Pete