Pete Dowson

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

Yes, but is that using the same facilities and protocols? I don't think that is the only test. Are you using TCP/IP in WideFS? If so it shouldn't be a problem, but there's a lot of magic in all this and I get lost in it. Hence the trials and errors :) I mentioned! If reinstalling doesn't help and you've been through the DOCs, try Katy. She has helped me (Network-wise I hasten to add!) a few times. Regards, Pete

It sounds good. I shall paraphrase your very words and suggest to others that they may do the same thing in future. Thanks! Pete

Surely the problem with the Hold/Pulse setting getting mixed up or lost is fixed in 3.21? That was specifically attended to and quite thoroughly tested. If it is still giving you problems I will need exact details of how to reproduce these (by email with Zipped attachments is best), please. . I agree that the processor shouldn't be too slow. I'm sorry, but all FSUIPC can do is to send the keystrokes you program it to do. There is nothing else it can do. It sounds like the PMDG panel coding is very slow in processing them. What would be needed is some accelerated increment/decrement shortcuts for these values, similar to those I've just added for the default A/P. Then you would not need to turn it so much. Do PMDG not list any such? What else can I possibly do? Have you asked PMDG to help, or maybe GoFlight? All I can do is let you program the GoFlight knobs to send whatever keystrokes or controls you want them to. FSUIPC does that. After that it is up to the receiving software. I am not going to re-write PMDG's cockpits for them, sorry. :? PMDG have promised an SDK, but, from what I've heard, it doesn't look too hopeful that this will allow me to provide new special controls for their panels as I do for Project Magenta. This is because it will not be free and it sounds like each user will need a license. I don't know how this is going to work out for most ordinary users, but probably the best, and maybe the most likely solution for Goflight, is that Doyle Nickless (CEO of GF) purchases the license and provides a new driver for his units. Regards, Pete

Oh, good! How did you get them to do that? I would like to advise others what to do in similar circumstances -- up till now it has been a bit of a palaver for both parties. Not wasted, do not worry. Regards, Pete

As far as I know from others, at present this can be done (and has been done), but only by using the Keyboard shortcuts provided by PMDG. There is an SDK planned for the PMDG 737NG, but I don't think this will be free and will, of course, entail some programming to use it. Regards, Pete

You need to download the FSUIPC SDK and check the Programmer's Guide. Just do a search on the words "rudder trim" and you will find it -- this is what I always do to find things. (Sorry, I've not got that PC on at present). As far as I know there is only one trim value, which is both control and indicator, but it is in double floating point format and the units are something like radians. In a program I am doing to set/read trims for a 737NG I found the value ranges from 0.0 to 0.2, so you'd need to scale this to suit your needs. You may want to monitor the value in that offset (eg using FSUIPC's Monitoring facilities) to see what range you get in your chosen aircraft. Regards, Pete

2.97? I don't support that any more. SorryHowever: Why aren't you using an up to date FSUIPC with FS2002? There are improvements and fixes going into it all the time, and many of these apply just as much to FS2002 as FS2004. Sorry, no. It sounds like this "Broker" program isn't setting the time correctly. I'm afraid there is no way I can debug other folks' programs. I suggest you get in touch with the author and see if he can help. I can certainly help him sort it out if he needs me to, though with all the Logging facilities and FSInterrogate he has access to, he shouldn't have any problems working out what's going on. Regards, Pete

Not much I'm afraid. Absolutely everything I know about Netwroks, and more added ffrom others, is included in the WideFS DOC. If you'vve been through all the ideas and possibilities there with no luck, then I'm afraid it's down to trial-and-error, or possibly help from a real Network expert (e.g. you could try Katy Pluta who hangs out in the FS2004 Forum). The error message is the least helpful I've seen (WideClient is merely repeating what Windows/winsock is telling it). For all the more usual errors I include the words describing the error to, but I've never seen a 10106 before! Looking it up in Microsoft help gives me this: 10106 The requested service provider could not be loaded or initialized. WSAEPROVIDERFAILEDINIT In other words it looks like there is either a driver problem -- it isn't installed correctly, or it is plain wrong -- or just possibly you are asking for a protocol you didn't install (though usually I think this gives a different message). As I've never seen this error before, the only thing I can suggest is uninstalling and re-installing the card and its drivers. Perhaps others may know more about this sort of thing. Regards, Pete