Jon Stockill wrote:
> I've just discovered that when using the null fdm I'm not getting
> updates to /position/ground-elev-m any more. So I can't actually
> retrieve the terrain elevation. Is there somewhere else in the property
> tree I could read this from?
The attached patch fixes this problem.
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.
This patch fixes configure.ac so that when an alternate prefix location for simgear is specified, configure tests for the header file jpegfactory.hxx in that specific location only.
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.