Pete Dowson

The FSUIPC.LOG file (in the Modules folder) would show if it is trying to access an unregistered FSUIPC and being refused. That's the first place to check. If the gauge in question is "WxGauge.gau", then, indeed, Mr. Praxmarer has been issued a Key for it, and as far as I know it would have been built into the Gauge code for automatic access permission. Otherwise, he would have to provide the Key for manual addition by the user. If the FSUIPC IPC read and write Logging is enabled, then the panel with the gauge loaded (or FS closed and reloaded, if the aircraft is default), the Log produced will tell me everything I need to resolve this. Regards, Pete

Sorry, I don't know. I don't use such a gauge -- this is a question for the author. Regards, Pete

There's nothing changed in Version 3.211 which affects buttons at all, it's only a fix for some calibration problems on axes. When you say "dead", do you just mean that those you already programmed no longer operate, or that the buttons are not even seen within FSUIPC's Buttons option page? If the former, please send me the FSUIPC.INI file. There have been some corrections to some areas, relating to aircraft-specific buttons and so on, so I need to check if the parameters in your INI file are still being read okay. Regards, Pete

I've had to make an error-fix release for FSUIPC 3.21 (it's version 3.211 and should be available soon). The main door status is exposed in this version, at offset 3367 -- I've allocated bit 2^0 in that byte for the main doors open (if set). The other bits are reserved in case I can find the others some day. Regards, Pete

I did some more checking into this, as it was quite worrying. I found that I made an error when adding the Cowl Flaps axes to 3.21, some time ago (actually soon after the preceding release went out)! It was quite serious. Calibration values were getting mixed between axes and between centres and maxima -- only the minimums were safe. The symptoms could be quite odd and misleading, or it may not affect anything at all. Quite nasty in fact. So, I've had to make a rush interim bug-fix release. It is version 3.211 and should be up on the usual places some time in the next 24 hours. Sorry for the problems and thanks again for the help. Regards, Pete

Sorry, but Florian is wrong. The FSUIPC.INI, LOG and KEY files are generated by FSUIPC when you run FS. They are never supplied in the ZIP. Pete

Hi Anders, Thnaks! Following exactly your procedure I can reproduce this now -- excepting I get -512 not +512. I thought it might be the reversing of the axis that is screwing something up, somewhere, but I'm at a bit of a loss. If I start all over again, from a fresh load, and do everything as per your list EXCEPT reverse the axis, it now still does the same bad thing! Yet I couldn't get it to do any such thing before! Now that I know how to make it happen I can trace it through and fix it. Thank you very much. Please use the standard FS calibration for now. I will get back to you when I've sorted it out -- it may be a few days. Regards, Pete

The Read is less likely to fail than the Process, because it doesn't really do anything other than add the request into a buffer in your own program. To do what you really want to do you need the Else ACID = "NA" within the If/Endif section for the Process. If VB accepts compound logic without executing both parts, you can of course combine both If's into one, with an "AND". This works okay in C/C++ because the code processes the separate condition from left to right, and will stop when the condition proves false. It may not work in VB though. None of this helps with your actual problem, though. Sorry. I'm not able to answer that. Regards, Pete

No it wouldn't! They are examples of the worst sort of uncommented C programming, and I'm thoroughly ashamed of them. Just because they work doesn't mean they are good! I wrote them as one-off, never to be re-visited (fat chance! :) ), test programs primarily for my own use. They were released as "useful" but not, heavens forbid, as "examples". I've been a programmer since 1963 and have got into awful habits which, though they work for me, I would hate to either impose on others or try to explain. If I were to release any of that for others to see I would feel totally bound to spend many hours on the code, tidying it up, structuring it better, and, last but no least, adding some comments! I really haven't got the time nor patience. Sorry. I notice that many VB programmer's don't mind sharing code snippets. I think that's probably the best way. Maybe there are also some C programmers who are more proud of their coding style and who are more conscientious in their commenting than I. If so, let us hope they come forward! :wink: Regards, Pete

Absolutely; I'm going to have to talk to my boss to see if he would like to pursue this. Of course if it is for internal use or for a known limited number of user sites you could simply purchase appropriate full user licenses for FSUIPC instead. Then your program(s) would have free access through those in any case. The only need for a program access key would be if you were distributing the program and expecting non-user registered FSUIPC's to be installed. Regards, Pete

