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.
