Pete Dowson

But they were all seen. Let's see: HidDemo log: 47877 LUA: Buttons= 40000000 0 0 0 0 0 0 0 47986 LUA: Buttons= 0 0 0 0 0 0 0 0 49624 LUA: Buttons= 40000000 0 0 0 0 0 0 0 49687 LUA: Buttons= 0 0 0 0 0 0 0 0 51543 LUA: Buttons= 80000000 0 0 0 0 0 0 0 51574 LUA: Buttons= 0 0 0 0 0 0 0 0 52744 LUA: Buttons= 80000000 0 0 0 0 0 0 0 52853 LUA: Buttons= 0 0 0 0 0 0 0 0 Both buttons, twice. lua log: 47846 LUA: Datalength=6 Buttons=1073741824 PrevButtons=0 47877 LUA: Datalength=6 Buttons=1073741824 PrevButtons=1073741824 47908 LUA: Datalength=6 Buttons=1073741824 PrevButtons=1073741824 47939 LUA: Datalength=6 Buttons=0 PrevButtons=1073741824 49546 LUA: Datalength=6 Buttons=1073741824 PrevButtons=0 49577 LUA: Datalength=6 Buttons=1073741824 PrevButtons=1073741824 49624 LUA: Datalength=6 Buttons=1073741824 PrevButtons=1073741824 49655 LUA: Datalength=6 Buttons=0 PrevButtons=1073741824 51481 LUA: Datalength=6 Buttons=2147483648 PrevButtons=0 51512 LUA: Datalength=6 Buttons=2147483648 PrevButtons=2147483648 51543 LUA: Datalength=6 Buttons=0 PrevButtons=2147483648 52682 LUA: Datalength=6 Buttons=2147483648 PrevButtons=0 52713 LUA: Datalength=6 Buttons=2147483648 PrevButtons=2147483648 52760 LUA: Datalength=6 Buttons=2147483648 PrevButtons=2147483648 52791 LUA: Datalength=6 Buttons=0 PrevButtons=2147483648 I should have put those numbers out in Hex, not Decimal. nevertheless they are correct, 0x40000000 and 0x80000000 respectively. FSUIPC log: 42214 WRITElua 3BBE, 2 bytes: 92 08 .. 47877 WRITElua 3340, 4 bytes: 01 00 00 40 ...@ 47877 WRITElua 3340, 1 bytes: 01 . 47877 Button changed: bRef=0, Joy=64, Btn=0, Pressed 47877 [Buttons] 51=P64,0,C65880,0 47877 FS Control Sent: Ctrl=65880, Param=0 47877 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000) HEADING_BUG_DEC That's one of your rotary turns. I see two virtual buttons, 30 (the '40' value) and 0 (the '01' value) are being set, at slightly different times. What is setting virtual button 30? Nothing in the Lua you've shown me does, but some Lua is doing it! 47971 WRITElua 3340, 4 bytes: 01 00 00 00 .... 47971 WRITElua 3340, 1 bytes: 01 . 49577 WRITElua 3340, 1 bytes: 00 . 49577 Button changed: bRef=0, Joy=64, Btn=0, Released 49577 [Buttons] 52=U64,0,C65880,0 49577 FS Control Sent: Ctrl=65880, Param=0 49577 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000) HEADING_BUG_DEC Button 30 is released, then 0. so far so good. This is repeated, but with a subtle difference: 51543 WRITElua 3340, 4 bytes: 00 00 00 80 .... 51543 Button changed: bRef=0, Joy=64, Btn=0, Released 51543 [Buttons] 52=U64,0,C65880,0 51543 FS Control Sent: Ctrl=65880, Param=0 51543 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000) HEADING_BUG_DEC 51574 WRITElua 3340, 4 bytes: 00 00 00 00 .... 52744 WRITElua 3340, 4 bytes: 00 00 00 80 .... 52853 WRITElua 3340, 4 bytes: 00 00 00 00 .... The button press of 31 is seen (the '80'), but it is cleared so soon. So, something else -- another Lua program -- is writing to the same virtual button offsets at the same time, but using buttons 30 and 31 instead of your 0 and 1. This is interacting with your Lua inputs and so destroying some of the results. And stopping the rotary one working. i notice this in your FSUIPC button assignments: 74=U2,2,CL2:K,0 This appears to be running a Lua program, number 2 in the list in the INI file (which you omitted). And you are pressing that button and getting that Lua running just before you do the test: 41980 Button changed: bRef=0, Joy=2, Btn=2, Pressed 41980 [buttons] 27=P2,2,CL2:R,0 Why? What is this you are doing? Pete

