Pete Dowson

But I thought the switch was self-centering? How does it manage to stay set elsewhere? Sorry, without the actual aircraft to experiment with I can't really say. You'd need to experiment. There is a small chance we could get enough information on what the switch does with the mouse by some extra logging. Add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=4097 LogButtons=Yes (replacing any similar lines if already there). Then load FSX and operate the APU switch with the mouse -- remembering exactly what you did, i.e. the order you did things. Keep the session short and don't do anything else. You can disable the extra logging later in the Logging tab -- set the "Extras" number to 0, for instance, and uncheck the Buttons/Keys logging. Regards Pete

The FSUIPC options screen is a completely standard Windows dialogue. There's nothing different about it to any disalogue you get in any other normal Windows program. There's no trickery, no fiddles, nothing dependent upon anything in any video driver or in FS. Whenever this has been reported it has always turned out to be a video driver problem -- possibly dependent upon video options selected in FS, but definitely video related. Considering the code for making the FSUIPC dialogue is identical in both FS9 and FSX (and in all previous versions dating back to FS98), yes, it is odd, and points more towards some options set differently in FS. Try ALT+ENTER to switch to Windowed mode. Regards Pete

Why should it not be? Why not ask AirSimmer? Regards Pete

Okay. That was the last one uploaded, about 6 days ago. I still have that here, and it works fine. Strange. Well, if I had a PC crash and restore without me knowing that might be possible ;-). But I do have good backup and source control to prevent any loss of code assuming no mystical happenings! Okay, but I would then be very mystified and need lots of information about how to reproduce it! Regards Pete

Buttons and switches in FS are mostly controlled by FS controls, not by "offsets", which are primarily for providing or setting values inside the sim engine. There is a range of GPS controls (all starting with the letters "GPS") provided by FS but I've a feeling not all of them work. You would have to test them, see how you get on. Erso you've tried them? You can assign to buttons as well as keys you know. It's another Tab in the FSUIPC options ("Buttons & Switches"). You can send any FS or FSUIPC controls via offset 3110. Regards Pete

Er, can you elaborate please? 1. What is the "problem" exactly? Do you mean multiple Lua executions of the same program through repetition? If so, and you only get that with Keys assignments, that's very odd because (a) I only tested it with key assignments, as I have no buttons on my dev. machine, and (b) both call the same routine in any case. 2. If so, then presumably it is related to what the Lua program is doing, so can you possibly show me the Lua program you have the problem with? 3. Still need the version number of FSUIPC please. Dates don't tell me that really (I don't keep a diary and generally release a 3. and a 4. version on the same day in any case. And the 10th was yesterday and I've not released an update for several days!). Thanks, Pete

Last night I was doing some initial studies at Lua - will go for it in the weekend to assess wether I will do it inside the FSBUS22(CCC logic programming) or go for Lua Okay. If you go for Lua and get stuck, get back to me. Regards Pete

The FSUIPC button repeat option already operates a "fast" mode if the button is held for longer than a certain time. It starts off slow to allow single increments easily.You can adjust both the delay and the repeat rate. Please check the FSUIPC Advanced User's guide, search for the "ButtonRepeat" parameter. Unfortunately, however, I suspect fast increments won't be easily recognised by PM as it looks for changes in a bit and will miss them if they are too fast. In other words, there's an upper limit, which is dictated by PM's speed and the WideFS link to it. Ah, if you want inc/dec in 10's like that you'd need to either write a program to do it, or a Lua plug-in. It's not a simply assignment matter because if you are currently at, say, 5 degrees the 10's increment should put you at 10, not 15 -- if you didn't care about the 10's alignment then I suppose you could program the button to send 10 increments to PM, though that will still get some missed i suspect. A plug-in in Lua could work well though. Instead of using the incs and decs you'd read the actual bug value, add or subtract whatever, and write it back, using the correct PM offsets. This is what the FSUIPC controls do for the default A/P commands. Regards Pete

Those aren't saved by my routine, but evidently by the MD11 routines. Same thing. If this is with FSX, please check the documentation. You can give it folder details where it will look to delete files for you. Look in the FSUIPC4 advanced users guide -- the section entitled "AUTOSAVE - Ini-file only options". I'm afraid the FS9 (and before) AutoSave DLL doesn't include these facilities. Regards Pete

I thought there was only the one workgroup name? How do you get more? Great news! Nowhappy flying! Regards Pete

Well, you could try setting the ServerName and Protocol parameters in the WideClient.INI file just in case there's a problem with broadcasting. Have you either disabled the firewall or specifically allowed wideClient and FSX to get through it on ports 8002 and 9002? Regards Pete

