What is actually happening is the camera is pointing to the right place (try zooming in), but the camera is also travelling up and down with the nose and it should be staying more steady (in sync with the CG altitude).
Attached is a fix for this. There is still something a little funky going on with the camera, but this solves the biggest problem. You will note that I deleted an unecessary reference to scenery.hxx in the patch.
I split the FGModelPlacement code out into it's own set of source files.
I created two versions of the fgLoad3DModel() routine. One that is
unecumbered by a panelnode dependency and one that is. acmodel.cxx is
the only place that needs to load an aircraft with instrument panels.
model.[ch]xx are now pretty much free to move over into simgear.
loader.[ch]xx should be able to follow closely behind.
This will be a big step towards being able to move the material management
code over into simgear.
the ascii scenery file format has actually worked in quite some time, and the
ADA runway light code has been supersceded by a slightly different mechanism.
requested parameters to determine if this should be an on-ground vs. in-air
start. The problem was that we never defaulted the value to anything so
if we didn't match an in-air condition, we simply inherited whatever value
was there from before.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
Set a random value for a numeric property
Params:
<property> - the name of the property to randomize
<min> - the minimum allowed value
<max> - the maximum allowed value
The one to fg_init.cxx initialises the AI subsystem regardless of whether it's enabled or not so that later enabling by the user doesn't crash it, and the one to main.cxx avoids running the ATC manager and ATC display system unless enabled.
This is just a port of an old 3D HUD patch to the new view code.
This pans the HUD with the view, by pasting it onto a quad fixed in front of the viewer. It also fixes the awful, arbitrary scaling problems the HUD code has. The old HUD only looks right when viewed at 1024x768 and 55 degree FOV. This works the scale out magically so that it looks right in all views. It also redefines the "<compression-factor>" tag in the ladder to (1) mean compression instead of expansion and (2) have non-psychopathic units (now "1" means 1 degree per degree). Fix this in your existing HUD ladder files before reporting bugs. It's definitely a cosmetic win -- the velocity vector points at the right thing and the horizon lines up properly.
Norman wrote:
I have created a modified version of Andy's patch that implements the 3D HUD as the 'normal' and the 2D HUD as the 'minimal' HUD. < i > and < shift I > keys
