FSUIPC Client DLL for .NET - Version 2.0

[Graham Pollitt]

OK I think I need some help now :?

As I mention on an earlier post it is fairly straightforward to obtain the 4 lat/long for each corner of the runway when it is at 0degrees (straightup). What I have been doing this morning is drawing the rectangle at 0degree position to obtain the 4 lat/long corners then thought it would be a case of rotating the BR, TL and TR corners x amount of degrees

ie if the runway is 340 degree heading then I would need to offset those 3 corners to 340 degrees leaving the bottom left corner as is due to this being a rotation point.

I know the middle position point at the bottom of the runway so I divide the width by 2 and add/subtract this to the middle position.

I also know the point in the middle of the runway so I subtract the bottom point from the middle, double it and add it to the bottom to give me the length.

I can then get my 4 lat/long corner points for the rectangle.

BUT I now have a similar problem to my original one a few weeks ago with rotating these points x amount of degrees.

I dont know how to convert ft into lat/long format so I am unable to properly find the width etc

Any ideas please? Am I looking at this in the correct way?

thanks

[Paul Henty]

Hi,

Well the widths coming in in feet does add a bit of complication. The conversion from feet (or metres) to latitude is complicated by the fact that as you get closer the the poles, a degree of latitude represents fewer and fewer feet (or metres).

There is a set formula for calculating this though. However, you then have to take into account how much of that you use and how much of the longitude you use. This of course depends on the heading.

For example for a 36 runway the 'width' is all latitude. For a 27 runway it's all longitude.

