lordofwings

Have not tried that yet but at least with a flight plan it does.

That is correct thanks! apparently the information was there in one of the many asterisks. Thanks a lot. Although I really don't see what was so difficult about just outputing L/R/C/W instead of a number. It is only about 6 lines of code.

I was thinking of using the data generated by the excellent tool MakeRunways but found a few problems. The documentation says that the runway information included in R5.CSV has the runway number followed by L|R|C|W (what is the W for?). When I look in the 2nd field (after the ICAO code) there are four digits rather than the usual 2 digit+letter runway code. The number is the actual runway heading in 4 digit format. The problems are: 1. There is no L|R|W|C indicator. 2. Shows as runways with separate headings. For example, I took MPTO which has 03L and 03R but they are listed as 0031 and 0032 when these are actually 31L and 32R respectively. Just for checking I went to check Sydney which also has two parallel runways 16L and 16R. I noticed this happens for all the runways.

Actually the simplest way is to make use of the FSUIPC GPS offsets. There you can see the properties of the previous and next waypoints. In this case the waypoint you are flying to would be the Next waypoint offset. This would work in the majority of circumstances except when: 1. There is no GPS on the aircraft

Is it possible that an application, via FSUIPC can force the flight simulator to read a specific flight plan file. That provided one gives the fully qualified name of the .PLN file of course. I have the SDK (3.7) but can't find anything about the "Controls" mentioned in one of the offsets.

Hi Paul, Thanks a LOT for that detailed explanation about the ill-named Disconnect. I guess next release might be a good thing to give it a more appropriate name (but that is up to you); nevertheless I do understand the situation as many years ago (when I was into open software) I also had an ill-named application name LOL. Anyway the explanation was clear and fantastic, I appreciate it and sorry if I ask too many questions it is just that I am working full time on this app. so I come across these things. Following your suggestion of some days ago I refactored and grouped within the classes but was thinking of having a finer detail of control by disconnecting offsets. So far there I am ok, I will just need to change the other things where I was 'disconnecting' groups that may/could be used later on. Well, it is clear now. Thanks a million and keep up the good work. Enjoy those holidays, I should be doing that too!

One of the wonderful things about the Offset generics implementation is that you can Disconnect() and Reconnect() offsets individually. It is alsco cool that the main class has a DisconnectGroup() method which comes quite handy when you have classified your offsets (as I did) and need to control them in groups. Unfortunately I seem to miss the obvious counterpart: ReconnectGroup() because some times you need to reconnect a group as a whole rather than going through each of the offsets programmatically. I think this would be a nice addition to the next version (when is it coming out?) and should not be difficult to implement as you already have the DisconnectGroup() which simply iterates through the whole list and operates on the offsets matching that group.

When I use the xxx notation as you may have noticed, is when I refer to a range. Or for that matter a generic range, ie. 0x3xxx means 0x3000 to 0x3999 in case that was not clear. The Programmer's guide indeed lists the alternator -don't know why when I searched for it it did not come up-. However, it does not have an "OK" in the FS2004 column so I guess no use trying to use that as I am not interested in compatibility with prehistoric products (FS2002 and older). May I ask what is the purpose of listing so many offsets with "NOT FSUIPC SUPPORTED" ? it is like saying "Candy does exist but you can't have it" LOL. I must say there is a lot of interesting stuff in that category.

I just noticed that some variables appear to be duplicated. I thought perhaps one was for older FS versions and the other not but I see no such remark. This applies at least to the Master Battery and Master Avionics switches. They are defined with offsets in both the 0x2xxx and 0x3xxx (as an example). Which would be the most reliable to use in such cases? And some others such as the Master Alternator Switch is defined in the 0x3xxx offset range, it appears in FSInterrogator but does not appear listed in the Programmer's Guide. Would that mean it is not really available in FS2004? or perhaps even FSX?

Sorry, typo error what I meant was that I could read (via trick) the departure airport but that the dest. airport which was directly accessible was returning an empty string. As for the rest of your post, you are right I just looked in the Programmer's guide and it is marked as you wrote. I guess it no longer works in FS2004 which is very sad. The thing is that I have mostly been using the FSInterrogator which is pretty handy (with a few shortcomings) but now as I see it is not totally in-sync with the documentation you provide. I guess the Danish (?) guy has some work to do :)

Nope, I meant that I cannot read the "Destination Airport ID string" that is supposedly directly accessible via the indicated FSUIPC offset. The departure airport is not directly accessible but I was mentioning how I managed to get such information from FSUIPC provided the aircraft is still in its departure airport. The destination however, which is accessible via the published offset, returns "" even when a full flight plan has been entered and loaded.

Yup, flight plan has already been filed. I can see the other data such as ETE, estimated fuel burn, destination airport ID (Prev WP ID when on departure airport).

While I am not having a problem with other offsets I use, this one is failing: Offset: 0x6137 Name: FS2004 GPS Destination airport ID Length: 5 bytes It simply reads 0x00 both on my app as well as with FSInterrogator

Actually I just found a way to do it :-) If the aicraft is still at the gate or runway of the departure airport this information can easily be obtained by reading the offset named "FS2004 GPS Previous WP ID string" which nicely returns a string with the ICAO code.

Pretty much says it, how do I go about finding out the ICAO code of the departure airport with FSUIPC? I scanned all the GPS offsets but only saw destination airport and prev/next waypoint. And to kill both birds with the same stone (if I aim right), is there a way to find out (or derive from somewhere) whether the a/c is at the gate ?

I noticed that your Offsets are internally indexed in FSUIPConnection using their address. At least in my add-on experiment I have run into situations in which I have two classes monitoring the same offset but that gives problems with an exception saying there is already an entry with that offset. That because I don't like to group all things into just one class but rather divide it in logical groups, some of which sometimes overlap slightly. What I try to do is to define the offset do the operation and if I no longer need it (until it gets needed again for some reason) to disconnect the group. Anyway, thought that might make it easier.

