noodnik2

Your welcome; glad to contribute! :D In my experience, any language looks "long winded and complicated" until you learn it. :wink: How is it "long-winded" and "complicated", anyways? :? Since I learned C# (about a year ago), I enjoy coding in it over C, C++ and Java. The .NET API is very comprehensive, and is easy to learn and use in the provided IDE - it's really been a pleasure. The .NET API is responsible for much of the pleasure - gone are the unwieldy window handles and legacy apis (they're hidden); just a nice OO interface with logical names. 8) I characterize C# as taking the best features from C++ and Java. Of course, just as there are still valid reasons to code in assembly language (depending on the requirements), I consider C, C++ or Java to be superior to C# in certain contexts. I was blown away by the performance of C#, given its extra level of interpretation (it reminds me of my surprise at the speed of Turbo-Pascal, so many years ago). :P

Thanks, Pete - that did the trick! The extra debug output in your new module helped me to find the problem and fix it (I could see that FSUIPC was getting all zeroes from my app). For the benefit of the users of the C# library, I'll post the fix here (BTW - maybe this was already fixed in an updated version of the C# library somewhere that I didn't see??) The overload of the "FSUIPC_Write" method accepting a "ref byte[] param" (byte array) was broken (as you will quickly see); here is the faulty code that was at the end of the method: int idx; for ( idx = (Token + 4) ; i < (Token + dwSize + 3); i++) { IPC[idx] = param[idx]; //xfer byte array to IPC managed FifO buffer } ... and here's the replacement code that caused everything to start working: for (i= 0; i< dwSize; i++) { IPC[Token + 4 + i]= param[i] ; //xfer byte array to IPC managed FifO buffer }

Is there anything more to do for application registration beyond writing the 12 byte (or 13 byte, including terminating zero) ASCII keycode string to offset 0x8001? Also, should a log entry be created acknowledging this write's success (or failure)? I'm using the C# library which I've modified to write (and "Process") my registration key (13 bytes total - the 12 byte registration key and a single binary 0) to 0x8001 just after linking to the library, and here's what I get. 249569 Client Application: "fsrwintool" (Id=2136) 249569 C:\Marty\Play\FSR\Rev2\GpsVideo\fsrwintool\bin\Debug\fsrwintool.exe 249589 Product="fsrwintool" 249589 Company="Marty Ross" 295335 Illegal write attempt: offset 330A, size 4 295335Program not accredited for use with this unregistered FSUIPC The "Illegal write attempt" could be normal, since the library attempts to write its version number to the read-only offset 0x330A (however, this is expected behavior for the library, according to "FSUIPC For Programmers.doc"). But I've stepped through the code with a debugger and verified that my 13-byte registration information is being written (and processed) without any complaints from the module (as in no error code is returned and no log entry is made) before the failing write to 330A (and before any other writes). Note that it's during the "process" of this failing write that the FSUIPC dialog pops up complaining about the unregistered status of FSUIPC. Any ideas? If I can't get this to work soon, I'll probably just opt for the first documented method for registering my application:

Pete, I'm working on a program attempting to re-create an actual flight (recorded in a GPS track log) in the simulator (a "GPSin", if you will). My program currently does this by producing a MS Flight Video (.FSR) file which it then delivers to the simulator. This seems to work OK, but the playback is a bit choppy, and there are some other problems which I'm hoping to solve by using FSUIPC. Using the method you suggested above (e.g., "manipulating the six degrees of freedom" using FSUIPC), what can I expect in terms of performance? For instance, am I likely to see the smoothness I'm currently missing as the simulator "flies" through the LLAPBH values I set? How many values should I set per second for optimal performance (my underlying data stream typically represents one datum per second, but my program currently produces a linear transition for each parameter to achieve a desired "frame rate")? Also, I read something about needing to use "Slew" mode when setting LAT/LON in FSUIPC; this doesn't sound good - is this correct/any comments? I'm also thinking about new things that I could do given the ability to "read" environmental cues from the simulator (as I could do with FSUIPC). For example, if I can get windspeed and direction then I can more accurately calculate heading (e.g. crab into the wind). Or perhaps more importantly, I could avoid "ground encounters" and other anomalies I'm currently experiencing due to not knowing the altitude of the ground at the current LAT/LON position (such as taking off from several feet underneath a runway, or banking during taxiing turns). I'd appreciate any ideas from you about how I could best use FSUIPC to effect the best possible result for my purpose. And, thanks for all of your support and for the great bridge to MSFS! -- Marty