I think the best thing here would be to leave your program working off the four corner coordinates and have another program work these out from the runway data (I assume you're going to do some kind of import program anyway).

Doing it this way would make the calculations at runtime faster as most of the complicated stuff would have been done during the import.

I can probably get you a routine that works out the corners from the info you get from makerunways in a few days. I'll just need to find my maths hat.

If this sounds like a plan I need to know exactly what data you have to work with from the makerunways program. I assume it's something like lon/lat of centre of the threshold, length, width, heading.

What would also be helpful is if you could give me the four corners AND the make runways data for a few of your working airports. Then I have something to test against.

Paul

[CptnYesterday]

Hi Paul,

first of all let me say thank you for this great .dll. It helped me pulling out the necessary data I need to get from FS 2k2 so far.

There's only one problem left, which I can't seem to solve all by myself.

I want to get the x,y,z acceleration data from FS to feed these back into a motion platform for a flightsimulator. According to the FSUIPC documentation the offset values for those are:

31C0 //x acc

31C8 //y acc

31D0 //z acc

And these seem to be the right offset values.

Furthermore the data format should be FLOAT64 and the fs units should be in ft/sec/sec.

Here is what i do to get the data:

...

Offset xAccFS = new Offset(0x31C0)

...

double xAccel = ((double)xAccFS.Value);

this.txtXAcc.Text = xAccel.ToString("f1");

...

Ok, so far so good. The data I get seems to be right since when I turn the plane left/right it changes the sign. But the values are somewhat crooked since they are really high...

Maybe you are laughing because this is most certainly a really stupid question, but how can I convert these values so the make sense? Am I missing a conversation there? Or is the "long" type not what i want to use?

Thank you very much,

Philipp

[Pete Dowson]

Right I've found the width!

I was looking at the very end of the line at stated in the readme, which in most cases is 0. It is sandwiched in the middle of the line.

KSEA,0341,47.437584,-122.311058,429,340.300,9550,111.70,150,19.700,47.450684,-122.311058,0

Apologies! It was at the end of the line when it was first added and the ReadMe updated, but of course there are other things added after. I'll amend the ReadMe!

Pete

[Pete Dowson]

Am I missing a conversation there? Or is the "long" type not what i want to use?

I don't understand the code at all (not my area), but in C/C++ "long" is certainly not usable for receiving a "double" as, even if it doesn't get "converted", a double is 64 bits long and a long is only 32 bits. In C/C++ you'd read 8 bytes from the quoted offsets directly into a double.

Regards

Pete

[CptnYesterday]

Hey Peter,

thank you for your help! Looks like I only had to change the type from "long" to "double". The values displayd now seem to look ok. I will have to run some tests on them though.

Philipp

[lordofwings]

Just wondering, is it possible to write an in-process module for the flight simulator so that it appears on a Menu?

For example if I write my application in C#, would it be possible for my app to add a menu entry to start/stop my application? or is that only possible if you use C++ ?

[Pete Dowson]

Just wondering, is it possible to write an in-process module for the flight simulator so that it appears on a Menu?

FSUIPC offers facilities for applications to add menu entries. You don't need to run inside the FS process just for that. Check the FSUIPC SDK. The section in the Programmer's guide is entitled "MODULES Menu access for applications".

For FSX, SimConnect provides more comprehensive menu facilities which can be used instead.

The language used isn't relevant.

Regards

Pete

[lordofwings]

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.

[Pete Dowson]

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.

Yes. The whole purpose of the FSUIPC IPC interface is onward compatibility. It is the same from FS98 through to FSX including even CFS1 and CFS2. Obviously extra things are added as new FS facilities appear, but the interface is the same and the older data is supported as far as it is still applicable.

Pete

[lordofwings]

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!

[Paul Henty]

Hi,

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.

So you'd like the DLL to maintain the connection in the background? Maybe it could fire an event when connected and when the connection is lost. I'll have a look at the implications - I agree it'll be a bit neater than the current way.

2. Did you test it with FSUIPC 4.x active or just 3.7x?

I don't have FSX but I'm pretty sure there are some people using the DLL with FSX.

This I ask because FSX is not listed in the connection enumeration.

The 1.1 release was pre-FSX. I'll see if Pete has a value for FSX and add it in. I have 1.2 being released soon with a a couple of minor bug fixes so I'll be able to incorporate it then.

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().

That's my fault - it's poorly written. For write-only offsets you still need to call Process(). What I meant in the doc was that the value is only written during process if the value of the local offset has been changed since the last process(). That is - it's not continuously wirting the same value.

For read/write offsets - they a read on every process() except where the local offset value has been changed since the last process(). In this case the offset is written to FSUIPC and then goes back to read mode.

Good work mate!

Thanks! I hope it's useful.

If you need any more info or help just ask...

Paul

[lordofwings]

So you'd like the DLL to maintain the connection in the background? Maybe it could fire an event when connected and when the connection is lost. I'll have a look at the implications - I agree it'll be a bit neater than the current way.

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 don't have FSX but I'm pretty sure there are some people using the DLL with FSX.

Ok, I will try it when I get the time. I have FSX but haven't had time to play with it because I cannot use it on Ivao yet (install problems).

The 1.1 release was pre-FSX. I'll see if Pete has a value for FSX and add it in. I have 1.2 being released soon with a a couple of minor bug fixes so I'll be able to incorporate it then.

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.

That's my fault - it's poorly written. For write-only offsets you still need to call Process(). What I meant ...

Pfrew! good thing I asked. Time to start putting those Process() where they are missing.

Thanks! I hope it's useful.quote]

It has so far, the original C# implementation was just to awkward to use.

If you need any more info or help just ask...

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.

FSUIPC Error #999: FSUIPC_ERR_WRITE_OVERFLOW. Offset for Offset 2FE0 is a ByteArray with a declared length of 32 Bytes. The array you are trying to write is different from this. (11 bytes)

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.

[Paul Henty]

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

I think you've run into a bug I've fixed in 1.2 which I will release soon. Sometimes a failed connection can prevent you from ever connecting.

I was trying to add a menu entry by writing to offset 0x2fe0

OK - You may be the first to try and write a string. Can you confirm that you declared the offset as a string and not a byte array. You should declare the string length as the max, then you should be able to assign a shorter string. If that's what you've done let me know and I'll check the string handling.

Perhaps it would be okay to add an Offset for uint[] or int[]

OK - I'll have a look at doing that.

Paul

[lordofwings]

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.

[lordofwings]

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.

[Paul Henty]

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

.

The local Offset objects can indeed only be declared once per address. If two classes need to access the same offset then they must reference the same local offset instance.

The best way to use the DLL is to create all your offsets when the app starts (with the appropriate grouping of course).

If you keep declaring offsets before every process then the code becomes very much like the old C# SDK, which is what I tried to improve on.

There's no harm in letting the offsets just sit there. If you don't call Process() for their group then they don't do anything.

What I recommend you do is create a seperate class that creates all the offsets you'll ever need and exposes them as public fields or properties.

You can then pass a reference to this class around (or make it a public static class) so the other classes in your app can access whatever offsets they need to.

That way you just have one central pool of offsets that's used by multiple classes in your app.

There's nothing to stop individual classes from calling Process() for the relevant group(s). You don't have to put the processing in the central pool.

Paul

[Guest ava038]

Hi to all,

I have a problem by sending text-messages via 0x3380. In C++ it's not a problem but with this .NET dll the text-message in simulator is showing only at the second time. In other words, the first sending is not showing the text-message, the second shows the first text-message, the third show the second text-message and so on.

Please try my attached sample and press the "Sending text" button to send the sample text to FS2004. The first time no text is displayed, the second time a converted text (another problem) is displayed? This is not a primary problem, because if you use the "byte[]" version, there are no converting in it?!?

I hope you understand what I mean.

Thx for your help.

Andreas Widmann

FSUIPCClientExample_CSharp.zip

[Paul Henty]

Hi,

There's two seperate problems here...

converted text (another problem)

Some characters (mainly punctuation) are getting converted wrongly.

This is due to the converter I'm using to translate the unicode (.net strings) into ascii (for flight sim). I'll fix this in the next version.

text-message in simulator is showing only at the second time

I've tracked down the reason for this. FSUIPC needs to have the text first and then the control code. When I say 'first' I mean the text must be before the control code in the IPC File that is used to communicate with FSUIPC.

I didn't realise that there was any such sensitivity (I'd never used the text offsets for example). My DLL lays out the IPC file in order of Offset address. This means the text control comes before the text at the moment because the offset address is lower.

