block (this required to move most of init() into postinit())
- undo the "which" pseudo-namespace workaround, and do it proper:
- let all nasal code in a joystick config file be executed in its own
namespace. This allows to define functions in the init block that
can be used throughout the driver file, and to write state variables
in one binding, while reading them in other bindings, all without
having to make sure that the values aren't lost in between, or collide
with another joystick driver's code.
For this the input subsystem creates a namespace for each joystick:
"__js0" for joystick 0, etc. The two leading underscores are there to
avoid collisions with user defined modules (similar to internal compiler
variables). The namespace shouldn't be used explicitly, at least not in
releases, and not from outside code, except for testing purposes, for
which it can be useful. (If using the Cyborg joystick as js[0], you
can read the modifier level as "__js0.modifier" from any nasal context.)
- make it public
- enable handleCommand() to execute a binding (or other nasal code defined
in a property system subtree) in a particular namespace (-> "module" child)
These changes represent some attempts to bandaid and patch a hopelessly
flawed system to impliment basic battery charging/discharging as well as
provide the ability to model ammeter gauges and draw current from multiple
sources (like load balancing multiple alternators in a multi-engine aircraft.)
The system design forces all these things to be horrible hacks or depend
on extremely subtle system side effects and call ordering so they may or9
may not work to one degree or another.
As mentioned in the mailing list, my recommendation is to move away from
using this system and instead build a procedural electrical system using
nasal. Sometime in the future we hopefully can impliment a better conceived
data driven electrical system model.
to the joystick index (x in /input/joysticks/js[x]) both when initializing
nasal init blocks & whenever updating the joystick. That's the only way to
make these nasal contexts aware of the joytick for which they were called.
And that's useful if a js maintains common variables, such as modifiers or
state variables, that should be shared between the namespace-less bindings
and initialization code. And, yes, it's over-engineered ... :-)
its own data, and can distinguish itself from other instances of the
same js driver. This property is removed after script execution.
Example:
self = props.globals.getNode(getprop("/input/joysticks/this"));
(no need to list the paths explicitly in $FG_ROOT/joysticks.xml any more)
- move identified js nodes to /input/joysticks/js[0-9], but
- don't overwrite already set joystick data there
- remove all nodes when they aren't used any more
- add "id" node, which contains the js id that lead to the selection
of a "named js" config
- add "source" node containing the path of the used js config file
- execute all nasal script groups at initialization time
I added an AIStatic object to my OV-10 sim for use in putting city signs,
vehicles, or anything else that will be static, but that I don't want to put
in the scenery files. It's inexpensive. Before, I was making such things
from AIShip.
I also added the ability to set flight plans to repeat, so that when an
airplane reaches the end it just starts over at the beginning. This is
useful for my OV-10 sim. I have C-141 and KC-135 traffic flying approaches
to Ramstein, and I only have to define two AI objects to do this.
Also, I found an inefficiency in AIBase, where every AI object was calculating
Mach number at every dt. Now only AIBallistic objects do this.
this is basically the past patch I sent to the list and which should now
really (...!?!?) fix the no ground below aircraft problem.
Reasons:
I understood my remaining thinko I introduced with the prevous patch, and the
same thinko I made in my test cases.
The feedback from the list told me that it should help.
2.
I made YASim query the the ground cache at the wrong place. This one fixed
this, one can now land the bo105 on top of the oracle buildings :)
3.
Is a followup of the scenery center update code: Register the scenery center
transform at the time it is put into the scene graph not at creation time.
4.
I held that part back from the past hitlist patch, because I hoped that it
will be sufficient (and the last one was in fact the biggest part) without.
As some test cases from Melchior showed me, it is not. We have additionally
to the wrong computed transform from the prevous patch some roundoff
problems. This patch adds some small tolerance to for the point in triangle
test.
... may be one even needs to increase the eps value further if starting at
some tile boundaries still fails.
5.
That is a big chunk.
Tested now for two days while hunting the second patch :) .
That is a partial rewrite of the groundcache to use its own datastructures for
that flat scenegraph in the cache. The basic advantage is, what Erik
suggested, to precompute some often used values of these triangles. Also
allmost all computations are now in double precision which should decrease
(hopefully fix), together with a similar tolerance for some point in triangle
tests, the problems with 'no ground below aircraft'.
I am playing with octrees for the groundcache, that will finally solve the
performance problem when high triangular count models end up in the
groundcache. This patch is also some prework for those octrees ...
It happens regularly during normal operation (ufo!) and only informs about
unfortunate, but known and deliberate behavior. The user can't do anything
about it, anyway. And finally: flooding the console with this message does
only *add* to fgfs' sluggish performance and makes every other message
go unnoticed.
Changes
=======
- correct the transparency probleme when old 3d clouds were enabled
(rendering context with an alpha channel)
- changed rain cone orientation, it can now be viewed from helicopter or chase
view (still not tower view)
- clouds are a bit more yellow/red at dawn/dusk
- weather data is now correctly propagated to the interpolator, this correct
visibility, wind, etc
- the 'metar' weather scenario now immedialty reuse the real metar data
- real metar no more overwrite custom weather scenario
1) The AIStorm sets the properties:
/environment/turbulence/magnitude-norm
/environment/turbulence/rate-hz
The actual turbulence effects are handled by the FDM.
If the effects are deemed unrealistic, then that will
have to be fixed in the FDM(s).
2) The zone of turbulence is cylindrical, and is centered
at the AIStorm's lat/lon. The diameter is set with
<diameter-ft>, the top with <height-msl>, the bottom is
assumed to be at <altitude> minus 1000 feet.
3) Note that the zone of turbulence may not match well with
the visual model of the storm. In this case I had to
x-offset the storm model by 4700 meters to match the zone
of turbulence. (i.e. the storm model is 4700m off center).
4) While I was in there I also increased the speed of the
lightning flashes to look more realistic.
This is another update for the cloud code, a lot of lines but this time I have started to add the doxygen doc.
Misc
====
- corrected a bug when RTT is not available, the current rendering context was
altered
- if RTT is not available then 3d clouds are not drawn at all
- impostors lighting is now recomputed when the sun changes position
- distant objects are no more seen in front of clouds
- blending of distant clouds is a bit better now
- litle optimization of code (uses a less cpu time)
- use layer wind speed and direction (no more hardcoded wind)
- fov is no more hardcoded
Changes
=======
- clouds (cu only) are dissipating/reforming (experimental)
- compute a turbulence factor that depends on surrounding clouds and type of
clouds (experimental)
- clouds shapes are defined in cloudlayers.xml
- type of clouds present in a layer is also defined in cloudlayers.xml
- cloud layers are generated from metar and other misc. data (in progress)
- added a rain effect around the viewer (enabled in the rendering dialog and
when the metar property says so)
- added a lightning effect (enabled in the rendering dialog) : cb clouds spawn
new lightnings
- added a dialog to select from different weather source : metar/property,
a 'fair weather' environment and a 'thunderstorm' environment.
/sim/startup/splash-progress)
- a string in /sim/startup/splash-title is displayed on top of the screen
and by default empty
- the splash image is scaled down if 512x512 is too big
- code cleanup
in terms of predictable packing and byte ordering. So rather than trying to
get fancy and shave a few bits off the structure sizes, just go with 32 bit
ints for everthing which saves a lot of potential headaches in the cross
platform and cross architecture arenas.
I have done a patch to eliminate the jitter of 3D-objects near the viewpoint
(for example 3D cockpit objects).
The problem is the roundoff accuracy of the float values used in the
scenegraph together with the transforms of the eyepoint relative to the
scenery center.
The solution will be to move the scenery center near the view point.
This way floats relative accuracy is enough to show a stable picture.
To get that right I have introduced a transform node for the scenegraph which
is responsible for that shift and uses double values as long as possible.
The scenery subsystem now has a list of all those transforms required to place
objects in the world and will tell all those transforms that the scenery
center has changed when the set_scenery_center() of the scenery subsystem is
called.
The problem was not solvable by SGModelPlacement and SGLocation, since not all
objects, especially the scenery, are placed using these classes.
The first approach was to have the scenery center exactly at the eyepoint.
This works well for the cockpit.
But then the ground jitters a bit below the aircraft. With our default views
you can't see that, but that F-18 has a camera view below the left engine
intake with the nose gear and the ground in its field of view, here I could
see that.
Having the scenery center constant will still have this roundoff problems, but
like it is now too, the roundoff error here is exactly the same in each
frame, so you will not notice any jitter.
The real solution is now to keep the scenery center constant as long as it is
in a ball of 30m radius around the view point. If the scenery center is
outside this ball, just put it at the view point.
As a sideeffect of now beeing able to switch the scenery center in the whole
scenegraph with one function call, I was able to remove a one half of a
problem when switching views, where the scenery center was far off for one or
two frames past switching from one view to the next. Also included is a fix
to the other half of this problem, where the view position was not yet copied
into a view when it is switched (at least under glut). This was responsible
for the 'Error: ...' messages of the cloud subsystem when views were
switched.
was probably my idea of a feature, but if the input buffer actually
does has a length of zero (as Melchior discovered for the case of a
zero-length .nas file) then there will be no null.
Changes
=======
- corrected some strange behavior when playing with the render dialog options
- the density slider is now working : if you are fps limited and still want to see clouds in
the distance you should play with that
- added the choice for texture resolution, its more comprehensible now (before it was
wrongly allways choosing 64x64 textures)
- changed the initial texture size : you now have 64 texture of 64x64, this uses 1Mo of
texture memory (before it was 20 texture of 256x256, that took more memory and there was
not enought impostors)
- sun vector is now right so the lighting is a bit better
- removed useless sort and light computations for impostors, this should save a lot of cpu
- blending of distant cloud is more accurate now
- clouds are now positioned correctly, they don't try to escape you anymore
- no more red/white boxes around cloud
- textures are now filtered (no more big pixels)
known bugs
==========
- distant objects are seen in front of clouds
- new and updated sources for the new volumetric clouds
- 2 new textures for the clouds
- an update to the render dialog to enable/disable and change a few parameters
for the new clouds
I have some small updates to the ground cache.
- Remove the usage of dynamic_cast where it is known that the result will be
non null.
- Renormalize the surface normal in double precision.
- Place the groundcaches center at the point it was requested not at the
scenery center. This fixes the problems with JSBSim's trimming together with
the ground cache. Now I am ready to commit JSBSim's ground cache usage.
I'm looking through the AI code, trying to find the bug that's killing the
thermals. The following things don't look right:
1) AIManager::101 , the Traffic Manager pointer is searched for by name at
every dt. I'll leave this for you to look at.
2) AIManager::295 , the thermal height is not being set. We need to
restore the line: ai_thermal->setHeight(entity->height_msl);
This fixes the thermal problem.
3) AIManager::328 , I changed the fetching of the user state to occur every
sim cycle, and changed the fetching function from by-name lookup to a lookup
by node pointer. It should be faster now, and more accurate too. This helps
the air-refueling.
have a "property" mode as well as the original "binary" mode. The property mode
will allow the remote module to request any set of properties, and it will send
those properties each frame. The remote module can reply with a list of arbitrary
property name/value pairs to update on the FlightGear side.
This is a first stab, so it's not the cleanest, most well concieved code, but it
allows an external module (communicating via a pipe) to have a huge amount of
flexibility in the data in can access and update.
Make SDL window resizable; This exposes the same problem that many
GLUT users have: resizing up may cause a temporary switch to software
rendering if the card is low on memory. Resizing down again switches
back to HW rendering. (KSFO is texture intensive, but there are no
problems in LOWL, and elsewhere.) Less and less users will have the
problem as cards become better, and it's no reason not to allow
resizing altogether.
_course_deg is first initialized in the if()-branch (gps.cxx:419). But
this branch isn't entered at first run if wp0==wp1, so that in line 615
fgfs tries to SG_NORMALIZE_RANGE() a random value, which can take a
long while if the number huge. This was occasionally a number greater
than 10160!
- initialize all vars before they are used (fixes endless loop)
- fix some compiler warnings (initialization order, unused vars)
FGAIMgr::GenerateSimpleAirportTraffic() tries to determine the airport's local
hour from the /sim/time/gmt-time string, which fails, because at this time the
property is still empty. That's why I don't get ATIS at LOWG (where it is *not*
midnight right now. :-) -> use sg's get_cur_time() instead
- don't treat *every* child in the xml as submodel, especially not a "param"
block
- do not only *enable* the contrail flag above some altitude, but also
disable it below
showDialog() is careful not to create a new FGDialog() if a dialog with the
same name is already open (active). But at this point it is already too late:
newDialog(), which was called shortly before, has already overwritten the
dialog properties. This leads to animated garbage in the best case, and a
segfault in format_callback() in the worst case.
- GUI::newDialog(): Don't you overwrite properties of an active dialog!
- GUI::readDir(): You may do that, but delete the old dialog first!
(necessary for reloading the GUI)
- FGDialog::makeObject(): only set format_callback() with setRenderCallback()
if the property is "live". Otherwise, only call it once at construction
time. This isn't only a performance improvement. Without this the label
was growing until it hit the limit (256).
The previous message wasn't totally correct. Strings are now allowed, too. And
the pattern is now '[ -+#]?\d*(\.\d*)?l?[fs]' and *may* be embedded in a string.
There may only be one %s or %f, though. %% is allowed in the preamble/postamble.
(Yes, %ls is allowed, too, and treated as %s.)
Also, "end" is superfluous now.
Printing floats in dialogs with 8 digits after the comma is inappropriate
for most cases.
- implement a "format" property for "text" gui elements (a.k.a. pui label).
Number formats are set by strtod/snprintf, while formats on non-numbers
are replaced by "%s". Practical example in the upcoming material.nas update.
Valid formats regex: '%[ -]?\d*(\.\d*)?l?f' (IOW: the format must begin
with '%' and end with 'f').
# Nasal:
number = dialog.addChild("text");
number.set("label", "3.1415926");
number.set("format", "%.3f");
The dialog handling has been written at a time when only one dialog was
shown at the same time, and dialogs were shallow -- with only children, but
no grand-children. This makes finding a draggable spot on modern, dialogs
with nested objects quite a challenge. The patches fixes this, and other things:
- check full object tree on button press, not only the outmost layer;
and don't give up just because we are in *something* (which could well be
something harmless, like a group); only ignore a few, sensible objects
(we don't want to drag after a click on a button or into an input field)
- don't lose dialogs as easily when dragging too fast (it does still happen
if one manages to enter an editable field while dragging, but this is
a plib problem and I don't feel like fixing that now :-)
- don't "live"-update input fields while they are in edit mode
- remove some "if (foo) delete foo;" redundancy
popping up and crashing when the B-29 model is in use. This isn't the
right solution; we should fine the NaN condition. But it's harmless
and allows development with the B-29 to continue.
back, but forgot to put the same fix into the runtime code. Also
added some comments so I don't get confused again the next time I come
through here. :)
I have done some cleanup where I moved some values out of classes where they
do not belong and such stuff.
Also the fols offsets are now named in the carrier xml file with a more
verbose name (flols-pos/offset-*) than before (only offset-*).
There is a little preparation for definitions of parking positions on the
carrier which should later be used for starting flightgear directly on the
carrier.
a safe undersleep() to conserve cpu. Essentially we undersleep our target by
just a bit (to avoid the chance of oversleeping.) Then we finish off the
remaining time slice with a busy-wait loop.
Norman Vine wrote :
> Frederic Bouvier writes:
>
>> Quoting Andy Ross:
>>> * Hopefully in a CPU-friendly way. I know that older versions of
>>> the NVidia drivers did this by spinning in a polling loop
>>> inside the driver. I'm not sure if this has been fixed or not.
>>>
>>> From my experience, the latest non-beta Windows NVidia driver seems to eat CPU
>>
>> even with sync to vblank enabled. The CPU usage is always 100%.
>
> Buried in the PPE sources is a 'hackish' but portable way to limit CPU usage if the desired framerate is met
>
> /*
> Frame Rate Limiter.
>
> This prevents any one 3D window from updating faster than
> about 60Hz. This saves a ton of CPU time on fast machines.
>
> ! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV !
> */
>
> static ulClock *ck = NULL ;
>
> if ( frame_rate_limiter )
> {
> if ( ck == NULL )
> {
> ck = new ulClock ;
> ck -> update () ;
> }
>
> int t_ms = (int) ( ck->getDeltaTime() * 1000.0 ) ; /* Convert to ms */
>
> if ( t_ms < 16 )
> ulMilliSecondSleep ( 16 - t_ms ) ;
> }
>
>
I implemented the method pointed out by Norman. It works great on windows and saves me a lot of CPU cycles. This way, I can get the same framerate in moderately populated areas and have CPU idle 50% of the time instead of wildly looping in the NVidia driver while waiting to sync on vblank.
It has been tested on Linux by Melchior. He saw the same gain in CPU cycles.
I have added a --aspect-ratio-multiplier=x.xx option to give some end user
control over the aspect ratio. (This may seem a little strange, but it's a
building block towards the capability of doing asymmetric view frustums in
FlightGear.)
ssgSetNearFar(). This by default creates a symmetric view frustum which is
typically what an application wants.
However, to get control of the view frustum in order to build support for
asymmetric view frustums, we need to wrap these calls with a bit of our own
logic.
This set of changes wraps all calls to ssgSetFOV() and ssgSetNearFar() with
FGRenderer methods.
I also standardized how the FGRenderer class is handled in globals.[ch]xx.
This led to some cascading changes in a variety of source files.
As I was working my way through the changes, I fixed a few warnings along
the way.
I attach the long-promised improved version of the USS Nimitz.
It includes an improved version of the FLOLS, which requires the attached
diff to be applied to AICarrier.cxx and AICArrier.hxx.
I've made lots of eye-candy in the form or the flightdeck crew.
Unfortunately, it about doubles the size of the tarball. I'll send it to you
later; when I've figured out some way of only loading on request (any advice
would be very welcome).
I could provide a \u2018bare\u2019 version to cut down on the vertex count for
less capable systems however, the count isn\u2019t huge in the first place.
I've cut the textures down as far as I can without losing definition.
I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
I've added some features to the PID controller:
Ability to set desired sampling interval in seconds. Use <Ts> under <config>
to set the desired sampling interval of the PID controller.
Example:
<config>
<Ts>0.1</Ts> <!-- desired sampling interval -->
<Kp>-0.05</Kp> <!-- proportional gain -->
<beta>1.0</beta> <!-- input value weighing factor -->
...
...
</config>
Ts defaults to 0.0, so if you don't set it it samples at the highest possible
frequency.
Add an offset to the input variables (input and reference).
Example:
<reference>
<prop>/controls/flight/elevator</prop>
<scale>-1.5</scale>
<offset>1.0</offset>
</reference>
Note that <scale> has higher precedence than <offset>, regardless of the order
that they appear in the config file.
I have made the
'Select Airport from List' option in FlightGear work
(I think) properly. I have some concerns about the
solution, which could be broken by changes to plib (if
they re-use the value I have assigned to
PUCLASS_LIST), but for the moment it seems to work OK.
Erik Hofman:
A request has been sent to John Fay to include the puList
code in the puAux subdirectory of plib so expect some
changes for future version of FlightGear.
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft.
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
Here's again one of the more obscure bugs that valgrind complains about: somehow
the STL container classes manage to read out values before they were ever set.
This patch fixes that. This may not cause any harm in this case, but valgrind
seems to *always* be right about them.
The following patches to SimGear & FlightGear ...
- create an FGMetar abstraction layer, whose purpose is:
* provide defaults for unset values
* interpolate/randomize data (GREATER_THAN)
* derive additional values (time, age, snow cover)
* consider minimum identifier (CAVOK, mil. color codes)
- add rain/hail/snow/snowcover support on the METAR side
- add max age of METAR data handling (currently set to
- add support for an external METAR cache proxy server
- add CAVOK handling
- set missing year/month in regular METAR messages
- fix a small bug in metar.cxx (wrong return value)
rather than /instrumentation/comm ... we need to be a little careful here
because typically, a single knob controls power to both matched com/nav pairs.
explicit calls to shutdown_all() which was causing this to be called twice.
This could cause problems with some IO modules (such as attempting to close
an invalid file descriptor the second time.)
a seperate explicite call or the io channels will be forced to try to shutdown
twice which could cause problems for some IO modules (i.e. attempting to
close an invalid file descriptor the second time ...)
We should now be able to find
wires or catapults when the ac3d model is loaded without the crease patch
(caused by the much more unstructured scene graph emitted by the old loader).
It should also emit more warnings if the carrier hardware configuration
includes conflicting definitions.
That code is the most intrusive one, it should not be used until you configure
an aircraft carrier as a aimodel. So I think it should be save to apply that
before the release too.
Attached is a patched runways.cxx. This fixes the find runway nearest to a given heading code. This was returning the last runway loaded at a given airport, not the nearest runway to the heading requested (which seems to always be 270deg by default). I have no idea how this has survived unnoticed for so long - I think it might be because you need to start at an airport with a runway near to 27 and one much greater than 27 eg. 36 to really tickle it, otherwise the runway nearest to 27 tends to be the final one loaded anyway. Try starting at KARR with and without the patch and note the surface wind. This should go in before the release.
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
I have a small update which fixes the algorythm used for marking solid
surfaces for some cases where some branch nodes carry the object names I had
expected in the leaf nodes.
That will also introduce the possibility to mark whole subtrees from the
scenegraph solid.
I still work on getting the YASim models see the detailed environment
especially the carrier.
I have *forgotten* to initialize and to destruct the ground cache object!
Oooopppss!
The attached patch allows to put comments in *.stg files[1]. Lines with
# in the first column (and only there!) are skipped. This has no effect
on overall performance, but has two advantages:
A) possibility to temporarily comment out objects during scenery design,
(or to put other remarks there);
B) possibility to put marks like "# BEGIN" and "# END" there that allow
automated merging of local landmarks etc.
--
[1] actually, comments are possible now, too. But they aren't explicitly
handled and fgfs tries to parse words in "comments" piece by piece. Ugly!
[2] Idea by Chris METZLER, that I make already use of. I have a local
scenery dir for some tiles with extra objects, such as VOR/DME for
all of Austria. These are surrounded by "# BEGIN LOCAL" and "# END LOCAL",
and today I was able to merge the new 0.9.7 scenery with my locally
changed files. :-)
I've finished the emigration of the radiostack, and I've also removed it
completely. It turned out that the comm radio is completely implemented in
the ATC subsystem. I've changed the affected ATC files to point
to /instrumentation/com, but I guess that the maintainer of the ATC code
should decide wether to make it configureable, and how.
I also had to change some files in Network and Main. The changes in network
should be obvious, but the changes in Main were a bit suspect. The files
included radiostack.hxx, but they weren't directly depending on
radiostack-hxx. They were depending on other files that were included by
radiostack.hxx. I got it to compile, but I'm not sure if I included the
correct directly depending file.
For the data directory I changed every occurrence of /radios/
with /instrumentation/ with this simple one-liner that I found on the net:
find -name '*.xml' -type f | xargs perl -pi -e
's/\/radios\//\/instrumentation\//g'
Instead of me sending all the files that got changed by this I suggest that
you execute the one-liner yourself. Of course I can not guarantee that this
will work perfectly, but I considered hand editing to be not an option (I'm
lazy). I don't want to test every aircraft to see if everything still works,
I think it's better to wait and see if anyone complaints about broken nav
radios/instruments.
This is a sub-system which can be added to any carrier.
These files add a functioning Fresnel Lens Optical Landing System (FLOLS).
The orange/red 'source' lights are illuminated according to the position of
the pilot's eye above/below the 3.5 deg glide slope. The apparent position
of the source light relative to the fixed green datum lights allow the pilot
to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is
below the coverage of the lowest (red) source light.
TODO - add rules for the operation of the wave-off lights.
I understand that the new hud/runway feature is still very experimental,
and that the search criteria for the active runway don't necessarily make
much sense. (We are searching for a runway on /sim/presets/airport-id
that matches the current wind direction best, and not the tuned in ILS
runway or something!)
Anyway: the new hud code completely denies the possibility of
globals->get_runways()->search() not finding a runway and returning false.
There's always a runway found at KSFO, but not so at e.g. LOXL, in which
case we are handing garbage over to sg_geodesy.cxx and find ourselves
caught in an endless loop in geo_direct_wgs_84().
Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic
can now fly multiple routes and be initialized while sitting statically at
airports.
currently just returns a lagged normalized value in the range of 0-1 that
is proportional to N1. It's up to the engine gauge to scale to the right
range. This is for lack of a real model of these items so we can have
something to drive the engine gauges.
I have now split out the ground cache functions into src/FDM/groundcache.[ch]xx
Attached are the two files and the patch to integrate that cache into
FGInterface.
The code is nowhere used at the moment, the fdm's need to be updated to use
that ground cache. The JSBSim-dropin.tar.gz from Martins ftp server does this
for example.
The carrier's scenegraph is not yet processed to be visible for ground
intersection testing. So the only benefit up to now is that the api is set
up. Using this I can put the changes to make JSBSim work with that into
JSBSim's cvs. Also I aim to provide Andy a patch to make use of that with
YASim.
Use a suggested exit method as described in the SDL_Quit man page. (fgOSExit() is still uncalled in both fg_os.cxx (glut) and fg_os_sdl.cxx, which makes these functions kind-of useless.) The other changes are fixes for gcc 3.3.4 warnings.
directory and over to the Instrumentation directory and make them modular
in the sense of being able to pick and choose what you include with any
particular aircraft.
Aaron says:
I just got the virtual runway hud projection working on all views and
2D & 3D HUDs. It is working awesome(see below). I have attached every
file that was modified (hud.hxx, hud.cxx, and the default.xml for the hud)
and every file that was added (hud_rwy.cxx and runwayinstr.xml).
Just a quick overview of how the instrument works.
The virtual runway is projected by getting the "cockpit view" of the
runway in 3D and projecting the points on to the 2D HUD. Therefore, the
virtual runway will be displayed the same in every view. For example,
you can land an aircraft from the "Tower View" by flying the HUD. Also
if you're in "Cockpit View" and it is centered then the virtual runway
lines will perfectly outline the actual runway. I am getting the active
runway via the wind like done in the ATC classes, which may need changed.
Also, I made the assumption the view 0, in view manager, is always the
cockpit view, which may need changed as well.
The runway configuration file will allow you to specify a center offset
(x,y) and a bounding box (width,height). You can also configure the line
stipple pattern for the outside and the center line. For instance, if
you wanted a 0xFAFA pattern, then specify 64250 as the value. If you
want a solid line, you can specify -1 or 65535 (0xFFFF) and zero will
turn the line off. It also draws a runway indication arrow when the
runway is not in the HUD or it can be drawn all the time if arrow_always
is true. The arrow will point in the direction of the runway (2D) by
rotating around the center at a radius of arrow_radius. If you wish to
turn the arrow off, you must set the arrow_scale <=0. The arrow really
should be 3D arrow that points to the runway (or points in the direction
of the aircraft-to-runway vector).
Add some controls required for carrier operations:
/controls/gear/launchbar
should be 1.0 if the launchbar is lowered, that means the aircraft should now
be arrested at the catapult.
/controls/gear/catapult-launch-cmd
Should be set to 1.0 when the aircraft should be launched from tha catapult.
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.
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.
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).
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.
Add a projector landing sight.
Add auto-land facilities.
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.)
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.
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.
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.
As a result of recent requests, I've implemented the ability to switch off
aerodynamic stabilisation:
This has to be added to the submodel.xml files:
<aero-stabilised>false</aero-stabilised>
When false the submodel retains the pitch given at instantiation.
It defaults to true.
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.
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.
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. ;-)
