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!]