Thus the control is being effectively sent before the text which explains what you are seeing.

This is something else I will need to fix. I'll have to preserve the order the local offsets are instantiated in and layout the IPC file in that order.

I'm on holiday for the last two weeks in June so it'll be July before I can get the next version out.

For now you can work around the problem (well the order one anyway) by declaring the Text and TextControl in two different groups. You then need to process() the Text group and then Process() the TextControl group.

This will force the correct order for now at the expense of an extra Process().

Paul

[lordofwings]

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.

[Paul Henty]

Hi LordOfWings,

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.

The next update will be in July. I'm going on holiday for a couple of weeks soon. I won't be able to do anything until I get back.

About the groups - I don't think you're understanding the whole disconnection thing. It maybe because it's not explained as well as it should be in the docs. It may be because 'disconnection' is a very bad name for what's actually happening.

I'll try and explain a bit better here:

Disconnection for the entire group:

The ability to disconnect an entire group is there only so that you can release the references to the offsets held by the FSUIPC.Connection class.

The only reason you'd want to do that is if:

1. You don't need the offsets anymore, ever, for the rest of your program's lifetime, AND

2. Those offset objects are about to go 'out of scope' in your program, AND

3. You understand enough about .NET garbage collection to care about who's holding references to your objects.

If you're ever possibly going to need the offsets again then don't disconnect them. It's incorrect to disconnect a group of offsets if you want to use them later.

If you don't want offsets in a group updated then just don't call process() for that group.

Registering offsets in a group and never processing them does no harm at all. They just sit there doing nothing.

As for reconnecting the group as a whole: that's impossible. The act of disconnection removes the entire group object (and therefore all the offsets in the group) from the FSUIPC.Connection Class. That's the whole point of the disconnectgroup() method.

