are sharp, as intended. These were are never seen in practice; I
found the problem while looking at 360 degree lift curve graphs
looking for discontinuities.
"jitter" when the aircraft was stopped. This is a fundamental
characteristic of the gear model, and can't be fixed without major
surgery (and not a small amount of blinding insight). But we can at
least clamp it so the value can't change unless the wheel is moving
with a nontrivial velocity (5cm/sec in this case).
Attached is a patch to add oil temperature to the YASim piston engine
model. This brings to life one of the pa28-161's otherwise 'dead'
guages. It's a pretty simple 'model' based on temperatures and warmup
times I've observed in the labs on auto engines and run through my
dodgy-memory filter. It does the job of populating the guage with
something plausible though.
it for the B-29). The gear model itself has supported this always,
but there was no interface from the XML file. Should be backwards
compatible. I don't think I broke anything...
I believe I have found the agl hud problems as well as the 'hole' in the
carrier's deck. I spent half the day to reproduce that problem, it did not
occure when you start on the carrier not does it occure with JSBSim and my
really often used testaircraft. So I really need to improove my helicopter
flying qualities.
I was under the impression that *all* FDM's call
FGInterface::updateGeo*Position(..)
so set the new position in the FDM interface. Therefore I had added at the
some code that updates the scenery elevation below the aircraft to *those*
functions.
Ok, not all FDM's do so :/
The attached patch factors out a function computing the scenery altitude at
the current FDM's position. This function is also used in those FDM's which
need to update this value themselves.
Also this patch restores the nearplane setting and uses the current views
altitude instead of the current aircrafts. I think that this should further
be changed to the eypoint's agl in the future.
The agl is again ok in YASim's hud.
I have traced that reset on carrier problem down to several problems. One of
them is the fact that on reset the carrier is updated while the aircraft is
not. That made the aircraft drop down an elevator sometimes. Depending on the
passed realtime while loading some parts of the scenery.
on RPM via a model developed by Vivian Meazza. Add a "boost" output
to the property tree. Fix a bug where MP would be reported "before"
the wastegate clamping.
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 ...
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. :)
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.
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:
Stub in hooks for Propeller feathering controls and the turbo prop "condition"
lever.
I added a line in FGFDM.cpp to force control properties to exist if they
don't already. This way you can specify anything you want and find them
in the property browser, otherwise no one else may create them and you are
stuck.
In PropEngine::solve() the code original sets _running = true at the
beginning and then sets running = false at the end. I changed this to
save the current value at the start, set to true, solve(), and then
restore the original value at the end. That way if we start off with
_running = true, we don't have to hack up the calc() routine which wasn't
using the value anyway.
Finally I added some very initial support to shut down a turbine engine
(_running = false) when the condition lever goes to zero.
the 30 seconds that Maik had originally intended, according to the comment.
This is important for the pending sound and rotor disc changes (and of course
for realism).
"slow/windmilling propeller" regime. I'm happy with the foundations
of the solution, but this hasn't been complete tested yet. The
solution behavior seems fine on the planes I tried.
PistonEngine class has grown an "Engine" superclass. Some other stuff
moved around too, and I cleaned up some property naming while I was in
there. This hasn't been tested very thorougly, hopefully I didn't
break anything.
work on the pa28 idle and without creating ridiculous side effects
(like being able to fly the aircraft with the starter motor, heh).
This one looks pretty good for now, pending work on the propeller to
get its low speed drag in line with reality.
reads the /consumables tree for input to determine weights, but
places output only in /engines/engine[n]/fuel-consumed-lbs where
it gets picked up by the Nasal code.
