Jump to content


Photo

FSUIPC Client DLL for .NET - Version 2.0


  • This topic is locked This topic is locked
428 replies to this topic

#21 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 452 posts
  • LocationBristol, UK

Posted 16 April 2007 - 06:14 PM

Hi Graham,

You need to be checking each boundry of the runway as opposed to just checking if it's in the four corners like you're doing at the moment.

The main thing you need to find out is the latitudes of the edges of the runway at the plane's current longitude and vice verse.

I've attached a graphic to show the maths for one boundry (NW/SW).

(the lon/lat units have been simplified to make things clearer)

We know the plane is at Lon 23.5E. But at what longitude is the edge of the runway at the current aircraft Latitude (24N)?

To find out we use some basic trigonometry with right angled triangles...

1. We know the positions of the NW corner and SW corner. From this we can get the lengths of two sides of the triangle. (Blue numbers)

2. The ratio between these side is 10:5 = 2:1.

3. What we want to know is: How far across is the edge of the runway at 24N. ('X' on the diagram). 24N is only 6 south of from the NW latitude . This forms a smaller triangle inside the larger one. (In red)

4. The ratio of the sides of this smaller triangle will be the same at the larger one (2:1).

5. To if the long edge is 6 the short one will be 6/2 which is 3.

6. Add that distance to the NW longitude (20E) and you get the absolute longitude of where the runway starts. In this case 23E.

7. Since the aircraft is at 23.5E it's east of the west boundry and so we could be on the runway.

You just do similar calculations for the other 4 boundries.

If they all pass, you're on the runway.


So here's a routine that will check if a point is within a quadrangle. This even works if the sides arn't parralel.

It's important that you enter the corordinates of the four corners correctly or it won't work. They are labeled NW, NE, SW and SE. Just make sure your map is pointing north and it should be fairly easy to work out which is which.

C#

private bool AreaContainsPoint(double AreaNELat, double AreaNELon, double AreaSELat, double AreaSELon, double AreaSWLat, double AreaSWLon, double AreaNWLat, double AreaNWLon, double PointLat, double PointLon)
        {
            bool InArea = false;
            // Check if point is EAST of the NW/SW boundry
            if (PointLon > AreaNWLon + ((AreaSWLon - AreaNWLon) / (AreaNWLat - AreaSWLat) * (AreaNWLat - PointLat )))
            {
                // Check if point is WEST of the NE/SE boundry
                if (PointLon < AreaNELon + ((AreaSELon - AreaNELon) / (AreaNELat - AreaSELat) * (AreaNELat- PointLat)))
                {
                    // Check if point is NORTH of the SW/SE boundry
                    if (PointLat > AreaSWLat + ((AreaSELat - AreaSWLat) / (AreaSELon - AreaSWLon) * (PointLon - AreaSWLon)))
                    {
                        // Check if point is South of the NW/NE boundry
                        InArea = (PointLat < AreaNWLat + ((AreaNELat - AreaNWLat) / (AreaNELon - AreaNWLon) * (PointLon - AreaNWLon)));
                    }
                }
            }
            return InArea;
        }

VB.NET

Private Function AreaContainsPoint(ByVal AreaNELat As Double, ByVal AreaNELon As Double, ByVal AreaSELat As Double, ByVal AreaSELon As Double, ByVal AreaSWLat As Double, ByVal AreaSWLon As Double, ByVal AreaNWLat As Double, ByVal AreaNWLon As Double, ByVal PointLat As Double, ByVal PointLon As Double) As Boolean
        Dim InArea As Boolean = False
        ' Check if point is EAST of the NW/SW boundry
        If (PointLon > AreaNWLon + ((AreaSWLon - AreaNWLon) / (AreaNWLat - AreaSWLat) * (AreaNWLat - PointLat))) Then
            ' Check if point is WEST of the NE/SE boundry
            If (PointLon < AreaNELon + ((AreaSELon - AreaNELon) / (AreaNELat - AreaSELat) * (AreaNELat - PointLat))) Then
                ' Check if point is NORTH of the SW/SE boundry
                If (PointLat > AreaSWLat + ((AreaSELat - AreaSWLat) / (AreaSELon - AreaSWLon) * (PointLon - AreaSWLon))) Then
                    ' Check if point is South of the NW/NE boundry
                    InArea = (PointLat < AreaNWLat + ((AreaNELat - AreaNWLat) / (AreaNELon - AreaNWLon) * (PointLon - AreaNWLon)))
                End If
            End If
        End If
        AreaContainsPoint = InArea
    End Function

It's also worth noting that this assumes the earth is flat. That's probably not a problem with checking a small area like a runway. The larger the area you check, the more inaccurate it becomes because of the roundness of the earth. The maths to do it property taking into account the round earth is fairly complicated.


