Landclass Assistant - Announcment

[John_Cillis 2,406]

Due to Pete Dowson's solicition of money for FSUIPC, my next version of Landclass Assistant (should it ever be released now) will not support the FSUIPC interface. See this thread in the MSFS forum.http://ftp.avsim.com/dcforum/DCForumID8/19368.htmlThis isn't a knock on Pete's contribution to the community, but the time to make FSUIPC payware would have been long ago, before practically every add-on to our hobby became dependent on it. I have invested much of my time in my code for LCA, adding the FSUIPC interface only in my most recent release. Although I could use the money (who couldn't), I have never considered making any of my efforts payware. FSUIPC was in part the inspiration for that. But it seems that now is time for Pete to solicit funds and indeed issue threats by proxy, and I will not associate any of my future software with his product, staying faithful to the spirit of freeware.-John

[Guest Richard Hill]

John;You are RIGHT ON! For one thing there are too many programs that require other programs that users have no knowledge of them. I for one downloaded your program to find that FSUIPC was required and new nothing of its use or if I would ever use it. From what I read probably not, so I have not tried LandClass Assistant although it is most likely what I an looking for. I also have installed Ground2K and the documentation has left me up in the air. I think in time more user friendly software will become available, to us less sklilled FS2K2 users. At present I am using TerraScene that works rather well but the file size is huge (about 5GB for my state) as custom textures must be used. With little to no knowledge of how I could transform them to FS2K2 and autogen texture, I will have to live with what I have at this time. I for one want to thank any and all Flight Simulator supporters, who have a love for FS2K2, take the large amount of time to make available toools for us. Without people like you even this froum would not exist let alone FS2K2. Richard;

[rhumbaflappy 113]

Hi John and Richard.I'd like to take this opportunity to remind everyone that they can send me all the money they want as donations. They won't get anything for it, but will have the satisfaction of making my life a bit more enjoyable.And I think we can figure a way to make those donations a tax writeoff as well.;)I wonder if Mr. Proudfoot would contribute?EDITED:On second thought, maybe everyone should just send me beer, so I don't spend the money foolishly.Dick:-beerchug

[Guest Joe]

Dick,I'll buy a round!http://myweb.cableone.net/joesumralliii/image007.gifYou guys sure do give allot of help here in this forum.Thanks!Joehttp://myweb.cableone.net/joesumralliii/hook5.gif

[rhumbaflappy 113]