Pete, As you may remember, I'm working on a program attempting to re-create an actual flight (recorded in a GPS track log) in the simulator (a "GPSin", if you will). My program currently does this by producing a MS Flight Video (.FSR) file which it then delivers to the simulator. This seems to work OK, but the playback is a bit choppy, and there are some other problems which I'm hoping to solve by using FSUIPC. Using the method you suggested above (e.g., "manipulating the six degrees of freedom" using FSUIPC), what can I expect in terms of performance? For instance, can/will the simulator show a smooth transition as it "flies" through the LLAPBH values I set? How many values should I set per second for optimal performance (my underlying data stream typically represents one datum per second)? Also, I read something about needing to use "Slew" mode when setting LAT/LON; this doesn't sound good - any comments? I'm also thinking about new things that I could do given the ability to "read" environmental cues from the simulator (as I could do with FSUIPC). For example, if I can get windspeed and direction then I can more accurately calculate heading (e.g. crab into the wind). Or perhaps more importantly, I could avoid "ground encounters" and other anomalies I'm currently experiencing due to not knowing the altitude of the ground at the current LAT/LON position (such as taking off from several feet underneath a runway, or banking during taxiing turns). I'd appreciate any ideas from you about how I could best use FSUIPC to effect a great result for my purpose. And, thanks again for all of your support and for the great bridge to MSFS! -- Marty

Excuse me if I'm in left field here (perhaps I didn't understand the original question), but this seems to be related to my recent interest in the MSFS "Flight Video Recorder" functions, accessible through Microsoft's "Netpipes SDK". Netpipes is available from Microsoft, at: http://www.microsoft.com/games/flightsip#netpipes As I hinted, I've recently gained some good experience with this facility, and can attest that it works pretty well in both FS2002 and FS2004. I'm using it to play back an NMEA data stream (recorded in real life) as a Microsoft FS Video.

Does anyone out there have any experience using Microsoft's "Netpipes SDK"? If so, what did you use it for, and what were your experiences with it?

Pete, Thanks so much for the helpful feedback! Is there any diagnostic facility or other feedback from the sim available that I could use to help me to understand what it's doing with my Netpipes (FSR) data stream? I can only imagine that some sort of debugging "back door" was left behind, to be activated by some registry or .ini entry. Do you (or does anyone else) know of anything like this? I'm quite sure that the sim doesn't like something about my FSR stream and is for the most part ignoring it. It sure would be good to have a hint...

Hello, My main question is: does FSUIPC provide a method for controlling the motion of the simulator (e.g., control or "slew" inputs). If so, are there advantages for using it instead of the "FSR" (Flight Video) format that Microsoft provides (as documented in the "Netpipes SDK")? I'm also looking for advice/suggestions from anyone that could help me in my effort, which I describe below: I've been playing with the "FSR" format in order to get the simulator to "play back" a flight recorded on a GPS. I currently have a rudimentary translator from NMEA to FSR, but the simulator is behaving badly when fed these files -- there are many parameters I'm leaving out, and Microsoft even directly suggests this should be OK (e.g., the simulator will figure out appropriate values for the missing parameters). Perhaps needless to say, it's tedious to debug! All I have is the stream of time/coordinates/altitude. I can also get heading and speed from the GPS. I'd like to feed this info to the simulator and have it "fly" the course, with it doing as much of the work as it can (such as calculating the appropriate bank angle, engine settings, etc.) Again, Microsoft seems to imply that the simulator will do this, but the evidence doesn't show that. Perhaps I should use a pure "slew" mode (at least at first), since all I really want to do is to "play back" the GPS track, and have it realized in a visual way. Perhaps actually "flying" the track is not a reasonable goal. In any case, is there a way to access the "slew" mode internally? Could I control the time/lat/lon/alt/hdg by doing this? Thanks ahead for any useful feedback!