ehofman [Fri, 19 Nov 2004 12:33:08 +0000 (12:33 +0000)]
Mathias Fröhlich:
The moving ai models will jump around realtive to the moving aircraft model.
I can see that with the carrier but others have noticed that too with ai
aircraft before.
The reason is that all SGSystems are called with a dt value which is not
necessarily a multiple of 1/hz.
In contrast, most FDM's use the _calc_multiloop function from FGInterface
which forces the time update to be a multiple of 1/hz for the FDM aircraft.
As a result, in the worst case, the FDM aircraft has moved nearly 1/hz seconds
further than the rest of flightgear (1/120sec*300kts that is about 1.3m).
That patch forces the time update to be a multiple of 1/hz.
curt [Thu, 18 Nov 2004 17:40:03 +0000 (17:40 +0000)]
This code is written on top of a driver interface only available with linux
(/proc file system) so it doesn't make sense to have other OS's trying to
open these files because they could never exist.
curt [Thu, 18 Nov 2004 05:04:35 +0000 (05:04 +0000)]
- ATC-Inputs.cxx: Fix some portability problems for non-linux operating
systems. Fix a couple bugs/oversights.
- atc610x.cxx: Much code has moved into the configurable input mapper
(ATC-Inputs.cxx) and the remaining input massaging code has moved into
the atcsim.nas module.
ehofman [Sat, 13 Nov 2004 15:00:00 +0000 (15:00 +0000)]
Roy Vegard Ovesen:
We have decided that hardcoded initialization of instruments and systems is
bad. So we remove them.
Hardcoded initialization is bad because it can't be overridden from config
files or from the command line. We prefer to do it through config files that
should be, eventually, aircraft specific (*-set.xml), not global
(preferences.xml).
ehofman [Sat, 13 Nov 2004 14:45:57 +0000 (14:45 +0000)]
Vivian Meazza:
I attach the latest version of Nimitz. The textures have been improved. A glide-path has been added, it is on by default, but can be switched off by means of the properties browser: /ai/models/ship/controls/glide-path. The origin has been adjusted to the turning pivot and approximate roll center.
Modified AiShip files are also attached. These allow the radius of the turning circle of a ship to be input. The turning circle is adjusted for speed and rudder angle. Roll has been corrected so that a ship leans out of a turn, not inwards like an aircraft. The roll angle is adjusted for speed and rudder angle (yes, application of more rudder reduces roll angle - rudders act as stabilizers).
TODO
Add a relative wind calculation so that a carrier can be turned to the appropriate launch and recovery courses.
Add a 'flight plan' so that the carrier can carry out a racetrack for flight ops.
ehofman [Mon, 8 Nov 2004 17:41:30 +0000 (17:41 +0000)]
Melchior FRANZ:
The caption should already be set when the window is opened. This is
important for some window managers. (KDE's kwin, for example, can store
special settings for certain windows, such as "no border" and "always
on top". KDE uses the window title to determine if a special rule is
to be applied. KDE will be made more tolerant, too.)
ehofman [Sun, 7 Nov 2004 14:46:21 +0000 (14:46 +0000)]
David Culp:
Here are files to get automated contrails working. I've set up contrails for
the 737, using my simple, untextured contrail model. Vivian has made another
contrail model, but I'm still trying to get his to work. I'm hoping others
will try to make contrail models also.
Here's some code that defines a top to thermals. When the top of a thermal is
reached the strength is phased-out linearly over the next 100 feet of
altitude. At first I tried just capping the thermal at the top, but the
change in thermal strength was too fast for the FDM to handle well.
Included is a new version of the thermal scenario that includes a top
(height-msl) to the thermal. The default value is 5000 feet.
david [Fri, 5 Nov 2004 00:18:58 +0000 (00:18 +0000)]
Added acceleration error to compass (most obvious during heavy braking
on the ground) -- this is based on some wild guesses, but it seems
reasonable for now.
The next step will be to give the compass some angular momentum so
that it does not snap instantly to a heading, and so that it can
overshoot a heading and oscillate.
david [Wed, 3 Nov 2004 15:59:49 +0000 (15:59 +0000)]
Begin a rewrite of the magnetic compass code. So far, only northerly
turning error is supported, and I don't know if this works properly in
the southern hemisphere.
david [Wed, 3 Nov 2004 15:15:32 +0000 (15:15 +0000)]
Begin a rewrite of the magnetic compass code. So far, only northerly
turning error is supported, and I don't know if this works properly in
the southern hemisphere.
ehofman [Thu, 28 Oct 2004 09:37:21 +0000 (09:37 +0000)]
Boris Koenig:
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-status={level} --show-aircraft
whereas "level" can be anything between
"alpha","beta","early-production" and "production"
Of course running something like
fgfs --min-status=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required
<status></status>
tag - but you can easily give it a try by adding something like
<status>alpha</status>
The tag should be placed as a sub-tag within <sim> - so directly behind
the <description> tag would be just fine and straight-forward.
ehofman [Tue, 26 Oct 2004 12:06:45 +0000 (12:06 +0000)]
Roy Vegard Ovesen:
I've made an encoder and a transponder. The transponder gets C-Mode altitude
information from the encoder. These two might not be very usefull right now,
but I think they might come in handy when the ATC network gets going.
ehofman [Sun, 24 Oct 2004 14:45:52 +0000 (14:45 +0000)]
Melchior FRANZ:
input.cxx allocates memory for js->getNumAxes() axes and for jsCaps.wNumButtons
or MAX_JOYSTICK_BUTTONS buttons per joystick. But it doesn't check if some
xml config defines bindings for more axes/buttons, in which case it writes
to unallocated memory and causes crashes. This is a real world example:
sidewinder-force-feed-pro.xml defines 7 axes, but only newer versions of
this js do actually have that many. Older ones (-> gameport) don't. The patch
drops unused and unusable bindings.
ehofman [Sun, 24 Oct 2004 11:05:14 +0000 (11:05 +0000)]
Roy Vegard Ovesen:
I've added two new debug log types for the instrumentation and systems. They
used to use the autopilot debug log, because I couldn't figure out how to
make new log types. Well, now I have figured it out. ;-)
ehofman [Fri, 22 Oct 2004 09:26:51 +0000 (09:26 +0000)]
Boris Koenig:
This will modify menubar.cxx/hxx so that it exports the
entire menubar (from menubar.xml) to the property tree, so that it can
now be changed dynamically using Nasal's setprop() instruction and
afterwards running a newly added fgcommand to update the menubar
based on those changes using the appropriate menubar path within
the property tree.
By default the menubar from menubar.xml will be stored within:
/sim/menubar/default
Erik:
I have moved the loading of menubar.xml into preferences.xml and
made sure that the menubar is destroyed every time a new menubar
is created.
ehofman [Thu, 21 Oct 2004 09:21:05 +0000 (09:21 +0000)]
Frederic Bouvier:
I think I found the problem in props.hxx. I have an exception when copying properties. An alias to a property that has no value trigger this exception. The code that generate that is in AIManager.cxx :
controls/gear/gear-down has no value ( _type == NONE ) and controls/lighting/landing-lights is copied somewhere.
Erik:
Frederic's fix was to change props.hxx but he has expressed his doubts.
For now I've commented out the line that causes the problem so we have more
time to look deeper into the problem.
ehofman [Tue, 19 Oct 2004 11:10:20 +0000 (11:10 +0000)]
A first stab at an ACMS (Aircraft Condition Monitoring System) Special Purpose support FDM. Move the ADA FDM into the Special Purpose directory and make the SP FDM's a configure option.
ehofman [Sun, 17 Oct 2004 17:29:34 +0000 (17:29 +0000)]
Frederic Bouvier:
This is a patch to make display list usage optional. They are on by default.
Use --prop:/sim/rendering/use-display-list=false to use immediate mode.
There is also a change in exception handling in main.cxx and bootstrap.cxx
ehofman [Sun, 17 Oct 2004 17:23:19 +0000 (17:23 +0000)]
Frederic Bouvier:
This is a patch to make display list usage optional. They are on by default.
Use --prop:/sim/rendering/use-display-list=false to use immediate mode.
There is also a change in exception handling in main.cxx and bootstrap.cxx
ehofman [Sat, 16 Oct 2004 12:37:39 +0000 (12:37 +0000)]
Roy Vegard Ovesen:
Instrumentation and systems are now configureable from xml files. The two
generic configurations generic-systems.xml and generic-instrumentation.xml
configures the systems and instrumentation as it was hardcoded. You can
override the generic configurations in a similar way as you override the
autopilot configuration.
ehofman [Thu, 14 Oct 2004 09:19:44 +0000 (09:19 +0000)]
Roy Vegard Ovesen:
I've added some digital filters to the autopilot. They are all low-pass
filters that filter away high frequency signals/noise. There are 4 different
filters:
1. Exponential - The algorithm is essentially the same as the one used in the
fgGetLowPass() function.
2. Double exponential - Two exponential filters in series. This filter has a
"steeper" frequency response curve. It filters "better" than the single
exponential.
3. Moving average - Averages a number of inputs.
4. Noise spike - limits the amount that the output value can change from one
sample to the next.
Filters 1 and 2 are characterised by it's filter-time in seconds. For filter 3
you have to set the number of input samples to average over. For filter 4 you
set the maximum allowed rate of change as [1/s]. Since the sampling interval
(dt) isn't constant we have to calculate the maximum allowed change for every
update.
Example of a double exponential filter with filter time 0.1 seconds, that is
1/0.1 = 10 Hz.
ehofman [Thu, 7 Oct 2004 20:34:56 +0000 (20:34 +0000)]
Melchior FRANZ:
As I had reported on 2004/8/4 00:02:56 ("yasim + bo105 + vrp + @#%$#@ == argh!")
there must be a bug somewhere in YASim, which is responsible for the Bo105
turning around the FDM origin (nose tip) rather than the CG. Some people assumed
that I was just another victim of the "view offset" illusion, but this wasn't
and isn't the case.
Maik Justus (the rotor man) has now supposedly found the bug in YASim[1].
Look at this code in FDM/YASim/Integrator.cpp:35--66:
ehofman [Wed, 6 Oct 2004 09:57:37 +0000 (09:57 +0000)]
Reverse the declaration order. jpgRenderFrame (form
erly known as trRenderFrame) is now declared as a NULL function pointer and ass
ignment of the proper function is now done in FlightGear (jpgRenderFrame=FGRend
erer::update).
curt [Wed, 6 Oct 2004 03:29:14 +0000 (03:29 +0000)]
Continued work to clean up the hires screen shot code and move it back towards
a working state. I still see an anomoly when taking a screen shot from inside
a 3d cockpit, but external (chase/tower) views seem to work well. I also
added a property to control how many screen-res tiles are generated in the
output. Theoretically, you can now generate unlimited resolution screen shots,
or limited only by your disk space and patience.
Today I successfully generated a 20*1024 x 20*768 (20480x15360) resolution
screen shot. If you rendered that at 100 dpi it would cover a poster of
about 17 feet by 12.8 feet.
Good luck trying to display something that big or convert it to anything
useful on a typical PC. :-)
david [Sat, 2 Oct 2004 22:35:39 +0000 (22:35 +0000)]
Restore trRenderFrame (which used to be in main.cxx before the
split). If SimGear is configured --with-jpeg-factory, then FlightGear
will fail to build unless this function is present.
FIXME: this is very messy architecturally -- find a better solution,
like passing this explicitly as a callback to the libJPEG class
(SimGear should not have a dependency on FlightGear).
ehofman [Sat, 2 Oct 2004 12:02:04 +0000 (12:02 +0000)]
Vivian Meazza:
I've finished the variation of Cd with Mach number.
The calculations are only applicable to ballistic
objects, and then strictly one shape: non boat-tailed bullets/shells, so
I've put them in AIBallistic rather than AIBAase. For all inputs, Cd
should be the sub-sonic value, so bullets will need changing.
Use the Transmit-Render functions for tower output instead of directly calling ATCdisplay. This is part of preparations for optionally handing the strings off to a TTS engine if required.
The calculation of submodel mass from weight has been moved from AIBallistic
to Submodel so that it is calculated only once, rather than on every
iteration as a present. The parameter <contents> has been added, primarily
so that droptanks will have the proper mass. It is the path to an
appropriate property containing a weight in lbs.
Care has to be taken with the use of <contents> because after a reset there
appears to be a delay in submodel instantiation (dt not properly reset???)
and the weight property is not always picked up before it is set to zero in
the key bindings. Slightly hard to explain. It works fine if FGFS has not
been reset though. There is a partial solution which involves the rejigging
of the fuel and gui nasal scripts, but there is still the visible delay in
instantiation to be resolved. I've nearly done the nasal fixes, which will
form part of an update to the Hunter only. I'll probably complete those
later today.
The value of rho (air density) varies with height. (Including the upper
stratosphere, ust in case someone wants to model ICBMs.) The standard
atmosphere is used (based on a sea-level temperature of 15 deg C.).
Erik Hofman:
I moved this code over the AIBase::update() so all AIModels can make
use of rho, temperature, pressure, etc.
I have added <Cd> and <weight> to the input parameters in the submodels.xml
script. Raw data may be used, thus avoiding the need to guestimate <eda>.
Eda remains, but should now be used to enter the proper cross-sectional
area.
Finish what was committed in a broken state yesterday.
Split up main.cxx into a program manegement part (which remains in
main.cxx) and a render part (the new renderer.?xx files). Also turn
the renderer into a small class of it's own. At this time not really
exctining because most of the stuff is still global, but it allows us
to slowly migrate some of the global definitions into the new class.
The FGRenderer class is now managed by globals, so to get the renderer
just call gloabals->get_renderer()
At some pijt it might be a good idea to also turn the remaining code in
main into a class of it's own. With a bit of luck we end up with a more
robust, and better maintainable code.