There's a simple example in several languages, including VB, in the FSUIPC SDK (get it from http://www.schiratti.com/dowson). Departure and arrival points? These are not aircraft values you'd normally be able to read. Do you mean the routing for AI traffic -- you can, in FS2004, get the departure and arrival airport ICAO ids for all operating AI aircraft in range? There is some information you can read from the GPS if you've got a flight plan loaded -- not departure and arrival, though, only last and next waypoint IDs. Fuel used isn't a value maintained by anything internal either. You'd need to keep track of that yourself by reading the fuel tank capacities and levels from time to time. There are no overall totals, just separate values for each tank - up to 10 of them! Regards, Pete

Maybe. Sorry, I don't know of most users of the DLL. I don't really know what ADAHARS or ARINC 429 means, but you can certainly get most if not all of that information from FS through the FSUIPC interface. You need the FSUIPC SDK, from http://www.schiratti.com/dowson. You don't need to write a DLL. You can write an external program, in C, C++, Visual Basic, Delphi, whatever (see the various packages in the SDK). The program can read the data from FSUIPC (for which you would need an Access Key) then convert it into whatever form you like and send to anything else you like. Your first step is to get the SDK and peruse the stuff in there. One of the documents is about Access Registration, which will tell you the requirements for an access key. For a commercial application we would need to discuss terms, but I could arrange a free time-limited one if you simply wanted to explore possibilities initially. Regards, Pete

There's nothing changed which will do that, apart from the fact that there are many more facilities in the later versions (and of course the list continues to grow), so FSUIPC's memory occupancy changes. This in turn could cause other parts of FS, or more likely add-ons, to load slightly differently. Even simply replacing the DLL in the Modules folder can change the order of the DLLs in the directory file for that folder, making FS load the files in a different order. All this amounts to revealing some problem you had already, the symptoms of which were not so evident until this change. I'm afraid that just about the only way of resolving such problems is to either start from a fresh installation of FS and gradually add your add-ons one at a time, testing each time, or, perhaps a little easier, the other way around -- uninstalling them one at a time. FSUIPC version 3 traps any crashes which occur whilst it is in control, and these are logged and recovered. If it is seeing any you will find full details in the FSUIPC.LOG file (in the Modules folder). By all means let me see that. However, it does not attempt to trap and recover from errors anywhere else in FS -- it would have no idea how to recover in the first place. For those you need to try to capture some details -- use DrWatson, for instance. If you like I can look at any such results and see if it points to anything obvious. One of the things to certainly try is to reduce your Sound hardware acceleration -- I can't remember exactly how to do that, but probably by running DxDiag. I have heard of timing problems caused by the way sound files are buffered. Regards, Pete

Shouldn't be. All FSUIPC requires is that the number in the maximum column is numerically greater than the number in the minimum column, using signed numbers. In all of its joystick facilities, the numbers increase left to right, no matter what this actually does in the simulator. When you re-check the INI file, ensure that the calibration line reads something like: Spoilers=-16193,16192 i.e. two numbers only, not like, say, a specific Throttle line which may be like this: Throttle1=-2295,-430,135,2295 i.e. four numbers, with the middle two defining a "centre" zone (idle in this case). (These two examples are from my test installation). Regards, Pete

Slovenia doesn't present any problem, surely? SimMarket has lots of customers there. Just check the first few pages in the FSUIPC User Guide. It gives you all the information you need, including methods of payment and a link to the pay booth. Regards, Pete

I don't know VB, but here are some possible problems for you to investigate: 1. How does the compiler know to provide space for 12 characters? Your "Dim" statements don't appear to state the maximum length needed for the string. The FSUIPC read might be overwriting something important if there aren't at least 12 character's worth of space. 2. Is this "NA" the full ATC Tail Number, or just the first 2 characters? If it isn't the complete tail number, does VB use only the length of the shorter string to do the comparison? Seems odd. In most languages a string "X" will not match a string "XY" unless you deliberately restrict the length of the comparison. 3. Is your VB system using ASCII strings in the same way as Windows and FSUIPC? The string you are reading will contain single (8-bit) bytes, one per chanracter, with a zero byte at the end. If your program is compiled to use double-width characters or Unicode, you will be expecting 2-bytes (16-bits) per character. Additionally, some languages store strings with a length byte at the beginning instead of a zero terminator at the end. All these things should be described someplace in your VB references. In the last problem, you may have to resort to using an array of byte values instead of a "string" as such, especially if your VB system cannot handle standard ASCIIZ strings ("ASCIIZ" = ASCII 8-bit characters with Zero termination). You should get some help here from other VB users. Sorry if my hypothesising makes it look rather complex. I'm sure it can't be that bad (though I must say I grew to hate VB a long time ago! :wink: ). Regards, Pete