Which 3.998 are you trying (a-e?)? There was a bug in one which set the internal version to 9.98, but it was fixed very soon after with an update. Have you tried the latest in the Download Links subforum? Pete

A window? Not the test of the left-hand side you were talking about? Sorry, I still cannot picture what you are seeing. There are no "windows" inside the dialogue tabs. Please look at the picture in the PFC DLL User Guide, at the top left of the first page of the chapter headed Flight Controls and Trims/Steering Pages That shows what the Flight Controls page looks like. Its format is pretty much fixed by the design of the dialogues. Now, what's different in your case. What's this "missing Window"? Pete

I assume you mean PFCFSX.DLL version 4.34. How did they get lost? The INI is only updated by changes in the Options. Sorry, I'm not understanding what you are saying. There is no page with "full right, full left, etc, etc" on the left hand side. And all of the PFC Options pages are fixed, predefined in the dialogue definitions. I cannot imagine anything that could destroy all the contents of predefined dialogues as you are suggesting. Could you show me a picture of what you are seeing? There is a later version of PFCFSX.DLL in the Download Links subforum which you could try, but there's nothing changed in anything that would affect you. If the actual graphics aren't being displayed correctly it sounds more like some sort of Windows or video driver problem, but i can't imagine what. Is it still the same if you remove your PFCFSX.INI file and let it make a new, default one? Regards Pete

What version of FS are you using? 0848 and 084A haven't been working, read or write, since FS2000 as far as I know -- as documented in the main FSUIPC Offsets list. 0830 is probably read-only, but you can try writing to it -- that's the only way I'd be able to find out. Regards Pete

Sorry, I haven't got time this week to analyse your log, and I'm on holiday next week (back on the 31st), but please try WeatherSet2, which uses the same mechanism, and log what that does. Then compare it to what you are doing. That's what I would need to do here in any case, because I really cannot remember all this stuff after so many years (5 since FSX code, but 7 now since that weather setting mechanism was designed). I'm around for another couple of days to answer questions and if I do make time I'll have a more detailed look, but really anything serious is going to have to wait a while I'm afraid. Regards Pete

Yes, on another PC across a Network -- but only programs designed to use FSUIPC to interface to FSX, and which don't mind running on a separate PC. Since wideFS has nothing whatsoever to do with what FSX or Windows is doing with monitors, it will make absolutely no difference. WideFs does NOT have anything to do with monitors as I already told you. WideFs does not provide you anything to view, but there is no point in having a PC on your network with no monitor on it. How would you use it, what is it for? I still believe you have a confused notion of what WideFS is. The only program i know wihch provides extended FS views across a Network is WidevieW, and that needs a full copy of FSX on each of the PCs. Pete

This is with FSX i assume? I get the same. I don't think full screen mode works very well with FSX multi-screen mode. WideFS has nothing at all to do with screens. It is a network extension to different PCs for FSUIPC applications. Maybe you are thinking of "WidevieW" which is a totally different product by a different author? Sorry, you've lost me. if you have two PCs you can put your screens on whichever you like. Only the PC to which your screens are attached have any control over them. Pete

"Callbacks"? What do you mean by that term? And you are not using any ... what? Your paragraph died prematurely I think. I'm pretty sure the Season is dictated by the Date and Hemisphere. You cannot change the Season directly, just as you cannot change the Day of the Year directly -- both are derived from the DATE. Actually, it's a 64-bit double floating point value, so i think it gives the proportion open (0.0 - 1.0). I really don't know for sure -- I've never had an aircraft with an opening canopy and never experimented with it. Regards Pete

