Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Unca-Fester]

The heading degrees is in a counter-clockwise rotation, which I assume is viewed from above the object, this used to throw me off when trying to manually install new scenery in FG, instead of just using the UFO object installer.  90 degrees is actually 270 degrees in FG, would that be the problem you're experiencing?

  Also the weird look is because FG relies heavily on alpha masking for complex structures like truss bridge sides and power transmission pylons and such, and the .png's probably have a different alpha mask coding format...?

[Stainless]

There is definitely something seriously whack about this data

I added helipad's to give me some more points of reference and then overlaid a part of the official map over a screenshot from my app.

While some things line up pretty well, other things are way out.




The scale of all the objects is wrong. The position is wrong. The orientation is wrong.

After all I don't think you would want to work in this tower.

[Pursuivant]

There is definitely something seriously whack about this data

Really stupid basic idea. Have you taken magnetic declension into account?

Other than scale and location being wrong, everything seems to be lining up on "almost" the correct axis, but at the slightly wrong angle.

Currently, Brighton City Airport/Shoreham has a magnetic declension of 0° 45' W  ± 0° 22'  changing by  0° 9' E per year but in 2016 it had a declension of 1° 2' W  ± 0° 22'  changing by  0° 9' E per year.

Calculator here:

https://ngdc.noaa.gov/geomag-web/

If you're using slightly data which uses magnetic north rather than true north that might explain the problem.

[Stainless]

It's a good point, but I have tried that.

Even if it was a problem, I have a single code block that converts latitude, longitude into a local world space coordinate system.

Code: [Select]

        /// <summary>
        /// Returns a new Vector2D which is the distance from the reference point in metres
        /// IE. Makes the data point local to the reference point
        /// </summary>
        /// <param name="clat">Reference point latitude</param>
        /// <param name="clon">Reference point longitude</param>
        /// <param name="slat">Data point latitude</param>
        /// <param name="slon">Data point longitude</param>
        /// <returns></returns>
        public static Vector2D ConvertToLocalised(double clat, double clon, double slat, double slon)
        {
            double m_per_deg_lat, m_per_deg_lon, deltaLat, deltaLon;

            m_per_deg_lat = 111132.954 - 559.822 * Math.Cos(MathHelper.ToRadians((float)(2.0 * clat)) + 1.175 * Math.Cos(MathHelper.ToRadians((float)(4.0 * clat))));
            m_per_deg_lon = (3.14159265359 / 180) * 6367449 * Math.Cos(MathHelper.ToRadians((float)clat));

            deltaLat = clat - slat;
            deltaLon = slon - clon;

            return new Vector2D(deltaLon * m_per_deg_lon, deltaLat * m_per_deg_lat);
        }



Since everything is in latitude : longitude, everything should be consistent. It could be wrong , but at least it should be consistent


I have decided that I am going to have to write an editor for airports, which will allow you to fix problems like this.

[Pursuivant]

I have decided that I am going to have to write an editor for airports, which will allow you to fix problems like this.

Sympathy to you for the disruption of your plan of work.

But, I can't say that I'm that sad since an airport editor is another "tool for sandbox" which will allow fans to modify the sim.

[Stainless]

 

Well it forced me to work on something I had been putting off.

If I am going to write an airport editor, I need to have terrain to put the airport on. Otherwise in game the airport could be underground or floating in mid air.

So I have started the terrain module I have been putting off for ages.

I have delayed terrain a lot because I was hoping to use a terrain system I have been thinking about for ages. Trouble is I haven't solved one key problem with it (spherical aberration due to curvature of the Earth) and so I really cannot use it for the editor.

So I will end up with two terrain modules. One for editors and one for game.

A bit of a waste of effort, but not terrible.

[Pursuivant]

So I have started the terrain module I have been putting off for ages.

Question: Will the terrain/airport editor take surface type and condition into account?

I ask because I've never encountered a flight simulator where you can't land any sort of plane on any relatively flat piece of ground not blocked by obstacles, or where imperfect runway surface does anything other than bounce your plane around. In reality, of course, aircraft are severely limited by runway material type and surface conditions as well as the aircraft's ground pressure and surface contact area.

Slippery runways slow take-off runs and create the risk of the airplane skidding off the runway or ground looping. Heavy aircraft will quickly destroy runways not designed to bear their mass and the forces they generate when they land. Aircraft attempting to take off, land, or taxi in muddy conditions might skid, ground loop, flip over, or get stuck (e.g., the Akutan Zero). Dry conditions and dirt, coral, sand, etc. runways generate massive amounts of dust which interferes with visibility on the ground (e.g., the failed 1980 Iran Hostage Rescue attempt by the USAF/US Army), makes take-offs and landings extremely visible from the air, and can cause damage to the engines and other aircraft systems.

If you choose to incorporate ground pressure into your sim, some potentially useful simplified equations are here:

http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1044&context=usarmyresearch

[Stainless]

I have already got a value for runway roughness in the database. 

[kalsonic12]

Possibility of blown tires during rough landings?

[Stainless]

Yes I want all of the damage systems to be realistic.

So tires bursting on landing, damage to flight control surfaces being resolved in a realistic manor, electrical system failures, hydraulics, everything as realistic as possible.

[Pursuivant]

I have already got a value for runway roughness in the database. 

Cool!

I was thinking that a value for runway type and surface conditions could also be a eventually be used as variables which trigger things like altered coefficient of friction, dust/snow cloud and water/mud spray special effects, and risk of things like blown tires, landing gear failure, FOD, and noseover/ground loop.

For runways which depend on seasonal conditions - like seaplane take-off areas or runways on iced over lakes, availability of runways and effects if an airplane lands in an inappropriate location could be linked to weather conditions.

Most airfield descriptions includes runway surface type and METARS or other game events can be used to infer likely surface conditions, so not that difficult to include the information in the editor.

Ground pressure usually isn't an issue when landing at an airfield, except for really big, heavy civil airliners. Even then, it mostly affects rate of wear to the runway over an extended period of time. It makes more of a difference when planes are operating from improvised airfields, for ski-equipped planes, or planes attempting to make wheels-down emergency landings in boggy, muddy, or sandy terrain. This was a big deal for WW2-era aircraft operations in some theaters. Understandable if you don't want to include it, though.

[Stainless]

My circuits are now committed.

It has begun....