Did it work in FS first, before "Setting" it in FSUIPC? Proper joystick calibration should be done in the normal way for good results. FSUIPC merely provides extra accuracy in setting end or null zones (and centres). It's working here and has been since introduced some years ago. There's been no changes for a long time. The spoiler axis is just like most of the others. When you click on the "Set" button just above the maximum value display, that's the value is remembers -- it is written to the FSUIPC.INI file. Check it there if you like. It is misleading to try calibrating spoilers on the ground. Just above the "stowed" or "down" position there is an "arm" position. FS seems to automatically deploy 100% spoilers when it is already on the ground if it sees any value on that axis corresponding to its idea of the "arm" position. However, I have experimented here and can see no way that this action can interfere with or prevent a decent true maximum being stored and recalled in FSUIPC. Please check your INI file, see what that says. Give me, step-by-step, exactly what you are doing and what you are seeing (and where you are seeing it), and possibly I can spot what is going on. Most of the spoiler problems I have heard about are related only to its behaviour on the ground. Try sorting this out in the air. And to eliminate FSUIPC from your investigations, just go to the relevant FSUIPC page and press "Reset" on the spoilers calibration section -- doing this will take FSUIPC entirely out of that loop. When you are happy and want more precise dead zones (though these are hardly so important with the spoiler axis), try FSUIPC again. Regards, Pete

For freeware it is always possible, even more so :wink: by requests from the authors themselves. I need some information about the program (DLL or GAU or EXE) which is accessing FSUIPC -- see inside the FSUIPC SDK. There is a document about Access Registration. Check section 4 onwards. Send the inforamtion it describes to me at petedowson@btconnect.com and I will return a Key. You can then build this into your program. Access to FSUIPC from scenery BGLs isn't actually possible as far as I'm aware (never has been?) -- but there are some of the original scenery variables still made accessible vis offsets (these are documented in the SDK). They are generally used for two-way communication between program and scenery. Regards, Pete

Door status? I only found out that FS has doors you could open recently! :) Looking through the current list of Gauge variables, there is one called "MAIN_EXIT_OPEN", but I can find no others. Is this enough? I could add it to my list, for "exposure" in an FSUIPC offset in the next version. I'm afraid things don't really work like that any more -- FS98 and before it was almost 100% that waysearch a fixed data area and you could find things. These days much of FS is written in C++ with COM-style interfaces and private data that is a devil of a job to find even by hacking through code. Regards, Pete

With a default FS aircraft, or something like the PMDG 737NG panel? I think the latter doesn't use the FS autobrake. Maybe other panels too. I assume you mean offset 0x2F80? That works fine, it has been in constant use here for three versions of FS. It is the location used by Project Magenta too. Bit 2? The values are decimal, 0 to 5. It is not a bit-oriented offset, it is numerical. And what do you mean, the switch "disappears"how does a switch disappear? This is a graphic on a panel? It is exactly as defined. These are not "bits" as such, you just write 0, 1, 2, 3, 4, or 5, exactly as it says. There's no mention of these as "bit" numbers! Where are you seeing that? Pete

I'll check that, but it sounds very off, as I clear the byte altogether when getting "frame rate" calls from FS. This would imply I get none in FS2002 when it has no focus -- which would effectively stop some of FSUIPC's variable updating in any case. Ugh. Hmmm. Strange. Regards, Pete

Hmm. Very strange -- unless the AV activity is doing something on the Network too -- a firewall or some nosing into packets being received "in case" they are viral? Whatever, if it is causing strange error returns from the Network software, it isn't right. Regards, Pete

Ah good -- so it was hardware all along! Glad you fixed it! Regards, Pete

Microsoft did not provide any axis inputs for Aileron or Rudder trim. However, I added this capability into FSUIPC some time ago -- you assign your axes to some axis input which FS does support, but tell FSUIPC the control number and it "pinches" the input and operates the trim for you. You calibrate it on Page 7 of FSUIPC's joystick options. You will need a user-registered FSUIPC for this, and full details of the facilities for assigning such additional axis controls are given in a section of the Advanced User's guide. "Engine cut" usually means fuel cut -- turn off the fuel. That's done by reducing the mixture to zero. There are mixture axes for each engine. The magneto switch merely operates the power to the magnetos on a prop and is the starter on a jet -- it won't stop a jet. TOGGLE_FLIGHT_DIRECTOR. Regards, Pete

There's really not going to be any connection at all between installing FSUIPC and losing sound. There's no relationship there at all. I don't know what's happened to your FS installation, but it seems another one of those processes of elimination are needed if you want to avoid a complete re-install. Regards, Pete