Anybody want to help me get NetPipes working?

[Guest]

I'm looking for some programmers to help me develop some working demos of the NetPipes SDK, in VB and C. I've been reading the discussions regarding FSUIPC, and I got inspired to see if I could get NetPipes to work. If successful, I intend to release them as freeware. I found the example provided in the SDK needlessly complex, and I simply couldn't get it working. (More on that below). So I trimmed it down to something really simple, but am having some problems.My trimmed down demo runs as follows : (see attachments) - create the pipe - tell FS to start recording - capture the data for awhile (no interpreting yet) - tell FS to stop recordingThe problem I am having is that FS seems to ignore the request to stop recording. There may be a bug in the SDK, or I just haven't figured out the right way to do it. That's where I'm looking for help. I've provided my demo program in C and VB, and I invite people to have a look at them, and see if we can get this thing working.The Official SDK ExampleHere's what I've been able to figure out. It can operate as a "server", where it puts FS in record mode, captures the data using the pipe, and sends it to some undefined third party (presumably over a network), using WinSock. It can also operate as a "client" where it receives data using Winsock, and feeds it to FS in playback mode over the pipe. I guess the idea is that you would have FS and the program in server mode on one computer, and FS and the program in client mode on another computer, and the two versions of FS would be slaved together. I couldn't figure out how to get that all working, though.The one pertinent point, though, is that when in "server" mode, it enters a loop where it reads data from FS, and sends it to the client. What I don't get is that the loop is set to terminate when it gets zero bytes back from FS on a pipe read. I don't see how that could ever happen. Anybody have any better understanding of that?Hope to hear from some of you!Russ Dirkshttp://forums.avsim.com/user_files/3164.zip

[rhumbaflappy 113]

Hi Russ.A noble task you have undertaken."The problem I am having is that FS seems to ignore the request to stop recording. "I noted in the VB code:Sub StopRecording() Dim hWnd As Long Dim ExcelhWnd As Long Dim cpdata As COPYDATASTRUCT hWnd = FindWindowByClass("FS98MAIN", 0&) cpdata.dwData = STOP_VIDEO_RECORDING cpdata.lpData = 0 cpdata.cbData = 0 ExcelhWnd = FindWindowByCaption(0&, Application.Caption) SendMessage hWnd, WM_COPYDATA, ExcelhWnd, cpdataEnd SubI think the pipename and the length +1 needs to be filled in here, or it won't turn off (?)... it's the only thing I can think of.Dick

[jcboliveira 1]

Try this:Put char MagicName[sizeof (sFSHandleMagic)+8+8+1];as globalthen on StopRecording () cpdata.dwData = LET_STOP_VIDEO_RECORDING; cpdata.lpData = const_cast(MagicName); cpdata.cbData = strlen (MagicName) + 1;Jos

[ronzie 21]

Try this forum. There are already discussions here.http://www.schiratti.com/dowson.htmlThis is Peter Dowson's FSUIPC forum. While you may not wish to use his SDK, this may be where you can get the attention of other programmers.

[Guest]

Thanks guys for the suggestions. Actually I had already thought of that and tried it, but FS still ignores the Stop request. I tried it again though just to be sure. The example given in the SDK has those fields set to zero as well. I think we need some input from Microsoft here!Maybe I'll leave this for now and start working on parsing the incoming data, or maybe work on the playback aspect.Just as an observation regarding Netpipes vs FSUIPC, I've noticed that while Netpipes allows you to "write" a large number of values into FS, it limits you quite significantly when "reading". About all you can get out of FS is what the aircraft is doing in 3D space (position, speed, pitch, etc), and the position of the major flight controls. From what I can tell, you cannot, for instance, read the value in the autopilot altitude select, or read what the OBS indicator is set at. Russ

[Guest]

Thanks for the tip.

[John_Cillis 2,406]

"About all you can get out of FS is what the aircraft is doing in 3D space (position, speed, pitch, etc), and the position of the major flight controls. From what I can tell, you cannot, for instance, read the value in the autopilot altitude select, or read what the OBS indicator is set at."That's one of the reasons I've about given up on the Netpipes SDK. Although it may support my Landclass Assistant project, it won't support my other project--Autoland 2002.What's frustrating is some people have the answers, either through reverse engineering of FS, or through inside info. If FSUIPC can read state data, so can any other app, whether it be in VB or C++. I'd love to tune my programs so they can read FS directly, as it'd be far easier to maintain them.BTW, the VB dev kit I've referenced in other posts was designed for FS98. There was a kit which allowed direct reading of 98's state data from within VB code. Sad to say, that kit no longer worked under FS2000. FSUIPC literally "saved the day" with its VB SDK.-John

[rhumbaflappy 113]

I'm not sure why you believe you could not get values out of FS. If the original netpipes program can actually recreate a flight in realtime over a network, it obviously is reading all the data needed.Dick

[John_Cillis 2,406]

I don't believe it's reading all the variables, such as A/P flags and values. Autoland relies on those to function. I saw no reference to being able to read these in the SDK, althought I might have missed it.-John

[Guest]

I think you're right John. Here's the relevant quote from the SDK:...an external data stream can drive Flight Simulator using any of the properties defined in the Panels and Gauges SDK. That list has hundreds of data elements.This section describes the data saved by flight

[rhumbaflappy 113]

Hi all.I think I also understand now. Apparently we can only read the data provided by the video recorder... although it appears we can write the full set of data elements to the sim, somehow. Limited read, unlimited write?Dick

[Guest]

One point that seems important and may be interpreted as part of the problem here, each "packet" of data doesn't send the entire state data... Only the changed data from the previous packet. If one of the "opening" packets is missed in some way, a whole swath of state data may be missed.May not be the "missing" data talked about here, but worth keeping in mind.Take care,Elrond ---Not enough bandwidth to display this signature! Don't reformat hard drive? (y/N)