Bug: No Tower View

[lordofwings]

The guys at the MS beta team have been able to reproduce my problem. I am not yet sure (not clear) whether this is the cause but it certainly is an omission that causes some errors that are not caught:

The XML code generated by FSX Planner does not allow you to indicate the tower VIEW. You can specify the coordinates of the tower but apparently not the altitude AND heading of the tower view. That is where the tower controller would be sitting and pointing his/her head to.

The person that did the check ran some tool on it and noticed those errors in the FSX Planner generated XML.

 

[rf360m]

Interesting. The SDK doesn't mention that the tower viewpoint can have a heading associated with it, just a lot/lon and altitude. I always though that the tower view looked towards whereever the user's plane was.

In any case, did they tell you what the xml attribute for the heading is? Is it just 'heading="xxx.xxxx"'?

-Russell

 

[HolgerSandmann]

Hi Russell,

actually, it's a false alarm by lordofwings. Here's what Dick posted in that newsgroup:

"Using FSX Planner' error checking, I discovered you had no tower view... it
defaults to N0.0, E0.0, Alt 0.0

Run the error checker in that program, set the tower view, and compile, and
the BGL is fine."

Cheers, Holger

 

[rf360m]

Hi Russell,

actually, it's a false alarm by lordofwings. Here's what Dick posted in that newsgroup:

"Using FSX Planner' error checking, I discovered you had no tower view... it
defaults to N0.0, E0.0, Alt 0.0

Run the error checker in that program, set the tower view, and compile, and
the BGL is fine."

Cheers, Holger

Ok - thanks Holger.

-Russell

 

[lordofwings]

False alarm? read the post, it says "error" "fix" "BGL fine" .

Now whether than solves my problem I don't know but it certainly indicates there is some sort of missing attribute there.

 

[jvile]

lordofwings

You are confusing the actual tower Scenery model Library Object with a Tower view because they are 2 seperate elements.

The alt="0.00F", pitch="0", bank="0", and heading="270" of a Control Tower have nothing to do with Tower View and your post is a false alarm.

A Control Tower gets a heading only because you can face it in the correct direction if needed. It always gets a 0.00F altitude unless you set the AGL to FALSE which now requires the Tower to be at AMSL.

This is a Control Tower

<SceneryObject lat="33.6417825142981" lon="-84.4216999638373"
alt="0.00F" pitch="0" bank="0"
heading="270" altitudeIsAgl="TRUE" imageComplexity="SPARSE">
<LibraryObject name="{c1b936ad-a25e-42c3-ad48-2dbcb1a3b501}"
scale="1.0" />
</SceneryObject>


The Tower View which is a different Element in the XML does not get a heading because it always looks at the User Airplane by default. There are other options as well to unlock the view and Pan if a Key command is placed into the Keyboard assignments.

This is the Tower View which the LAT/LON agrees with the actual Control Tower above if you want the view at the center of the actual Control Tower.

<Tower
lat="33.6417825142981"
lon="-84.4216999638373"
alt="411.40F" />

Some FSX airports are set at alt="0.00" AGL and you have to raise the eye view point. If you want to unlock the Tower view then do the following.

Go into the keyboard assignment list of FSX found in the Display setting menu. Scroll down toward the bottom until you see a entry called

"View track pan toggle"

Assign a keyboard mapping (stroke) for this event.

So what does this do?

In FS9 the Tower View always locked to the User Airplane. In FSX we now can unlock the Tower view from the User Airplane which is refered to Track/Pan Toggling as per the Tower cameras. This allows us to toggle between tracking and free-panning modes. What you do is go to the Tower View in FSX. Once you are in the Tower now hit the key assignment you used to unlock the look view toward the User Plane.

You are now free to pan 360 degrees/up down (hat switch or keyboard) in any direction plus ZOOM in and out all from inside the Tower.