Pete Dowson

I don't know of any FSX aircraft which use FSUIPC for getting the wind, so are these aircraft ones you've transposed from FS9? Even in FS9 the wind at the aircraft is easier for a gauge to get directly from FS that to go through FSUIPC. I'm afraid I can't possibly support old versions of FSUIPC. Please update to at least 4.70. Version 4.60 is over a year old now. If it still happens, check the FS value by using the Shift+Z display at the top of the screen. If the gauge disagrees with that, then paste the FSUIPC4 log file here. But close FSX fist please. Regards Pete

Well, the glaring error seems to be here: Limit1 = 80 * 140 / 16384 -- to 80 Celsius where you want to compare "Limit1" with the FS value where 16384 represents 140. This makes Limit1 equal to 0.68, a value which is between 0 and 1 for the offset out of its range of 0-16384 for 0 - 140 degrees! To make "Limit1" equal to the value equivalent to 80, you would need Limit1 = 80 * 16384 / 140 of course. You are scaling the other way. You can do that too, like if (OilTemp1 * 140 / 16384) > 80 then ... but of course that is far less efficient because you are repeating the computations 50 times per second. Which brings me to this: ipc.sleep(20) Isn't 50 times per second a bit over the top? Especially considering that you are flashing a LED over a 2 second period too. Why not just check it every half or even one second? Regards Pete

You don't need to buy FSUIPC again. It is licensed to you, not your computer. Which page is this, please? I don't actually have a website. Are you talking about the links in the Download Links subforum here, or Enrico Schiratti's "Dowson" page, or someplace else? [LATER] Ah, I've checked it on Enrico's page. It looks like he's lost a graphic recently -- there used to be two I think, one for FSUIPC and another for WideFS. I'll write to him and ask if he could change it. Thanks for letting me know. Unfortunately I've no direct control over that page. Well, you didn't need either if you've purchased before in any case. But I don't handle sales at all. Your only recourse is to appeal to SimMarket I'm afraid. Regards Pete

I don't know the aircraft, but there is no autopilot I know which hanbles altitudes in 1's, only 50's or 100's. I can't really help much without seeing what you are doing. Why not post your Lua code or macro entries into a message so I can see? Regards Pete

Sorry, what do you mean "send for a long time"? Are you taslking about probramming a jpoystick button to send a keypress, or a keypress to send something else? I need to know what you are doing first. If you are using the keyboard are you sure it isn't simply the keyboard's automatic repeat action you are seeing? FSUIPC can't stop the keyboard repeating. Regards Pete

From the formula you quote there it seems all you need to do is have a loop diving by 38 and converting the remainder, eg. (untested) // n = original number from BGL char icao[5]; int i = 0; while (n && (i < 5) ) { icao = n % 38; if (icao < 2) break; icao += (icao < 12) ? '0' - 2 : 'A' - 12; n /= 38; i++; } icao = 0; Regards Pete

Great! Do you think you could re-post your solution in the User Contributions subforum, please? It will eventually scroll off out of sight here, but deserves to be retained for others in a reference place. Thanks! Pete

I can't diagnose problems with no information. Are both PCs in the same WorkGroup, as advised in the documentation? If not, have you added the WideClient.INI parameters suggested in the documentation? (Have you even read any of the documentation?) If you've followed instructions and still have problems, I need to see the Logs so I can tell what the problem might be. There will be a WideServer.LOG in the FS modules folder, and a WideClient.LOG in the folder in which you placed WideClient. Paste both into a message here. Regards Pete

It depends 100% on how those panels are written. If the author used the C/C++ Gauge development kit from Microsoft, then, yes, they should work fine. But not everyone does. Regards Pete

No, they are still exactly as they were. In FSUIPC4 offset 0BB2 is derived directly from the SimConnect variable "ELEVATOR POSITION", 0BC0 is "ELEVATOR TRIM PCT", and 11BA is "G FORCE". Use FSUIPC4 logging -- or better, monitoring, to see. If you Monitor those to the normal log it will also show the SimConnect values explicitly. Regards Pete

