• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Airspace information

Very good stuff Eric. I never ventured up past 60N, so its great to see what's going on there. Your map is really looking good!

I see that I didn't make my point very clear regarding zoom. From my data, I saw slightly different scaling of the longitude vs latitude axes. The difference would manifest itself at greater zooms if the same zoom magnification is applied to both axes, so I should not have clouded the point with the latitude comment.

I'm sure you'll have no difficulty adding in the other layers, and FSX gives us a few more to work with than FS9. Keep it going; I'm anxious to test your product. Very cool.

Bob
 
Just to keep you posted, work is going on slowly and I have added the distance measuring tool. It works quite well in accordance with the GPS distance calculation.

DistMeasure_LFBO-GAI.gif


Confirmed by the nav log:

NavLog_LFBO-GAI.gif


Eric
 
That is progressing very nicely Eric, and it's really great looking. There's a lot you will be able to do with this as your module evolves. I expect that your distances are rather exact as you are doing your own great circle calcs between points drawn by your own code. As I see it, you only need to insure that your overlay map is always precisely superimposed, throughout all zooms, with the gps module when you use the gps terrain as a base.

Now that you have distance calculation, have you double checked the accuracy of your range rings? The gps module's range rings are highly inaccurate.

Looking good!

Bob
 
Yes, there is a lot we can do with this module because it is highly configurable with XML variables that anyone can edit easily.
As you can see on the latest image I have posted, the distance calculation is perfectly in accordance with the GPS distance calculation. This is logic, this is the only valid way of calculating distances between 2 lat/lon points. And all the work I have done before this consisted in ensuring my map objects are perfectly superimposed with the GPS map layer. This is the case today, I am 100% sure.

The range ring distance is a more complex problem. I know it is absolutely inaccurate in the standard GPS, it is definitely better on my moving map, but still not perfect. In fact, it is perfect on the vertical axis, along the meridians. This is because wherever you are on earth, 1° of latitude is always equivalent to 60 NM (1 NM = 1 minute). But on the parallels, this is only true at the equator. According to the GPS projection system, the more you go north, the small the distance is from a parallel to another. To be accurate, the range circle should be an ellipse, which would be ugly... When you reach 70° latitude, the range circle would then depend on the window size ratio: a square gauge would make circles, while a rectangle window would make ellipses, which would look strange as well. This is why I decided to always draw circles, even if it is not perfectly accurate on the horizontal axis...

I'm not sure my explanations are clear, I think you will understand more easily when you test the gauge with the grid displayed.

Eric
 
eric_marciano said:
To be accurate, the range circle should be an ellipse, which would be ugly...
Click to expand...

Now you know why I stated earlier that I believe that for FSX, MSFT removed the latitude cosine correction for zooms below zoom factor 270 in order for the range rings to be "reasonable" at arbitrary latitudes, at least when zoomed in.

If you have not already gotten to that part, remember to remove the cosine correction in FSX for those zooms at least when your map is overlayed on the gps terrain base.

Good stuff. When you get to flight plan, will you include rendering the approach procedure?

Bob
 
I will never reach a zoom factor of 270, so no problem :)
The flight plan I display is only composed of the waypoints, the information provided by the SDK. It doesn't include the approach procedure.

Eric
 
eric_marciano said:
I will never reach a zoom factor of 270, so no problem :)
The flight plan I display is only composed of the waypoints, the information provided by the SDK. It doesn't include the approach procedure.

Eric
Click to expand...

Eric,

I may need to define my terms here... :o

I use the term Zoom Factor as it would be used in the stock gps_500 gauge (map_ZoomFactor). Line 761 from the FSX gps_500.xml gauge:

<Zoom>(@g:map_ZoomFactor) 1852.0 *</Zoom>

In the stock gps gauge as well as in MapView.xml, Zoom Factor is selected from the values listed in the XML case statement of the CalculateZoomFactor macro (line 41 in MapView.xml and line 105 in the FSX gps_500.xml gauge. FS9 has the same meaning and use). As one zooms in, Zoom Factor is lower. I would think that flight sim users view their gps map most often at Zoom Factors below 270, but nonetheless, sometimes above 270 too. So, we may be meaning different things if you say you never reach Zoom Factor 270. I dunno ....

The FSX gps module applies cosine latitude corrections to the parallels only when Zoom Factor is equal to or above 270. As stated, my theory is this has to do with the introduction of range rings in FSX, when a radar gauge became possible. But FS9 is different - latitude cosine corrections are applied at all Zoom Factors. The other exception you have pointed out ... at latitudes 70 degrees and above. In this way, your module must also treat FSX differently than FS9 if you want to be consistent with the base gps terrain, and I was simply asking if your FSX version did. I've tried to make this point three or four times already in this thread, but it's likely I have not been careful to completely explain what I mean.

Regarding Approach, the reason I asked was because your module is shaping up to replace (and look much better than) the gps.dll map except for the gps terrain base which you still use. It depends on how far you plan to take your product. But, my opinion is that any gps map that does not draw the approach is incomplete. The approach becomes part of the flight plan when it is loaded. The real Garmin 500 series and the FS9/X gauge render the Approach twice - once as a pop-up through <LayerApproach> and secondly when loaded, as part of the Flight Plan through <LayerFlightPlan>.

Your product is very nice indeed -- my compliments!

Bob
 
rpmc said:
Regarding Approach, the reason I asked was because your module is shaping up to replace (and look much better than) the gps.dll map except for the gps terrain base which you still use. It depends on how far you plan to take your product. [...]
Click to expand...
This is where you are wrong, Bob, my plan is not to replace the existing GPS, which is good on many aspects. My objective is to simulate a paper map similar to the ones I had when I used to fly in VFR. I know the map details (roads, rivers, terrain, ...) is not accurate enough for VFR, but at least you have the airports, VORs, NDBs, etc... On some aspects, my moving map is not as complete as the GPS: no flight plan definition, no access to nearest airports, no warning when entering an airspace, no ILS display, etc... So the 2 tools have different roles, my moving map can do things the standard GPS can not do, and vice-versa.

Eric
 
AMAZING stuff Eric !!

Great potential in so many areas.

I am looking at it and thinking .. POTENTIAL for a great FSX Multiplayer RADAR !!

While the current Radar is "ok", it LOCKS UP after a period of use, and it lacks some much needed features, that cannot now be easily added to the existing XML controlled dll.

What you have here, is the potential to do almost anything, on that Map, including display aircraft, and definable Tags etc etc.

$64,000 Question. Do you have any interest in looking into a RADAR application for your "Map".

Geoff
FSMP
 
Yes, Geoff, I thought about using my moving map as a multiplayer radar, but as you already know, I already have the ATC Radar for this. I agree, it would be better if my ATC Radar was based on the map I have here, but I'm not sure the FS market is very demanding for this kind of product, even if it is better than the first version.
What are the missing features you are thinking about?
If they can make a difference, I may change my mind about the option of developing a new radar :)
And if you think about other possible uses of the map, let me know...

Thank you,
Eric
 
You must log in or register to reply here.
Back
Top