Wideclient deliberately saves the previous log (the one with the 0) when it is started so that folks with problem can restart it quickly without losing any possibly diagnostic information. The only thing wrong there is that the Client is not seeing the broadcasts from the Server, probably because they aren't in the same workgroup! Did you ever read the part of the User Guide which is headed like this: Configure your Network IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! It does actually mean what it says, and it does tell you these things and provides a work-around if you really don't want your PCs in the same workgroup. Pete

You could write a little Lua plug-in to do that, yes. It would have to test the mode and copy the relevant value into one of the user-free offsets at 66C0-66FF. That's the same. If you are writing your own driver, that's the place to do it. If you only have an interface program which can read one stated offset, then use the Lua program. But my question about arranging for the decimal point still applies. Of course your Lua program or driver could format the result into character format, if that's what your display can handle. Yes, those are what I use. Regards Pete

There's no point looking on the Server PC for a Client log. The client runs on the other PC, not the Server! WideClient cannot run without producing a log. What files are listed in the same folder as WideClient? It IS possible to put a parameter into the WideClient.INI file to make it put its log elsewhere -- you've not done that I assume? Or have you put WideClient in a folder in Vista or Windows 7 "Program Files"? If so, then you are looking at an aliassed folder, not the real one, because those operating systems don't allow writing to Program Files, and make aliassed copies. You'd need to run Explorer "as administrator" (a right-click option) to view the correct folder. Otherwise the only plausible explanation is that you are running a different copy of WideClient than you think you are. Regards Pete

Okaydownload WideClient 6791 from the Updates announcement. The new facility is included, and documented. Regards Pete

You mean "FiddleMachForPM=Yes"? I don't know, because I don't know FSBus and what you can do with it. IAS and Mach are formatted differently -- NNN or N.NN. How would you cope with that? Who is putting the "." in or leaving it out? Sorry, I don't really understand the question -- "how do I write this number as the active QNH, when pushing STD travelling through TA?". Do you mean when descending below the TL? The TA applies to climbing. Project Magenta should show the QNH it will set in the subscale, below the legend "STD". That is the value in 5536. When you press STD again, it swaps the value from 5536 to 0330, which is the active FS altimeter setting. You would normally adjust the QNH value, whether active or pending, by using PM's INC/DEC facilities -- that way you'll get a nice 0.01" increment when set to inches and a 1 hPa increment when set to hPa. Any other method can get rounding differences. Regards Pete

You need to show me the WideClient.log file, from the same folder. WideClient ALWAYS produces a log -- it is the first thing it does when started! The FSUIPC4 install log shows that was installed okay, but we already knew that. Pete

Oh, that's a new one to me -- the abbreviation "FSC" has always meant FS commander to me! PMDG make several different aircraft, both for FS9 and FSX. The FSX ones do not use FSUIPC and have no offsets. The FS9 ones do use FSUIPC, but PMDG keep their offsets secret. It sounds as if you will need to think about using a different aircraft. Strange, i don't remember them ever applying for a license. Regards Pete

So that includes the power management thing for the ethernet device too? What is weird is that is works for so long then graunches to such a slow pace that applications give up. I cannot imagine anything in software which would do such a thing except the things we tried (memory, buffers, etc). The fact that it's the same with both UDP and TCP tends to eliminate ethernet drivers -- though maybe not fully, as they do have a lot of commonality. You could try IPX -- you'd need to explicitly install the protocol into Windows first, though, and IPX is not quite so easy to configure. Details are provided in the WideFs guides, once you have IPX installed in both PCs. IPX is actually the most efficient and simple Network protocol, having the advantage that it was purposefully designed for local networks, not the Internet. That alone may enable it to bypass some potential problems. I think hardware problems which do such a slow down are sometimes faulty components which overheat, performing normally till then. The only other suggestion I can make now is to try posting on the FSX or FS2004 forums here, asking specifically for help from one Katy Pluta. She is the most capable networking expert I know. Regards Pete

I've thought further about this and decided it would be a useful facility to add, so I will try to make it work. If I do add it you'd still use KeySend, but the parameters in the WideClient.INI file would be something like: KeySend1= Focus,Run# ; to change focus to SB I'll post again when I have something for you to try, assuming I can make it work. Regards Pete

Okayso, did it help? I a pretty sure I provided both alternatives, to set Protocol=UDP in the Client.INI or to use the 'preferred' parameter (and I don't recall offhand whether it is PreferredProtocol= or ProtocolPreferred=, so you'd need to look it up). Neither are there in the INI files by default, you have to add them if you want them. The Client INI choice forces that protocol for that client (different clients can be operating with different protocols), the Server INI choice is called "preferred" because it merely stipulates the Protocol for any client that doesn't stipulate one itself. Regards Pete

