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
I've fixed a bug in FGRunways::search(aptid, tgt_hdg) which wasn't working properly for airports with multiple parallel runways. I've also firmed up and pulled out into it's own function the GetReverseRunwayNo code, and done some input checking.
As a result of fixing the above in runways.cxx, I've pulled out the
parallel implementation in the functions that set position by airport and
heading/runway number in fg_init.cxx and called the runways functions
instead.
ttStandard is copied from ttBerndt, with the following modifications:
1. All turbulence is diminished within three wingspans of the ground.
2. The horizontal forces are used to calculate the moments, but then
zeroed out so that only the vertical force is actually applied to
the aircraft.
3. The yaw moment is not used.
In fact, the horizontal forces and the yaw moment should be allowed,
but they are extremely rare compared to the vertical force and the
pitch/roll moments. For now, simply zeroing them gives the most
accurate feel.
The "switch" layer type now takes any number of child layers, and will
use the first child that has a condition that evaluates to 'true' (no
condition is automatically true). Previously, it could take only two
children, controlled by a boolean property.
for a little while, since it uses different properties. There are
some improvements, especially with searching and range. It also has
its own serviceable and in-range properties, independent of any
coupled VOR.
// search for the specified apt id and runway no
bool FGRunways::search( const string& aptid, const string& rwyno, FGRunway*
r )
there was a bug, in that each runway corresponds to *two* runway numbers
(eg 01/19, 10L/28R) but the function was only checking one. I've modified
it to check the supplied number against both possible numbers for each
runway.
Secondly, I sent in the function:
// Return the runway closest to a given heading
bool FGRunways::search( const string& aptid, const int tgt_hdg,
FGRunway* runway )
a year or two ago now when I first did the ATIS. I'm not sure what I was
doing at the time (copied most of it out of fg_init.cxx) but I don't think
it's ever worked, so here's a brutal modification that does!
FGExternalPipe is destructed.) This leaves the name pipe hanging around
even after flightgear exits, but assuming we put the files in /tmp that
shouldn't be a big deal.
ExternalNet interface:
- allows a much more closely coupled execution. A remote network FDM will run
at it's own rate, and maybe a particular data packets will come, maybe it
won't. This makes it very hard to control timing and keep the animation
smooth. There are also cpu scheduling issues with running multiple
processes on a single machine. The linux scheduler by default runs at
100hz. If an FDM process uses a sleep/alarm system to avoid wasting
CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This
makes it *impossible* to serve a display system running at 60hz without
dropping frames.
- the downside is that the FDM process must now run on the same machine as
the master flightgear process.
arrays of insufficient size are allocated in prop_picker.cxx ( size()
don't count the null char ) and strcpy is writing outside the allocated
array. A patch follow.
I've updated the instrument modulator code to allow tricks like the one
described by Andy. It is now possible to define <min>, <max> and
<modulator> in one layer and if <min> and/or <max> ore within the range
of the <modulator> tag, their value will be honoured.
So, if you define
<layer>
<min>0</min>
<max>50</max>
<modulator>100</modulator>
</layer>
The value will stay at 50, until the modulator forces it back to 0.
- NED and UVW are working correctly
- knots is giving true airspeed instead of calibrated airspeed
- mach is not working at all
This desperately needs a trimming routine.
earlier, before fgInitSubsystems().
Modify fgInitPos() so that the plane is not automatically aligned with
a runway when an airport is the reference point unless (a) a runway
was explicitly requested, or (b) the plane is on the ground with no
offset distance specified. To set up the plane lined up on an
approach to a runway, use something like
fgfs --airport=CYOW --runway=32 --altitude=300 --offset-distance=0.5
This way, it's possible to specify a starting position relative to an
airport without getting snapped onto a runway approach (unless you
want to be).
better scheme.
While it's true that the actual ILS indications are unreliable when
far off the approach path, the ILS is not out of range -- you can
still ident it (an essential part of any approach procedure), and the
indicator will usually be doing something, however bizarre. The
current scheme did not allow the user to ident the ILS until
practically on the approach path.
04Feb. Actually been running since the beginning of January with these
patches. All changes work without crashing with the current base package cvs,
but there are some visual problems with the views (other than pilot view)
without changes to the base package.
As soon as you can build test and commit I can add in those base package
updates that will make it all work nicely. I will also go through all the 3D
Aircraft configs to make sure the change in the "pitch-offset" for cockpit
views (see below) are made to maintain current behavior.
Here are the files (changes listed below):
http://www.spiderbark.com/fgfs/viewerupdate.diffs.gzhttp://www.spiderbark.com/fgfs/viewerupdate.tar.gz
Here are the two modifications I had to make to get flightgear (just
updated from CVS) to build. The first one is for being able to specify
SimGear's location at the ./configure command line, and the second one
is to be able to link.
Here's a change to the GUI property picker I did a few weeks back.
It makes the values in the property pick 'live' (and also re-factors
the picker code to use less arrays, this should be obvious from the
diffs). A good demo is to open up the engine node and observe the rpm,
cylinder head temp, oil pressure and so on while playing with the
throttle and airspeed. It's pretty rough (some rounding of digits would
help) but useful for testing (at least I think so). I'm not sure about
the performance implications either, but it seems fine for me.
All logs and log entries are now disabled by default, unless
explicitly enabled by an 'enabled' property. This works much more
intuitively with the GUI dialog.
the whole electrical system. We will also need a mechanism to kill
individual suppliers (such as the alternator), but this is good enough
for most training.
if the station is too far away. Instead, simply return the closest station.
All the code that searches navaids does it's own range checking anyway.
This will make the navlist query functions a bit more useful for other
types of functionality where you may need to lookup a station without
consideration of range (i.e. presetting your position relative to a navaid.)
a spinning gyro.
Changed FGInstrumentMgr to inherit from FGSubsystemGroup, greatly
simplifying the (already simple) class. I should probably rename this
to FGInstrumentGroup or something similar, but not today.
Added the gyroscopic turn indicator (part of the TC).
hemisphere the distance is positive, if you are in the departure hemisphere
the distance is negature. (Possible use for graphing approach distance
vs. glide slope or cdi.)
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
(I thought I'd slip this in along with David's change to the default menu
configure option. I believe that will cause a new config.h to be generated
which will cause a near complete rebuild of FG (as will this globals.hxx
change) so it shouldn't cause additional grief to have these happen at the
same time.)
menubar. This one allows regular command bindings, with the
(temporary) condition that every menu item must have a unique text
label. The new menubar is disabled by default; to enable it,
configure --with-new-menubar.
input bindings. They will work only with the latest CVS; otherwise,
./configure will disable them. There is a new command, 'script',
which takes a single argument, also called 'script', containing PSL
code (currently PSL requires a main() function).
Erik Hofman has written some more elaborate code for triggering PSL
code from drop-down menus and scheduling events; I will look at
integrating that next.
and property-multiply:
Firstly, change back to wrapping modulo the interval, with "min <= x <
max" semantics. I believe the previous implementation did that. The
inline function that Norman mentioned also does that.
Secondly, make it snap to the nearest value (min + N*resolution) when a
"resolution" tag is present, taking special care of floating-point
precision. Or perhaps specify "number of divisions in the interval" as
an integer, instead of "resolution" by which I meant a floating-point
"size of a division".
[also fixed]
While working on this file I noticed some potentially serious warnings:
fg_commands.cxx: In function `bool do_property_adjust(const
SGPropertyNode*)':
fg_commands.cxx:435: warning: control reaches end of non-void function
fg_commands.cxx: In function `bool do_property_multiply(const
SGPropertyNode*)':
fg_commands.cxx:465: warning: control reaches end of non-void function
/usr/local/include/simgear/misc/props.hxx: At top level:
fg_commands.cxx:600: warning: `bool do_presets_commit(const
SGPropertyNode*)' defined but not used
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
experimental lighting rendering (which is very expensive on my
machine, for example). To use distance attenuation,
/sim/rendering/distance-attenuation must also be true.
It adds a command line options to enable/disbale distance attenuation
using a property rather than using a #define inside the code. It also
adds a small change for systems that don't support the OpenGL extension,
so that the lights *do* fade away as they get furher away but they don't
get smaller in size.
property-adjust.
Modified property-adjust and property-multiply so that they always
work with double values, to simplify the code.
Factored out some common code.
Added a 'mask' argument to the property-adjust and property-multiply
commands. If mask is set to "all" (the default), then the command
works as before; if mask is set to "integer", it works only to the
left of the decimal point; and if mask is set to "decimal", it works
only to the right of the decimal place. This functionality is useful
for tuning VHF COM and NAV radios.
Ensure that if a condition for a panel mouse binding fails, other
bindings for the same area will have a chance to run.
Add a repeatable flag for panel mouse bindings (defaults to true).
- dialog-open
- dialog-close
- dialog-update
- dialog-apply
The last two can copy a value from a property to a GUI field or
vice-versa either individually or across the whole dialog.
really useful unless we simultaneously change the per-iteration deltas
to be smaller. Add another pseudo-tunable to control the speed with
which we change values across iterations. As it turns out, this is
much more effective than the threshold tunable. It does come at the
cost of lower solution performance, however.
I wrote:
> I can confirm this. Layers on the 2D panels (but oddly, only the 2D
> panels) aren't drawing over the background with the current ATI
> drivers.
OK, this turns out to be a trivial fix, although I still think it's a
driver bug. There are two calls to glPolygonOffset in the panel
rendering code (shared by both 2D and 3D panels). One is called
per-layer, and sets up a layer-specific offset. The other is called
for drawing the background textures, to lift them off of any
underlying cockpit geometry.
I was using different "factor" values for each, incorrectly. Patch
attached. It was affecting only 2D panels because the 3D ones don't
use background images.
Problem is, by my reading of the specification the bug should have had
the effect of pushing the background texture *farther* behind the
instruments, instead of pulling it on top of them. Either I'm reading
the spec incorrectly or ATI has inverted the sense of the factor
argument. Dunno, I'll submit a bug report to them and see what
happens.
Link the standalone executable against the source files explicitly rather
than libYASim, as the Irix linker can't handle the unneeded dependance on
other parts of FlightGear.
isn't well-constrained by the solution process is the drag-vs-aoa curve.
The default value that YASim picked was very steep, and resulted in most
of the jets flying their approaches *way* behind the power curve. This
changes the default to be more forgiving, and adds an "idrag" tunable
to the configuration file for tweakers.
Also, change the default gear springiness to be less stiff.
Changed steering to use the rudder command rather than the rudder
position. During taxi, the rudder trim shouldn't affect the steering
in any serious way.
This should be configurable in the aircraft file, since not all
aircraft use the rudder pedals for ground steering.
[In FlightGear, this may make it easier to taxi straight.]
I have updated the lighting code to use fog to try to fade the runway lights
in smoothly, but still keep them from being visible until you are about 7-10
miles out, and then only have them be very faint at first. I think what I
have is a bit nicer than before since it completely avoids the "popping" effect,
but I've very open to tweaking the actual ranges based on people's real
world experiences.
option to specify a starting airport + specific runway. If you don't specify
a runway, you get the one that's closest to your specified (or default)
heading.
To compile the development CVS version of FlightGear(0.9.0) i had to
apply some small changes to SimGear and FlightGear.
The changes need probably some additional ifdefs for other platforms but
since my linux-hd crashed i can't verify that.
Here's a patch to fix the offsets bug. The problem was the transform was just
getting added to a local instance rather than being returned by the function.
> Jim Wilson wrote:
> > How hard would it be to have a property that toggles hotspot
> > visibility? It'd be nice to be able to turn it on and have yellow
> > rectangles show up on the hotspots...
>
> That's not a bad idea.
It's actually an astoundingly good idea, and implementable over lunch
to boot. :)
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property. I mapped a toggle event on this to a
spare joystick button, and had fun. :)
[dpm: bound to Ctrl-C]
avoid having the 2D instruments obscure 3D objects in front of them):
It's related to depth buffer precision. On my Geforce cards (2MX and
3), it never happens with the 24 bit depth buffer you get by default
at 32bpp. At 16bpp, it picks a slimmer depth buffer (probably 16 bit)
and the texture layers bleed through.
The code is using a pretty big argument to glPolygonOffset, and I've
never investigated how small it can be. If someone has a little time
the next time they see this issue, try changing the value of
POFF_UNITS at the top of Cockpit/panel.cxx. Decrease it until the
textures *just* start to interfere with each other, and post the value
that works for you.
The general idea is to help clean up some aspects of the FDM init and be
able to provide startup conditions in a less ambiguous manner.
Previously, things like positions, orientations, and velocites were set on
"the bus". These had to be read by the FDMs which then were supposed to
initialized themselves to those values and turn write around and start
modifying those values. It was messy and cumbersome.
Now, all the initial fdm conditions are written to a sub-[property-]tree
under /sim/presets/
The values in /sim/presets/ always stay set to what the user has specified.
The user can change these at his/her liesure, and then request a "reset"
which will reset to the new conditions. I don't even want to say how this
worked before. :-)
Now, an script, or gui interface can stage a set of initial conditions while
the sim is running (without disrupting it), and then call "reset" to commit
the change.
People who should worry about all this are FDM writters, and a small few
others who care about over all program structure and flow.
duration-sec. This animation may have any number of child objects,
and each one will be displayed for the requested duration before
moving on to the next one.
Added Animation::init for initialization after children have been
added to an animation.
Added a default implementation of Animation::update, and removed all
of the empty ones in derived classes.
Removed tabs from model.cxx.
Indeed, there was no check for panel visibility in the input code. I
guess we've never noticed because nothing was fighting for the same
real estate in the past. This one-liner appears to fix the problem.
[also converted all tabs to spaces for Norm Vine]
That's a little too small to resolve differences at 16bpp. Try the
patch below. It decreases the lifting substantially. You will see
a slight increase in z-buffer flickering but it isn't bad. Note
that we removed the "distance" component the other day, the purpose
of it was to lift the lights higher when viewed at shallow viewing
angles. The distance component is critical for the street lights that
can be very long distances away.
But with the distances we're working with here it really doesn't
do all that much. The factor used in this patch is about as shallow
a lift as can be used when looking straight down at the airport. At
24bpp there's no effect from incorporating a distance component.
The choice is to reintroduce a distance component...one that works (and
only for 16bpp), or alter the factor used in the patch below to strike an
acceptable balance between different viewing angles when in 16bpp mode.
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all "3D" cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another "update" hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
"mouse press delay", and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
parts of the tree left over at the end which the failsafe was catching, but
this could impose a huge framerate hit if the missed portion of the tree
was large enough (and it very often was.)
rabbit lights appear to almost work except the last light or two is never
included in the animation and longer strings of lights are drawn as all
light on ... :-(
a tile boundary. (Potentially imposes a slight performance penalty, but
getting the correct answer needs to be higher priority than getting the
wrong answer really quickly.)
I noticed that textures for scenery static objects are not loaded
anymore for a few weeks. Static objects have absolute path while
random objects and aircraft have relative path but fgLoad3DModel
unconditionally prepend fg_root to the model path. This patch test the
beginning of the model path to choose if fg_root has to be prepended
to the model path.
Ok, I found the problem. You're computing the dynamic pressure in
"psf" and adding it to the static pressure in "inHg" to form the
total pressure. The attached patch is the simple fix to the source.
With that fix, failing the pitot while in cruise at 3k' will cause
the airspeed to indicate beyond redline during climb ... well before 4k'.
Thus, a pitot problem can be detected on any IFR altitude change.
Similarly, failing the static (with working pitot) while cruising 4k'
causes the airspeed to indicate beyond redline during a descent
well before reaching 3k' (during which, of course, the ALT looks fine).
Thus, a static failure can be detected before the aircraft breaks out
of the pilot tolerance range and is blatantly conspicuous soon after.
Now the options can be localized as well. This adds a slight problem for
the --language options, but not that much (worst case, the strings are
loaded twice consuming some more memory). I tried to be as accurate as
posiible when copying the options texts, but there might be some
mostakes left.
This adds supports for a language specific font, defined in locale.xml
I've also moved the fgInitLocale() routine from main.cxx to fg_init.cxx
to prevent an ungly extern definition in options.cxx.
are now working. A runway light is defined by a point and a direction. The
point and direction are combined with the local up vector to create a small
triangle orthogonal to the direction. The two ficticous corners of the
triangle are given an alpha value of zero, the orignal corner is given an
alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT)
mode which means only the corner points are drawn, and since two have alpha=0
only the original point is drawn. This is a long way to go to draw a point,
but it ensures that the point is only visible within 90 degrees of the light
direction, behind the light it is not visible. This is still a long way
to get to drawing a point, but we use an environement map, with the direction
vector as the normal to mimic a light that is brightest when viewed head
on and dimmest when viewed perpendicularly or disappears when viewed from
behind.
- warning, there is a bug in how the current runway light direction vector
is calculated which will adversely effect runway lighting. The airports
should be regenerated in order to fix this problem.
The FGGlobals constructor does not initialise the locale pointer.
Under MSVC, uninitialized pointer have a value of 0xcdcdcdcd, not
0, so a test in mainLoop fails and the program segfault.
This patch set un initial value to locale.
This patch fixes some bugs for correctly reporting un-updated
configuration files, and adds support for a --language=<code>
commandline option, overriding the language specified by the OS.
