Pete Dowson

That should be okay. If the Ipaq software can talk through it, so can GPSout. Sorry, I don't know any of that stuff. Maybe others have suggestions. There are some folks have used on a Palm PDA. I have a Palm, but it's USB. None. Pretty much all parts of FS need all the other parts. Although I assume your PDA uses "Pocket Windows" or "CE" or whatever it is called, even if it was 100% compatible with Windows98 or XP, which is unlikely, I don't suppose it sports 2 Gb disk space and at least 256 Mb main memory, does it? :wink: Regards, Pete

If it has a serial connection, you need a cable for it, and you need GPSout.dll installed in the FS Modules folder, configured appropriately (see the other post on this for now -- I'll update the GPSout read.me in due course). GPSout is one of the free modules available on http://www.schiratti.com/dowson. No: for that it would need to be Networked and have the folks at Project Magenta produce an Ipaq version of their CDU program, or something similar! Regards, Pete

Oh dear! This is going in circles. I know you said that. And I even gave you a line to try in the Aerosoft configuration. You then said it didn't work and gave no further information. Then you said it worked, but not exactly as you wanted. Please refer to this part of my message in response to that: Then, instead of doing as I asked and showing me the FSUIPC INI entry for the button, you confused matters entirely by saying you didn't even program the button in FSUIPC, here: So, IF you are using FSUIPC to assign the PTT function, I can help, but you have to actually read what I said and show me the FSUIPC INI details so I can program a latching button for you. If, as you said more recently, you are NOT using FSUIPC there is no point in continuing. No, there are no delay facilities. Either your button is the wrong type -- it is making only momentary contact -- or the Aerosoft program is at fault and reporting press/release on each press. Either way you'll need to latch the button and press it once for Talk and again to not talk. It seems to me more likely that you are using the wrong button type in the first place. If you want me to help program FSUIPC to make it work, please please please read what I say. Look for the file called FSUIPC.INI. In there you will find a [buttons... section, in which your button programming for this button will be found. I need to see that and I need to know what Joystick/Button number FSUIPC sees your button as, in the FSUIPC Buttons page, when you press it. I'm not going to repeat all this yet again. Please read things a little more carefully. This is getting quite exasperating. :( :( :( Pete greetings Mark

I don't have any details of paid registrations here. You'll need to send me both the registration emails (send to petedowson@btconnect.com) with a note saying which name/address you want to use. The email address should be a valid one, as the notification automatically goes to that one. When you get replacement details, if the name/address are different at all, you will need to delete the FSUIPC.KEY file from the FS Modules folder before loading FS. This will allow to to re-register from scratch. Regards, Pete P.S. I see now that you emailed this to me also, so you'll have two replies! :wink:

Did you look at the Advanced User's Guide, the section on Button programming and flags? I certainly am confusedif you are not assigning the functions for the button in FSUIPC, and you are not using FSUIPC, what has all this discussion been about? If you are using FSUIPC, and you did assign the buttons to "ptt on" when pressed and "ptt off" when released, in FSUIPC, then there will be entries in the FSUIPC.INI for it. That is where these assignments are stored, and that is what I asked you to show me IF, that is, you still want help working this out! Please tell me now whether all this is anything at all to do with FSUIPC. If not, then you don't really need my help, you need Aerosoft's! :( :( :( Pete

You'll need to be more specific. State which offsets you are reading, the length you are using (number of bytes) and what sort of variable you are reading them into. Use FSInterrogate so you can see how these things really behave. FSInterrogate is the main learning and checking tool. Always check what you are reading with what FSInterrogate is showing for the same values. It will help you understand it all better. The most likely things you are doing wrong are: 1. Reading only part of the total value, eg 1 byte for a 4 byte value. 2. Reading into the wrong data type and so seeing the wrong format. 3. Reading a smaller value into a larger data type (e.g. 1 byte into an Integer) without setting the Integer to zero beforehand to ensure the uninitialised parts aren't misleading you. Please check using FSInterrogate, and also use the FSUIPC IPC read logging so you can see exactly what your program is reading. Regards, Pete

Done. Pete

The value WHERE on the screen? What are you looking at that says it is going to 0%? Sorry, that is even more confusing. What is the difference between this "real throttle" and the one you referred to before? Do you have several throttles? Do you have both calibrated correctly, in Windows or whatever drivers you are using? I don't have a TQ6 or a "Sim-Yoke" (I've not heard of the latter, actually). FSUIPC does nothing with throttles unless you specifically ask it to. If you aren't sure what you've done, just delete your FSUIPC.INI file (or move it out of the FS Modules folder) so that the defaults are set. I don't think USB devices are any worse than Game Port devices -- excepting that I don't think you can normally unplug them and re-plug them in without restarting FS. At least, such hot-plugging has never worked here. I really have little idea about what your problem is. Maybe I can help you, or someone else here can, but you need to explain a little more carefully, please. Regards, Pete

Everything you need (except the VB6 compiler of course) is to be found in the FSUIPC SDK which you can get from http://www.schiratti.com/dowson. Regards, Pete

Thanks for the information. I'll add these details to the read me. Regards, Pete

Why don't you write to me direct then, if it has to be private? See the little "email" button down below? Try that. Regards, Pete

Ahso it DOES actually work!!! Are you keeping the button pressed in? Normal PTT buttons need the button held? Or is the button you connected perhaps a momentary contact one only? If you are using a momentary contact button, or you wish to press it once to talk then push it again to stop talking, you'll need to "latch" it. Instead of programming it in FSUIPC for "PTT on" on push and "PTT off" on release (as I assume you've done?) you'll need to program it by editing the FSUIPC.INI file, using a Flag to make FSUIPC remember the "toggle" state of the button. The same applies even if your button is not momentary, but the Aerosoft driver treats it as such (which would be odd) -- i.e. only reacting to "off->on" and not signalling "on->off". None, now that we know it is working. Check your use of the button, the type of button, and your current FSUIPC programming. You can read the relevant sections of the Advanced User's guide for FSUIPC to see how to use flags. If you want any help on that, show me the Buttons section (only) of your FSUIPC.INI file, and tell me the Joystick/Button number you are trying to program (you can read this in FSUIPC's Buttons programming page on screen). Regards, Pete

It's on its way. Regards, Pete

Yes, to find errors like that you need to log things around the area you suspect, so that you can eventually narrow down the place, in your program, from which the Windows error is occurring. Unless your program is multi-threaded (which can be a real nightmare to debug, believe me!), this should be reasonably easy. You can also write your own error trapper using standard Windows API calls. In recent versions of MSVC this is by using the __try{} and __except{} structures. They can trap access violations, et cetera. I'm afraid things don't really work like that. You need to think through the possibilities and lay the traps, step by step, narrowing it down till you find the cause. This can involve sending different test versions out to your users (the ones experiencing the problem) so that they can return you the information, which you can thereby gradually piece together. Regards, Pete

My AutoSave DLL is not payware, it is free. Why do you think otherwise?In fact most of my modules are still free. Even FSUIPC is free for freeware programs and costs nothing extra for many accredited commercial programs. And it certainly does no harm installed whether you pay for the extras in it or not. Sounds like you have removed some essential parts of FS, not just FSUIPC.DLL and AUTOSAVE.DLL. The module called "traffic.dll" is part of FS2002's built-in AI traffic software. There are no parts of FS nor any of my software that get installed in Windows folders. You are mixing up some wrong DLLs and probably making a bit of a mess. Sounds like you need to first uninstall FS properly then reinstall from scratch. You've probably made a mess of it. And if you've been deleting things in Windows\system32 you may even need to reinstall Windows as well. None of my modules are hard to install or remove. They are simply either in the FS modules folder, in which case they will load and work, or they are not, in which case they won't load and FS will run happily without. There's nothing simpler. Regards, Pete

It's accuracy seems to be in a little doubt, which I'm trying to get clarified (see thread "Paused when in menus"), but here's the proposed entry in the Programmer's Guide for offset 3365: Regards, Pete

Sorry, I've no idea -- but if it is over 24 hours I think you are supposed to press a "problem" button somewhere on the site. I suspect that the usual possibility is that, for some reason, the email containing the key(s) hasn't got through to you. There seems to be a lot of email rejection going on these days -- about 10% of the (legitimate) emails sent to me seem to come from addresses which reject my replies, even though they are from folks asking for help. It makes me feel quite useless at times. Best bet is to go to http://www.simmarket.com (assuming SimMarket is where you bought the registration from) and enter your account. If the keys have actually been sent to you already, they will be retrievable there. Regards, Pete

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