Hope this works.

I've started to put Lon/Lat support in the .NET client DLL. I'll put this in there as well. Can't say when I'll get time to finish it off though.

Let me know how it goes...


Paul

Attached Thumbnails

  • RunwayMaths.JPG

  • 0

#22 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 17 April 2007 - 11:37 AM

fantastic, just what I needed, works fine now

thanks Paul :)
  • 0

#23 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 27 May 2007 - 07:25 PM

I was using AFCAD to manually get the 4 corners of the runway and entering this info into an 'airport.dat' file. My app was working fine although I only had 6 airports in the list so far. Upon discovering MakeRwys.exe I thought it would be able to read all the info that I needed but it seems to lack on some points(unless I am not using it correctly!)

Is there any way to read the width of a runway from any of the scenery bgl files?

Using MakeRwys.exe I can obtain the centreline lat/long and the length of the runway. What I cant appear to do is to expand the centreline x degrees to the left and right to form a rectangle over the runway as I dont know the width.
  • 0

#24 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 452 posts
  • LocationBristol, UK

Posted 27 May 2007 - 09:11 PM

I don't know anything about BGL files sorry.

MakeRunways seems to include runway widths. This is from the readme...

R4.csv
This is the same as the previous CSV file, but additionally includes
runways widths as the last value in each CSV line. This is used
in Radar Contact (before RC4.3) for more precise ATC operations.



Let me know if you need help modifying the routine I gave you to work with the new data (e.g. centreline + width, rather than four corners.)

Paul
  • 0

#25 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 28 May 2007 - 06:30 AM

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

Regarding the updated code I will try it myself over the next few hours and if I get stuck I will be sure to let you know Paul :D

Best regards and thanks
Graham
  • 0

#26 Graham Pollitt

Graham Pollitt

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts
  • LocationCheshire, UK

Posted 28 May 2007 - 07:53 AM

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
  • 0

#27 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 452 posts
  • LocationBristol, UK

Posted 28 May 2007 - 10:47 AM

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
  • 0

#28 CptnYesterday

CptnYesterday

    Newbie

  • Members
  • Pip
  • 4 posts
  • LocationKorea

Posted 31 May 2007 - 03:49 AM

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
  • 0

#29 Pete Dowson

Pete Dowson

    Advanced Member

  • Moderators
  • 27,283 posts
  • LocationNear Stoke-on-Trent, UK

Posted 31 May 2007 - 07:39 AM

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
  • 0

#30 Pete Dowson

Pete Dowson

    Advanced Member

  • Moderators
  • 27,283 posts
  • LocationNear Stoke-on-Trent, UK

Posted 31 May 2007 - 07:48 AM

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
  • 0

#31 CptnYesterday

CptnYesterday

    Newbie

  • Members
  • Pip
  • 4 posts
  • LocationKorea

Posted 31 May 2007 - 07:59 AM

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
  • 0

#32 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 07 June 2007 - 06:58 PM

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++ ?
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb

#33 Pete Dowson

Pete Dowson

    Advanced Member

  • Moderators
  • 27,283 posts
  • LocationNear Stoke-on-Trent, UK

Posted 07 June 2007 - 07:09 PM

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
  • 0

#34 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 08 June 2007 - 08:38 AM

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.
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb

#35 Pete Dowson

Pete Dowson

    Advanced Member

  • Moderators
  • 27,283 posts
  • LocationNear Stoke-on-Trent, UK

Posted 08 June 2007 - 09:16 AM

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
  • 0

#36 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 09 June 2007 - 10:42 AM

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!
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb

#37 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 452 posts
  • LocationBristol, UK

Posted 09 June 2007 - 11:33 AM

Hi,

[quote]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.[/quote]

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.

[quote]2. Did you test it with FSUIPC 4.x active or just 3.7x? [/quote]

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

[quote]This I ask because FSX is not listed in the connection enumeration.[/quote]

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.

[quote]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().[/quote]

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.

[quote]Good work mate![/quote]

Thanks! I hope it's useful.

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


Paul
[/quote]
  • 0

#38 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 09 June 2007 - 12:56 PM

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.
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb

#39 Paul Henty

Paul Henty

    Advanced Member

  • Members
  • PipPipPip
  • 452 posts
  • LocationBristol, UK

Posted 09 June 2007 - 01:16 PM

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
  • 0

#40 lordofwings

lordofwings

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts
  • LocationEarth

Posted 09 June 2007 - 03:24 PM

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.
  • 0
Blogger: Lord of Wings Blog
Facebook: Lord of Wings
Twitter: @aviationweb




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users


About simFlight - simflight.com - simflight.de - simflight.fr - simflight.nl - simflight.pt - simflight.es - simflight.it - simflight.jp - simrussia.com - simMarket