I had to reverse a number of signs to get it right. I took the opportunity
to add roll to the submodel so that droptanks will come off with the right
orientation. I have neither added the rotational speed to the submodel, nor
yaw, so if you release droptanks with significant roll rate or yaw angle on
the aircraft the submodel will not be quite right. Straight and level, or
nearly so, is fine.
paging system much more robust when position change is very rapid and sporadic.
Recall that we must load 3d models in the main render thread because model
loading can trigger opengl calls (i.e. with texture loading) and all opengl
calls *must* happen in the main render thread.
To accomplish this we load the base tile in the pager thread and build a work
queue of external models that need to be loaded. We never allow a tile to be
paged out of the tile cache until all it's pending model loads are complete.
However, when changing position very rapidly, we can quickly create a huge
backlog of pending model loads because we are changing positions faster than we
can load the associated models for the existing tiles. The end result is
that tiles that are long out of range can't be removed because there is still
a huge backlog of pending model load requests and memory blows up.
This change being committed allows the tile paging system to remove tiles
if they are out of range, even when there are pending models to load. The
model loading code in the render thread can now check to see if the tile
exists and discard any model load request for tiles that no longer exist.
This situation should never occur in normal operation, but could occur in
"contrived" situations where an external script was rapidly changing
the simulator position to then be able to query FG terrain height, and doing
this for a large number of points that are distributed across a large area.
The maths, so far, is now correct. Roll and pitch are now both in the
correct sense. The aircraft velocity is added correctly to the
submodel velocity, and the submodel is now visible when instantiated.
However, the velocity is measured at the aircraft centre. To be totally
correct we ought to take into account the aircraft's rotational
velocity. We have pitch rate and roll rate available, but not yaw rate
(small anyway).
Here are some things I've added to the submodel code.
First, I added a first_time value that is true when the trigger is pressed and
false when the trigger is released. The true value is also made false after
the first pass through release(). Release() then uses this to force the
first dt (per salvo) to be zero. I was hoping this would make the submodel
appear closer to the airplane, but I don't notice a difference with the
tracers. In a prior test I found that the first dt is about 2.5 times larger
than subsequent ones. Maybe this will be effective with slower submodels,
like smoke, contrails, etc.
Secondly, I updated the IC.elevation and IC.azimuth calcs to correctly add in
the yaw and pitch offsets, corrected for bank angle. Actually this is still
an estimation. A proper calculation will sum the submodels vector with the
airplane's vector. Until that's done only models which are fired forward
will have proper IC.
Testing revealed that the code was not reading y-offset - a
typo in the original code, and roll was in the wrong sense. All readily
fixable, and it now works.
I've added another parameter to the submodel - wind.
It's activated by the entry <wind>true</wind> in the ../submodel.xml file.
If true, the submodel is affected by the local wind, otherwise not. The
parameter defaults to false. This is useful for exhausts and smoke, and
possibly all objects.
Attached are the modified files to add buoyancy as a parameter for a
ballistic object. It may be set by adding
<buoyancy>x</buoyancy> to the submodel .xml file, where x is the appropriate
value (ft per sec2):
32 neutral buoyancy - contrails
>32 positive buoyancy - exhaust plumes
(0 non-op - default value)
If <buoyancy>x</buoyancy> is not used, then there is no effect on the
current ballistic model
Silly me. I was starting the timer at zero, so the first tracer didn't fly
until 0.25 seconds after pulling the trigger. Now the timer starts at the
same value as "delay", so the first round comes out immediately.
Also, I've added an optional configuration attribute that allows you to change
the ballistics of the submodel. This allows parachutes, or anything else
that has ballistics different from a bullet. The attribute is called "eda",
which is the equivalent drag area. Default value is 0.007, which gives the
same ballistics as the current tracers. Increasing this value gives more
drag. A value of 2.0 looks good for a parachute.
math stuff
########################################################################
The deceleration of the ballictic object is now given by:
[ (rho) (Cd) ] / [ (1/2) (m) ] * A * (V * V)
where rho is sea-level air density, and Cd and m are fixed, bullet-like
values. So the calculation is:
0.0116918 * A * (V * V)
The value "A" is what I'm calling the "eda" (equivalent drag area).
########################################################################
A parachute model will have to be built so that the parachutist's feet
are in the forward x-direction.
Here is the submodel.xml config I use for "parachutes":
<submodel>
<name>flares</name>
<model>Models/Geometry/flare.ac</model>
<trigger>systems/submodels/submodel[0]/trigger</trigger>
<speed>0.0</speed>
<repeat>true</repeat>
<delay>0.85</delay>
<count>4</count>
<x-offset>0.0</x-offset>
<y-offset>0.0</y-offset>
<z-offset>-4.0</z-offset>
<yaw-offset>0.0</yaw-offset>
<pitch-offset>0.0</pitch-offset>
<eda>2.0</eda>
</submodel>
Last night I sent these new files to Vivian to fix a problem he found. Since
we can have more than one submodel we need more than one "count" property.
The new code creates a property systems/submodels/submodel[n]/count for each
submodel. Vivian is using this count property for his sound.
Here is an update for the submodel system. This will allow submodels to be
defined for any aircraft, and there are no default submodels. To use this
submodel system you need to set up a binding (slight change in property name
from last one, but you can use any property name you like, as long as it
matches the name in the submodels.xml file, see below):
<button n="0">
<desc>Trigger</desc>
<binding>
<command>property-assign</command>
<property>/systems/submodels/trigger</property>
<value type="bool">true</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>/systems/submodels/trigger</property>
<value type="bool">false</value>
</binding>
</mod-up>
</button>
Then in your *-set.xml file you need to define a path to the configuration
file (similar to the way the electrical system is now done):
<sim>
...
<systems>
<electrical>
<path>Aircraft/Generic/generic-electrical.xml</path>
</electrical>
<submodels>
<serviceable type="bool">true</serviceable>
<path>Aircraft/FW190/submodels.xml</path>
</submodels>
</systems>
...
</sim>
Then you put the submodel configuration file in your aircraft's directory.
I've attached a file, submodels.xml, that can be used to define a gun that
works just like the former one did.
There are two things remaining to be done. One is to change the function
SubmodelSystem::transform() to properly position the submodel. This will
require some complicated matrix code that I might borrow from Yasim.
Well here's some tracer stuff. If fiddled around with submodel.cxx. It now
does what it says - you need to put this:
<!-- trial gun system -->
<systems>
<submodel>
<serviceable type="bool">true</serviceable>
<amount type="int">120</amount>
</submodel>
</systems>
In the *-set.xml file NOT within <sim></sim>. Trouble is it still defaults
to serviceable=true, but it also defaults to amount=0. Unless this bit of
code is included it wont run, so other models can't fire inappropriate
tracer. Revised submodel.cxx file attached.
I've changed to a non-billboard solution. I tried to make the viewing angle
of the tracer less than 180 degs, but failed. Close enough I think. It's
still a bit big, but a reasonable compromise. .AC file attached.
I remain concerned about the tracer colour. In practice, red is better (and
it's what I am used to) but David seems set on white, and I don't want to
upset him. I'm going to adjust the texture a bit more tomorrow.
Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger):
<button n="0">
<desc>Trigger</desc>
<binding>
<command>property-assign</command>
<property>/systems/submodel/trigger</property>
<value type="bool">true</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>/systems/submodel/trigger</property>
<value type="bool">false</value>
</binding>
</mod-up>
</button>
Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags):
<systems>
<submodel>
<serviceable type="bool">true</serviceable>
<amount type="int">70</amount>
</submodel>
</systems>
Future improvements will include:
1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity.
2) sound?
3) a more accurate calculation of the submodels location at any pitch/roll/yaw.
4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance.
I think that's all of it.
All necessary elements for an ADF gauge had been migrated from
Cockpit/kr_87.cxx to Instrumentation/adf.cxx. Migrating the sound
related elements was apparently planned, but not done yet. This
intermediate state broke the ident morse sound: it couldn't get
turned off and it always indicated "SF", regardless of the tuned-in
frequency. The following patches continue the migration:
adf-radio.diff => Base/Aircraft/Instruments/adf-radio.xml:
---------------------------------------------------------------
* sets maximum volume to 1 (rather than 2); Not only is 1
loud enough (and 2 unpleasantly noisy), it also prevents
the knob from being turned to non-existant positions. :-)
* fixes wrong use of /instrumentation/adf/ident
* the voice/ident selector(?) remains unchanged, but as it's
not switched to "IDENT", there'll be no ident sound by default
this is consistent with other sounds and DME.
radiostack.diff => src/Cockpit/radiostack.[ch]xx:
---------------------------------------------------------------
* comment out use of FGKR_87 class. kr_87.[ch]xx is now no
longer used. kr-87adf.xml would no longer work, either, but
isn't used anywhere, anyway. Future adf radios have to use
the adf instrument, using xml/Nasal for specific hardware
implementation details.
adf.diff => src/Instrumentation/adf.[ch]xx:
---------------------------------------------------------------
* adds ident morse sound capability using two new input
properties:
- /instrumentation/adf/volume-norm (double)
- /instrumentation/adf/ident-audible (bool)
this was always only meant to be a test program for the metar lib, but now
that people are referring to it as a means to get metar reports, I think a
usage info is desirable. The list of test ids, on the other hand, isn't
necessary any more. This can still be handled by a Makefile or the commandline.
I'm all for keeping this tool in cvs, however. And also the not-used stuff
therein is a welcome source for how to use the SGMetar class.
This is a workaround for an issue where the xml dialogs were shrinking on
subsequent pops.
Andy Ross says:
That looks like it should be fine for a release-time workaround. The
2 pixel border on dialogs is at best a minor feature, and probably
invisible since the sub-frames all have their own padding.
Clearly the right fix would be to find out where the code is getting
confused by the previous layout. In principle, the layout should be
idempotent: if you don't change the layout constraints, it shouldn't
change its layout. There's still a bug in there somewhere.
I've included the latest fixes to the Traffic Manager/AI flightplan generation
code. Most of the code changes are in AIFllightplan.cxx. This is the code
that runs without depending on predefined FlightPlans in
#FG_ROOT/Data/AI/Flightplans.i
As suggested by Dave, I've also added a new property in
preferences.xml: /sim/traffic-manager/enabled, which is used to control
whether or not the traffic manager is active.
I'm still working on a few more 737 traffic patterns, those are going to take
a little longer, so I didn't want to wait sending in this code.
Finally, I haven't put much effort into ensuring "aeronautical correctness" in
this version yet. The code works on my system, but what the AI plane do may
actaully be quite rediculous. But I'd like to leave that for the next
version.
Stub in hooks for Propeller feathering controls and the turbo prop "condition"
lever.
I added a line in FGFDM.cpp to force control properties to exist if they
don't already. This way you can specify anything you want and find them
in the property browser, otherwise no one else may create them and you are
stuck.
In PropEngine::solve() the code original sets _running = true at the
beginning and then sets running = false at the end. I changed this to
save the current value at the start, set to true, solve(), and then
restore the original value at the end. That way if we start off with
_running = true, we don't have to hack up the calc() routine which wasn't
using the value anyway.
Finally I added some very initial support to shut down a turbine engine
(_running = false) when the condition lever goes to zero.
for localizers. I further hacked this to support GS and DME transmitters
(although Robin's DME transmitter data doesn't convey orientation
unfortunately.)
I have 3 issues that are fixed by this set of patches.
1. In extensions.cxx
#else if !defined( WIN32 ) must be changed by
#elif !defined( WIN32 ) because the text after #else
seems to be ignored
2. banner is not available on windows, only cygwin
3. ANSI escape sequences are not interpreted on the
windows console. We just have garbage that is hard
to read.
motion.
- Track a timeout value so we can optionally hide the mouse pointer after
some user specified timeout period.
- in doMouseMotion() always update m.x and m.y even if we return early because
pui wanted the event. Without this, we can't reliably detect motion vs.
inactivity.
- in _update_mouse() add a dt parameter so we can decriment the timeout value
in "real" time.
- in _update_mouse() optionally hide the mouse pointer if m.timeout goes to
zero. Restore the pointer (and the timeout counter) if the mouse is moved.
will delay it's reply by 50ms. The ground station can change it's reply delay
to trick the airborn dme unit into reporting a distance that is offset from
the true distance by some constant value. In FG we model this by subtracting
a fixed distance from the actual distance.
It is thus possible in our implimentation for the displayed distance to become
negative. This patch clamp DME distance to a minimum value of 0.00 so it can
never go negative.
A good elevation is critical for proper glide slope modeling. This patch
assigns the average field elevation to any ILS component that doesn't have
a valid elevation.
Also, for an ILS approach, use the GS transmitter elevation for glide slope
calculations rather than the localizer elevation, in some cases this can
make a big difference.
Wouldn't it be better to prepare the whole list of paths (or two
separate ones for Terrain/Objects if necessary) in FGGlobals::set_fg_scenery,
and to pass the vector<string>s to FGTileEntry::load? It doesn't seem to make
a lot of sense to split the path up, modify it, mount it together to one string
again, and then let FGTileEntry::load split it up again.
Here we go:
Main/globals.cxx
================
As fg_scenery is now a string_list, we don't need initialization. Furthermore,
this list is cleared with every set_fg_scenery() call.
ctor: create default dir from fg_root if necessary. Otherwise check all paths
of --fg-scenery/FG_SCENERY: If the path doesn't exist, ignore it. If it contains
a dir Terrain and/or Objects, then only add that to the list. If it contains
neither, then use the path as is.
Scenery/tileentry.cxx
=====================
Trivial: don't split a "base path", but use the given path_list as is.
(I considered a variable name "path_list" better suited than "search".)
Scenery/FGTileLoader.cxx
========================
No more fiddling with sub-paths. This has to be delivered by get_fg_scenery
already.
Here's some additions to AI that allow refueling from an AI tanker (the actual
onload of fuel must be handled by the user's FDM of course, this just lets
the FDM know that the user is in position to refuel).
I've added a new class of AIAircraft called "tanker". It uses the same
performance struct as a jet transport. An AI tanker is just like an AI jet
transport, except it uses the already-existing radar data to control the
boolean property systems/refuel/contact. The code change was minimal.
An AI tanker can be created like this:
<entry>
<callsign>Esso 1</callsign>
<type>aircraft</type>
<class>tanker</class>
<model>Aircraft/737/Models/boeing733.xml</model>
<latitude>37.61633</latitude>
<longitude>-122.38334</longitude>
<altitude>3000</altitude>
<heading>020</heading>
<speed>280</speed>
<roll>-15</roll>
</entry>
This puts a tanker over KSFO at 3000 feet, in a left-hand orbit. When the
user gets within refueling range (contact position) then the property
systems/refuel/contact will be true. Otherwise it is false.
The dimensions of the refueling envelope are pretty rough right now, but still
usable. The user must be behind the tanker (ie. radar y_offset > 0). The
user must be at or below the tanker's altitude (ie. radar elevation > 0).
The user's lat/lon must be within 250 feet of the tanker's lat/lon (ie. radar
range_ft < 250). This last requirement is loose because the radar data is
only updated every 100 ms, which is accurate enough for radar use, but
which is sloppy for air refueling. This could be tightened up by increasing
the radar update rate to once every sim cycle.
I'm going to add a light to the T-38 instrument panel that will monitor the
property systems/refuel/contact. This will make it easier to explore the
boundaries of the refueling envelope.
Here's some new AI stuff.
1) AI objects must now be defined in a scenario file, not in preferences.xml
or a *-set file. (Of course this doesn't prevent objects from being created
dynamically, as with Durk's traffic manager).
2) A new demo_scenario file is attached. It creates 3 aircraft, a sailboat,
and a thunderstorm.
3) Objects without flightplans live forever.
4) FGAIShip::ProcessFlightplan() is not yet implemented.
5) preferences.xml should now define only <enabled> and <scenario>
These change add some code that at initialization time will snap all
localizers into perfect alignment with their runways. It's my experience
that the DAFIF/FAA data reports runway and localizer headings to a level
of precision that is great for making charts, or adjusting your OBS, etc.
But the level of precision of this data can be far enough off to make you
visibly *un*aligned with the runway when the CDI needle is centered.
There are probably cases where the localizer isn't really perfectly
aligned with the runway, or intentionally misaligned to avoid obstacles
or terrain. So I have made this configurable for those that trust the
data more than I do. Just set "/sim/navdb/auto-align-localizers" to
true/false in the preferences file to turn this feature on or off in the
code.
- FG now directly supports Robin's native nav database file format.
- His latest data now separates out dme, gs, loc, and marker beacon
transmitters rather than lumping them all into a single "ILS" record.
- These new data structure changes prompted me to do some code restructuring
so that internally these different types of navaids are all kept as
separate lists and searched and handled separately.
- This structural change had a cascading affect on any code that
references or uses the nav databases. I've gone and "touched" a lot of
nav related code in a lot of places.
- As an added bonus, the new data (and code) adds DME bias so these will
all now read as they do in real life.
- Added Navaids/navdb.cxx and Navaids/navdb.hxx which provide a front
end loaders for the nav data.
- Added Navaids/navrecord.hxx which is a new "generic" nav data record.
- Removed Navaids/ils.hxx, Navaids/ilslist.cxx, Navaids/ilslist.hxx,
Navaids/mkrbeacons.cxx, and Navaids/mkrbeacons.hxx which are all now
depricated.
1. Removed aircraft roll on ground.
2. Decreased descent pitch angle.
3. Updated flightplans to include <on-ground>
4. Fixed property indexing, so all AI aircraft have their own property branch
The default value of <on-ground> is false, so you only need to specify it when
on the ground. For takeoff you need to specify <on-ground>true</on-ground>
for the first waypoint, and for the acceleration waypoint. For landing you
need to specify it for the touchdown point and any taxi points.
One problem. WARNING **** There is a bug in the way the property system
works, which causes a segfault, but I don't know if the problem is in the
property code, or in how I'm using it. After an AI object terminates, if you
access the property tree through the property browser the sim will segfault.
First, preferences.xml will define the scenario filename.
For now, the other way of defining ai objects still works, so the sailboat
stays in preferences.xml. Later, I'll move the sailboat into the demo
scenario. If no scenario filename is given, then no scenario will be
processed.
I changed the demo scenario to create two 737's, one takes off on runway 01L,
and the other takes off on runway 01R. This will make a good demo for the ai
system. One problem, if you takeoff on 28L/R right away, you might run into
the taking-off 737's, or be scared.
Here's the newest AI stuff.
The AIManager at init() creates a new scenario. Right now the
default_scenario is hard coded in, but eventually the AIManager should get
the scenario filename from preferences.xml.
The scenario defines which AI objects will be created. Right now it only
creates AIAircraft, but this is easily extended. The scenario also defines
which flightplan will be assigned to the airplane. Scenario config files go
in data/Data/AI.
The Airplane gets a pointer to a FlightPlan object. Each airplane should get
its own flightplan object, even if two airplanes have the same flight plan.
This is because the flightplan maintains the iterator pointing to the
current waypoint, and two airplanes might be at different locations (for
instance if they were created at different times). The flight plan files go
in data/Data/AI/FlightPlans.
When the airplane gets to the waypoint named "END" it vanishes. The
AIAircraft destructor deletes its flight plan (if it has one).
The last waypoint is a place holder only. I called mine
<WPT><NAME>"EOF"</NAME></WPT>.
little larger.
The text widget can now be meaningfully associated with a property; in
PUI, it's "value" isn't the same thing as its label, but we can hack
things to treat them symmetrically.
Commit an experimental "live" property that can be set on widgets to
cause them to update their values every frame. This works great for
text widgets, as above. Note that this synchronization is input-only:
no support is provided (or needed -- the GUI only changes when the
user does something) for writing those properties out every frame.
the 30 seconds that Maik had originally intended, according to the comment.
This is important for the pending sound and rotor disc changes (and of course
for realism).
Fix the leg distance calculation to display nautical miles instead of meters.
It turns out that Simgear already has a range normalize function, so I use
that one instead.
for a while, it turned out to be pretty easy to implement. Also, the
property picker is now non-modal, I presume the modality wasn't an
intentional feature.
I've added a vertical navigation capability to the GPS module. One can input
two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then
the altitude deviation from a "straigth" line from wp[0] to wp[1] is
calculated. The true course and course deviation from wp[0] to wp[1] is also
calculated. All this can be found in the wp subdir where one also finds the
wp[0] and wp[1] subdirs.
All this has to be done through the property browser. Maybe I should make a
gui window for the GPS!
"slow/windmilling propeller" regime. I'm happy with the foundations
of the solution, but this hasn't been complete tested yet. The
solution behavior seems fine on the planes I tried.
PistonEngine class has grown an "Engine" superclass. Some other stuff
moved around too, and I cleaned up some property naming while I was in
there. This hasn't been tested very thorougly, hopefully I didn't
break anything.
configure and compile out-of-the-box on a MinGW target:
Use -lSDL instead of -lglut32 on windows builds when --enable-sdl
is set.
Link against alut.dll in addition to openal32.dll.
Replace BSD bcopy() with ANSI C memmove() in a few places. This is
simpler than trying to abstract it out as a platform dependency in a
header file; bcopy() has never been standard.
The ENABLE_THREADS handling has changed to be set to 0 when threads
are not in use. This breaks expressions like #ifdef ENABLE_THREADS.
Replace with a slightly more complicated expression. It might have
been better to fix the configure.ac script, but I didn't know how and
this whole setting is likely to go away soon anyway.
The MinGW C runtime actually does include snprintf, so only MSVC
builds (and not all WIN32 ones) need _snprintf in JSBSim/FGState.cpp
Building on a platform with no glut at all exposed some spots where
plib/pu.h was being included without a toolkit setting (it defaults to
glut). Include fg_os.hxx first.
And when still using glut, glut.h has a bizarre dependency on a
_WCHAR_T_DEFINED symbol. It it's not defined, it tries to redefine
(!!) wchar_t to disasterous effect.
anymore. Instead Frederic Bouvier suggests to add a <number> tag to
the axis definition which accepts values for <windows> and <unix>
for now but which can be extended later on:
<axis>
<desc>Rudder</desc>
<number>
<unix>2</unix>
<windows>3</windows>
</number>
<binding>
<command>property-scale</command>
<property>/controls/flight/rudder</property>
<offset type="double">0.0</offset>
<factor type="double">1.0</factor>
<power type="double">2.0</power>
</binding>
</axis>
1. The listener is always positioned at the origin.
2. All sounds eminate from the aircraft's model position.
3. Sound positions are relative to the listener location.
I've added a tracking bug to the gps. This is of course very similar to a
heading bug for a DG. I don't know if this is the common name, but I feel
that for a gps the name tracking bug is more accurate than heading bug. A
true bug error and a magnetic bug error is calculated and shifted into the
-180 to 180 range so that they can be used by autopilots.
I've also fixed a property name that crept in when I had to change back to
indicated-***. Back then I accidentally changed the desired course name to
"indicated-course". The property that is supposed to be the input for the
desired course should naturally be named something like "desired-course", and
definitely _not_ "indicated-course". If this name change breaks anything it
should be fixed in the other end.
I've also commented out a lot of #includes that I don't think is needed. I'm
on Suse 9.0 now, and it builds fine here, but this might be a problem for
different platforms I guess we have to cross our fingers.
my code was accidentally drawing the cockpit twice
in view 0. This patch should fix the problem of
lights not seen through canopies or prop discs.
It was also drawing the lights ( ground and rw )
after the clouds, so they were not obscured by
them.
command bindings accessible from XML. This still probably isn't a final
solution (which would drive the HUD from propery values), but it's a step
in the right direction anyway.
This update contains a change to not overwrite the altitude-ft preset during
"onground" start. The change also prevents a ground trim issue with the
JSBSim fdm when a "reset" is done by FlightGear.
this patch is to clear a problem that I sometimes
encounter : FG locks when hitting the cancel button
of a dialog. In fact, an interator is always invalid
when it was used to erase a member of a collection.
The braces are here to help my debugger, and I also
removed a warning about unused variable.
I restored the output to cout / cerr
for the options and the warning for the version mismatch.
There is a dummy SG_LOG to allow the windows version to
popup the console.
The snapshot rendering use multipass now.
- We need to be able to support a per engine master bat/alt switch.
- Forgot to write the gear level state into the network structure.
native_fdm:
- renamed EGT->egt for consistancy.
- added manifold pressure to the structure.
FG_ENABLE_MULTIPASS_CLOUDS must be defined to enable
the algorithm. I made this because the stencil buffer
must be initialized at the beginning of the program and
OpenGL can fallback to software rendering if it can't
find a visual with stencil buffer. I didn't touch the
configure script, so CXXFLAGS=-DFG_ENABLE_MULTIPASS_CLOUDS
must be set before running ./configure.
If FG_ENABLE_MULTIPASS_CLOUDS is defined, the main render
loop begins by reading the /sim/rendering/multi-pass-clouds
property. It is a boolean property so there are only two
quality levels. false means no multi pass and no use of
the stencil buffer, true means an additionnal pass for
both upper and lower cloud layers.
The algorithms are as follow :
/sim/rendering/multi-pass-clouds=false
1. draw sky dome
2. draw terrain only
3. draw clouds above the viewer
4. draw models except the aircraft
5. draw clouds below the viewer
6. draw the aircraft.
The cloud rendering doesn't update the depth buffer.
This means that models overwrite clouds above the viewer.
This is only noticeable for tall buildings and when
flying very low. Also, drawing low clouds after models
means that they are not blended with models' translucent
surfaces. Large transparent area require alpha test
enabled and AI aircraft canopy are making holes. The
pilot's aircraft being rendered at the end, there is no
problem with canopy or prop disc.
/sim/rendering/multi-pass-clouds=true
1. draw the sky dome
2. draw the terrain only
3. draw all clouds
4. draw models except the aircraft
5. redraw the clouds where the models where drawn ( stencil
test on )
6. draw the aircraft
The assumptions made by this algoritm are that the terrain
is not transparent ( should be true in all cases and
that there are no clouds between the aircraft and the viewer.
Assuming these facts, there should be no blending bugs.
The screenshot rendering is not updated yet.
the keyboard modifiers outside of a key event handler, so adding the
fgGetKeyModifiers() call to doMouseMotion was broken. The user could
see "phantom" modifier keys.
trying the --show-aircraft option, I noticed that I had
no output. This is because there are still output to
cout or cerr, that are not triggering my console patch
for windows. The patch attached use SG_LOG instead.
A request to hit a key is also added because otherwise,
the console window will disappear as soon as the program
stop.
This problem is minor though given the fact that fgfs.exe
is shipped with fgrun that do show the available aircraft
in a much nicer manner.
work on the pa28 idle and without creating ridiculous side effects
(like being able to fly the aircraft with the starter motor, heh).
This one looks pretty good for now, pending work on the propeller to
get its low speed drag in line with reality.
reads the /consumables tree for input to determine weights, but
places output only in /engines/engine[n]/fuel-consumed-lbs where
it gets picked up by the Nasal code.
This is a fix for my earlier "Remove some hardcoded dependencies between fdm,
viewer and acmodel" patch. The problem was discovered when testing the
wrightFlyer.
deriving a class and the base class used this type.) Return to using
const char and hope people compiling against earlier versions of plib
have compilers that think typedef const char cchar; char *abc; is equivalent
to const char *abd;
This patch adds the ability to do a simple scaling of input without having to
add hardcoded helpers. Example:
<reference>
<prop>/autopilot/settings/vertical-speed-fpm</prop>
<scale>0.01667</scale>
</reference>
The message 'Alert: catching up on tile delete queue'
comes from the fact that 48 tiles are scheduled and
added to the cache at startup before the plane location
is initialized. My proposed patch is to initialize
SGLocation with an invalid position and detect this
fact before scheduling tiles. I prefer to do that
rather than testing for lon and lat being 0,0 because
it is a valid position and someone could want to fly
near Accra.
This patch is for windows only. It hides the console window
until there is a message to print. It only support SG_LOG,
that I think is the right way to display something in FG.
Add FGPredictor class to xmlauto. Add support for horizontal navigation based
on flight track as opposed to heading. Add crosstrack-error support to nav.
Simplify error adjust calculation for horizontal nav (better interception).
Fixed potential divide by zero that was producing nan issues in the xmlauto
code.
I've done som more work on the gps instrument.
- You can now input airport-, nav- or fix-ID to select a waypoint.
- You have to specify either "airport", "nav" or "fix" in the waypoint-type
property (some fixes and navs have identical IDs).
- Formatted the time to waypoint output.
- Cleaned up and changed some propery names (wp-heading -> wp-bearing).
- I've also added a name member to the FGNav class so that the gps instrument
can get the name of the nav.
- Changed the airport name parsing in simple.cxx.
I've done some changes to xmlauto.cxx.
Only calculate the derivate filtering if derivate time Td is greater than
zero. This means that one can set Td=0.0 in the xml file to completely remove
the derivate action. (Setting Td to zero in the current version would lead to
a division by zero and crash.)
Setting the integrator time Ti to zero doesn't make sense, right! I've
modified so that setting Ti to zero results in the integral action being
completely removed.
null space without killing the engine (hardware specific problem.)
- NMEA output: I'm slightly confused but it appears that a real GPS outputs
traditional unix line endings on it's gps strings, we were outputing DOS
CR/LF which was causing some confusion. This changes the line ending
convention to match that of a real gps.
- Calculate true ground track and speed for NMEA.
explicitely. This value has always been feet, but there were a couple places
in the code that assumed this elevation was meters. The result was that you
could park directly over the top of the Black Forest VOR (112.50) NE of KCOS
and get a dme reading of 2.5 or so. This problem is now resolved.
I added some things to the AI stuff to improve the AIThermal processing.
Before, all the thermals were processed in order, and the last one overwrote
the prior one. Now, only the data from the nearest thermal is kept. This
way a tile can be populated with many thermals, and (as long as they have the
same diameter) the one nearest the airplane correctly takes effect. This
will make us ready for the next step, "auto-thermaling", where FlightGear's
tile manager can cover a tile with thermals, and set the thermal strength
based on land-use type.
I moved the enumerated object_type to the base class. When an AI object is
created it now sets the _otype variable in the base class. This lets the AI
manager find out what kind of AI object it is dealing with, using the base
pointer. I also added a function isa() to the base class, so the manager can
process objects differently based on their type.
The AI manager now sends AIThermal processing to a different function, where
only the data from the nearest thermal is kept. After the manager processes
all the AI objects, then the results from the nearest thermal are applied to
wind-from-down.
occasionally cause a large number of valid stations to be flagged as invalid.
This *seemed* like a "race condition" type problem because there were some
assumptions in the communication between the main process and the threaded
loader which if they broke down could lead to this problem.
In the process of removing this ambiguity, I restructured the threaded
(and non-threaded) metar fetching code a bit. Some of the top level logic
(which Erik politely left untouched) didn't make nearly as much sense in the
context of a threaded metar loader and could have contributed to some of the
wierdness I was seeing.
Here's a new batch of AI code which includes a working radar instrument.
I put the radar calculations into the existing AIAircraft class. It was
easier that way, and it can always be migrated out later if we have to.
Every tenth sim cycle the AIManager makes a copy of the current user state
information. When the AIAircraft updates it uses this information to
calculate the radar numbers. It calculates:
1) bearing from user to target
2) range to target in nautical miles
3) "horizontal offset" to target. This is the angle from the nose to the
target, in degrees, from -180 to 180. This will be useful later for a HUD.
4) elevation, in degrees (vertical angle from user's position to target
position)
5) vertical offset, in degrees (this is elevation corrected for user's pitch)
6) rdot (range rate in knots, note: not working yet, so I commented it out)
and three items used by the radar instrument to place the "blip"
7) y_shift, in nautical miles
8) x_shift, in nautical miles
9) rotation, in degrees
The radar instrument uses the above three items, and applies a scale factor to
the x-shift and y-shift in order to match the instrument's scale. Changing
the display scale can be done entirely in the XML code for the instrument.
Right now it's set up only to display a 40 mile scale.
The radar is an AWACS view, which is not very realistic, but it is useful and
demonstrates the technology. With just a little more work I can get a HUD
marker. All I need to do there is make a bank angle adjustment to the
current values.
I went through the AI code to put the "bank" node back into the config file,
so the models can fly circles. While I was in there I made some other
changes.
*) Moved the initialization of roll, tgt-roll, pitch ... etc, from init()
into the constructor, so it wouldn't over-write the config settings.
*) Changed the altitude getter to remove the meters-to-feet conversion. The
altitude is kept internally in feet. Only the scenery code needs meters.
*) Added "bank" item for config file (for type=aircraft). Left bank is
negative.
*) Added "rudder" item for config file (for type=ship). Left rudder is
negative. Internally this is stored in the "roll" variable, but the ship
model doesn't roll. It uses the "roll" variable for turning though.
The following puts a tanker at 3000 feet, 6 nm northwest of KSFO. On takeoff,
the tanker is visible over the hanger building at one-o'clock.
<entry>
<type>aircraft</type>
<class>jet_transport</class>
<path>Aircraft/737/Models/boeing733.xml</path>
<speed-KTAS type="double">320.0</speed-KTAS>
<altitude-ft type="double">3000.0</altitude-ft>
<longitude type="double">-122.455</longitude>
<latitude type="double">37.69667</latitude>
<heading type="double">200.0</heading>
<bank type="double">-15.0</bank>
</entry>
are many recognized limitations and inefficiencies with this entire approach,
however, it's a quick and dirty way to get something working, where before
we didn't.
The last change from Curt to Airports/simple.[ch]xx made
GUI/AirportList.cxx not compilable because of the loss of
a '*' in getAirport.
Also : fabs is not defined under MSVC unless <math.h> is
included.
updates based on the "closest" airport with metar data available. Note that
the web based query is in the main loop and causes brief sim pauses. Update
rate (once per minute) needs to be tweaked with, but is a good value for
testing.
seem to be fully deterministic in P-only mode. This old simple controller
does what I expect, so it's good for calulating stage #1's of multi-stage
controllers.
I just met a couple of warnings about depricated headers beeng used.
Please take a look at patch (against today cvs) attached wich
does strstream -> stringstream migration. I hope you found it usefull.
latest version is attached to reduce need to search property
tree each frame. I don't think this will break any Fg code and
opengc has been updated a while back and have had no complaints ;-) so it
should be a no impact change, hopefully.
controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
net_ctrls.hxx net_fdm.hxx net_fdm_mini.hxx net_gui.hxx
I, Curtis Olson, being the primary author of these header files, hereby
release them into the public domain to facilitate interfacing FlightGear
with other external code (which might need to remain proprietary or may
be licensed under some not quite GPL compatible terms.)
account for variation in lighting alignment, but it's more useful than the
previous attempt which was based on a misunderstanding of how environment
mapping worked.
to handlers which might want to assign it to a SGPropertyNode_ptr for
reference counting (Nasal does, for instance, to prevent garbage
collector interactions). If that smart pointer is then destroyed,
that will free this object while it is still live.
Simply use a SGPropertyNode_ptr here; the code ends up smaller as a
bonus, since FGBinding no longer has to deallocation for _arg.
places now use sgCartToGeod() instead of rolling their own
approximation. And YASim is now using exactly the same 3D coordinate
system as the rest of FlightGear is.
scripts) to create dialogs at runtime. Augment "dialog-close" to take
a name argument, allowing code other than PUI callbacks to close
dialogs.
The changes to the GUI directory to enable this are actually minor,
basically amounting to using SGPropertyNode_ptr reference counting
(the GUI subsystem no longer "controls" the dialog property trees, so
it can't delete them).
interface, and use it to cache FGNasalScript objects returned from
a new parseScript() method.
Added a rand() function.
Added an interpolate() function interface to the new SGInterpolator
subsystem.
the core YASim stuff. Mostly cosmetic: whitespace adjustment, dead
code & meaningless comment removal, a little code motion to better
partition the helicopter handling from the original code (no more
giant if() { ... } around the solver). Added a warning to the parser
to try to eliminate the string booleans that crept in.
There should be NO behavioral changes with this checkin.
makes more sense to keep I/O running. That way remote telnet connections
will still respond, and the sim can still accept and send data. This also
allows a remote script or gui to pause and (more importantly) be able to
the unpause the sim.
are cosmetic, but we now have a combination of code that seems to work
very robustly. I was able to land the yf23 at about 130 kts on the lower
level of the bay bridge and then taxi the entire length.
traingle strips right ... it was mixing up the vertex ordering slightly.
Oh what the heck, it was really screwing up tristrips. Everything else looks
correct though. :-) Hurray for the red book.
a <rating-amps> tag which also implies that the switch is a circuit breaker.
Eventually we could have code that will automatically trip the breaker if
the current exceeds the rating.
support an attached property name and an intial state, but this can easily
be extended to configure a switch to be a circuit breaker with a max rating,
etc.
current draw. This is only one piece of the puzzle, but as we move forward,
the idea is better modeling of the ammeter, and we could automatically pop
circuit breakers if the current gets too high.
Patches to allow control of more than 1 (up to 10) ejection seats, and
control them with more flexibility. A particular ejectection seat can be
disarmed or failed, in which case it can't be ejected until it is armed
or fixed.
aloft layers to match a current OAT at the current altitude. This can be
run from an external script or gui.
Given the specified OAT (and the current aircraft altitude), the code
calculates the equivalent sea level temperature, and then assigns that to
all active boundary and aloft environment layers.
Upon further review, I was very misguided, and unfortunately no one slapped
my hand at the time.
Factoring in the environment manager's interpolation scheme, it makes complete
sense to specify the sea level temperature at each boundary and aloft layer.
In fact, this is the only way that allows the temperature interpolation to
make sense, especially around the boundary layer. This is confusing stuff,
but it now works perfectly. :-)
Here's a patch to locate the base package inside the application bundle on OS-X. The patch also disables the CPSForeground hack in boostrap.cxx, which is unnecessary if the we're running as a proper bundle rather than a Unix command line program.
Both of these changes are only compiled if OSX_BUNDLE is defined (I'm doing this via a setting in ProjectBuilder), so if you're building on OS-X using configure + make, you shouldn't see any chance.
1. Do not stop scanning STG files after OBJECT_BASE is found.
2. Load OBJECT_BASE only once.
3. Load OBJECT only when no OBJECT_BASE has been found or when
OBJECT_BASE was found in the same file (probably should be only the
latter, if we constrain OBJECT_BASE always to come first).
4. Always load OBJECT_STATIC and OBJECT_SHARED.
Frederic Bouvier:
First, MSVC 7 bombs when a value greater than 255 is passed to
issomething(), so I copy k to a char (unsigned ) kc before calling
them.
Second, with my french keyboard, and I thing this is the same for
a great number of countries, some characters from the regular ASCII
set can only be get with ALt Gr that appears to be CTRL+ALT.
Especially, I can't select the second engine because '@' is
AltGr+'' nor all because '~' is AltGr+'' (and I have to hit space
after otherwise I can get or that are not used in french) and
FG try to cope with the modifiers.
So, currently, we have to mask out CTRL and ALT modifiers when they
are together. The current bingings don't allow 2 simultaneous to
be declared so it shouldn't break anything.
This has been on my local copy for a while (well tested :-))
It fixes a problem with the auto throttle jumping around needlessly. Adjustments are calculated based on the last calculated autothrottle setting rather than reading the throttle setting from the property tree.
from the rest of the runway lighting. VASI/PAPI lights are generally
always on. Also, the red/white VASI coloring has never worked right.
This is also a step towards fixing that problem.
Here's a new FGSimTurbine module. Changes are:
1. Adds starting and stopping functionality
2. Calculate() now calls other functions, based on the engine's state, which gives more readable code.
Until now turbine engines were always running as long as fuel was available. With this new module the engine defaults to OFF. To start with the engine running, the variable FGEngine::Running must be set to true at sim startup. In FlightGear this is done with --prop:/engines/engine[n]/running=true.
To start the engine (on the ground), first set the starter to ON, i.e. FGEngine::Starter is set to true. In FlightGear this is done by toggling /controls/engines/engine[n]/starter to TRUE. Note that the current FlightGear key binding will not work, as it causes the starter to quit when the key is released. A new key binding is needed, without the mod-up.
When N2 reaches 15% or greater, place the fuel cutoff control to FALSE. This is FGEngine::Cutoff. In FlightGear this is done with /controls/engines/engine[n]/cutoff set to FALSE. The engine will then accelerate to idle. Upon reaching idle, the starter is automatically turned off, and the engine is running. There is presently no FlightGear key binding for the fuel cutoff switch.
To shut off the engine, place the fuel cutoff control to TRUE.
If you shut down the engine in flight it will windmill. To airstart you will need at least 15% N2, just as with a ground start. When you have enough N2, place the cutoff control to FALSE and the engine will restart. Note that if you can't get enough N2 by speeding up, you can get it by using the starter.
The reverser still works, and is controlled in FlightGear with /controls/engines/engine[n]/reverser. With the reverser control on (TRUE), the engine will produce negative thrust in proportion to throttle position, i.e. to get more reverse
thrust, increase throttle.
Here's a new FGSimTurbine module. Changes are:
1. Adds starting and stopping functionality
2. Calculate() now calls other functions, based on the engine's state, which gives more readable code.
Until now turbine engines were always running as long as fuel was available. With this new module the engine defaults to OFF. To start with the engine running, the variable FGEngine::Running must be set to true at sim startup. In FlightGear this is done with --prop:/engines/engine[n]/running=true.
To start the engine (on the ground), first set the starter to ON, i.e. FGEngine::Starter is set to true. In FlightGear this is done by toggling /controls/engines/engine[n]/starter to TRUE. Note that the current FlightGear key binding will not work, as it causes the starter to quit when the key is released. A new key binding is needed, without the mod-up.
When N2 reaches 15% or greater, place the fuel cutoff control to FALSE. This is FGEngine::Cutoff. In FlightGear this is done with /controls/engines/engine[n]/cutoff set to FALSE. The engine will then accelerate to idle. Upon reaching idle, the starter is automatically turned off, and the engine is running. There is presently no FlightGear key binding for the fuel cutoff switch.
To shut off the engine, place the fuel cutoff control to TRUE.
If you shut down the engine in flight it will windmill. To airstart you will need at least 15% N2, just as with a ground start. When you have enough N2, place the cutoff control to FALSE and the engine will restart. Note that if you can't get enough N2 by speeding up, you can get it by using the starter.
The reverser still works, and is controlled in FlightGear with /controls/engines/engine[n]/reverser. With the reverser control on (TRUE), the engine will produce negative thrust in proportion to throttle position, i.e. to get more reverse thrust, increase throttle.
now read the config file out of the individual aircraft directory rather
than the collective Aircraft-yasim/ directory (which is now obsolete.)
This requires a corresponding update of the base package cvs.
$FGROOT/data/Aircraft hierarchy. There could be some long term performance
concerns if a person has a *huge* collection of aircraft or a really slow
file system, but I see zero performance blip here from recursing the default
CVS tree. We should also allow the user to specify the whole path to the
-set.xml file if they don't want to recurse ... this way we could eventually
come up with an aircraft selection dialog box on the front end so the user
could manually walk the tree to the desired aircraft. There also the system
wouldn't have to search for the aircraft.
functions (note to Norman: I looked at the web page you listed and that
looks like a good idea, but I don't have time right now to go through and
debug an entirely new routine. What we have works well enough for now I hope!)
This patch is there to correct a problem that prevent to load static objects when specifying a relative fg-root or a different, relative, fg-scenery. It appears that there is a mix between fg-root, fg-scenery and PLIB's model-dir.
It has been reported on the list that users are not able to see the buildings, especially those running the win32 builds because they run 'runfgfs.bat' that set FG_ROOT=./DATA.
I decided not to use model-dir because it just add confusion and to build a valid path earlier.
Firstly, the search of a given runway number was coming out wrong if the
reverse of the one actually in the database was given, resulting in the AI
plane going to the wrong runway. This was caused by the fact that if the
reverse runway number to the one wanted was matched then revrwyno was
assigned to rwy.rwy_no, whereas actually it was the original runwayno that
should have been assigned.
Secondly, whilst instrumenting the search with couts to see what was going
wrong, I noticed that one runway would come up loads of times. It turns
out that this is because taxiways and the next airport line were loaded in
as the last runway, with only the type changed, in the constructor. Thus
the total number of runway entries for all except the last airport equalled
(no-of-runways + no-of-taxiways + 1). I've changed a couple of lines to
fix this.
[Curt: this was partially fixed last week, but now it should be completely
fixed. Thanks Dave!]
- Ambient is based off the lookup table only.
- Diffuse is based off of the lookup table, but multiplied by a combination
of sun/fog colors.
The result is a bit more ambient light at dusk and night since the world is
never 100% dark. And we still get nice sunset/sunrise colored illumination
of surfaces that are directly illuminated by the sun.
immediate end to glut, only that I'm going through and cleaning up (and
taking inventory of the actual glut dependencies in case I want to investigate
SDL.)
search when loading scenery tiles. (I am not set on using ";" as the
delimiter because it is a command separator in unix, but ":" is a critical
part of the windows file naming scheme (c:\foo\bar) so that is even worse.)
Example:
--fg-scenery=/stage/fgfs04/curt/Scenery-0.9.1/Scenery;/stage/helio1/curt/Scenery
-0.7.9
The Propeller class ignored negative RPM but still returned a torque
value, which ratcheted up a higher and higher negative RPM until drag
overwhelmed the aircraft.
In reality, the propeller should windmill at a reasonable postive RPM,
introducing a constant drag on the aircraft -- the propeller should
*not* stop unless the plane is flying very slowly. That's a future
project.
The jitter is most likely caused by the irregular frame rate and CPU clock dependent intervals. There's no easy way around that. I tried some fancy interpolation and all that -- to no avail.
- Handle rotational interpolation across the "zero" point.
- Bug fixes to the rotational interpolator
- Change intervals for medium term and long term data recorders.
I have added a fledgling replay system that records flight data and control
positions during the flight.
I have added an internal command called "replay" which will trigger a replay
of the entire saved flight data set. This could be bound to a keyboard or
menu command, in fact this entire module is screaming for someone to build
a gui to control playback speed, amount of playback, etc.
This is the initial version so there are kinks that still need to be worked
out, please be patient.
These changes should preserve previous functionality (with the exception of a
couple bug fixes).
Bugs fixed:
- AP no longer resets the error accumulator when switching altitude modes or
just closing the autopilot GUI. It will not be necessary to collect the barf
bags after selecting a new altitude anymore. Makes things much smoother.
- climb_rate calculation in the altitude hold mode included a factor that made
sense for the c172. It is now scaled according to the configuration's target
climb rate.
Additions:
Autothrottle (supports speed control only) is more configurable and accurate.
VerticalSpeed mode added (automatically arms to altitude if flown toward
altitude setting).
Exposed various properties, added new lock properties.
Square the normalized direction acceleration for the y and z axes, so
that turbulence predominantly affects pitch.
Bind to the /environment/turbulence/magnitude-norm and
/environment/turbulence/rate-hz properties in FlightGear.
The current chase view respects heading but ignores roll & pitch. And it follows heading without delay, which makes the viewer behave quite strange. This change makes the chase view feel more natural. You aren't fixed behind the plane, but follow all its movements with a delay.
Erik Hofman:
I've decided not to add the patch to preferences.xml in the base package because something feels funny with that. I think there needs to be some more discussion about it.
clarity:
nav_radial => nav_target_radial (same as selected, except for a LOC)
nav_heading => nav_reciprocal_radial
nav_magvar => nav_twist (it's not always the same as magvar)
nav_heading_needle_deflection => nav_cdi_deflection
nav_gs_needle_deflection => nav_gs_deflection
Added nav_radial back in, but now it shows the current radial from the
VOR, as one would expect. This value also appears in the
/radios/nav[*]/radials/actual-deg property.
This patch exposes the nav_id--Navaid (VOR/ILS) IDs--in the property tree for use in EFIS displays. Both the string and individual integer (char) values are published.
Erik Hofman:
I have converted all sprintf() functions in navcom.cxx into snprintf() for some extra securety.
This patch adds an "interval-sec" property which allows fixing an interval in seconds (or fraction of seconds) for the repeats for emulated axis controls (digital hats) on joysticks.
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