How is it you did not succeed? What did you try? For flaps, assign to Flaps, then go to calibration for flaps, calibrate the full range first, then select the detentes option and follow the instructions in the User Guide for setting each detente position. For spoilers, assign to spoilers, then go to the calibration and calibrate the full range and the 'centre zone' for "arm". Regards Pete

And this log actually says this? How does it work that out? The FSUIPC log shows it connected okay, though there are some problems, evidently. What does the FSUIP4 Install log show? That's a SimConnect error being reported, probably due to corrupted data. You might get more information from a SimConnect log. But it only occurred once, for each throttle, at one time, implying that only one packet got corrupted. There would be thousands of successful messages which aren't logged -- the throttle axes would not simply send one value and nothing else! The fact that FSUIPC logs that it couldn't install the wind smoothing hack is more worrying as it certainly implies some corruption. The log shows everything is okay, except for the two points I mentioned. The menu itself is established through SimConnect so it couldn't be seen if there was no connection. From what I've seen reported over the years that's probably the worst thing you can do with FSX. It is almost impossible to uninstall fully -- the SimConnect side-by-side libraries just won't uninstall properly, ever, but get left in a state which usually prevent a proper re-installation. When I experimented with this in order to try to work out the correct way to fix such problems, I had to give up. The WinSxS system in Vista and Win7 is diabolically convoluted. I ended up having to reformat the disk and re-install Windows 7, not just FSX. The only good thing to come out of it was that at least I got rid of a lot of garbage I'd collected over the years, via updates from XP to Vista to Win7. Nothing more, except possibly explaining how that "control manager" so incorrectly determines what it thinks FSUIPC makes of SimConnect. Apart from that, my understanding from what you've shown me is that there is something bad, possibly disk corruption, possibly dodgy memory, in your system as it is now. Certainly the Weather.DLL isn't matching any version which FSUIPC4 has seen (hence the failure to install the Wind Smoothing fix), yet it can handle the RTM, SP1, SP2 and Acceleration versions (as well as 3 of the pre-release Betas). But whether that's because the DLL is corrupted on disk, or looks that way in memory, I couldn't say. Regards Pete

Where do you see this message? It isn't one from FSUIPC. Is it in a window, in a message box with buttons, or what? Can you describe it in more detail please? No. Apart from that, which appears to be some glitch in simconnect, there is also some problem with your Weather.DLL, as indicated by this line: Both of these two things are indicative of something wrong, either a corrupted FSX installation or possibly (and less likely) a memory problem. Pete

If you are using FSUIPC to calibrate you do actually need to calibrate, otherwise it really isn't doing you anything useful at all. Calibration is a matter of setting the end points and centre, but please follow the numbered steps in the user guide. It helps to leave a little leeway at either extreme and in the 'centre'. if you haven't been calibrating then I'm really not surprised the slope selection has no effect, because that works on the calibrated values. If the "IN" values from the pedals are giving a range of values, not just two (full and off) then it isn't a driver or registry issue. That was only a thought, as I've seen it mentioned before -- though mainly with toe brakes. Regards Pete

There's nothing except proper calibration. If your pedals have no changing values outside your "short amount of throw" then they are broken, and nothing can be done in any software. Put simply, if there's no change in the input there cannot be any change in the output (the result).-- the software has no way of detecting any extra deflection. If you are still seeing the "IN" values changing beyond your "short amount of throw" then you simply have no calibrated suitable minimum and maximum values for that movement. Check the numbers. Are you sure the rudders are actually behaving as analogue inputs and not digitally (i.e. just "off" or "on" with nothing in between)? I have heard that folks can have such problems with some joystick devices or drivers. I think its a bug in the driver installation which needs some registry change to fix. Have a search, maybe on the Logitech support forum, if there is one. Regards Pete

Why separate versions for FS9 and FSX? Why not just allow "ANY" so that your program works with both? The interface is the same except for the extras added in FSX, and you can check the version subsequently for that. What is "FlightSim.FS2K4" set to? What does the FSUIPC ipcread logging show? Pete

