These patches add a clock instrument, which allows to model failure ("serviceable") and to adjust the time independently of the system time (defaults to GMT). The main incentive is to make the p51d clock work and adjustable via the knob.
o Offers a time string ("12:03:15") for the LCD or for LED
clocks, or an empty string in case of failure/power off. The
instrument assumes that digital clocks are battery buffered,
so they will be updated even if there's nothing on the display.
o Offers the number of seconds since midnight for analog
clocks, like in the p51d. This number is not increased
if !serviceable. So the clock will stand still and continue
where it stopped when it's serviceable again.
I did not consider voltage yet, because the Mustang's clock will need a lot more current than the LCD clock. The instrument is updated 4 times per second but returns immediately if neither time nor offset changed. The function getGMTString() in fg_props.cxx could be removed after applying these patches.
between temperature at altitude vs. temperature at sea level. The dialog
box asked for temperature at altitude which makes sense, but all the
internal crunching expected temperature at sea level. However, it makes no
logical sense to specify the sea level temperature for different layers so
I changed the internal processing to work with temperature at altitude and
then derive an approximate sea level temperature at the end.
If you know the ground temperature, you can just enter this temperature
for the first boundary layer and the system should do the right thing.
/sim/rendering/horizon-effect
toggle sun and moon resizing effect near the horizon
/sim/rendering/enhanced-lighting
toggle enhanced runway lighting on or off
/sim/rendering/distance-attenuation
add distance attenuation to the enhanced runway lighting
etc.
Improved the weather system to interpolate between different
elevations and deal with boundary-layer conditions. The configuration
properties are now different (see $FG_ROOT/preferences.xml).
This version handles a zero fuel load better. I found that if you try to consume fuel from an empty tank, with zero fuel flow, the FGEngine::Starved flag alternates
Normally for smoothest frame rates you would configure to sync
to your monitor's vertical refresh signal. This is card/platform
dependent ... for instance with Linux/Nvidia there is
an environment variable you can set to enable this feature.
However, if your monitor is refreshing at 60hz and you can't quite sustain
that with flightgear, you can get smoother frame rates by artificially
throttling yourself to 30hz. Note that once you are about about 24fps, it
is *change* or inconsistancy in frame rate that leads to percieved jerkiness.
You want to do whole divisors of your monitor refresh rate, so if your
display is syncing at 75 hz, you might want to try throttling to 25 hz.
Melchior FRANZ:
The reason: these models are to be added to the scenery, but the
scenery isn't yet set up at this point. The correct order is:
- set up model_lib (needed by the scenery)
- set up scenery (needed by the model manager)
- set up model manager
- Modified the rpm vs. suction formula to hit much more realistic numbers.
We should be seeing just over 4 inhg at idle and approaching 5 inhg at
full throttle.
slave to a specific frame rate (i.e. 30hz). This is potentially desireable
if you are running on the ragged edge between 30/60 hz ...
It would be nice at some point to make the code a bit more flexible and
configurable so it could be activated from the command line or preferences
file.
to doing random ground cover objects. This is still in it's embrionic
state so don't expect this to do anything useful or interesting yet.
It shouldn't hurt anything though either.
TITLE: Using delete [] versus delete
The extra "[]" warns the compiler that there is a whole array of objects here so that P's destructor must be called on each element of the array rather than just on P itself (which would be equivalent to the first element only).
> > Here's a patch to add manual-pitch control to the propeller in YASim. A new
> > control axis "PROPPITCH" is added. Requires "manual-pitch" boolean property
> > in the "propeller" tag.
> >
> > Tags and Properties to add in order to enable:
> >
> > manual-pitch="true"
> >
> > <control-input axis="/controls/engines/engine[0]/propeller-pitch"
> > control="PROPPITCH" src0="0" src1="1" dst0="0.40" dst1="0.80"/>
> >
> > Note that for the time being, excessively low RPM or excessively high RPM is
> > brought undercontrol by a scaling range defined in the control-input tag
> > (see "dst0" and "dst1" properties).
I have attached some revisions for the UIUCModel and some LaRCsim.
The only thing you should need to check is LaRCsim.cxx. The file
I attached is a revised version of 1.5 and the latest is 1.7. Also,
uiuc_getwind.c and uiuc_getwind.h are no longer in the LaRCsim
directory. They have been moved over to UIUCModel.
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.
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.
maintianed or upgraded in a *long* time so it didn't support many new
features like the runway lighting. If anyone was using it for anything,
it should not be a huge amount of work to switch to the binary format.
SimGear includes a reader and writer for the binary format.
I modified the files in src/Autopilot to add waypoint capabilities to the telnet port.
'set waypoint <WPT>' will set the next waypoint.
'get waypoint' returns one string which is the list of waypoints.
'set waypoint 0' will delete the next waypoint.
appears still to be indicating.
Added a 'caged' property to the AI, for aerobatic work.
Temporarily disabled tumbling due to pitch, until I can learn more
about it.
Publish the current amount of tumble (-1.0:1.0) under
/instrumentation/attitude-indicator/tumble-norm.
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.
proceed to search for an VOR of that same frequency. On rare occasion
this search could return true with a far distant VOR and cause a small
amount of confusion.
I believe.) :-)
- The height of the navaid was not being properly converted to meters
before being used in our internal calculations. This caused the GS
to be placed too high.
- I was using the wrong trig function to calculate the current approach
angle of the aircraft. The distance to the GS source is the euclidean
point to point distance and represents the hypotenuse (not the ground
distance) so I need to use asin() rather than atan() to calculate the
angle.
- I was calculating distance directly to the GS source, rather than
taking into consideration that the GS transmitter projects a plane,
so I need to take the distance to the line where that plane intersectso
the ground. Previously, the way I modeled my distance calculation, the
GS transmitter effectively formed a 3 degree cone from the source. The GS
transmitter is usually placed a 100 meters or so off the runway edge so
the cone model could never bring you in to the touch down point precisely.
With these changes, the GS will bring you in precisely to the touchdown
point as defined in the default.ils.gz file (it wouldn't before.) The only
issue that remains is that it will bring you in to the elevation defined
in the ILS database, which doesn't necessarily match the DEM/SRTM terrain
at that point. Still on average, this will be a big improvement until we
can do a better job of getting the runway end elevations nailed correctly.
New panels are loaded now
New 3D model gets loaded
Reinitialize more subsystems
Add reinit() to FGFX, sound gets reinitialized
Still a lot needs to be done though.
that after a reset or reposition, several FDM variable were not unbound
correctly and left dangling pointing to unallocated memory. This wasn't
a crash type bug, but those properties then had bogus values. This
specifically prevented the turn coordinator gyro modeling from working after
a reset or reposition.
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.
KEMT (w120n30 scenery), and you will have to set the property
/sim/ai-traffic/enabled to 'true' to see the other plane (and tune
comm1 to 121.2 to hear the other plane's radio calls).
For sounds that play while a value is in transit, use time rather than
the number of frames to judge when to halt the sound because it will be much
more reliable on high performance systems. It currently waits 10 ms.
before stopping the sound, but you might want to fiddle it a little by
changing MAX_TRANSIT_TIME defined int fg_sound.hxx
really see anything different in the day, but as day turns to night the
panel smoothly darkens and the lighting component becomes visible.
Lights are wired to electrical system so if you kill power, you lose the
lights.
The code reads the electrical system config and contructs an internal model.
Nothing is done beyond that yet ... the electrical system is not updated,
nor is it connected to the property system in anyway.
fgLoad3DModel() throws an exception if it fails to load the requested model.
This causes FGTileMgr::update(...) to exit. So I've added a try/catch block
to catch the exception and display an error message instead.
jump whenever you cross a tile, but there are currently a lot of other
positioning problems as well, so this doesn't really detract too much and
means you can play with 3d clouds from just about any starting point.
A bug lurked into our uiuc code.
There are two changes:
[1] Comment out the chunk of code as shown (compare w/ the old)
[2] Put back in the function call, and in that code change AlphaTail to Alpha.
Use getDisplayName instead of duplicated code: gives a better
decision on whether to display the index.
Replace unnecessary node lookups by name with direct access: tidier
and more efficient. E.g. "getValueTypeString
(node->getNode(name.c_str()))" -> "getValueTypeString (child)".
When the scroll bar slider is dragged, the list scrolls only far
enough to see all items; only the arrow buttons can scroll it so far
that the last item goes to the top of the view.
Fix scroll bar proportional size: was wrong when the list was only
a little longer than the visible area.
Minor fixes such as "delete files[i];" -> "delete[] files[i];"
(where the item being deleted is an array of characters) and removal of
global variables.
Smooth scrolling when dragging the slider: one item at a time,
rather than one tenth of the list at a time.
Fix a bug that would have occurred if instantiated with arrows=2.
Sort properties primarily by name and then by numerical index
order, rather than a simple ASCII string order. E.g. "js[1]", "js[2]",
"js[10]" rather than "js[1]", "js[10]", "js[2]".
Avoid crashing if the selected property path does not exist;
display an empty list instead. This cannot happen when the property
picker is working properly, but did happen due to missing indices prior
to this patch, and could happen if the user is allowed to type a
pathname, as in the http and telnet interfaces.
Fix truncation of strings to PUSTRING_MAX: was wrong when string
length was exactly 80.
Fix: move the scroll bar to the top each time a new list is
displayed. It was left at its previous position, while the top of the
new list was displayed, not corresponding to the slider.
Use getDisplayName instead of duplicated code: gives a better
decision on whether to display the index, and avoids invalid property
paths being generated which would previously crash find_props().
Replace unnecessary node lookups by name with direct access: tidier
and more efficient. E.g. "getValueTypeString
(node->getNode(name.c_str()))" -> "getValueTypeString (child)".
speedups to uiuc_menu.cpp.
(Note these were originally submitted before the cutoff date for new
features, but something was corrupted in the transfer so I granted a bit
of leeway in the schedule.)
I removed some pending random code and I also fixed a
small cosmetic glitch where dt_play was cleared before it was printed.
Curt: Erik changed the sound update intervale and I further I tweaked it.
The issue is that if we put too much into the sound buffer, then we can't react
quick enough to sounds like tire squeek that need to be synced with the visuals
and the action. We put too little into the sound buffer and we risk the
audio dropping out for moment if a frame takes longer to draw than the amount
of audio in the buffer.
I've modified the code to display a brief help message instead of the
whole bunch of options. To get the complete message -v or --verbose has
to be added to the command line.
Here is a FGIO class derived from FGSubsystem that replaces the fgIOInit()
and fgIOProcess() functions. The FGIO::update(double delta) doesn't use the
delta argument yet. I suspect it could be used as a replacement for the
calculated interval value but I'm not familiar enough with that piece of code
just yet.
I've also added two "command properties" to fg_commands.cxx that select the
next or previous view. Writing any value to these properties triggers the
corresponding action. As an example I modified my keyboard.xml:
<key n="118">
<name>v</name>
<desc>Next view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/next</property>
<value type="bool">true</value>
</binding>
</key>
<key n="86">
<name>V</name>
<desc>Prev view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/prev</property>
<value type="bool">true</value>
</binding>
</key>
And of course these actions can also be triggered from external scripts via
the props server.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Here are some changes that gave me a significant frame rate increase of about 10 fps with random objects disabled. The interesting thing is that these changes aren't in the main loop but are in tile loader. My guess is that I've reduced the memory footprint just enough to reduce CPU cache misses, though I have no hard evidence of this.
Initially I modified all SGBinObject member functions to pass/return by reference instead of by-value. This gives little or no speed up but allows for some optimizations in fgBinObjLoad(). It is these changes that reduce the number of memory allocations. Needless copying of vectors, and vectors of vectors, can be very memory intensive, especially if they are large.
Anyway I would be interested to see if you get similar results. I would emphasize that the frame rate increase only occurs with random objects disabled. I lose about 10-15 fps on my GF2MX 32MB with random objects, probably a fill-rate limitation or texture memory thing.
* Finally I think I have the partial ssg tree deletion routine working correctly
after I managed to break it (and other confusion in the code cause it to
never be called so I didn't notice the problem.)
* Converted several SG_INFO statements to SG_DEBUG to clean up some
extraneous console output.
* This *should* conclude my investigation into a massive memory leak. :-)
Animations are now contained within the scene graph itself and are
updated whenever the graph is traversed -- that saves time by not
updating animations not currently in sight, and it allows animations
to be used for static objects and random objects as well.
Added new FGModelLoader and FGTextureLoader classes. These are intern
tables for models, to guarantee (mostly) that no model is loaded more
than once. FGTextureLoader is not yet used anywhere, but
FGModelLoader is now in place everywhere that ssgLoad* used to be
used (thus adding the ability to use animations).
In the future, FGModelLoader will add some interesting functionality,
including the ability to reload 3D models on the fly.
I've merged FGProps and FGTelnet so there is just a single property server.
I've left in the --telnet=port# command line option but it could be removed
if we wanted to. The command line accepts two forms of the --props option.
The original (--props=medium,dir,hz,host,port#,style) and the shorter
--props=port#. If you accept this change then src/Network/telnet.[ch]xx
can be removed from the cvs repository.
Your 3D models cause a stackdump when the base is separate from the
root. I've attached a patched newmat.cxx - you may want to test it
before committing!
I changed the code such that textures terrain also takes ambient,
diffuse, specular and emissive from the materials.xml file.
[note from dpm: doesn't seem to work yet]
When the scroll bar slider is dragged, the list scrolls only far enough to see all items; only the arrow buttons can scroll it so far that the last item goes to the top of the view.
Fix scroll bar proportional size: was wrong when the list was only a little longer than the visible area.
Minor fixes such as "delete files[i];" -> "delete[] files[i];" (where the item being deleted is an array of characters) and removal of global variables.
Smooth scrolling when dragging the slider: one item at a time, rather than one tenth of the list at a time.
Fix a bug that would have occurred if instantiated with arrows=2.
Sort properties primarily by name and then by numerical index order, rather than a simple ASCII string order. E.g. "js[1]", "js[2]", "js[10]" rather than "js[1]", "js[10]", "js[2]".
Avoid crashing if the selected property path does not exist; display an empty list instead. This cannot happen when the property picker is working properly, but did happen due to missing indices prior to this patch, and could happen if the user is allowed to type a pathname, as in the http and telnet interfaces.
Fix truncation of strings to PUSTRING_MAX: was wrong when string length was exactly 80.
Fix: move the scroll bar to the top each time a new list is displayed. It was left at its previous position, while the top of the new list was displayed, not corresponding to the slider.
Use getDisplayName instead of duplicated code: gives a better decision on whether to display the index, and avoids invalid property paths being generated which would previously crash find_props().
Replace unnecessary node lookups by name with direct access: tidier and more efficient. E.g. "getValueTypeString (node->getNode(name.c_str()))" -> "getValueTypeString (child)".
name "random-objects".
Put the random objects for each tile inside a top-level
ssgRangeSelector with a maximum range of 20km. This saves a lot of
range tests for distant tiles, and gives about a 10% framerate boost
on my card at 1000ft AGL (possibly more on faster cards).
instead, use a separate dummy bounding sphere for each triangle and
each tile, with the actual bounds, to make sure that objects are
always added when they should be in sight.
the tile cache it's ssg elements are disconnected from the main ssg scene
graph, and then the tile is thrown on the end of a delete queue. The
tilemgr->update() routine runs every frame. It looks at this queue and if
it is non-empty, it incrementally frees the compents of the first tile
on the queue. When the tile is completely free it is removed from the queue.
The amount of time to free the memory for even a single tile can be quite
substantial, especially with the increased overhead of dynamic/random
ground objects. This change allows the system to spread the work of freeing
tile memory out over many frames so you don't get a noticable single frame
hit or stutter.
the triangles containing the objects were out of the view Frustum,
they were never traversed by ssg (and thus, never culled). Now, every
200 frames, do a pass through the whole scene graph with cull-testing
disabled and without drawing anything; that will allow random-objects
to be collected incrementally.
-----------------------------------------------
Fixed a segfault on exit.
Changed the radius of the dummy bounding sphere from 10m to 1000m to
ensure that FOV culling doesn't leave anything out.
Allow an object to have more than one variant model, which will be
chosen randomly. Simply repeat the <path>...</path> property.
Removed the <billboard> property and replaced it with <heading-type>,
which can be set to "fixed" (leave the model oriented as it is),
"random" (give the model a random heading between 0 and 359 deg), or
"billboard" (always turn the model to face the camera). The default
is "fixed". Models look much better when they are not all facing the
same direction.
Allow the user to group models with the same visual range, so that
there can be *many* fewer nodes in the scene graph when the models are
not visible. This causes an XML-format change, so that instead of
<object>
<range-m>...</range-m>
...
</object>
<object>
<range-m>...</range-m>
...
</object>
...
we now have
<object-group>
<range-m>...</range-m>
<object>
...
</object>
<object>
...
</object>
...
</object-group>
Every object in a group can still have its own model(s), coverage, and
heading-type, but they all share the same range selector.
This change should already help users with tight memory constraints,
but it will matter much more when we add more object types -- for
example, we can now add dozens of different urban building types
without bloating the scene graph or slowing down the LOD tests for
tris that are out of range (i.e. most of them).
1. Only one copy of each object (and its texture) is stored in memory,
no matter how many materials use it.
2. Random objects are added to a triangle only when the objects are in
range, and they are deleted as soon as the objects are out of
range. That way, only a relatively small number of ssg nodes are
used at any one time.
This patch seems to eliminate freezes when tiles are freed. There are
occasional stutters at extremely high speeds (i.e. over 3,000kt), but
it seems smooth enough for normal aviation speeds.
- no extra nodes are created at all if the material has no random
objects defined
- the range selector is place correctly under the transformation
- there is only one range selector for each object type in each
triangle (experimental -- doesn't seem to make a difference in speed
or memory)
This patch removes Curt's patch that randomized ranges slightly, since
individual random objects no longer have their own range selectors.
It also leaves the object-group-range value unused, for now.
- tidies up the update-time-step handling (making it a simple "dt");
- makes the altimeter get a proper pressure, and the (unused) vacuum
calculation get a proper RPM (*);
- replaces property name look-ups with static pointers to property nodes.
Notes from DPM:
- the static pointers are a very bad idea, but they're only temporary;
I plan to make FGSteam into a proper subsystem soon, and then they
can be member variables
- I fixed the patch to get the current static pressure from the
/environment/pressure-inhg property, so that the altimeter interacts
properly with FGEnvironment
The present sets of bindings result in the throttle being "squared"
about its centre, which is silly. This is because the "squared"
parameter is not set by the throttle binding, but the default is
"true". We discussed this before and I think there was general
agreement that the default should be "false" on the basis of
generality.
situations for every kind of airplane. But at the moment we have nothing
implimented and this will cover the simpler cases until someone has a
chance to impliment a fuller solution.
GL/gl.h can't be included at the first position in windows. It requires
the inclusion of windows.h that must be included in other fgfs header
file. I only move down #include <GL/gl.h>
This patch eliminates about 10 of valgrind's "Use of uninitialised
value of size ..." messages. They are all caused by approachlist building
incomplete FGApproach class instances and then copying them into the
approchlist container, hence copying data garbage.
I know, I couldn't win a beauty contest with this patch, but the
alternative approach -- letting operator<< always leave complete
entries -- didn't look any better. And I do only add those seemingly
useless initialization where the values would be used uninitialized
else. The constructors are only run during setup and won't slow fgfs
down at runtime.
Make locally-used strings local instead of global. (The safety and
cleanliness benefit outweights the slight performance hit. If
performance is an issue, the way these strings are used should be
optimised.) Use existing defined constant instead of a literal
number.
+ The panel(s) are now an first-class SSG node inside the aircraft
scene graph. There's a little code added to model.cxx to handle the
parsing, but most of the changes are inside the new FGPanelNode
class (Model/panelnode.[ch]xx).
+ The old FGPanel source changed a lot, but mostly cosmetically. The
virtual-cockpit code moved out into FGPanelNode, and the core
rendering has been abstracted into a draw() method that doesn't try
to set any OpenGL state. I also replaced the old inter-layer offset
code with glPolygonOffset, as calculating the right Z values is hard
across the funky modelview matrix I need to use. The older virtual
panel code got away with it by disabling depth test, thus the "panel
draws on top of yoke" bug. PolygonOffset is really the appropriate
solution for this sort of task anyway.
+ The /sim/virtual-cockpit property is no more. The 2D panels are
still specified in the -set.xml file, but 3D panels are part of the
model file.
+ You can have as many 3D panels as you like.
Problems:
+ The mouse support isn't ready yet, so the 3D panels still aren't
interactive. Soon to come.
+ Being part of the same scene graph as the model, the 3D panels now
"jitter" in exactly the same way. While this makes the jitter of
the attitude gyro less noticeable, it's still *very* noticeable and
annoying. I looked hard for this, and am at this point convinced
that the problem is with the two orientation computations. We have
one in FGLocation that is used by the model code, and one in
FGViewer that is used at the top of the scene graph. My suspicion
is that they don't agree exactly, so the final orientation matrix is
the right answer plus the difference. I did rule out the FDMs
though. None of them show more than about 0.0001 degree of
orientation change between frames for a stopped aircraft. That's
within an order of magnitude of what you'd expect for the
orientation change due to the rotation of the earth (which we don't
model -- I cite it only as evidence of how small this is); far, far
less than one pixel on the screen.
[and later]
OK, this is fixed by the attached panel.cxx file. What's happened is
that the winding order for the text layer's polygons is wrong, so I
reverse it before drawing. That's largely a hatchet job to make
things work for now, though. We should figure out why the winding
order is wrong for only text layers and fix it. I checked the plib
sources -- they're definitely doing things CCW, as is all the rest of
the panel code.
Odd. I'm also not sure why the 2D panel doesn't care (it works in
both winding orders). But this will allow you to check in working
code, anyway. There's a big comment to this effect in there.
instrument. This needs to move somewhere permanent.
Also, remove a bogus fuel consumption setting that (1) was off by a factor
of 3600 (hours, not seconds) and (2) collided with identical code in FGFDM.
the amount of drag that the produced lift *would* have produced given an
unflapped air surface. A nifty trick involving the assumption that AoA is
small works for this, and produces plausible results in the high AoA case
as well.
Also, trim for approach using the elevator-trim control, not elevator.
Just cosmetic for current planes, but future ones might have differing
implementations of trim.
This is the small code fix which is needed for the new options.xml file.
It is needed because otherwise the "--prop:name=value" is showed
incorrectly.
There is another problem though, when compiling with --without-logging
the help message isn't displayed at all! We *must* change that somehow.
Curt: good point, the SG_LOG()'s have been switched to cout's ...
(and not the throttle setting), but the recalculation left in a degeneracy
when the target/throttle setting was exactly zero. Zero times a big number
is still zero. Fixed to use real math, not theoretical math.
- More progress with proper radio freq tuning and proper interpreting of the
hardware values.
- Filter ignition and flap switch values since the hardware implimentation has
a dead zone where the value can go to zero in the middle of a change in
switch position.
I've updated the FIXME in the code, and fixed a typo (descr instead of
description), but the SG_LOG() functions doesn't produce any output for
me. Could you confirm it's still working for you?
Curt Olson:
I did a bit of further tweaking and it all looks good now. The tricky thing
is that SG_LOG() always appends an endl at the end of every message.
This is an enhanced version of the options patch.
It's more robust now, and gives some helpful information if something
goes wrong. Also the naming in the options.xml file has changed to the
syntax David suggested.
Since no one objected to the patch I think it is safe to included it.
class, FGModelPlacement, while FG3DModel retains control of animation.
This way, we can have a single, top-level placement, but multiple
layers of nested models underneath. To include a nested model, use
something like this in the XML wrapper:
<model>
<path>Models/Stuff/my-component.xml</path>
<offsets>
<roll-offset-deg>45</roll-offset-deg>
</offsets>
</model>
contain colon-separated ranges. For examples, winds from 180 degrees
10 knots gusting 15 knots would be
--wind=180@10:15
Winds variable from 180-220 degrees 5 knots would be
--wind=180:220@5
FGEnvironment does not yet support variable-direction winds, so
nothing will yet happen in the second case.
Modifications to support querying navaid database by station ID (not just
frequency.) Some corresponding changes to testnavs.cxx to test new
functionality.
This is a small patch that makes the autopilot work much better with big heavy
airliners as well as the small Cessnas. Of course this doesn't address the
way autopilots should be modeled.
But by making a couple changes the "George" is now capable of landing either a
C172 or a 747 very close to the center line of the runway with a moderate
cross breeze (15-20kt).
The changes:
- Added turn configurability so that things like Max Aileron and Roll can be
configured per aircraft.
- Enhanced localizer routine (NAV mode) to begin lining up the aircraft as soon
as the cone is entered. The former model is adopted for the last 5km of the
approach in order to ensure greater precision (makes a very slight difference).
[float cast added by David Megginson to keep G++ 3.0 happy]
This is a small patch that makes the autopilot work much better with big heavy
airliners as well as the small Cessnas. Of course this doesn't address the
way autopilots should be modeled.
But by making a couple changes the "George" is now capable of landing either a
C172 or a 747 very close to the center line of the runway with a moderate
cross breeze (15-20kt).
The changes:
- Added turn configurability so that things like Max Aileron and Roll can be
configured per aircraft.
- Enhanced localizer routine (NAV mode) to begin lining up the aircraft as soon
as the cone is entered. The former model is adopted for the last 5km of the
approach in order to ensure greater precision (makes a very slight difference).
[float cast added by David Megginson to keep G++ 3.0 happy]
1. Typo where /environment/density-inhg instead of
/environment/density-slugft3 was flagged as archivable.
2. Density should no longer be archivable anyway, since it is
calculated internally and not directly settable by the user.
temperature, and dewpoint. The /environment/density-sea-level-slugft3
property has been removed, and the /environment/density-slugft3
property is read-only.
Fetch all pending remote fdm network packets so there is not chance of
getting behind.
Add support for driving control panel lights.
Working on better modeling KX 155 tuning behavior.
won't apply the right gross weight due to fuel differences.
When solving for zero force, do so in the global frame, not the
aircraft's. In principle, this shouldn't matter (zero is zero in all
frames), but in practice this should help to avoid oscillations.
Calculating lift as force perpendicular to the ground (and not the
wing plane) is clearly the Right Thing, anyway.
Also added support for a /yasim/gross-weight-lbs property, which
should be generically useful.
when the lift/drag are really solid. And defer the approach trim until
the all four of the other variables are perfect. I believe this should
fix the solution failures under gcc 2.95.2.
implicitly in PropEngine by disallowing negative torques, but that was
removed at some point. We really need the explosion protection here
at the source.
This patch adds "elapsed time" support to the sound code.
It is now possible to define <internal>dt_play</internal> or
<internal>dt_stop</internal> instead of a propery in the <volume> and
<pitch> sections of the configuration file.
This is a small fix for what turned out to be a major bug. Ground elevation
was calculated incorrectly when distant from one of the view locations. This
resulted in several problems including bizarre gear trimming, mid air
"crashes" (as in thinking we hit the ground) and so on when close to or on the
ground.
Unfortunately it does require a second ssg traversal when in tower view
(only), but the increased load isn't all that noticable. For the time being
this really is the best solution. In a future update I will be eliminating
the unecessary per frame traversals for the static views (without having to
maintain multiple ssgRoots).
When we go to multiple FDM instances we will perhaps need to put the ssg
traversal and ground elevation queries for the FDMs into an event timer that
updates the FDMs ground elevation in a round robin fashion (maybe every 1/n
seconds where n is the number of FDM instances running).
layers. The properties controlling each layer are inside
/environment/clouds/layer[n], and the available properties are type
("clear", "overcast", "mostly-cloudy", "mostly-sunny", or "cirrus"),
span-m (should be about 40000), elevation-ft, thickness-ft, and
transition-ft.
This is a new improved patch for the previous tile manager fixes.
Rather than building dependencies between FGlocation or the viewer or fdm with
tilemgr what I ended up doing was linking the pieces together in the Mainloop
in main.cxx. You'll see what I mean...it's been commented fairly well. More
than likely we should move that chunk somewhere...just not sure where yet.
The changes seem clean now. As I get more ideas there could be some further
improvement in organizing the update in tilemgr. You'll note that I left an
override in there for the tilemgr::update() function to preserve earlier
functionality if someone needs it (e.g. usage independent of an fdm or
viewer), not to mention there are a few places in flightgear that call it
directly that have not been changed to the new interface (and may not need to be).
The code has been optimized to avoid duplicate traversals and seems to run
generally quite well. Note that there can be a short delay reloading tiles
that have been dropped from static views. We could call the tile scheduler on
a view switch, but it's not a big deal and at the moment I'd like to get this
in so people can try it and comment on it as it is.
Everything has been resycned with CVS tonight and I've included the
description submitted earlier (below).
Best,
Jim
Changes synced with CVS approx 20:30EDT 2002-05-09 (after this evenings updates).
Files:
http://www.spiderbark.com/fgfs/viewer-update-20020516.tar.gz
or
http://www.spiderbark.com/fgfs/viewer-update-20020516.diffs.gz
Description:
In a nutshell, these patches begin to take what was one value for ground
elevation and calculate ground elevation values seperately for the FDM and the
viewer (eye position). Several outstanding view related bugs have been fixed.
With the introduction of the new viewer code a lot of that Flight Gear code
broke related to use of a global variable called "scenery.cur_elev".
Therefore the ground_elevation and other associated items (like the current
tile bucket) is maintained per FDM instance and per View. Each of these has a
"point" or location that can be identified. See changes to FGLocation class
and main.cxx.
Most of the problems related to the new viewer in terms of sky, ground and
runway lights, and tower views are fixed.
There are four minor problems remaining. 1) The sun/moon spins when you pan
the "lookat" tower view only (view #3). 2) Under stress (esp. magic carpet
full speed with max visibility), there is a memory leak in the tile caching
that was not introduced with these changes. 3) I have not tested these
changes or made corrections to the ADA or External FDM interfaces. 4) The
change view function doesn't call the time/light update (not a problem unless
a tower is very far away).
Details:
FDM/flight.cxx, flight.hxx - FGInterface ties to FGAircraftModel so that it's
location data can be accessed for runway (ground elevation under aircraft)
elevation.
FDM/larsim.cxx, larcsim.hxx - gets runway elevation from FGInterface now.
Commented out function that is causing a namespace conflict, hasn't been
called with recent code anyway.
FDM/JSBSim/JSBSim.cxx, YASim/YASim.cxx - gets runway elevation from
FGInterface now.
Scenery/newcache.cxx, newcache.hxx - changed caching scheme to time based
(oldest tiles discard).
Scenery/tileentry.cxx, tileentry.hxx - added place to record time, changed
rendering to reference viewer altitude in order to fix a problem with ground
and runway lights.
Scenery/tilemgr.cxx, tilemgr.hxx - Modified update() to accept values for
multiple locations. Refresh function added in order to periodically make
the tiles current for a non-moving view (like a tower).
Main/fg_init.cxx - register event for making tiles current in a non-moving
view (like a tower).
Main/location.hxx - added support for current ground elevation data.
Main/main.cxx - added second tilemgr call for fdm, fixed places where viewer
position data was required for correct sky rendering.
Main/options.cxx - fixed segfault reported by Curtis when using --view-offset
command line parameter.
Main/viewer.cxx, viewer.hxx - removed fudging of view position. Fixed numerous
bugs that were causing eye and target values to get mixed up.
the wrong place. The Atmosphere::getStd*() calls are used by the
solver, and thus really need to return values for a "standard"
atmosphere. Otherwise, an aircraft started up in Moscow will behave
differently than one initialized in Cairo. :)
The place where environmental pressure and temperature get inspected
at runtime is in YASim.cxx. The changes there, happily, end up being
even smaller than the ones to Atmosphere. This ends up replacing code
only, and removing some comments.
Here is the new super improved telnet property interface. CVS changelog
is at the end of this message. Once this new telnet code is in and
compiles every where we can remove Network/props.[ch]xx. I've added a
--telnet=<port> command line option to invoke the new server. Later on
we could remove the --props option, or least change it to invoke the new
server. I'll let you decide.
I've added some new commands to the telnet interface:
view next Select the next view.
view prev Select the previous view.
view set <n> Select view 'n'
view get Return index of current view
I'm not sure if these same effects could be achieved through property
operations. The commands provide a convenient shortcut in any case.
I'm also planning on adding a panel command to manipulate panels and
objects contained therein (eg simulated mouse clicks). There is going
to be some commonality with the command objects so we may need to
rationalize this in the near future.
Finally, I've also included my python stuff. This is still very much a
work in progress, basically I've been using it to test the new telnet
server. I have tested it with python 2.2. Feel free to add it to the
repository if you want. I would suggest a scripts/python directory
CVS Changelog
Network/telnet.cxx: New property telnet protocol interface. It supports
the same user interface provided by the --props server. Additionally it
handles multiple simultaneous connections. Added "view" command to
manipulate viewmgr.
Network/protocol.hxx: Added protocol configuration exception.
Main/fg_io.cxx: Added new "telnet" protocol. Added protocol
configuration parse exceptions. Simplified protocol configuration
parsing.
Main/options.cxx: Added --telnet=<port> command line option and help
message.
set_Density; since JSBSim doesn't override the get_* methods from
FGInterface as well, the wrong values are always set anyway.
Take the static temperature, static pressure, and density values from
an external source if requested by the
/environment/params/control-fdm-atmosphere property. This isn't
working properly yet for JSBSim because of interactions with the
trimming routine.
Stratosphere). The atmospheric properties are as follow:
/environment/temperature-sea-level-degc
/environment/temperature-degc
/environment/pressure-sea-level-inhg
/environment/pressure-inhg
/environment/density-sea-level-slugft3
/environment/density-slugft3
Setting either the sea-level or altitude value automatically sets the
other value appropriate, except for temperature at altitude above the
Troposphere (where there's no reliable way to back-calculate it). The
atmosphere model appears in the atmosphere_data array in
environment.cxx, and can easily be extended into the upper
stratosphere and beyond.
These are not yet tied into the FDMs or steam module.
Removed configuration option --with-new-environment and
FG_NEW_ENVIRONMENT macro.
Added configuration option --with-weathercm and FG_WEATHERCM macro.
FGEnvironment is now the default; use --with-weathercm to get the old
weather.
object rather than a pointer.
FGEnvironment now has the beginning of an atmospheric model, and will
recalculate temperature (not pressure or density, yet) based on
elevation.
FGEnvironment has a copy constructor.
- changed FGSubsystem::update(int) to
FGSubsystem::update(delta_time_sec); the argument is now delta time
in seconds rather than milliseconds
- added FGSubsystem::suspend(), FGSubsystem::suspend(bool),
FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with
default implementations; is_suspended takes account of the master
freeze as well as the subsystem's individual suspended state
- the FDMs now use the delta time argument the same as the rest of
FlightGear; formerly, main.cxx made a special case and passed a
multiloop argument
- FDMs now calculate multiloop internally instead of relying on
main.cxx
There are probably some problems -- I've done basic testing with the
major FDMs and subsystems, but we'll probably need a few weeks to
sniff out bugs.
The FlightGear patch is to take account the change in the getChildren
function that now returns a vector<SGPropertyNode_ptr>. If the
removeChild functionnality is to be added in FlightGear, all those
SGPropertyNode * floating around should be changed to
SGPropertyNode_ptr.
- don't send "set" confirmation when in data mode. If an external
program really cares if the settings were accepted, which is
rather unlikely, it simply has to "get" the property again.
The returned line would have been a pain to parse, anyway
(something like "from-model = 'true' (bool)").
- do not only "set" the first token, but concatenate all given
tokens with a space in between. This won't be used much, but
makes sense for setting strings, while it does no harm when setting
numbers. Silently ignoring all but the first token is impolite. ;-)
- remove old, commented out debug message that doesn't make much
sense any more.
Due to jumpy joystick read-outs the UFO jitters a lot in turns.
This patch implements simple damping for aileron/elevator/throttle.
Furthermore it lets the UFO fly backwards if brake[0] is active
(by default associated with the joystick's fire button). After all,
everyone knows that UFO's can fly backwards!
It's cumbersome to use the MagicCarpet as 3D cursor, because everytime
you shoot over the target you have first to turn by 180 degrees and to
fly back.
This patch lets the magic carpet fly backwards if brake[0] is active,
which is by default associated with the joystick's fire button.
Turns out it was a problem with a long string, not the font. Plib is limited
to 80 characters in things like this listbox. BTW I checked and all the fonts
are missing those characters. So, no point in changing.
Description:
Fixed segfault caused by long string.
> I have attached some new additions to the UIUC code. Most of the
> changes allow for the addition of apparent mass. This is very
> useful with light aircraft and gliders.
I changed the sound code to let it use FGCondition. This changes the
code and configuration files rather drastically. Furthermore I've added
an in-transit mode which plays the sound only when the tied property is
changing.
Changes:
Code:
* Added condition support to trigger an event
* Removed the <type> section from the main event definition
(this could be done using conditions)
* Removed the abillity to use several events with the same name,
instead it is required to use conditions.
* Updated the README.xmlsound
Base package:
* Changed the configuration files accordingly.
* Changed flaps and gear to use the new in-stransit mode.
* Changed the flps.wav file so it can be looped.
* Created a new gear.wav file (whcih can be looped)
and a gear-lck.wav file for gear locking sound.
IMPORTANT:
To change existing configuration files to the new ones, it is important
to pack events with the same name together into one singel event, using
the condition specification. Also, when using special types (inverted,
flip-flop, raise or fall) these should be changed to a conditions also.
For more information, please look at
FLightGear/docs-mini/README.xmlsound and the supplied aircraft
configuration files located under FlightGear/Aircraft (espesially
c172/c172-sound.xml and c310/c310-sound.xml).
default implementation that uses user-supplied params. Currently, the
only parameters are
/environment/params/base-wind-speed-kt
/environment/params/gust-wind-speed-kt
but others will show up soon (i.e. sheer, variable direction, variable
visibility, etc.). To activate these properties, you have to
configure --with-new-environment.
The gusting function is simplistic and needs to be replaced with
something better, though it doesn't feel too far off.
subproperty, 'spherical', which is true if the object has spherical
symmetry and should rotate around both the x-axis and z-axis to face
the camera (i.e. a simple cloud), and false if the object has only
cylindrical symmetry and should rotate only around the z-axis (i.e. a
tree).
1. If /position/longitude-deg and /position/latitude-deg are in range,
use them.
2. Otherwise, if /sim/startup/airport-id is not empty, use it.
3. Otherwise, set the lon/lat to the middle of the KSFO field.
The default used to be Globe, AZ, but that doesn't make sense since we
don't distribute that scenery by default any more.
With this change, starting from a save file seems to work properly:
fgfs myflight.sav
- Added initial_value argument, in milliseconds, that specifies when
event is first run. The default value of -1 triggers the event
immediately as per the existing behaviour. A repeat_value greater than
zero runs the event no less than every 'repeat_value' milliseconds
afterwards. A repeat_value of zero deletes the event.
- Modified run queue behaviour such that only one event per frame is
run.
ATCmgr.cxx:148 says:
// Returns true if the airport is found in the map
Yes, it returns true if the airport has been found. But it fails
to return the airport data. Just plays around with a local pointer. ;-)
I have finished working the bugs out of my "Enhanced" version of the Magic
Carpet FDM. The UFO FDM works the same as the Magic Carpet with the
following exceptions:
The aircraft's pitch is determined by the Elevator setting (with a pitch
rate of 45 degrees per second).
Climb is forward velocity * sin(pitch)
Speed is forward velocity * soc(pitch)
Roll is tied to the aileron (again, with a roll rate of 45 degrees per
second)
Turn rate is sin(roll) * 45 degrees.
Yes, this does mean that turning is quite a bit more sluggish than
climbing.
If you are wondering why a UFO FDM, it is because it's best that I not
replace the existing magic carpet and this FDM does behave like a UFO (it
hovers, can spin and pitch while hovering, and does not obey the laws of
physics ;)
SGTimeStamp "-" operator returns it's result in usec's, there is an upper bound of 37.8 minutes on the maximum difference this operator can reliably report
before the math overflows. I change the global "int elapsed_time_ms" variable
to a "double sim_time_ms" and restructured how the value is calculated.
----
The practical result of the overflow bug is that a large negative dt was
passed to the event manager and the end effect was that no events would
be run until their counters caught up ... in another 37.8 minutes or so.
This led to an investigation into why the ident playing didn't work anymore.
Recent changes in the sound manager broke some assumptions the radiostack
code was making. These patches should hopefully fix all that back up.
Erik, please review these changes to double check I didn't do more damage
than good. :-)
These are the updates for the View manager properties. Removed the last of
items (within the viewer/viewmgr) hard coded to view number. Added support
for per view configuration of ground level nearplane value. Tower views look
very nice with little or no z-buffer problem in the models. Pilot offset
dialog can be used to move eye in all views.
>90deg, even though src/Cockpit/radiostack.cxx has code to deal with
those; as a result, no backcourses were getting through.
This fix allows the common case of backcourses to work again, but
breaks the uncommon case of a runway using the same frequency for two
separate localizers. That special case will have to be detected
somehow. Still, this fixes more approaches than it breaks.
graph as the terrain, except for internal cockpit view. The SSG
scene-graph variables (except for the lighting root -- I'll get that
later) are now held in globals.hxx.
FGModelMgr::draw() is obsolete; I'll remove it in a future revision.
Minor fixes. Made some changes to get lighting correct for time of day
for now. MSVC compatibility fix and returned to clearing z-buffer only in
LOOKFROM (formerly pilot view).
[dpm: removed the last one, since I had already made a similar patch]
else and *doesn't* clear the z-buffer when in external view; tighten
the far plane for internal view back to 100m to give us maximum
precision (this will be important for some instruments; I might even
move it to 50m).
Here are the Boost-less FGEventMgr updates I promised.
Removed Boost dependencies from FGEventMgr.
Removed Boost configure check.
fgMethodCallback now handles const member functions.
I've successfully tested these changes with gcc and msvc.
Synced to CVS 19:36 EDT 2002-04-10 (after this evenings JSMsim and Base
package updates).
Description:
Added FGLocation class which is new home for calculating matrix rotations.
Viewer can now be configured to access rotations created by the model rather
than repeating the same calculations again.
Changed model initialization for the time being so that its location data is
available for the viewer (currently required by other subsystems). At some
point we can move this back to fg_init along with the viewer initialization.
Seperated the update from the draw function in the model code. The viewer
code needs the same matrix data, and moving the update portion at this time
does not increase the number of matrix math iterations.
Moved the model draw so that it always appears "in front" of lights and clouds.
Reogranized viewer update routine for using the FGLocation class and
simplified some more tasks. The routine is fairly easy to follow now, with
the steps ordered and spelled out in comments.
Viewmgr only updates the current (visible) view now, with the exception of an
old reference to "chase view" that will be corrected in forthcoming changes.
Also will be doing some work on the viewmgr outputs.
Model is now clears the z-buffer in all modes. This will be changed with the
next viewmgr update. The only side effect is that models always disappear
when over 5km distant from the eye point (can't really see them anyway:-)).
Other than a flag to indicate "internal" view I don't anticipate the
configuration interface for viewmgr/views will be changed a lot for now. It
is close to done. The next viewmgr update will however rework the outputs so
may change location.
This code will run with the previous version of preferences.xml, but will run
faster with the newer version. I am attaching a preferences.xml that should
not be commited before the code. All the changes are in the /sim/view section
and should show a simpler view configuration that references model locations.
Note that I've added a 2nd tower view in "lookfrom" mode for illustration
purposes. You can look around using the mouse. You may want to remove that or
comment it out.
Synced to CVS 19:36 EDT 2002-04-10 (after this evenings JSMsim and Base
package updates).
Description:
Added FGLocation class which is new home for calculating matrix rotations.
Viewer can now be configured to access rotations created by the model rather
than repeating the same calculations again.
Changed model initialization for the time being so that its location data is
available for the viewer (currently required by other subsystems). At some
point we can move this back to fg_init along with the viewer initialization.
Seperated the update from the draw function in the model code. The viewer
code needs the same matrix data, and moving the update portion at this time
does not increase the number of matrix math iterations.
Moved the model draw so that it always appears "in front" of lights and clouds.
Reogranized viewer update routine for using the FGLocation class and
simplified some more tasks. The routine is fairly easy to follow now, with
the steps ordered and spelled out in comments.
Viewmgr only updates the current (visible) view now, with the exception of an
old reference to "chase view" that will be corrected in forthcoming changes.
Also will be doing some work on the viewmgr outputs.
Model is now clears the z-buffer in all modes. This will be changed with the
next viewmgr update. The only side effect is that models always disappear
when over 5km distant from the eye point (can't really see them anyway:-)).
Other than a flag to indicate "internal" view I don't anticipate the
configuration interface for viewmgr/views will be changed a lot for now. It
is close to done. The next viewmgr update will however rework the outputs so
you can expect that the data that viewmgr is writing to the property tree
may change location.
This code will run with the previous version of preferences.xml, but will run
faster with the newer version. I am attaching a preferences.xml that should
not be commited before the code. All the changes are in the /sim/view section
and should show a simpler view configuration that references model locations.
Note that I've added a 2nd tower view in "lookfrom" mode for illustration
purposes. You can look around using the mouse. You may want to remove that or
comment it out.
- Throttle control position
- Mixture control position
- Magneto/starter control position
Added support for receiving:
- Engine state (off, cranking, running)
- RPM
- Fuel Flow
- EGT
- Oil Temp
- Oil Pressure
- Fuel tank quantity
- Weight on wheels
I made these modifications to correct the problem of getter functions
returning pointers to local variables. Those variables are no longer
locals and become static. One should be aware that it kills reentrancy
!
This patch moves built-in Class (for now only mag-ribbon) into special
directory as you have written it in TODO: in comments of this class in
panel_io.cxx. IMHO it is good idea. I want to play with built-in
classes and OpenGC and this will be useful.
Made a couple more adjustments, now the function builds the
transformation matrix (sans the translation) directly from the five
inputs. After realizing that it may be necessary for the new location
class to publish a world up vector, comments were added indicating
which values constitute world up.
Minor patches to initial tower view code. Added calculation for "tower" at
any airport, placed a couple fractions of a degree off the center. Moved the
farplane from 100m to 5km so that "lookfrom" mode can see the model. 5km is
still in a reasonable range for a depth buffer. Note that looking at a model
anything but a small distance will cause some problems on older cards.
Temporarily changed viewer to always report elevation/lon/lat of the aircraft
in order to avoid a problem with the ground trim getting recalculated when
tower and aircraft are on different tiles.
radiostack.cxx, fg_init.cxx and main.cxx. If these changes are accepted
then you can remove Time/event.[ch]xx and Include/fg_callback.hxx from
the repository.
Tower View and viewer config is in place. Note that the interface is
still in a state of flux. A couple of the config items (namely the
offsets) are still using the old settings. The tower is hard coded
into the base package for a position off the starting runway at KSFO
and is probably not in the right place for there even. Looks pretty
cool though! Tower View is the third view. If you aren't at KSFO
you'll just see blank space in view 3. It's looking through the earth or
something like that :-). Important note: zoom in with a few
hits of the "x" key to see the plane better in tower view.
This should fix it. The problem wasn't the rotations but a difference in
the translations. Note that this fix also puts the wheels back on top of the
pavement when in external view.
Changed the steering gain from +/-0.1 to +/-1.0, so that the steering
angle for the nosewheel (when present) is the same as the rudder
deflection angle. That's probably not exactly right, but it's much
better than we had before -- you can now steer the plane on the ground
reasonably during taxiing.
case logging is disabled). This way, when people specify a
non-existant aircraft or have an error in a custom XML file, they'll
get an error report, at least.
system. A chap from Germany called Alexander Kappes (cc'd) got
in touch with me a few weeks ago and has written the start of
Approach control. At the moment tuning in to a valid approach
frequency (Dortmund or East Midlands) should result in vectors to
a spot about 3 miles from the active runway, and a telling off if you
stray too far from the correct course, in the console window. He
seems to know what he's doing so expect this to improve rapidly!!
I've added a rudimentry AI manager and a hardwired Cessna at
KEMT on the runway - I'll remove it before the next release if I don't
have it flying by then. There seems to be an issue with framerate
which drops alarmingly when looking at it - I've a feeling that I've
possibly created several Cessnas on top of each other, but am not
sure.
ability to run a nonlinear model with flaps. The files ls_model.c and
uiuc_aero.c were changed since we had some functions with the same
name. The name changes doesn't affect the code, it just makes it a
little easier to read. There are changes in LaRCsim.cxx so UIUC
models have engine sound. Could you send me an email when you receive
this and/or when the changes make it to the CVS? Thanks.
Also I noticed you have some outdated files that are no longer used in
the UIUCModel directory. They are uiuc_initializemaps1.cpp,
uiuc_initializemaps2.cpp, uiuc_initializemaps3.cpp, and
uiuc_initializemaps4.cpp
Rob
and specific animation types are derived from it. This change makes
the code much easier to read, maintain, and extend.
Added a 'translate' animation type for a scaled, 3D linear translation
(such as a sliding throttle knob).
Renamed the 'offset' property to 'offset-m' or 'offset-deg' as
appropriate; ditto for 'min' and 'max' properties.
MSVC fix from Bernie Bright:
You can keep the enum private if you add the following declarations
immediately afterwards:
struct mouse;
friend struct mouse;
It seems that MSVC doesn't grant the nested mouse decl. any special
access privileges to its surrounding class.
Clear frame buffer and render model after rest of 3D scene. This has a
small frame rate cost (YMV). But who thought 3D cockpit would be cheap?
If anyone has a better idea, have at it!
Just did some more careful testing and I see little or no frame rate loss
with the depth buffer clear. Also you can change the near plane to 0.1
and get rid of the "sunroof" (so I don't have to make up another set of
patches.
My last patch fixed the initialization problem only for the main branch, but
ignored the _MWERKS_ branch.
- merged the branches, only the loop head needs different treatment;
- don't access n.type before it is initialized (valgrind complaint)
- created a constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.nav.gz entry, so we would have
got a mixture of the broken one and the previous one; in case of
the first entry, that would have made nice random values ... ;-)
- move the automatic FGNav variable into the loop, so that the gets
cleanly constructed for every database entry.
- commented out the frequency min/max exploration, which isn't used at all
- updated the commented out debug output statements, which were simply
copied over from the nav* files, but never adapted (I needed them :-)
* src/ATC/atislist.cxx
Patch from Melchior Franz:
- merged the _MWERKS_ & generic #ifdef branch, only the loop head needs
different treatment
- commented out a "n >> skipeol" that is used in navlist.cxx to gobble
the starting C++-style comment from default.nav.gz; atis inherited
that, but there is no such comment in default.atis.gz, so the first
data entry got thrown away
- commented out min/max frequency exploration (-> only for debugging)
- enhanced the constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.atis.gz entry, so we would have
got a mixture of the broken one and the previous one;
- move the automatic FGATIS variable into the loop, so that it gets
cleanly constructed for every database entry.
- don't access a.type before it is initialized
- updated the commented out debug output statements; they were still
designed for the FGNav class ...
- merged the _MWERKS_ and the generic branch, only the loop head needs
different treatment
- created a constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.fix.gz entry, so we would have
got a mixture of the broken one and the previous one; (valgrind
complained ...)
- move the automatic FGFix variable into the loop, so that the gets
cleanly constructed for every database entry.
- don't access fix.type before it is initialized
- updated the commented out debug output statements (they were copied
over from navlist.cxx but never adapted)
radiostack.cxx:703 says
bool light_on = ( outer_blink || middle_blink || inner_blink );
but none of the flags has ever been initialized when this line is first
executed.
This patch creates a seperate scene graph for the cockpit. The near plane is
only moved up when in the interior (pilot) view. This is because with
rounding (I presume) it the visible ground is a bit up higher than it is with
the older nearplane setting. Not much, but it is enough to bury the wheels.
I suspected this might be true but spliting to two sg's confirms it. If
necessary we can adjust the model up a bit when in interior view. This might
be good so we can set the near plane even closer when in the cockpit (its
still at 0.2m).
In general this looks a lot better on my Voodoo with this patch. No
perceptibel change in frame rate on my system. In terms of future plans I'd
see the sense in making the model plug into either scene. This will be
necessary when we have multiple model instances in the frame.
The matrix doesn't define some cells, which are actually used
in the multiplication. That makes the result unpredictable.
I have no idea if 0.0 is the correct value for these, but
garbage is hardly the correct value either. Should some of them
be set to 1.0?
Think my brain is getting clogged with matrices :-). Well I've got the funky
orientation offset bug out of the model code. In the process the model.cxx
got optimized a bit. At some point we'll need to liberate model.cxx from the
viewer class, but it is no longer hard coded to access the "pilot view" to
get it's data. Instead it uses whatever the "current" view happens to be. I
may try and do that final bit of having models rotate independant of the view
tomorrow night, or start right in on the viewmgr and get a tower view up and
running. You guys have any preference? My brother's family is coming to
visit for a few days so what I don't get done tomorrow night probably won't
get done until after the weekend.
The compiler complains about too long names for instanciated templates
that result in name truncation. There are warnings but finally it ends
with a fatal errors. I found that ignoring the warning cure the
problem.
as a follow-up of my previous message, I found that in panel.cxx, function
const char *FGTextLayer::Chunk::getValue () const, there is the use of a
member variable _buf that seems to be uninitialized.
When the loop starts, n.type is still undefined, so the while statement
depends on unitialized garbage. The input operator cares for the [End]
bracket anyway (returns if the first character is a '['). So it is safe
to check for it after reading the line and break if necessary.
The first hunk might not be necessary, but the light_coverage property
was the only one that wasn't explicitly defaulted, which is unfair. ;-)
The second hunk adds the missing initialization to the init routine.
This is necessary, because (unlike the material entries from material.xml)
the generated light entries don't get the light coverage set. Yet
obj.cxx:795 reads this information out fot every leaf, although not needed
in the case of lights. Avoiding this isn't worth the trouble.
The last hunk sets the missing normal_index. The POINTS branch in
gen_leaf was always called with this int_list empty, which made the normals
handling use data garbage.
It seems that the airport database was changed some day and the End?Flags
changed from floats to strings. The database definition, though, was not
adapted and still created number entries. Reading out these flags led to
access to memory, that was never initialized. While it didn't cause crashes
during normal use, it actually caused one when I ran fgfs in ddd. Seems,
that the concerned memory region wasn't zeroed out then and hence uncovered
the bug.
Of course, the runways.mk4 database has to be re-created with the new
definitions.
Fix FGViewer::update so that pitch offset and goal pitch offset work
together nicely (the offset was snapping to 90/-90 when only one of
the two was changed).
Viewer improvements from Jim Wilson:
These files get the 3d cockpit working and fix a few issues in the viewer
code.
XYZ offsets are now defined as follows: X -left/right+ (along wing axis), Y
-up/down+ perpendicular to the aircraft, Z is -in/out+ the aircraft's body axis.
I've also done some cleaning up of unused and mostly unusable interfaces,
added commentary to the *.hxx, combined together some duplicate code and
eliminated a couple unecessary operations. I also moved what was left of the
"protected" zone to "private" since we aren't subclassing this anymore.
(mainly in src/Input/input.cxx) will make src/GUI/mouse.cxx obsolete
and bring the mouse into the same input system as the joystick and
keyboard. This is just preliminary work allowing, covering mouse
clicks (no motion yet), and it actually crashes on a middle or right
click.
The new mouse support is disabled by default until it become stable;
to try it out, you need to configure --with-new-mouse.
for fuselage Surface objects. If the fuselage wasn't aligned perpendicular
to the Y axis, the matrix wouldn't be orthonormal. Since all of, perhaps,
three aircraft have ever been built this way, it's doubtful I would have
found this as a bug report. :)
Description:
This update includes the new viewer interface as proposed by David M. and
a first pass at cleaning up the viewer/view manager code by Jim W.
Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and
modified the Makefile.am accordingly.
Detail of work:
Overall:
The code reads a little easier. There are still some unnecessary bits in
there and I'd like to supplement the comments in the viewer.hxx with a tiny
bit on each interface group and what the groupings mean (similar but briefer
than what you emailed me the other day). I tried not to mess up the style,
but there is an occasional inconsistency. In general I wouldn't call it done
(especially since there's no tower yet! :)), but I'd like to get this out
there so others can comment, and test.
In Viewer:
The interface as you suggested has been implemented. Basically everything
seems to work as it did visually. There is no difference that I can see in
performance, although some things might be a tiny bit faster.
I've merged the lookat and rph (pilot view) code into the recalc for the
viewer. There is still some redundancy between the two, but a lot has been
removed. In some cases I've taken some code that we'd likely want to inline
anyway and left it in there in duplicate. You'll see that the code for both
looks a little cleaner. I need to take a closer look at the rotations in
particular. I've cleaned up a little there, but I suspect more can be done
to streamline this.
The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO
the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about
to rip it out. It would seem that there more conventional ways to get
spherical data that are just as fast. In any case all the viewer was pulling
from the quat matrix was the pitch value so I modified mouse.cxx to output to
our pitchOffset input and that works fine.
I've changed the native values to degrees from radians where appropriate.
This required a conversion from degrees to radians in a couple modules that
access the interface. Perhaps we should add interface calls that do the
conversion, e.g. a getHeadingOffset_rad() to go along with the
getHeadingOffset_deg().
On the view_offset (now headingOffset) thing there are two entry points
because of the ability to instantly switch views or to scroll to a new view
angle (by hitting the numeric keys for example). This leaves an anomaly in
the interface which should be resolved by adding "goal" settings to the
interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc.
Other than these two issues, the next step here will be to look at some
further optimizations, and to write support code for a tower view. That
should be fairly simple at this point. I was considering creating a
"simulated tower view" or "pedestrian view" that defaulted to a position off
to the right of whereever the plane is at the moment you switch to the tower
view. This could be a fall back when we don't have an actual tower location
at hand (as would be the case with rural airports).
ViewManager:
Basically all I did here was neaten things up by ripping out excess crap and
made it compatible as is with the new interface.
The result is that viewmanager is now ready to be developed. The two
preexisting views are still hardcoded into the view manager. The next step
would be to design configuration xml (eg /sim/view[x]/config/blahblah) that
could be used to set up as many views as we want. If we want to take the easy
way out, we might want to insist that view[0] be a pilot-view and have
viewmanager check for that.
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
inclueded in some of the files. Irix doesn't have cout in the std class,
so I changed it to "cout" and included SG_USING_NAMESPACE(std) at the
beginning of the files.
And some minor warning cleanups.
and fixes a 'potential bug' if the FGFS View code were to change
I also consolidated the specialized IntersectLeaf()
as they really didn't gain us much outside of their having
'more direct access into the SSG controlled data'
I would like to see the fgCurrentElevation functions moved
out of hitlist.cxx.
The one obstacle is their being dependent on my PLib
auxillary functions
ssgGetEntityTransform()
ssgGetCurrentBSphere()
code has been run through astyle with the default options
fixed this when I made the mistake the first time.
The view code wasn't properly handling the transition across tile
boundaries so we'd get a 'flash' of the scene wrongly transformed for
one frame at every tile boundary crossing. This is what
scenery.get_next_center() is for.
the property system, among other things. A separate integration into
the FDMs will follow shortly.
This code will be used only if the --with-new-environment option is
*not* passed to configure.
separate header file. This change will help integrate properties into
JSBSim.
Also, I (David Megginson) removed most of the SimGear include
statements from globals.hxx, reducing the amount of recompilation
every time SimGear changes. This required making minor changes to a
lot of files that were depending on the side-effects of the inclusions
in globals.hxx.
- implement the standard FGSubsystem interface, for consistency
- eliminate current_autopilot and add get/set_autopilot to FGGlobals,
for consistency
- use private methods rather than static functions for tying
properties
There should be no change in functionality.
is a work in progress and needs severe enhancement before it will be
useful. It provides a UDP data channel that goes both ways between
flightgear and the fdm. It also provides a TCP 'command' channel so
flightgear can 'reliably' send commands to the remote fdm (such as set
starting position, reset on ground, etc.)
includes the ability to specify per vertex normals rather than depending
the normals list being the same as the vertices list. (Support for
previous binary file format scenery is maintained.)
This seems to pretty much correct the problem. Part of the problem is that
rotations are occuring at the firewall (model origin) which seems a little
un-natural inside the cockpit. The rest of the problem is I am just learning
how this stuff works (I know I've been saying this for a couple months
now...but hey I'm slow :-)).
* Add new trigger types: raise, fall
* Add new trigger offset parameter
* Add new volume/pitch types: inv, abs, sqrt
* Add initial support for multiple events to intervere in a single sound
(by using the same name, see the crank section of 172-sound.xml)
* Cached the volume/pitch type fucntions
(No more if's inside the loops in update())
created a new class, FGViewPoint (declared in viewer.hxx) that holds a
single position in FlightGear coordinates, and have used it to factor
a lot of the common code out of viewer_lookat.cxx and viewer_rph.cxx.
I don't know whether this new class will stay or not; it might just be
a temporary step, or it might end up taking over much of the current
viewer functionality. It would be a bad idea to code against it right
now.
plane to 0.2; otherwise, use the old defaults.
This is a temporary step that will allow me to work on a 3D cockpit
without breaking current behaviour; the final approach will be to put
the 3D model in its own scene graph, with different clipping plane.
OK, attached is a replacement for mouse.cxx that works the view using
the view-offset/tilt interface, rather than the (kinda odd) GuiQuat
stuff. It's kind of a hack job, as I left the hooks to GuiQuat in in
other places for fear of breaking something. Still, it removed more
code from mouse.cxx than it added, which has to count for some
elegance points.
Oh yeah, I forgot to send that one along. This one is my bug, I
goofed the precedence in the fgPanelVisible() function in panel.cxx
such that the panel was *always* visible if virtual cockpit was
enabled. Here's a replacement. I've modified the style from a single
boolean expression to an if-list, since that's more readable to my
eyes for expressions this big:
and soon to be renamed) is true, FlightGear will draw the 3-D model
even in internal view. This makes sense right now only with the C310
model, since the others don't have any kind of interiors modeled and
all surfaces in all models are one-sided.
This isn't quite working yet -- the view code is very hard to
disentangle, and currently, if the view is not forward, roll and pitch
are applied incorrectly. It looks interesting (modulo a messy model)
on the ground, in level flight, or looking straight ahead under any
other flight conditions.
to 10m after takeoff, but that doesn't really make sense any more,
especially if models are going to have interior views. Is there any
real saving in pushing the near plane out anyway?
was some confusion between degrees and radians which would lead to a huge
goal_view_offset value. The display would sit and spin for a *long* time
trying to wind it's way up to this large value.
difference between the two is this: A sample is file related and sound
is a authonomus entity. This means you can have several sounds pointing
to a single sample. In that case, just one sample is loaded into memory.
The advantage is you can play the same sample with different pitch or
volume, but with just one sample loaded into memory.
To fully support this there is a new fucntion call:
FGSimpleSound *sample = new FGSimpleSound("filename");
mgr->add(sample, "name");
should be replaced by:
FGSimpleSound *sample = mgr->add("name", "filename");
But the old behaviour is still supported with one minor change, sounds
with the same name aren't supported anymore.
Erik
Actually, I think I'm off the hook here; the problem is pre-existing.
What's happening is that the x/y offsets enter the modelview matrix at
line 346 in the current panel.cxx. But note that the same
transformation also occurs before each instrument rendered at line
403. What's happening is that the instruments are double-translated
relative to the background.
Unless I'm not understanding something, the one inside the instrument
render loop looks unnecessary. Removing it fixes the issue and
doesn't cause any bugs that I can find. It also fixes a bug where you
could scroll the instruments on top of the 3D panel, where the offsets
are supposed to be ignored. :)
Attached is a new panel.cxx which fixes that bug, and substantially
simplifies the virtual panel code (the matrix inversion that I thought
was needed wasn't, but there were some offsetting scale bugs that hid
the problem).
These changes add to the "Add Waypoint" dialog so that you can see the entire
list in the pui dialog that you are adding to. Also made some minor changes
so that the autopilot is now activated (toward first waypoint target heading)
when a waypoint is added.
command will save *all* properties, rather than just those marked as
archivable. This feature was requested by Tony Peden to make it
easier to write documentation on the properties, but it should also be
useful for debugging. There is currently no default binding for the
command with the write-all parameter set to true.
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
actually very powerful when combined with factor and offset -- for
example, on the C310 model the nose wheel can now retract completely
before the doors start closing.
subsystem to Flightgear. No more functionality is implemented
than at present (apart from an ATIS bug-fix - station wouldn't
change if the radio was switched directly from one station to
another) but it is much neater than the current hack and should be
easily extendable.
Some cruft is still probably left over in radiostack.[ch]xx such as
the bindings to the comm frequencies but I'll leave removing those
until I'm sure they're not needed there.
newauto.cxx. Basically everything is the same functionally except for a
changed in the initial altitude setting to 3000ft instead of meters (the panel
is in feet).
and scaling of control values to properties. Also added a time interpolation
feature that replaces the hacked-in "retract-time" feature for the gear in
a more general way (applicable to flaps, too!). Incompatibly breaks
the XML syntax; get new files!
individual aircraft to have different sounds (and cleaning up my code
a fair bit). The most important user-visible change is the renaming
of the /sim/sound property to /sim/sound/audible.
(other than "none") is "spin", which must be tied to a property giving
a value in RPM. This gets the DC-3 propellers turning. The next type
will be "rotation", which will allow the flaps, elevators, ailerons,
and rudders to move (and even gear, eventually). Later, I'll add
"shift" for sliding things around, and will figure something out for
blinking lights.
the XML file, including the path to the 3D file.
This change obsoletes the existing /sim/model/*-offset-deg and
/sim/model/*-offset-m properties in the main property tree, and
replaces them with /offsets/*-deg and /offsets/*-m in the model
property file. The /path property in the model XML file is relative
to the XML file's location rather than FG_ROOT.
Added two new properties:
/environment/temperature-sea-level-degc
/environment/pressure-sea-level-inhg
These are now supported in FGEnvironment as well, though they always
have the same value for now. They need to be hooked up to the FDMs.
different locations, and hitched it into FGGlobals. FGEnvironmentMgr
has taken over as the subsystem, while FGEnvironment is simple the
information that it returns. I've removed current_environment
completely -- everything now uses properties or goes through
FGGlobals. FGGlobals itself has a couple of useful methods:
const FGEnvironment * get_environment ();
const FGEnvironment * get_environment (double lat, double lon, double alt);
The first one returns the environment data for the plane's current
position, while the second returns the environment data for any
arbitrary location. Currently, they both return the same information,
but that will change soon.
