Pete Dowson

Yes, that will work for the frequencies supported by FS at present. Pete

I couldn't find any way of reliably changing the colour or font. The positions and sizes are user-selected. He can also undock it and move it to another screen, and so on. It is just another FS window. Its size and position are saved, separately for docked and undocked modes, in any flights he saves. That's all part of the FS facilities I hook into for this display. Regards Pete

Glad you like it. I did find a bug in it yesterday. If you are running with one aircraft with a profile and some profile-specific keys or buttons programmed, then load a new aircraft and assign a different, new, profile, and program the exact same button or key set (no more, no less), these operate okay, but the proper new profile Keys or Buttons sections aren't created in the INI file. The stupid program doesn't notice the change from the previous aircraft on exit from the Options. Easy to fix, and you probably wouldn't notice -- yet! ;-) I've got some other stuff to finish off and I'll make a more official interim update with it all included, probably over the weekend. I've also just finished transposing the same set of Profile changes to FSUIPC3, so your good results came in good time! So, please look out for updates in the update Announcements (replaces the old separate Downloads announcements) above. Thanks! Pete

You didn't bother to try the Lua plug-in I supplied? In the next update for FSX (but not FS9 or before) it would be possible to have a little Lua plug-in, auto-loaded when FSX starts, which does the pitch conversion continuously and makes it available via the 0578 offset, just as if it came from FS. The facility to "mask" FS values with computed values is something I'm working on now. Sorry, I'm probably not the right person to ask about how to interface such motion simulators. I always thought the range of actual motion was strictly limited, that the main point of any motion was not for real angles and attitudes, but for the accelerations, the "seat of the pants" feelings the pilots get when the aircraft is changing attitudes, speeds, whatever. In normal balanced flight there's no need for any real pitch, roll or yaw -- the eyes do it for you via the wraparound display technologies. So if I was building a motion base I'd only need small pistons, enough to give the odd jerks now and then and to provide turbulence effects. The cockpit would in reality remain almost horizontal, and after any changes to induce acceleration feelings, just "wash out" slowly back to horizontal without the occupants noticing. I would have done something like that for my 737NG cockpit, using something like the Dbox pistons, except for the fact that the cockpit weighs nearly a ton and is in an upstairs room on floorboards, and I don't trust the possible occasional near doubling of weight being sustained! ;-0 Regards Pete

Strangely enough, just write a multiline message -- i.e. one with more than one line in it. FSUIPC doesn't do auto wrapping, you make the lines yourself. Pete

Not in FS they don't not yet. That's a relatively new development (well, new in FS programming terms). FS doesn't support the new narrow channel separation yet, so the 3rd decimal digit isn't needed or used. Pete

Sorry, I don't see the point. The computation to get your 0-360 is so easy, just simple arithmetic. Why would you need any change to FSUIPC? Yes, except for the deliberate error -- the case where the pitch is < 0 should be 360 + pitch, of course, or 360 - abs(pitch). Anyway, you can test this with a simply Lua plug in. Here, copy this and save it in the FS Modules folder as "pitch.lua", then load up FS, assign a Key press to "Lua pitch" and then use that keypress to start it. Put FS into slew mode, plane horizontal (Ctrl+Space on FSX) and use the slew pitch up slow or down slow control to make it turn the whole 360 degrees and observe the values on screen: -- "Pitch" example LUA plug-in to show pitch 0-360, by Pete Dowson, January 2009 -- Loop forever: to stop this you'll have to use the LuaKill control on it. while 1 do -- Get the pitch and bank data we want to display -- (Note that it is read in one instruction, so that all values -- apply to the same FS frame) pitch, bank = ipc.readStruct(x0578, "2SD") -- and convert them from FS units to units we like pitch = pitch * 360 / (65536 * 65536) bank = bank * 360 / (65536 * 65536) -- compute 0-360 value for pitch if math.abs(bank) &gt;= 90 then realpitch = 180 - pitch elseif pitch &lt; 0 then realpitch = 360 + pitch else realpitch = pitch end -- display it all in an FS window ipc.display("pitch="..pitch.."\nbank="..bank.."\n\nrealpitch="..realpitch) -- Sleep for 50 mSecs so the update gets done roughly 20 times per second ipc.sleep(50) end Regards Pete

The log file you already sent shows nothing useful I'm afraid. Of course it was for a hang, not a crash, and for 3.82, not the current version. The procedure to narrow this down has simply got to be a process of elimination. there are too many things going on with your system normally. Something certainly has a bug in it -- a program sending invalid data to FSUIPC. I can deal with that (rejecting the data) but I would then have no idea what it would do to that program. Best to isolate it first. Pete