Ah ... I know and use their PM assigned offsets reference, but I've not looked at their (evidently slightly flawed) version of my own reference data. Regards Pete

Okay. The problem is due to a small error in that version of FSUIPC -- fixed in 4.742, the current interim version. It happens when the [Auto ...] sections are the only ones which are aircraft-specific -- i.e. there are no assignments or calibrations which are also aircraft specific. Due to a little bug, as described in the changes list, this stops FSUIPC generating the needed [Profile] section which tells it to use the [Auto] sections. Just make sure folks keep up to date with interim changes and it'll be fine -- see the Download Links subforum. I will be building a replacement installer in a few days. Just got some testing to do on more recent additions. Regards Pete

Problem tickets are the way to raise a problem with simMarket. They don't respond to emails, you have to use the ticket system. Pete

They still offer that discount after all this time? I thought that was just an incentive offered after FSX release to get folks to upgrade! I'm amazed it is still offered! Sorry, but if SimMarket have no record of your purchase I'm not sure you can do anything. Raise a problem ticket, maybe? I can help only with technical problems. Regards Pete

You have something backwards there. The OUT values needed for spoiler arm are at the low end. Why not use the detente facilities provided for this? The spoiler control values are as described here, extracted from my Offsets documentation: [ Spoilers control, 0 off, 4800 arm, then 5620 (7%) to 16383 (100% fully deployed). The 4800 value is set by arming. Values from 0 to somewhere close to, but below, 4800 do nothing. The percentage extension is the proportion of the distance in the range 4800 to 16383, even though values 4800 to 5619 cannot be used—7% seems to be the minimum Sorry, you've lost me there. I've no idea what you are doing really. What is wrong with calibrating it with the arm detente ("centre") as intended? Please read this part of the FSUIPC user guide: The Spoiler (speed brake) control is a little special. It has no “centre” as such, but the facilities for setting a centre in FSUIPC4 are used to calibrate a zone on your lever in which the spoiler should be “armed”. You don’t need to do this, it is options: if the two centre calibration values are the same (i.e. there is no centre “zone”), then there is no arming action taken by FSUIPC4. If, however, you do calibrate with a centre zone, then the values from “minimum” (the left most value), or lower, up to the lowest of the Centre values will all select spoilers down (i.e. parked). The centre zone will arm the spoilers, and the range from the higher of the two centre values up to the maximum (the right-most value) will actually operate the full range from 0% to 100% deployed. BTW it would help with questions like this if you'd at least state the version of FS you are talking about. The version of FSUIPC would help too usually. Regards Pete

What discount? Pete

How come you "strongly believe" such an odd thing? There's only ever one version 3 and one version 4. All registration does is release the User Facilities. There is only one current version of SUIPC3 and one current version of FSUIPC4. There never has been a "registered version" and an "unregistered version". I cannot understand where such nonsense arises! Pete

No, sorry. Spaces are not relevant. I'd need to be able to reproduce this to see why it was occurring, but there's nothing special about any naming methods. If you can narrow it down to something you can reproduce yourself, get back to me. if i can think of anything extra that can be logged, I'll let you know. The mechanism is the same one which selects the aircraft-specific Buttons, Axes, JoystickCalibration and Keys sections too. Maybe it is something related to those (or their absence?), so a sight of his INI file might help. Oh, and, please, rather than say "latest" for the FSUIPC version, please ALWAYS give the version number. That is what it is for. "Latest" is really quite meaningless -- anything from 3.99 to 3.998e and 4.70 or 4.742 is "latest" and that covers over 6 months of development and many releases for two distinct platforms. You haven't even said which FS version you are talking about! Regards Pete

Not really, but it thickens the plot somewhat! We'll see what we can do when Tom_G has more time. Now I know the score it should be clearer. Thanks for commenting. Regards Pete

Only if the bluetooth driver in the PC emulates a serial port, like some USB connected GPS devices. See what name the device has (it might be a port name like "\\.\WCEUSBSH001 ", which is the typical USB one). Regards Pete