Not sure. I can certainly get them in FSX if needed -- no one's ever asked for them, but they are easy enough in FSX as far as I can see. In FS9 I think they are the same as TURB_ENGINE_1_PCT_AREA, etc, which might be accessible okay at 2074 (engine 1) etc -- see the secondary list (unsupported) at the end of the main "FSUIPC for Programmers" document. As far as I can tell, "PCT_AREA" is the same as "Nozzle percent". The double following (207C) is the reverse equivalent. I cannot undertake to check these for you, but do let me know if they look right. If so maybe I'll add support for them n FSUIPC4 too, for FSX. That wasn't stupid. It's a jolly good question. Interesting that no one's been after such values in the 12 years or so of FSUIPC! ;-) I'm away now till Monday. Regards Pete

You can reach me by email on petedowson@btconnect.com. Would you like the end result hosted here? Or would you prefer it to stay resident elsewhere? Provided you don't omit anything I'm sure it will be fine, and thank you! Regards Pete

Where did you get version 4.20? It is years out of date and unsupportable. Please get a currently supported version such as 4.70. Only download from the proper sites. Having mapped drives is not relevant to WideFS, though you might want to do that for other programs. Have you read any of the WideFS user guide? Please do so, especially the section on configuring your network. There's a RED note there strongly advising you to do so. But first get a current version of FSUIPC installed. Regards Pete

Assuming you mean the fuel tank levels, which documentation did you search? Because if you search on the word "tank" or "fuel" in either of the FSUIPC offsets lists from the SDK you'll find them easily. Regards Pete

