Pete Dowson

You need to be a bit more specific. Can't you find the fuel information you need? There are details of levels and capacities for all the possible tanks. Just search in the main table in the Programmer's guide for the word "fuel". For Visual Basic there are files and an example provided to get you going. If you have a little experience in VB you should have no problem, though I am not qualified to help in that language. If you expalin what problem you have, even show what you are doing which you cannot make work, I'm sure other VB programmers will help sort it out. Regards, Pete

There's no magic about those offsets compared with any others. I'm sure it is really nothing to do with those, though it may be to do with the code around your access to them. If it is crashing in your program, which it is, you should be able to get a DrWatson dump and locate the last call to Windows (or more likely to a library routine) you did before the crash. If you can reproduce the problem then it should be easy enough, as you can use the Debugger which comes with the language compiler you are using. If you cannot reproduce it, then you'll need to add some diagnostics to your program -- I do this via my Log files. Regards, Pete

Pretty much everything uses NTDLL.DLL, as it is the support for many Windows APIs and probably many parts of Windows. You are pretty well certain to be using NTDLL, it is almost impossible to avoid. You might as well say "I am not using Windows". If your process is crashing, which it is, then there is an error occurring in your process. If FS is crashing then that's another matter, but I'm afraid only you can debug your program. Check that in your string or array handling for the strings you are trying to write you are not exceeding some bounds and overwriting something else in your program. You can easily create stack corruption which could be reported later in almost any of the depths of Windows. Windows XP is very good at preventing errors in one process destroying another. Regards, Pete

One of the gauges in the panel is trying to use FSUIPC using the completely incorrect interface, the one intended for external programs. The gauge concerned must be a couple of years or more old as I don't know anyone programming this incorrectly these days. Unfortunately, because it is using the wrong method, I cannot even identify which gauge it is so you can remove or replace it. But, unless you want to pay to register FSUIPC as a User, I'm afraid that is what you will have to do. If you look in the PANEL.CFG file for the program you will see all the gauges listed. Try removing them one at a time. The most likely one would be a TCAS gauge. If there is one, try removing that first. I think there are some good working freeware ones you could try instead -- look at the list of Freeware Keys earlier in this Forum. Regards, Pete

FSU? Short for FSUIPC? You need the official Microsoft panels SDK. It will tell you all you need to know about officialy supported variables and key events. I'm not sure how you would synchronise to frames. FSUIPC does it via some Chain calls from FS. But using the module users interface to FSUIPC is very fast, that isn't a problem. Regards, Pete

I did think of two other method. If you are writing the program to capture the data, you could EITHER: 1. Write the program as a monitor (advanced programming for windows!), like the PortMon utility freely available from http://www.systeminternals.com, just capturing the output inside the PC as it goes out, OR 2. Write the program to read the data on one COM port and send it out on another. You'd be using three COM ports altogether -- one for GPSout to the first one for your utility, then the output from that to the other device. COM ports can be added via USB easily enough, you just need a serial port USB adapter. Of course, if all you want is a database of the values, you could write a program to read them from FS via FSUIPC and not use GPSout at all for that part. Regards, Pete

Aren't I still waiting for your email with FSUIPC.INI before, Logs and FSUIPC.INI files attached, so I can investigate this for you? Nothing has arrived yet. Pete

3.203 has a fix for folks with GoFlight TQ6 modules, that's all. It isn't on general release yet. Please check the Notices at the top of the Forum for release details. The FS A/P controls control the FS A/P. PMDG don't use the FS A/P. The only way with any such aircraft would be to find what keystrokes they use for their A/P (if any) and program those. If they don't support keystrokes then possibly the only other way is to use something like Key2Mouse (from Luciano Napolitano) to convert keystrokes into mouse clicks. Regards, Pete

