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
- 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.