An FSC update? Is that "Flight Sim Commander"? sorry, I don't know the program, so I cannot possibly comment about any updates. They aren't "offsets", they are just PMDG controls. Sorry, I really have no idea what you are talking about. FScommander and Servos? Huh? I'm pretty sure now that you've come to the wrong place. I provide support for FSUIPC and WideFs, and a few other add-ons I produce. I am not FSC support nor do I know anything about PMDG "offsets" (mainly because PMDG do not publish their offsets, if they use any at all -- which depends on the version of FS you are using, primarily). Regards Pete

Yesbut with provisos. The problems with any version of FS on Vista or Win7 really arise only if you let the FS installer do its job without selecting an install location of your own, outside of the "Program Files" folder. And the problems are not actually with FS but with add-ons which were not designed with Vista and Win7's oddities in mind. This is because the Program Files folders in both Vista and Win7 are protected against writing or change by any program which does not have "elevated administrator" privileges. Even The programs themselves that are installed in Program Files cannot, without such privileges, write to their own folders! FSX knows this, it is "Vista aware" (and marked as such), and writes its data to ProgramData and AppData folders. This is the MS-preferred system, and newer add-ons written to MS-Vista standards would deal okay with this. But many like to write to folders inside the main FS folder, and therein lies most of the problems. The FSUIPC4 installer makes the FSX Modules folder read/write accessible to all, which is how FSUIPC4 is able to happily create its logs and INI files there. [installers -- anything with Install or Setup in the name --automatically get run with elevated admin privileges]. The situation is a lot worse with FS9 or before, because it is not Vista-aware, and does want to write to its own folders. To get over this, Vista/Win7 recognises it as a non-Vista program and when it is installed in Program Files it creates aliases for the FS folders. The makes things very confusing to the user. If you look at FS9's folders in Program Files with Explorer then you do not see the "real" ones, unless you run the Explorer "as administrator", which gives it elevated privileges. This is why I eventually gave up and wrote an installer for FSUIPC3 as well -- manually copying FSUIPC.DLL into FS9's Modules folder didn't get it into the real one unless done with elevated privileges. The best and most efficient way around all of these potential problems is to always install FS in its own folder -- not accepting its installer's choices. I've always done this in any case. My FS9 is in a folder :\FS9 and my FSX in :\FSX. Then there's no fuss, no bother. Yes, that's one possibility. But I'd still like to know if those button presses shown in the log were spurious (generated wrongly or automatically), or were actually your actions. If the latter, then it shows that FSUIPC4 was not "hung" but actively scanning your buttons and so should have been displaying them on the dialogue tab. In this case it may be something else preventing the dialogue from operating correctly, so the thing to do then is check the others -- do all the other dialogue tabs in FSUIPC4 operate okay, or not? In FS9 there have been occasional conflicts with other add-in DLLs which somehow prevented the tabbed dialogues working. Something to do with mouse and keyboard interception, on the face of it. The usual culprit was "actigate.dll", though I could never reproduce any problems with it here, so it wasn't just that DLL alone but something also related to the environment. It was never resolved. Possibly you have something else installed which is having a similar effect. Maybe you could show me your DLL.XML and EXE.XML files just so I can check through the add-ins? Regards Pete

Well, yes. There's no need. FSX is perfectly happy as it is, as a normal Vista or Win7 application. And if you run FS at an elevated privilege then you have to run all programs which want to exchange data with it at the same level - else Vista and Win7 block the data sharing. There seems no point at all in making life so complicated. So all the button changes listed in that log were real button presses you did at that time? Are you comparing FS9 in Vista with FSX in Win7? Why aren't you running FS9 in Win7? There's no difference in FSUIPC's treatment of buttons in FS9 or FSX. What is more likely to be different is the joystick driver in Vista to Win7. Strange. Why not just change to Win7 for both? So we don't know if it would have recovered if one or other of the 4 (?) devices were to be removed? Regards Pete

Yes, but the Lat/Lon you are reading from FSUIPC is NOT in character format. It has no points or commas in it. It is a binary value, not a printable one! In fact, as I see you are reading the 64 bit integer versions in 0560 and 0568 there are no fractions at all in those -- just whacking great integers which you convert to whatever ou wish. Yes, and still there are no character, no points nor commas! They are floating point values in exponent/mantissa form in the binary format dictated by Intel. If you are displaying them later, in a printable form, it is that part of your code which is doing it. It is absolutely nothing whatsoever to do with FS or FSUIPC. Regards Pete