You can't then ask it to reconnect the offsets because it's lost all referencs to them.

I think I made a mistake calling it 'disconnectGroup'. On reflection it should have been something like 'UnregisterGroup' or 'DeleteGroup' or 'RemoveGroup'.

I might depreciate that method in the next version and rename it.

Disconnect/Reconnect individiual offsets:

This facility actually does the same thing as the groups but for individual offsets. Again, we are really unregistering or deleteing or removing the offset.

However, the offset can reconnect (re-register) itself becauase it remembers what group it used to be in.

I added this so you've got a very fine level of control and flexibility within the grouping system if you need it.

Again bad naming. Should have been something like MyOffset.UnRegister() and MyOffset.ReRegister().

So in summary: you shouldn't be disconnecting at all. You just don't need to. The control over which offsets are read or written is done by the grouping. Offsets never get updated unless you process the group they are in.

Within the grouping you can further control individual offsets with the Disconnct and Reconnect methods if you need to.

I hope this is much clearer now. I'm afraid I chose bad names for the methods.

If you need any more info I'll be happy to answer any questions...

Paul

[lordofwings]

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!

[Graham Pollitt]

Here is what I am trying to do

http://williams.best.vwh.net/avform.htm#Example

tc1 should be 66deg but I read 55deg

and here is the code

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Dim lat1, lat2, lon1, lon2 As Double

Dim dis As Double

Dim tc1 As Double

Dim a, b, c, d, f As Double

lat1 = (33 + 57 / 60) * (Math.PI / 180) 'answer in radians

lon1 = (118 + 24 / 60) * (Math.PI / 180)

lat2 = (40 + 38 / 60) * (Math.PI / 180)

lon2 = (73 + 47 / 60) * (Math.PI / 180)

dis = 2 * Math.Asin(Math.Sqrt((Math.Sin((lat1 - lat2) / 2)) ^ 2 + Math.Cos(lat1) * Math.Cos(lat2) * (Math.Sin((lon1 - lon2) / 2) ^ 2)))

dis = dis * ((180 * 60) / Math.PI) 'convert to nm

tc1 = Math.Acos((Math.Sin(lat2) - Math.Sin(lat1) * Math.Cos(dis)) / (Math.Sin(dis) * Math.Cos(lat1)))

tc1 = tc1 * (180 / Math.PI) 'convert to degrees

Label1.Text = "lat1=" & lat1 & " lon1=" & lon1 & " lat2=" & lat2 & " lon2=" & lon2 & " distance d=" & dis & " course:" & tc1

End Sub

EDIT - found the problem, I was converting into nm and using that as the distance when it should have been in radians, doh, lost 2 hours bcos of that :)

[Paul Henty]

Hi all,

Version 1.3 has been posted on page 1 of this thread.

Changes since the last 1.1 release are: (1.2 wasn't publically released).

* Fixed error in connection code where a failed connection could lead to never being

able to connect.

* Fixed error in string handling that could cause strings read from FSUIPC to be corrupted.

* Fixed error in string encoding where certain symbols were corrupted when writing to FS.

* Offsets are now written to the IPC file in the order they are created. This problem

will not have affected most people but some offsets (like the ones to send text to FS)

are sensitive to the order in which they appear in the IPC file.

* FSUIPCConnection.DisconnetGroup() has been deprecieated and replaced by

FSUIPCCOnnection.DeleteGroup(). DisconnectGroup was a bad name. From now on you cannot

compile a project that calls DisconnectGroup(). However, projects already compiled that

use this method will containue to function as before.

* Added a new property DLLVersion to FSUIPCCOnnection. This returns a version object

representing the version of the client DLL.

* Added FSX to the FlightSim enum so that you can now write apps that only connect to FSX.

There were other requests that havn't made this build. I've not got much time at the moment as I'm moving house. This release is mainly bug fixes with a couple of easy enhancements.

All requests are still on the list for future versions.

Paul

[Graham Pollitt]

thanks Paul, appreciated as always :D

Gray