The current interim updates for FSUIPC, from the Announcements, allows users to assign names (only single letters, but not numbers) to their known named devices, and FSUIPC then automatically finds the correct device -- provided it still has the same name. Obviously it can't handle a name change automatically, but at least then the change that you accomplished in the assignments would simply be a change in the [JoyNames] section, to associate the joystick letter to the new names for devices. All the other sections are then unaffected. The letters can be auto-assigned by FSUIPC, or can be chosen to suit usage -- eg "R" for rudder, "J" for joystick, "Y" for Yoke, "Q" for throttle Quadrant, and so on. Regards Pete

I always reply to non-spam emails i receive, so either it got lost in one of the many outages I used to have (dodgy power cable, overhead ones disturbed easily by wind -- now fixed1) or it got seized and dumped by my ISP. Sorry. Well, Microsoft and others seem to manage with the information supplied. I repeat what I said in my last message. I CANNOT after 10 years, change what is reported as pitch by FSUIPC. It is merely relaying what is supplied by FS to all gauges and anything else which asks. Surely the algorithm I outlined does it all for you. What IS the problem you have with it? It gives you the pitch from 0 - 360, as you asked. Your software needs to do a little computation using the Bank value as well. Please tell me what you don't understand. I am perplexed! Regards Pete

Not before now, no. I just believed what I thought MS stuff told me. I never have time to check and test every value -- especially those simply passed straight through from FS, or given direct access into FS innards, like the LLAPBH values. I do check values computed or derived by my own code of course. For interpretation of the rest I am completely dependent upon feedback from those who use the data. Anyway, you are completely correct. And it is the same in all versions of FS. So my documentation has been wrong now for nearly 10 years, and you are the first to even notice it -- or maybe just the only one to bother to tell me! I will correct the documentation. I cannot change what FS provides -- it will certainly mess up existing programs if I do. The Bank angle will have to be read too, in order to compute the 0-360 pitch. The absolute value of the bank angle is between 90 and 180 when the aircraft is "upside down", and between 0 and 90 otherwise. So, the three resulting cases are: Pitch >= 0, abs(bank angle) < 90: real pitch = pitch Any pitch, abs(bank angle) >= 90: real pitch = 180 - pitch Pitch < 0, abs(bank angle) < 90: real pitch = 360 - pitch Check that for me please. If you agree, I'll include it in the documentation the next time I update it. Regards Pete

None of the code I have produced have "ReadAndProcess" or "WriteAndProcess" calls. I wouldn't ever propose such calls because they tend to encourage folks to use one process call for each and every offset read or write. Ugh. The whole interface is designed to be used with regular blocks of requests -- one Process call for many reads and writes, mixed. The Process call in my code is a "SendMessageTimeOut" with the timeout set to a number of seconds (you'd need to check the code for that, I don't recall), so yes, the Process call blocks unless it fails and so times out, in which case you'd get an error returned. On top of that I think some parts of the library code i provided do a number of retries, within the part incorporated into your code. These calls have to block because the memory FSUIPC is being asked to dump the data into belongs to your program. If control were returned whilst FSUIPC was still accessing it, and you freed it or terminated, FS would crash. The normal way to get around such blocking calls is to use threads. Regards Pete

O2C8 is the value updated directly by SimConnect, the others are derivative. It will be updated at the same time as the other flight related values like pitch, bank, heading and airspeed. I know of nothing to make it different (but see [LATER]). It isn't an autopilot, but a series of little feedback loops for pitch, bank and speed, so the V/S didn't come into it. Maybe. I really don't know how it is computed in the sim. If you monitor it on screen with, say, the "Display Vals" Lua plug-in, is certainly seems to change rapidly enough. [LATER] Checking my code, the V/S is actually in the "visual frame rate" group rather than in the "Sim Rate group" like the latitude, longitude and so on. But so are the speeds. I can move them to the faster group, though I think a lot of the time the two equate. If you don't get anywhere, check again with version 4.415 or later when you see it posted in the updates announcement, probably before the weekend. Regards Pete

No need to apologise, and thanks in any case for trying to help. I like to see that happen on the Forum. Too often it appears to be just me talking to everyone else, but actually that's probably because I am usually very fast at responding. When I am away for a few days others do jump in to help a lot more, which is most gratifying! This is why I switched from email support to the Forum system. Regards Pete