I will help, but not till Monday at the earliest. Tomorrow morning i leave with my wife for a weekend at my daughter's. We'll need some information to start with. Run the hidscanner program and save the log file it produces. Check the Vendor and Product name of the card and edit the HidDemo.lua file accordingly (two lines near the top). Change "logging=false" to true and run that Lua in FSUIPC. (assign a keypress or button to Lua hiddemo and start it with that). Save the log (the FSUIPC log or the hiddemo.log if you've enabled Lua logging in FSUIPC). Operate the dials you want to use so that changes from them get logged. Between those two files there will be enough information. the rest is easy. Show me them (paste in a message). No rush. you have till Monday in any case. ;-) Regards Pete

I think it's done in GFDev.DLL, the driver FSUIPC uses from GoFlight. You could do it with a Lua plug-in. You'd need to time the gap between each signal. Check, for example, the "tripleuse" lua example provided. However, I have doubts that FSUIPC's button polling rates and Lua load-compile-test rates would be adequate for a dial instead of a button being pushed by a finger. I'd recommend looking at the new HID facilities for joysticks, just released today. FSUIPC 4.704 or 3.992 feature these (and WideClient 6.88). Download (from "Download Links" subforum) the latest Lua plug-ins documents and examples and see the "HidDemo" lua plug-in. That does a lot more than you'd need. You'd only need to read certain "axes", those corresponding to your dials. The rest could be left to normal methods. Of course I am assuming that the card looks like a joystick HID device? If not you'll need to tell me more. Regards Pete

Ah, good. That's a lot easier for you then! Regards Pete

You should be able to save such a Window setting. Or at least you could modify the Flight file to set it that way. You can use the InitialButton facility described in the FSUIPC Advanced User's guide to automatically press real or imaginary joystick buttons once, when FS is loaded and ready to fly, or you can have Macros or Lua plug-ins run automatically when any or a specific aircraft is loaded -- see the section entitled Automatic running of Macros and Lua plugins in the same document. I think that "Shift+1" keypress is actually assigned to the FS control PANEL_1, but check. You'd be better off sending the controls rather than the keys. PANEL ID OPEN is actually better stil -- you have to give the correct ID as a parameter though. I'm afraid that FSUIPC doesn't offer any mouse functions (except mousewheel trim). You might need to investigate something like Luciano Napolitano's "Key2Mouse" program. Regards Pete

How weird. So they were firing off changes so rapidly that FSUIPC wasn't able to get responses back from Windows. Yes, thank you. I've actually never heard of such a thing happening before. I do have timeouts built into FSUIPC to stop it waiting forever for a response, but if it is sticking inside the Windows part of the scanning process it can't really do a lot about it. It still sounds to me like a deficiency in the driver part of the process. But I'm glad you found the work-around. Regards Pete

Actually I don't think either needs FSUIPC. VATSIM programs Squawkbox4 and FSInn/FSCopilot don't use FSUIPC4, and neither does any recent version (ASX, ASE) of Active Sky, at least not with FSX. Sounds like the SimConnect bug again. Please see this thread: http://forum.simflig...ipc4-470-crash/ If you've already installed FSCopilot then it could possibly be a clash with that, though I think that was resolved in FSCopilot a while back. No, that's totally irrelevant. Regards Pete

No. the read of offset 4200 is for you to check that FSUIPC is able to accept your command . You must wait till that reads zero before doing the rest. You effectively have no such protocol at all in your code -- what is the point of reading 4200 if you take no notice of it? See? Also this next bit is not good: I suspect that will hang, as you aren't testing any status, but the success or otherwise of the READ. Without a Process there's nothing done in the loop so it will simply crash or fail when the memory is full of your read requests. Er, like where? There's really no room for any "NULL"s here! You need to understand it all. I think you need to look at some of the examples of interfacing to FSUIPC. You need to learn the interface first. The reads and Writes only accumulate requests in your program's memory. Only the Process call talks to FSUIPC. If you are using the libraries, then for an internal FS module or gauge you need to use the internal module library and the FSUIPC_Open2 call to connect, supplying your own memory for the transfers. Additionally, note that the 3rd parameter in the FSUIPC_Read and _Write calls is the ADDRESS of the data (i.e. a pointer), not the data., so even that "status" entry you have above should probably be "&status" instead. I assume you intended that loop to wait until your sound has finished? But that is only uupdated when you ask for status. For instance, what if someone else starts a sound? You can't tell by simply reading 4202, you have to write your sound's ID first to 4204, with command 4, the "query status" command. This interface is a sophisticated multiple sound + multiple client facility. You need to follow the written protocols for each operation, exactly as documented. Regards Pete

Yes, it is AUTOSAVE.DLL, which is the freeware predecessor to the facilitiy in FSUIPC4. It's available along with all my stuff on the http://www.schiratti.com/dowson page. Regards Pete

Odd. Comes up here straightaway. Try again now. Also check the Download Links subforum here. Regards Pete

So, no more problems? That isn't what I read in your last message! I am really confused now! Okay, so in other words it was really nothing to do with going into FSUIPC options. That was a complete red herring. I'm wondering if the Raildriver software is messing up the joystick drivers for FS. That still doesn't answer the question I'm afraid. when you say "Keys" do you mean it in the sense I use it throughout FSUIPC -- i.e. keyboard keys, or do you really mean switches and buttons? It makes helluva big difference! Again: keys or buttons? So you do not mean FS9 is now working as you said at the start? You can surely see how this is so confusing. It might be crystal clear to you, but I can only go by what you tell me as I cannot see your system from here. It really is too easy. Just select the text you want to quote (using the mouse of course) then clcik the quotes button just above the edit area -- the quote button is the one looking like a speech bubble. To wrap pasted files do the same but use the code button instead, the one looking like <>. I've done that for you in the last message so you can see. I didn't really want all of that. I'll ask when I need to see something, and it'll probably be with some logging turned on.. I thought you wanted to post something which you'd identified as significant. There's nothing odd there at all. Regards Pete

This "PlaySound" needs wide characters? Most APIs have both ASCII and Wide Character variants, and the compiler chooses the correct one according to your compilation settings. For a module in FS you should probably really be compiling with normal single byte character mode. I suspect this might be the problem. And you can cast a parameter by preceding is the (LPCSTR). no, it cannot have as my FSUIPC sound facilities work okay. If it is due to access it will be that Playsound demans exclusive access and can't get it. You should be able to work out which error it is by processing the error number! As I said, that is surely your first step! Why? That is very old now and obsolete -- I do not support it any more and it will not work in FSX. As I said, I put all of the Esound capabilities into FSUIPC. I pointed you to the documentation. Regards Pete