Hi John.In a more serious vein...It does look like most of the info needed to read the current data state of the sim is available with the Netpipes SDK example.It involves several steps:1) get the window handle of the running flight simulator.2) create a link(?) that allows you to turn on the flight recorder function outside the sim itself.3) create a pipeline that actually replaces what would normally be the file that flight recorder would save to.You now would have a pipeline that is getting streaming state data from the sim. The remaining step would be to figure out where in the 4096 byte pipe buffer the desired data exists. There appears to be 2 types of data: aircraft and environment. From the Netpipes SDK, FlightRecorder.h:/* Properties name for the aircraft and enviroment objects are the same names as used by XML gauges. * They defined in "properties" document from the Panel SDK. * That document also defines possible unit names, such as "feet" or "knots". */That leads me to believe there should be a way to access the desired data from the pipeline by name... I'm sure the names would need to be defined as addresses in the outside program, but those addresses should exist somewhere ( probably in the gauges.h file ).Aircraft data depends on the CFG file of the aircraft... you can't get turbine engine data from a Cessna. :)But the enviroment data should be available for all situations.===========================I don't presume to know how to put all this together.. and each programming language would be slightly different. But, it's obvious a third-party resource, like FSUIPC, really isn't needed at all to read state data from the sim... or to write to it either! MS is basically telling us, in the Netpipes SDK, what their preferred method of InterProcess Comunication is... use the flight recorder function of the sim ( not some 3rd party dll )!If a few good examples of this method were developed, it would put FSUIPC quickly on the back burner. If a utility developer doesn't need a 3rd party DLL, then he wouldn't use it. Why be dependant on FSUIPC, if a few examples could show us how to directly read ( and write ) the data?Unfortunately MS didn't give us a simple example of accessing the state data in an external program from Visual Basic, or Delphi... that would have pretty much ended the monopoly of FSUIPC with the release of that SDK.================Like you, John, others are experimenting with interactively using the sim in scenery design tools. FSUIPC is a quick and easy solution for us. It's too bad it's future development now seems tied to the amount of voluntary donations that Dowson receives. It would have been much better for him to have simply stopped development of FSUIPC ( if he's tired of it ), and "open-sourced" his code, so someone could have developed the dlls for future versions of the sim. I have noted that he has not asked the sim community for programming assistance ( to help with the burden of coding and testing ).. but simply asked for money.In looking at the Delphi coding examples from the FSUIPC SDK, they reveal many snips of code that check for versions of the sim, and shut down FSUIPC access if a defined sim version isn't found. In fact, the FSUIPC.dll might not even work in FS2004 as it now exists! It's not FS2004's fault, but rather the "checking" routines inside FSUIPC that would prevent it from working. The older FS6IPC, that FSUIPC has replaced, will crash the sim if used... so that's probably why the checking routines are needed.==============It does appear that the flight recorder will continue be used in the sim... so maybe that's where we should think of going with our tools. MS certainly thinks that's what we should be using. That's why they delivered the SDK.As design toolmakers, we don't need the added functionality of FSUIPC.. joystick manipulation, or altering visiblility levels, "bug" fixes... We just want to get some realtime locational data into an external program... and the idea of "piping" the data from the flight recorder capability of the sim makes sense for this.This is another time I wish I had much better programming skills. :( I think a competant programmer that knows VB and Delphi could probably whip up a couple of examples of reading data externally, pretty quickly.Dick

[LuisFelizTirado 33]

In light of Dick's request, I would like to add my name to the list. Send money, beer, cigars, and anything else, and I solemnly promise not to contribute anything to the FS community.Best regards.Luis

[rhumbaflappy 113]

Hi Luis.I had forgot about the cigars... I will accept them as well. Dick@-@

[arno 1]

:-lol you guys are crazy (but I think the point behind it is clear thought).Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[John_Cillis 2,406]

I'll take a look at your suggestions.... If I can do it in VB, then I'll be able to exploit a new means of interfacing to FS.There was a great kit for FS2000, which had VB routines for interfacing with FS. I tried to use it with FS2002....no dice. In reality, once one knows the calling conventions, any FS DLL function should be accessible from VB. But that info is hard to come by and even harder to interpret.... I've called Windows GDI functions before, but the conventions are well documented. All MS has to do is come out with a similar kit for VB. Why they never have, when it is a language they sell and support, is beyond me. But I believe it has something to do with their reported efforts to do away with VB's implementation of pointers, and pushing of C++ and .net for working more closely with the O/S. -John

[rhumbaflappy 113]

Hi John.Where could I find a copy of those VB routines.. or the VB interface kit itself?Dick

[John_Cillis 2,406]

It's been years since I've seen the package. Having no more use for them, I long ago deleted the kit from my system. When I reflect on it, I actually believe it was FS98 which the kit supported, as I had one version of my Autoland utility which ran off of the routines.-John

[rhumbaflappy 113]

Hi John.Reviewing the Netpipes SDK, it appears a pipe isn't needed either.Get the FS window handle, use SendMessage to communicate:http://msdn.microsoft.com/library/default....SendMessage.aspThe message you send is WM_COPYDATA:http://msdn.microsoft.com/library/default....WM_COPYDATA.aspVBNET has a ton of stuff on 'SendMessage'... but almost nothing on 'interprocess' or 'WM_COPYDATA'.http://www.thescarms.com/vbasic/PassString.asp is interestinghttp://vbaccelerator.com/codelib/ssubtmr/startup.htm and so is this!Dick