NetPipes and current aircraft position

[Guest rogue1]

I'd like to use NetPipes for a freeware VB program that would only need to retrieve the latitude and longitude of the current aircraft position. I'm reluctant to use FSUIPC, due to the uncertainty of it's availablility and potential cost. Anyone have any pointers.Can I use gps_export.dll? If so, can someone point to the methods that it exposes and the proper way to interface from VB?I'll continue to review the NetPipes SDK and if I find something that answers my questions, I'll post it here.TIA...Jim

[John_Cillis 2,406]

I've been struggling with the same issues, and have the same desire--I initially would just like to get lat/lon from the sim. But from what I can see, the variables netpipes can capture are limited, and VB support and documentation....well, let's say it's not an SDK in my eyes, as a good one should be flush with examples in the languages Microsoft supports. I guess they consider VB an orphan stepchild.Sadly, I am not much of a hacker into dll calling conventions. Give me a good piece of sample code, and I can do it as I did with FSUIPC's SDK.For what it's worth, remember that FSUIPC will at least be available for FS2002, and there's no way Pete D. can go back to the thousands of users and dozens of freeware developers asking for some form of payment--not on past versions, anyway. We may just stumble into dumb luck and find that Pete's work does work for FS2004. His VB SDK works magic in FS--I coded Autoland 2002 (for aircraft) and Landclass Assistant (for scenery design) with it. If you're coding for FS2004, you're in the same boat Pete is in--one of the reasons I think he's looking for compensation for his work, as it is a costly (in terms of time) process to get the information from Microsoft needed to code something as complex as an interface.

[Guest rogue1]

I doubt it will work in FS2004. I'm trying to develop something for the FSGarmin's to retrieve weather maps from the web. I am really hoping that someone has information related to gps_export.dll. Just based on the name, that one has to have the lat/lon information. Jim

[Guest]

Hi there,Why do you not just create a gauge (or a module if you do not want to include the gauge in every aircraft) which exports the LAT/LON position? The gauge will work in FS2004, for sure.

[Guest Fabio Miguez]

Hello all.I think their problem, Marcel, is where to get that data.

[John_Cillis 2,406]

I revisited the netpipes SDK last night. Problem is, it is designed around C, and I've coded less than a thousand lines of C in my lifetime, and that was over ten years ago.What I did read that may be of help, is that the conventions used in the Netpipes SDK can be used to call up any variable that can be accessed via the Panel and Gauges SDK. That should allow you access to lat/lon. As to calling this all up in VB, that's more of a challenge. I have a zip file from someone who played around with netpipes in VBScript, but I haven't tried it, and I can't vouch for how it works, whether it works, etc....If you want it, email me at jcillis.nospamx@hotmail.com (remove the ".nospamx" when sending the email).... Put "VB Netpipes" in the subject, as I use aggressive spam filtering on that account....-John

[Guest]

I did a fair bit of work with Netpipes about a month ago, porting it all over to VB. The only problem is, there is a significant bug in Netpipes which renders it pretty much useless. The gist of it is, you first send a message to FS to tell it to start sending data to the pipe, you collect data from the pipe, and then you send a message to FS telling it to stop sending data. The bug is, FS does not respond to the "Stop" message. I can give you what I've got, and maybe you can have more success with it than I. I've got a Yahoo account set up for EZ-Landclass, so just use that account to send me a message and I'll send you what I've got. Send to "ezlc_feedback.noXspam.@yahoo.ca"Russel Dirks

[John_Cillis 2,406]

Hey Russel!I think it's actually a copy of your work that I have zipped up.... I saw it referenced in a thread.The problem with the SDK is it wasn't written for the casual user to learn how to interface with FS. It is the worst piece of documentation I've ever seen, but I'll preface that by saying a large part of my work is writing end-user documentation for rollouts done on my WAN.I suspect the bug is with the documentation, vs. the actual interface. MS throws out so many teasers, such as the reference to pulling data from the panel and gauges interface. But they don't show us how in the major languages they support. Personally, I think Microsoft bundled this together and called it a SDK just to have something to blab about.... It just doesn't compare to the SDK Pete wrote for FSUIPC. I was coding off of that within minutes. Microsoft could have done the same thing, even building the interface libraries and function calls for us. One include in VB, and one could read the latitude with a simple read_lat function call. That's exactly what my FSUIPC code looks like for Landclass Assistant and Autoland... I built all the calls I needed in an include file, so that I could read/edit what I did later without having to remember the nuts & bolts. BTW...thank you so much for your mention of LCA in your documentation. Moreover, your explanation of the 257x257 grid matrix is the clearest I've seen. If I can import lat/lon via Netpipes, I may upgrade LCA to support the more accurate 257x257 format...-John

[Guest]

>I doubt it will work in FS2004. I'm trying to develop>something for the FSGarmin's to retrieve weather maps from the>web. Marcel had the right idea... simply write a small C++ gauge that does nothing more than read the a_variable(s) for lat/lon and then writes them to a simple text file every x number of seconds (say, every 30 seconds or so)...Then, use your VB routine to read the lat/lon from that same text file.K.I.S.S. principle in action! :)BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://mtco.com/~rsam/fartslogo.jpg