One possibility, if you have them assigned in FSUIPC (not just calibrated there), is that the new drivers have effectively changed the identity of them as seen by FS, and FS, in its wisdom, has seen them and automatically assigned them as new devices. If you have things assigned in more than one place it can produce some very weird results, so that's the first thing I'd check. Of course they may also look like new devices to FSUIPC too. So check both. If you are using the latest interim update for FSUIPC (available here, in the Announcements), it creates a section in your FSUIPC INI file listing the "JoyNames" it finds associated with each joystick number assigned by Windows. There are facilities for assigning letters instead, and then FSUIPC will automatically handle such changes as best it can (assuming the names don't change, only the numbers). Otherwise, have you asked on the Saitek forum? They should know what their driver updates do? Regards Pete

I need more information before I even look at it, please. Both of these are always absolutely necessary: 1. Version of FS (FSX, FS9, FS2002, FS2000, FS98, CFS1 or CFS2?) 2. Version of FSUIPC (if not the latest, please update first). Then can you please go to the FSUIPC "Logging" page, enable Monitoring of 3122 as type UByte, check "normal log", and also enable IPC Write logging. Then re-test, and show me the parts of the log where you write to 3122 and the results are shown. Thanks, Pete

The pitch data is complete. No more is needed. It gives all 360 degrees -- 0 to 179.999999.... pitch down and -0.000001... to -180.0 pitch up. What more could there possibly be? If your pitch reference zero is other than the horizontal it is just a matter of arithmetically adding or subtracting that reference, surely? What is the difficulty? It's only one dimension, there are no other factors. Pete

Okay, but now you know. It's just as much stealing as those who take copies of friends CDs and DVDs, denying the makers/artistes their income. Sharing a copyright product is a violation of that copyright. Yes, when they have given me the original, leaving them without. That isn't possible with software, which is why it is either licensed to the individual (as with my stuff), or to the one specific PC (as with Microsoft Windows and most other licensed software). I tend to think the latter is too restrictive, but perhaps I should consider going that way. :-( This is exactly the same. What is the difference between your friend making you a copy (which is actually how most CD and DVD sales are lost) and you downloading it from the internet? In fact, it isn't the copy of the software which is illegal, it is the Key to allow you to use it. You cannot get that from the Internet without purchasing. Any downloadable keys you may find are either pirated and fall foul of traps set into the software, or are revoked as and when discovered, as, indeed, your friend's should be if you will reveal it in your honesty. Please go and buy your own Key, and update your version of FSUIPC -- or simply delete the FSUIPC.KEY file from the FS modules folder so making your copy unregistered, as it would be if you had downloaded it. And then thank your friend but warn him not to do such things again. Regards Pete

Stutters in FS9? On a machine like that? Could your hard disk have been getting full or badly needing defragmenting? That's illegal. The license is sold to a specific user and registered in his name and email or home address. If he"gave" you those details he's in violation of his license, and the registration must be revoked. You are effectively using stolen property. I deliberately didn't go down the road of restricting use of FSUIPC to a particular PC as i think this is unfair on the user -- I prefer it licensed to the person. But that doesn't give any one the right to make copies and give them to friends. That's stealing and is akin to making copies of CDs and DVDs. And it isn't supported either. If you want support you need to purchase your own key and update to the latest version. I'd appreciate it if you'd show me the Key you are using, too, please, so I can revoke it. Otherwise we cannot be on good terms. Pete

Do you always load FS from ASA? It is looking more and more like a bug in ASA rather than the add-on aircraft. I'm not sure it is wise, until we get to the bottom of this, to run ASA until FS is loaded and ready to fly. All sorts of things might be going wrong if ASA is messing with FS whilst it is initialising. Why have you reverted to FSUIPC version 3.82? That's really very old, and no use to anything I can do. Please stay with 3.858 until i send an update for you to try. It is huge even though FS crashed/hung on loading? That is VERY suspicious, and even more indicative of a problem caused by ASA trying to do something whilst FS is initialising, before it is ready for whatever it is ASA wants it to do. The MOST important part is the last part, the bit before the crash, though if FS hung instead of crashing that might not be so useful. ZIP it and send it as an attachment to petedowson@btconnect.com. Do NOT send it without Zipping -- it will zip up quite small. I'll look at that one, but please try to get one from a CRASH not a HANG, and using FSUIPC 3.858, not 3.82. Please also do some testing where you run ASA later, when FS is ready to fly. It sounds like it isn't waiting for the "FS is ready" signal from FSUIPC before trying to set the weather -- FS will certainly not like attempts to set weather when it is still initialising all that stuff! Have you reported all this yet to HiFi Simulation, as a potential ASA bug? If not I think you should. I am on good terms with them and we can resolve it between us, but bugs need to be reported by users, not by third parties like me. Oh, just looking at the start of the Log, you have other FSUIPC clients also running. "SBMPJOIN9.DLL" (part of Squawkbox?) and "SDscene.DLL", which I don't know though must have licensed. Then, later, SBMOD9.DLL starts up too, followed by ACTIVERADAR.DLL. You didn't mention any of this before, did you? Any one of those could also be part or the whole of the problem. Maybe you should continue doing some elimination. Do you know what SDscene.DLL is for? Try removing it temporarily from the Modules folder. SBMPJOIN9.DLL and SBMOD9.DLL too if you aren't flying on-line during these tests. You really do need to pare it down to the minimum setup which crashes if we are ever to resolve it! You don't need ACTIVERADAR.DLL either just to use ASA. Move all these optional FSUIPC-using DLLs out of the Modules folder for now -- keep them safe, then run more tests with just ASA. If that's then okay, add them back, bit by bit. ActiveRadar first, test, then the two Squawkbox ones, test, then finally that SDscene, whatever that's for. If it still fails with no FSUIPC users excepting ASA, we know it is definitely ASA. Regards Pete

Not sure why you'd want to use "GEAR TOGGLE" for separate up and down operations when there are perfectly good GEAR UP and GEAR DOWN controls available for such separate assignment? This was why I was puzzled by the original question, and still am. If you are going to all the trouble of editing the XML files, why not take advantage of the controls FSX actually does support, not just the ones MS thought you should be ogffered in its assignments menu? I had assumed, wrongly maybe, that the fact that the original question was asked here, in the FSUIPC support forum, implied it was related to assigning buttons in FSUIPC. ALL of the FS controls (and more added by FSUIPC) are available for direct assignment through FSUIPC. If you really do wish to take advantage of the XML file instead to program FS controls, you will find a full list of names for all FSX controls in a PDF installed for you into the FSX Modules folder when you install FSUIPC4. Any of those should be usable in the XML file -- just omit the underscores separating the words. (You do not need to purchase FSUIPC4 to be able to install it and read this, and you can always delete FSUIPC afterwards if you don't want it installed). Regards Pete

Any of the cockpit selection controls will highlight or select that other cockpit function or view and so "un-highlight" the previous one. Have you not looked at the extensive list of controls provided (installed) in the FSX Modules folder for you when you install FSUIPC4? Examples of selecting controls are: ADF COM_RADIO DME MAGNETO NAV_RADIO VIEW VOR_OBS XPNDR If you simply want keyboard focus back to the normal view, I think the VIEW command does it. Regards Pete

Did you get my email, sent yesterday (Monday), Bill? Regards Pete

The documentation simply reproduces what the Microsoft SDK says for the same variable. I have never used those so I've no idea whether Microsoft are mistaken or not. They have been consistent throughout the life of FS, and they are documented as ft/sec in the latest SimConnect SDK for both FSX and ESP, so I really do think they are correct. You can easily check. For the specific aircraft the speeds are given in the Aircraft.CFG file. For example, the FS9 737-400: [Reference Speeds] flaps_up_stall_speed = 142.0 //Knots True (KTAS) full_flaps_stall_speed = 113.0 //Knots True (KTAS) cruise_speed = 477.0 //Knots True (KTAS) max_mach = 0.82 max_indicated_speed = 340 //Red line (KIAS) So for this one, VS1 is 142, VS0 is 113, VC is 477. Max Mach is in another offset I think. Why? Are the values inconsistent with that? 194.12639 ft/sec = 115 knots 261.64862 ft/sec = 155 knots Those seem reasonable for an airliner. What aircraft is this? Have you checked the Aircraft.CFG file, where they are defined? I've never heard of VLS before now, and there's no sign of it in FS, nor can I find any references to it in technical aviation books. Can you elucidate? Regards Pete

Sounds like he has an invalid registration. If it works okay when he deletes the FSUIPC KEY file, then that is the problem. Either the key was purchased AFTER his system's date (i.e. he has the date wrong) or he is using an illegal (pirated) key. If he believes it is okay he should ZIP the key file and send it to me at petedowson@btconnect.com. If it still fails without registration is could be a code signature failure -- it will tell him in the FSUIPC Log file. That could be due to a DLL which has been tampered with, or possibly because he has Pete L. Dowson recorded as an untrusted publisher. Regards Pete