I see, I was thinking that perhaps FS passenger had achieved this by making itself a panel gauge in each of the planes that are delivered with it but I guess I was wrong. Any idea where I can get info about how to make a DLL application that can run as part of FS? I write my progs in C# so I wonder if that would be possible given FS is not a managed application.

I am writing my first add-on for FS in C# (.NET). I have gotten to the point that I can declare a hot key as well as a menu entry. I see my menu entry appear under Modules and for what I notice both the key and the menu activation are detected. Basically I poll the Menu and Hot Keys and then my programmed classes raise an event (callback) whenever any of these two are detected. I start my application outside FS because I do not know how you can start it from within FS (such as IvAp does). What I wanted was that when my entry in the Modules Menu is activated, that my application would pop up on top of the current view/panel just the same way IvAp or FsPassenger do. So my app. gets called back when the menu activation is detected and the application sets focus on itself but it never pops up on top of flight simulator. I guess it is because the app itself gets focus within itself but not within the desktop (of which FS is currently the owner of the desktop focus). Can anybody enlighten me how this can be done? I see for example that FSPassengers (I have a demo only) automatically starts whenever you startup FS.

Thanks for the info, I had indeed declared it as a byte array as I was not sure if a string was going to be handled ok. Made the necessary correction for it to work as byte array but I will change it to string as soon as I get the time.

No, I thought an IsConnected property would be enough and one handles the connection if it is not connected (returns false). But I must admit I also thought that the application could subscribe to an OnConnectionLost or OnDisconnect event in order to handle a) a reconnection or b) exit when it is done. I have not checked Pete's 4.x SDK so I do not know if it is there. What I would expect is that given that FSUIPC supports it, that the enumeration in the 3.x SDK would also have it if it were possible for any FSUIPC client to connect as I understand it is possible. Pfrew! good thing I asked. Time to start putting those Process() where they are missing. As a matter of fact yes, I started FS9 and then my client and I noticed that even after the plane was at the gate during the first trials it would fail to connect to FS9. Also, I think I might have encountered a bug. I was trying to add a menu entry by writing to offset 0x2fe0, as you know the entry has a maximum of 32 bytes. I tried to write a shorter string (11 bytes) and I got an overflow exception as shown below. Apparently one must write the entire block. And finally another request :-) Perhaps it would be okay to add an Offset for uint[] or int[]. For example the hot slots is an array of DWORD (Int32 in .NET). I tried it but it gave me an exception so I had to work around it by using a raw array of bytes.

Hi Phenti, As I mentioned b4 I scrapped out my previous add-on attempt which was based on the "standard" .NET FSUIPC library delivered in the SDK. The suggestions and questions are are for the Phenti .NET client only, not for the C# SDK that comes with FSUIPC. Given that I was up to a restart I decided to try your .NET client and am very pleased with its level of abstraction. Here are some comments, suggestions and questions (yup, I read the document): 1. A IsConnected property in the FSUIPCConnection class would be handy rather than having to wait to do a Process and then catch an exception. 2. Did you test it with FSUIPC 4.x active or just 3.7x? I know FSUIPC works with both FS9 and FSX but I wonder if your client (.NET Client) actually connects if it finds an FSUIPC running under FSX. This I ask because FSX is not listed in the connection enumeration. For what I understand it should be no problem but I wonder anyway. 3. The document says that when you define an Offset with the WriteOnly attribute, that the item is automatically written/sent to FSUIPC as soon as you set the offset.Value member without having to do Process(). My question is, does the same happen if the Offset is Read/Write ? or must one in that case explicitely call Process() for the .Value to be sent? At least that is what I am assuming so far. Good work mate!

Well I read it and that is how I understood it. I read both separate sections but to me that simply looked like contradicting information because I did not read anything that you mention in the previous post that "it makes it a menu reference" and that "they are separate slots". Remember, one thing is what the documentation says as interpreted by the one that wrote it, and another one might be what others interpret. Sorry for me being so much into precise, unambiguous information. I guess it would help to state those things in the document as it would not hurt anybody ;-) Thanks for the info.

Hi Pete, Thanks for the info. The document in question was indeed not in the FSUIPC SDK I downloaded but in the FSUIPC that got installed on my system when I installed IvAp. However, I do have another question. When I read the document it tells that to configure the hotkey I have to write those 4 bytes in the free slot. That is ok. It also says the first byte is the "virtual key code" , the 2nd the "shift modifiers" and so on. But then on the document describing the Modules Menu (Programmer's Guide) it starts saying I have to write 0xFF to the first byte of the hotkey slot I am using. That would mean that the "virtual keycode" settings are then overwritten. Or am I missing something?

I am trying to get the hot key and menu working but have run into a stumble block. According to the Programmer's Guide (FSUIPC) I can read the number of slots, that is clear. Then afterwards one must write the assigned hotkey to the slot. But then it goes about talking about the virtual keycodes but refers to a document that I cannot find in the SDK, something about an Advanced Users guide or so. I found the Controls document but has nothing about virtual keycodes. For example I want to use Ctrl+Shift+F for my hot key entry, what would that keycode be?

Ok, good to know I don't have to step down to C++ to get my add-on working. As for the rest after weeks of work I came to the hard decision of sending my add-on project to the scrap yard. Just too many established versions out there with similar functionality. Started a new one, this time using this particular object oriented .NET FSUIPC SDK as the original one was well, procedure oriented. My question now is... If FSX is running with FSUIPC 4.x, would this SDK be able to connect? I would like a generic way to say "connect to any" (as in the old) and get a connection regardless of whether it is FS9 or FSX. I don't care about older versions.