Just to let you know I'm working on a new add-on module for FS2002 called FSConnect. It's basic purpose is to allow third party programs to "read" and "write" state information from/to FS2002, similar to FSUIPC. When and if I get it done, it will be released as freeware. My basic motivation is to have something to support my EZ-Landclass program, and other similar freeware programs (AFCAD and others) in case FSUIPC ever goes payware.I've got the reading part done. That was fairly simple - just a matter of using the pre-defined function calls in the Panels & Guages SDK. However, I've found that writing values into FS2002 is much more difficult. My first reading of the SDK had led me to believe that FS2002 provided a pointer to all data elements, but that turns out not to be the case. So I then began using a debugger to trace into the "lookup_var" routine, to try and determine the memory addresses myself. I found out where lat/lon is stored (that was my main priority), but found that writing new values to those addresses had no affect on the simulator. This has all given me a much greater respect for what Peter Dowson has accomplished with his program!So at this point, the program is not going any farther unless I can figure out how to write at least lat/lon values into FS2002. Anybody have any knowledge of this they want to share?Russ DirksPS: I know there are some people who think that Netpipes is the way to go for this, but I've spent a fair bit of time working with Netpipes, and found that it is basically of no use in it's current state. First of all, there is a bug either in the SDK or FS2002, whereby you cannot turn the "recording" mode off. Second, writing values into FS2002 is accomplished by putting FS2002 into "playback" mode, which causes a visual indicator to appear on the user's screen. When you turn playback off, a full or partial reload occurs (ie. AI, and possibly textures). For these reasons, I am of the opinion that Netpipes is an unworkable solution.

Sorry Russ.No knowledge on that subject from my side. But I do want to commend you on your undertaking, I feel an option is needed, so thank you very much for your efforts, be sure they are appreciated.I'd also like to tell you to post all questions you may have, for even though I am not able to shine any light on this one, I might be able to provide help on others, and I'd love that.

I know if you can at least read lat and lon, that'd be a bonus for Landclass Assistant, since I don't write those values. But how would you deliver the data to an app like VB? I'd be happy to beta test what you have already with LCA....As for writing values, I'd take a look again at Pete's SDK for FSUIPC if you haven't already... That may yield a clue....-John

>I know if you can at least read lat and lon, that'd be a>bonus for Landclass Assistant, since I don't write those>values. But how would you deliver the data to an app like VB?I've got it set up to use a feature called global atoms, which is basically a very simple way to pass strings between programs. The data is encoded in the string.I'll let you all know if I make any more progress.Russ

Your work is very much appreciated from my perspective. Definite hats off to you. It is very much adding the icing to the cake so to speak with my scenery work. One problem though, I am messing with the landclass stuff more than actually doing the scenery work now. LOL. Keep up the great work sir!

Hi Russ.I'm glad you're still working on this. :)As John has indicated, there is a good use for reading state data with scenery design programs. Latitude, longitude, ground altitude, are the big three. I don't believe anyone has figured out how to derive the current landclass/waterclass... the sim knows the value, but we don't know where that info is hiding. Other data like season and region are also hiding.I don't think there is anything inherently wrong with anonymous or named pipes, but the FS example is misleading in that it concentrates on using the flight recorder, instead of the gauge data.I believe FSUIPC is able to write data, because Peter Dowson has found the memory offsets.. which change from version to version. That's part of the large amount of work Peter has refered to, and which has him contemplating a payware version for FS2004.As far as gauges, aren't they basically DLLs that have been renamed as *.gau? I don't know if that's helpful or not. :(Dick

Dear Russ,you are on the right way. The next would be to debug these offsets to find out from where they are set. You will find the right offset.I know which offset you found and I know you found it in the g*****.dll .You can write values into this offsets, but the FS only reads it out if you set the data while beeing in "Slew mode".Regards,Marcel Burrchief programming departmentbluesky software development

AWESOME!!! I GOT IT WORKING!!!Thank-you so much, Marcel!Stay tuned ...Russ Dirks