If the dialogue is entered via a Menu, yes, because the 1 bit is set only by the MENUSELECT message from Windows. No, none at all. Though I must admit I don't know exactly what causes the "ENTERIDLE" message -- it is this which sets the 2 bit. I don't see how the value could ever be 3 in that circumstance, because that would definitely mean that FS receieved a MENUSELECT message. Maybe you are using the ALT key to swap processes? That may give a temporary 1 bit because ALT is the MENU key. The bits are cleared whenever FS sends FSUIPC a "frame rate" call. The only time I know, when FS doesn't have the focus, that no frame rate calls are sent, is when FS is minimized. In older versions of FSUIPC it would effectively stop doing anything when FS is minimised -- the returns you got would be the values frozen at the time it was minimized. Mostly that is still true, I just keep enough going to prevent WideClient's timing out. If you are minimising FS then I wouldn't be surprised if the value goes to 2. If you do it with the ALT key it may even get stuck with the 1 bit too. I've not really got any solution to that at present -- others seem to regard a minimised FS as a pretty well stopped one in any case, though it does carry on at a very low frame rate I think. If anyone has a better idea of how to decide on these signals, I'd be glad to consider it. Regards, Pete

Interesting that Mondays in your country are the 'bad days'. Here we tend to blame bad stuff on Fridays -- because folks have their minds more on what they'll be doing that weekend. Also known as Poets Day ("P*** Off Early Tomorrow's Saturday"). :) Glad your system is okay again / at last! Let's hope it now has a long and healthy life! Regards, Pete

Yes, but unfortunately that flexibility is at a cost too, in cases such as those you mention. The mechanism being used in FSUIPC is developed from the simple joystick button assignment originally provided several years ago. It works well for all buttons and toggle switches, but it doesn't really suit rotaries so much because of the time-lag factor. A proper treatment of rotaries would count the clicks and do bulk updates rather than simply INCs and DECs, but this involves reading the appropriate FS value, adding or subtracting a value, and re-writing it. This is easy enough for specialist software designed for the specific hardware, but not so good for generalised treatments. What I possibly could consider adding to FSUIPC at some stage are "fast" versions of the sorts of INC/DEC controls that you may wish to program on rotaries. For instance, +10/-10 for heading, +1000/-1000 for altitude, and so on. This is not technically difficult, it is just a lot of work for which I haven't really got time at present. I have made a note about this, though, and may try to fit them in later in the year. Meanwhile, certainly try doubling up by programming both press and release (this doesn't prevent single increments as one rotary click is either a press or a release). For "fast" values you will have to edit the INI file, though, and multiply the number of identical controls issued. Incidentally, you should be able to mix programming some things in FSUIPC and others using the GoFlight provisions -- choose the most appropriate for what you want to achieve. Regards, Pete

Hmm. Not sure how you'd do that. The transfer is unidirectional -- that is, it only uses the TX wire from the FS PC to the RX on the recipient device, plus the common or ground. So presumably you could take another lead off that to another input. But I suspect that would drag the signal level or voltage down so making the stuff unreliable, or possibly even taking excess current and damaging one end or the other -- I know that to be a possibility with parallel ports (I've blown up a couple that way!). There are probably ways of splitting an RS232 signal correctly and safely, but it is not an area I know anything about I'm afraid. Perhaps a search on the web may strike lucky? Or posting questions on a hardware forum? Regards, Pete

