This patch limits the maximum simtime we do simulation computations for.
That is highly sensible if you run flightgear in valgrind or some realy slow
debug build. In such a case it is possible that flightgear gets totally
unresponsible, because simulation time might increase slower than real time.
That patch introduces a maximum simulation time per rendered frame to limit
that effect.
If the property /sim/max-simtime-per-frame is set to something strictly
positive, the simulation time is limited to that value.
The default is unchanged - no limit.
Anyway, from the point of view of gui responsiveness and responsiveness to
realtime controls like joystick inputs it might be a good idea to limit that
by default to say 1 second. If you have less than 1fps, flightgear is
unplayable anyway and I believe we do not longer need to care for realtime
correctness for that case ...
though the window wasn't resized. I'm just not adventurous enough for
a cleaner solution in the light of the upcoming release. At least the
xsize/ysize properties aren't set each frame any more, so listeners
work now properly.
Incorporating the shared ptr code:
- All scenegraph references from SimGear
- SGMaterial which already had a reference counter uses now that common
infrastructure.
- SGMatModel is now counted.
- SGSoundSample from SimGear
- And the corresponding change for the sound samples in flightgear which fixes
a latent crash if FGBeacon would evern be deleted.
Erik Hofman:
This patch contains an update to net_ctrls.hxx that adds an extra 100 bytes
(or an equivalent of 25 (u)int32_t types) of reserved space. This could be
used to make the protocol forward and backward compatibel within a certain
scope. Be sure to read the instructions at the begining of the header file
when addinf new variables.
"play-audio-function" command. This function can be called from internal
code, from nasal scripts, or from external scripts to play a single one-off
wav file. File/audio data is loaded and unloaded on the fly automatically.
Create a queue of one-off wav files. Calling layer can request the system
to play any wav file. The request is thrown at the end of a play queue.
The queue is serviced sequentially so that queued wav files will no longer
overlap. When a sample is finished playing. It is removed from the queue
and deleted from memory. The next remaining request in the queue is then
played.
- Provide a Nasal interface to display simple text messages on the screen
like the ATC display. In fact, I copied the code from the ATCDisplay.cxx
and simply shifted it further down the screen.
Erik:
TODO: Integrate the two pieces of code.
anything in the nav tree is valid or not.
- Fix an order problem between caching data values and searching for a new
station that could cause odd and unexpected and hard to reproduce results.
Added a convenience function to estimate the time to intercept the selected
radial give the current heading and speed. This can be useful to a flight
directory to compute the point to switch from armed to coupled mode at just
the right time so the pilot can roll out onto the desired heading on the
desired radial.
Add a first whack at estimating a ground track heading error (difference
between aircraft heading and ground track directon.) This needs more work
and testing.
The prototype of update_metar_properties does not match overridden func.
trafficmgr: iterators below begin() and after end().
tower.cxx : iterator incrementing beyond end().
replaced with efficient listener callbacks. One use is the new FPS display.
This is reviewed and OK'ed by Andy, relatively trivial and separated from
the rest of Nasal, so problems are quite unlikely and confined to users of
this function.
The callback is executed whenever the property is written to -- even if
the value didn't change. The triggering Node is available via cmdarg().
Examples: _setlistener("/sim/crashed", func {print("haha!")});
_setlistener("/foo/bar", func { print(cmdarg().getPath() ~ " changed")})
it's also possible to enable/disable menu/item entries with higher numbers.
This can be useful for adding entries from other config files (aircraft
specific or local). I'd say aircraft files can use indices starting with
[100] and local files starting with [1000]. Such high number will never
collide with an entry in menubar.xml, even if entries are added/removed
there.
Display the ground intersection point on mouse click (if click not consumed
by the gui or the panel.) This should eventually get stuffed into the
property tree.
Computes the pick direction and starting point. This is code that translates
a screen coordinate into a vector in the FlightGear world (between the eye and
the on-screen coordinate.) Armed with this vector in FG world coordinates,
you could call a scenery intersection routine and lookup the lon/lat/elev of
the point in the world that was clicked on.
* in some cases more specific sg exception types were used in place
of the more generic one, e.g., sg_io_exception instead of sg_exception
when the context of the error was an IO error
* in some cases, the error message was made more specific
* minor style fix for exception rethrowing --- using throw; whenever
a re-throw is made; sometimes optimizing away the exception symbol name
in the catch handler at all
* more specific catch handlers added in some places -- e.g.,
an sg_io_exception caught ahead of sg_exception
- fix indentation (there were 2, 3, 4, 7(!) space indents as well as tab
indents, all mixed together)
- no code changes, except one "if (foo) {}" changed to "if (!foo) return; ..."
Unfortunately, we don't have an easy way to access the puObjects
only by knowing the respective XML property node, because the
menu structure was built by plib from string lists. That's why
we walk the puMenuBar tree and store {property node}->{puObject*}
pairs in a map. With this infrastructure in place we can now
easily enable/disable entries, but we can also make other changes
to menu buttons as we see need. The structure of puMenuBar is
described in the pui documentation, so it's less of a hack than
it looks. :-)
remove a hack and do it properly: if the requested elevation is for some
reason below the surface and the intersection test fails (as it appears
to be the case in EGLL), try again from 10000m ASL
mf: typos
Insert empty string as marker between FG_SCENERY path elements.
FG_SCENERY=A:B expands to [A/Terrain, A/Objects, "", B/Terrain, B/Objects, ""]
(assuming that both A/ and B/ have Terrain/ and Objects/ subdirs).
tileentry.cxx -- FGTileEntry::load():
Check all tile dirs in FG_SCENERY from left to right: add all objects
to the scenery until a terrain tile was found: In this case read the
rest of that group (i.e. the Objects/ twin dir) and then stop scanning.
Better structuring of log messages & fix warnings.
sea tile, and finally process the objects. This guarantees that all objects
are placed relative to a valid tile center, rather than to the origin (0/0/0).
This is important for objects in sea tiles, and allows to display objects
of *.stg files that came sooner in FG_SCENERY.
This was the reason why some people (especially SuSE10.0/gcc 4.0.2
users) couldn't see others in MP. I don't even know why I'm committing
that. It's less important than taxi lights ...
metar fetcher. Effectively this caused the metar thread and the main
thread to both attempt to fetch weather data. This could lead to long pauses
when the main thread decided to fetch the weather, and introduced a race
condition that could cause a segfault/crash.
Investigating this issue, I discovered that even longer ago, someone confused
#defines and #ifdef symbols with C/C++ variables. If I #define XYZ 0 it is
defined so #ifdef XYZ is true, not false like a variable. Our thread
detection made this mistake and there were follow up patches to work around
it.
So I fixed the configure script (ahhh, reading the autoconf manual is highly
recommended excercise for people editing the configure.ac file.) I also
discovered that we were hardwiring with_threads=yes with no way via configure
options to disable threads from the build so I fixed that.
Then I patched up the #ifdef's scattered through the code to match the
configure script changes, oh and by the way, I stumbled upon a past typo
that led to the race condition in the metar fetching thread and fixed that.
Here's a fix for a bug I introduced when I updated the AIStorm with
turbulence. The change I made to the FGAIEntity struct was overriding the
thermal <strength-fps> data.
too old (wrong system time or broken proxy): stops after 10 stale reports
were fetched in a row. This should simply stop further fetching, but due
to a bug in the threading system(?) it does currently lead to abortion,
just like any other exception in the fetcher.