[Guest]

You wouldn't happen to know if there is any publicly available information on how to create a module within FS, would you? I'm thinking in terms of a replacement to FSUIPC.Russel Dirks

[John_Cillis 2,406]

Check your email... I found something which might serve as a start, at least....-John

[Guest A_Delta_Sierra]

Here is what the Lon/Lat data is going to be used for. :-)http://mtco.com/~rsam/WxOnGarmin.JPGI can jam the map NEXRAD Radar data into the Garmin folder and then update the Garmin and everything works great. So, yes, the free Garmin 530 will be/is able to show real time NEXRAD Radar images. Jim is making it so it does it w/o user intervention. ;-) we need help calibrating the 150 plus maps for the system, when you are all finished here, Visit the "FSFlightMax and FSGarmin forum" here on AVSIM to catch up on the latest new develpments and lend a hand if you have time. Can't pay much, but you will be contributing to your fun and the fun of others in using these two great instruments.Here is a direct link to the forum.http://forums.avsim.com/dcboard.php?az=show_topics&forum=178If you haven't downloaded the FSGarmin and FSFlightMax and would like to get into the REAL WEATHER RADAR returns, download them and come on over and visit. This feature is about as real as it can get without having the Garmin in a real aircraft.Once again, drop in and look what the FSGarmin is going to be like shortly. Ramble along with us so we can get what you, THE customer, would like to see. Post your comments either here, or in the FSGarmin forum.Best Regards,Bob.. PS I made a quick xml gauge the other night that displayed these NEXRAD Radar images, but when I "jamed" in an updated image using the same file location and folder as the first image that had loaded into FS I got, as expected, a file sharing error and could not overwrite it. The needed image is only 375k so no real stutter is seen when it loads. I had two images, slightly different and had them toggle back and forth without any load time problems on my computer.Any ideas why FS takes complete control of the image file when it is used in a guage? Figure out how we can get around that one and you can build your own NEXRAD Radar gauge with a "surround" fitting the application. Haven't seen many Garmins and flightmax instruments in the new 777 or A340.

[Guest]

>Any ideas why FS takes complete control of the image file when>it is used in a guage? Figure out how we can get around that>one and you can build your own NEXRAD Radar gauge with a>"surround" fitting the application. Haven't seen many Garmins>and flightmax instruments in the new 777 or A340.That's a simple question to answer. FS2k2 loads the gauge bitmaps into memory for faster usage, but also places a lock on the filename. Perhaps using the 'reload' function will be helpful:(>K:RELOAD_PANELS)BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://mtco.com/~rsam/fartslogo.jpg

[Guest A_Delta_Sierra]

Bill said to Bob:"That's a simple question to answer. FS2k2 loads the gauge bitmaps into memory for faster usage, but also places a lock on the filename. Perhaps using the 'reload' function will be helpful:"Yes, I feared, and I tested jamimg (overwriting) a new image and it wouldn't work. I just wondered why they put the lock on the image file. The FSGarmin software doesn't lock the file when it loads it into memory. I guess being good programers, they didn't want anyone changing the data while they were using it. After all they might want to write to the file. Old - good habits. But not in this case. ;-( If I would use the reload function, I would have to time the external program to exactly take advantage of this time slot. Can do it continous, because the external program when it can't update the file, crashes to a blue screen that requires a c/r to exit. Maybe the external program needs to ignore the locked file flag and just keep banging away and then when the reload is issued, it slips the new file in. But won't the reload generate a noticeable stutter? This is more rambling .. on old times with a couple of questions.I guess what would work, in olden times, would be a direct write to the disk. All of the image files are the same size byte wise. So if the Vbasic external program that gets the image, converts it to the a bmp, and then, if it know the exact location on the hard drive(cylinder,sector,track ...) where the previous image was stored it could rewrite the data and avoid the file sharing error? Are programs still allowed to direct access the hard drive like this? They could in old times. Yes, I know, a bad practice, but a man has to do what a man has to do. :-)Regards,Bob

[Guest]

>I guess being good>programers, they didn't want anyone changing the data while>they were using it. After all they might want to write to the>file. Old - good habits. But not in this case. ;-( If FS is using the Windows file lock, there should be a way to 'unlock' the file. Unfortunately, I've forgotten most of what I used to know, so couldn't say exactly how that could be implemented.>Maybe the external program needs to ignore the>locked file flag and just keep banging away and then when the>reload is issued, it slips the new file in. But won't the>reload generate a noticeable stutter? You would have to put a timer on the reload command for every x minutes. Depending on how "gauge heavy" the panel is, there could be a several second delay while all the gauge code is reinitialized and updated. The only thing you would notice is no sound and an hourglass during the process... :(BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://mtco.com/~rsam/fartslogo.jpg