sorry thats not working.... :( do you have a nother idea?? please.... No. There's no other way that I can think of! Why doesn't it work? Have you tried Aerosoft support? Even if the "mask" method doesn't work, if the TRIM work then this should at least write 1 to the offset when you press the button and 0 when you release it, maybe messing up the rest of the same Byte if the mask is ignored. Have you enabled FSUIPC write logging and checked the Log to see what is happening? If you don't understand the log, show it to me. This is starting to look like a major job for Aerosoft rather than me, I'm afraid -- if it doesn't work then the Aerosoft driver needs attention. But if it doesn't, how have you got the others to work? There's no way I can debug their software I'm afraid. Pete

Sorry, this is getting confusingyou seem to be starting a new thread each time uoy write here! :( I think if you are going to do this it would be better to use my email instead, and please keep the Subject Line the same. Please go find my answer in the previous thread you started, and try to follow the instructions I gave you there -- ZIP up any logs and INI files for me and attach them to the emails. I can't really deal with this here because it is extremely difficult now you have three or more separate threads all going on the same subject, each seemingly reporting without replying to the previous one. Thanks, Pete

No, your problems aren't similar. You are getting 4 distinct programmable values for each dial. The problem with the TQ6 was that it destroyed the recognition of faster turns versus slower ones, so you wouldn't see 4 values at all. There won't be any -- when you turn the knob you either get a "fast turn" or a "slow turn" -- having them programmed separately for exactly the same FS control will give the either that FS control, or that same FS control. The idea of fast and slow values is for you to assign FASTER controls for the FAST turns -- you can't do that with many, if any, standard FS controls as it doesn't provide them. Project Magenta provides fast and slow controls, and possibly some other panels do too. Also remember that the rotaries emulate a button being pushed and released. Each "click" either pushes or releases that button, one click each, so for normal operation you need to program the same FS control to both press and release in FSUIPC's buttons page. That would give you double the speed in any case. If you wanted, say, quad speed on the "fast turns" then you'd need to edit the FSUIPC.INI entries and make both the press and release perform the same control twice, or more (and so on). with the simple single INC/DEC controls provided by FS this is almost the only waybut ... if you want to take advantage of FS's own acceleration, you mght try programming them for Key Presses instead of FS controls. Again, the same applies about presses, releases, and multiple entries. Well, apart from what I describe above (which I hope will help), you seem to be applying the FSUIPC facilities to functions that are probably MUCH better served directly by the GoFlight programming. All of the standard functions in FS are surely covered in what GF provide, aren't they? I added programming facilities into FSUIPC and WideFS mainly to cater for the needs of Project Magenta users and other non-standard cockpit software. I had no intention of trying to supplant GoFlight's drivers. The FSUIPC stuff is far too generalised. Regards, Pete

This message is simply the error WideFS is receiving from Windows. You have something configured which is stopping the connection. What that maybe, I'm afraid I don't know -- maybe a firewall (XP's own, or ZoneAlarm, etc), or some sort of block in a router, hub or switch. I hope some Network experts can jump into help you here -- all the things I know about Netwrk problems (and many things I don't) are actually discussed in the WideFS document. After that, for me, it is guess-work and trial-and-error I'm afraid. Regards, Pete

Aha! Right. Now we are getting somewhere! The decimal value 3008 corresponds to the hexadecimal FSUIPC offset 0BC0, which as you will see from the FSUIPC SDK's Programmer's Guide, is the Elevator Trim value. So you can program writes to FSUIPC. Good. Can you change individual bits in a location, given its offset (converted to decimal of course)? If so then you can use the virtual buttons facility to make your PTT switch look like a Joystick Button. I've looked at the website, and according the the (rather brief) description of the data format, the "65535" value (the 5th in the example) is a 16-bit mask. Unfortunately it doesn't say what the mask actually does, but assuming you can use it to select which bits you change in an offset, the you should be able to make virtual buttons happen. 65535 is hexadecimal FFFF which is all the bits in the 2 bytes the example is using, so it just means select the whole lot. So, assuming that support from Aerosoft has been discontinued (has it?), you'll need to experiment a bit. As I mentioned, there are 36 bytes from offset 3340, in which each bit is a "virtual button" for programming in FSUIPC. Try the lowest bit (1) in the first of these bytes. hex 3340 is decimal 13120 (use your calculator: 3 x (16 x 16 x 16) plus 3 x (16 x 16) plus 4 x 16, plus 0). The "mask" for the 1 bit is 1. You want that bit to turn on when you press the button, off when you release it. So try: 13120,1,1,0,1,0,0,Virtual Button 1 According the the list of fields in the document on the website: Decimal address of variable in FS2002 (here it means in FSUIPC!) = 13120 Number of bytes in address = 1 (you only need 1 bit in fact) ON value = 1 (to set the bit) OFF value = 0 (to clear the bit) 16-bit mask = 1 (to avoid changing any other bits, I hope) Special function code = 0, no repeat wanted Special function value = 0, no special function Description = whatever you like. I don't know if this will work or not. It all depends on what is meant by "mask" in the documentation, though I think my interpretation is the only sensible one. Let me know. Once FSUIPC sees the button or switch in the Buttons page, you can program it to do whatever you like -- in the case you are interested in, PTT on when pressed, Off when released. Regards, Pete

... and you say that the Button programming you entered is not written out to FSUIPC.INI, or that it is but it isn't remembered when you next load FS? This was a problem before 3.202, but it was certainly fixed and tested. So I don't understand what is happening on your system. It is happily working now in many systems including my own. It seems there is something very different about what you are doing, so I need much more detail. I need a very specific example. Program one button. Exit FS. Save a copy of the FSUIPC.INI file. Reload FS, see if the button still works or not. If not, exit FS, and show me the [buttons ...] sections of both the saved FSUIPC.INI and the latest one. Also tell me exactly what programming you did and, if Aircraft Specific, which aircraft (please make it a default aircraft so I can do exactly the same here). Regards, Pete

Okay, let's pause there for a moment: How are those switches programmed to do those things in FS? What software do you use to do thisare the switches seen as Joystick Buttons pr Key Presses in FS or FSUIPC, or are those functions provided by some software from Aerosoft? The rest of your question cannot be answered properly until this detail is understood. I'm afraid that if FS does not see the keys as joystick buttons or keypresses, then neither can FSUIPC see them that way. Unless you can make the Aerosoft driver provide input to FS or FSUIPC in some form that can be recognised, then how can it be utilised? You see the problem? If you know how to do this for the functions of the other keys, please explain and then maybe we can develop that for the additions you want to make. Regards, Pete

It doesn't get to the PC at all -- it changes the codes returned by the rotary next to it (OBS) -- you can see this both in Test mode and in FSUIPC's Buttons page. Regards, Pete

The host (server) must actually be on the network before WideClient can even initialise correctly. It's really a fatal error, best to just switch on the Server first. None in particular that I know of. It's a matter of experimentation with PM components. A post in the PM Newsgroup may elicit some suggestions. Regards, Pete

That was a problem a few versions of FSUIPC ago. You have not installed the one I sent (3.203). Please check, or show me the log file. This confirms that you have not actually installed the new one. Not only that, you were not using the latest version before that (3.202). Check the version number in the first options page, look at the Log file. Regards, Pete

Yes, if the TQ6 is connected it seems to be sending messages to FSUIPC all the time, and this wrecks the timing of the rotary inputs. I've made a modification to FSUIPC which does correct this, but isn't released yet. I've also got a WideClient with it fixed too, but I take it you are using the GoFlight stuff on the FS PC? I am emailing you an interim version of FSUIPC with the TQ6 interference fixed. Regards, Pete

I've had a look. One shows a photorealistic texture with an airport and the FS airport graphic drawn on it in a slightly different position. The other seems to be okay, or else I'm not seeing straight. Both textures and the airports laid on them are scenery elements. This is not something than can be "corrected" at run time, whether via FSUIPC or anything else. It is a scenery data issue. You can try building your own airport to replace the default one, or see if someone else has done the same. Certainly many airports come with their own surrounding textures too, which could overlay the ones you are seeing -- maybe if you placed your photo scenery at a lower priority than the airport layer this would happen here. As an example of successful blends of photrealistic scenery by one third party with matching detailed airports by another, take a look at the UK VFR photo scenery in combination with Gary Summons' UK2000 airport series. It can be done, it just needs a bit of effort. Regards, Pete

FSUIPC has no influence on scenery files. I don't know what inaccuracies you are referring to, but all the scenery and the definitions of airport layout and facilities (AFD files) are part of the "BGL" data base which is scanned and indexed by FS on loading. In fact, with FS2004, you can't even change scenery whilst it's running, you have to reload FS after editing the scenery library. There are scenery design programs around, and you can edit the AFD files with AFCAD, so any errors you find can be corrected -- just not at run time. Maybe you can find some add-on scenery or AFD files to correct the errors you have found? Regards, Pete