On 02/07/2007 02:14 PM, Andy Ross wrote:
> So if there's a design flaw here, it's at a higher level. Maybe
> what's really needed is a "digit extractor" animation instead.
Good news: The /design/ is not as flawed as it looks.
All evidence indicates that the primary problem with the
step-and-scroll function was not the design; the primary
problem had more to do with the implementation. The code
was practically begging to get bit by roundoff errors.
A patch to fix the code can be found at
http://www.av8n.com/fly/fgfs/animation.patch
It's a patch to animation.cxx (the latest CVS version thereof)
providing a virtually complete rewrite of the apply_mods(...)
function therein. Folks will need to
-- apply the patch;
-- recompile simgear and install the new version.
-- re-link fgfs against the new simgear library.
(The makefile will probably force a major recompile
of flightgear, which really shouldn't be necessary,
and can be prevented if you're clever, but that's
a topic for another day.)
I have done only limited testing, but it appears to successfully
unbreak quite a few heretofore broken instruments.
For example, the radios in the SenecaII-jsbsim were very
broken, but they seem fine now.
There are some tricky bits in the code, but I was careful not
to add any "detestable" comments.
The goal here is to fix all the step/scroll bugs, without any
need to fool with <bias> or anything like that. Similarly
there should be no need for fudge factors that are "almost"
equal to unity to ensure correct formatting of the display.
If this goal is not being met, please let me know.

Hi,
the path-cache of sim/flight-gear is not designed for removing nodes. If
you remove a node and query it by it's name you probably get this
removed node, independent if another node with the same name has been
created meanwhile. This due to the path-cache of each node, which
stores links to nodes by it's name to speed up the access. But if a node
is removed, it is only removed in the path cache of the parent (and in
this step the index is ignored, too).
The enclosed propbug.nas shows this bug. Just copy it to your data/Nasal
folder and start flightgear. It should display
--------------- propbug.nas ----------------
set /foo/bar/a/b to 1
dump getNode("foo").getNode("bar/a/b")
b {DOUBLE} = 1
remove child b from foo/bar/a
dump getNode("foo/bar/a")
a {NONE} = nil
set /foo/bar/a/b to 2
dump getNode("foo/bar/a")
a {NONE} = nil
a/b {DOUBLE} = 2
dump getNode("foo").getNode("bar/a/b")
b {DOUBLE} = 2
--------------- propbug.nas ----------------
on the console, but it displays:
--------------- propbug.nas ----------------
set /foo/bar/a/b to 1
dump getNode("foo").getNode("bar/a/b")
b {DOUBLE} = 1
remove child b from foo/bar/a
dump getNode("foo/bar/a")
a {NONE} = nil
set /foo/bar/a/b to 2
dump getNode("foo/bar/a")
a {NONE} = nil
a/b {DOUBLE} = 2
dump getNode("foo").getNode("bar/a/b")
b {NONE} = nil
--------------- propbug.nas ----------------
The last line is different. The Node /foo/bar/a/b is set to 2, but is
displayed to be nil.
The enclosed patch corrects this. It's the same patch I posted earlier,
but reviewed/overhauled by Melchior (Thanks!).
What it does:
- make every node maintain list of properties that link to it
- add functions to erase node by address from hash bucket/entry in their
path caches, so that all references can be removed
- if a node is removed, it (and all children, grandchildren, ...) calls
all linked properties to remove them from their path-cache
This fixes problems with the aerotow over multiplayer and maybe some
other problems, where nodes are queried by name.
Please commit.
Maik

On Thu 8 February 2007 23:09, Martin Spott wrote:
> "gh.robin" wrote:
> > On Thu 8 February 2007 11:13, Thomas F?rster wrote:
> > > I hit on a strange problem when using the --flight-plan commandline
> > > option with the default c172. All controls are working except the
> > > ailerons, which makes flying around a bit challenging... ;-)
> >
> > If it is FG cvs with OSG, it is not a surprise to me, i told before on
> > several topics regarding autopilot, that it is not working.
>
> If you would not notoriously combine such "bug reports" with senseless
> allegations then people probably would take your reports more
> seriously,
>
> Martin.
Martin,=20
Nice your answer , what would have more, to take that information seriously=
?
just, remember,
from Lee =3D=3D>
I experienced similar problems a few days ago - some of the AP controllers
seemed to be working from start-up but others didn't. Re-setting the AP
controllers via the debug menu appeared to kick them into life after
start-up. I also had problems with some AP controllers seeming not to
work after I removed other unrelated redundant controllers but didn't have
enough time to look further into it or establish any consistency.
from me =3D=3D>
The CVS FlightGear and Simgear dated "2007-12-27" built, gives an Autopil=
ot=20
working
The CVS FlightGear and Simgear dated "2007-12-27 12:00" built, gives an=20
Autopilot destroyed.
=2E............................................
if we reload the autopilot config with menu/debug
We get the autopilot working heading and altitude<=3D=3D
That information from me was only to help to improve FG cvs with OSG , if y=
ou=20
do want it .........i don't mind i have solved that bug with a specific=20
trick on my side.
Anyhow If you want more, i can give you the size and the color of my shirt.
Regards
=2D-=20
G=E9rard

"gh.robin" wrote:
> On Thu 8 February 2007 11:13, Thomas F?rster wrote:
> > I hit on a strange problem when using the --flight-plan commandline option
> > with the default c172. All controls are working except the ailerons, which
> > makes flying around a bit challenging... ;-)
> If it is FG cvs with OSG, it is not a surprise to me, i told before on several
> topics regarding autopilot, that it is not working.
If you would not notoriously combine such "bug reports" with senseless
allegations then people probably would take your reports more
seriously,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Am Donnerstag 08 Februar 2007 18:35 schrieb gh.robin:
> On Thu 8 February 2007 11:13, Thomas F=F6rster wrote:
> ...
> If it is FG cvs with OSG, it is not a surprise to me, i told before on
> several topics regarding autopilot, that it is not working.
> Nobody but Lee answered to confirm that it is not working.
No, this was with the 0.9.10 release. The c172 starts with waypoint mode=20
enabled if --flight-plan is given, but the autopilot (the one in the plane)=
=20
switched off. Switching off waypoint mode with F6 gives back full controls.=
=20
Looks like an interference of the generalized FG autopilot and the c172 one.
Thomas
=2D-=20
PhD Student, Dept. Animal Physiology, HU Berlin
Tel +49 30 2093 6498, Fax +49 30 2093 6375

On Thu, 08 Feb 2007 12:59:02 -0500, John Denker <sf@...> wrote:
> I routinely observe 135 Kias at 2850 RPM in level flight at 1000 MSL,
> using only 13 gph.
Is it possible that post-OSG all fdm's are snappier ? I've no hard
evidence but I seem to be able to overspeed the c310-ifr much more easily
sine I got an OSG build; no complaints, it's a lot easier to follow the
LLZ lately too.
--
<=>

On 02/08/2007 12:35 PM, gh.robin wrote:
> If it is FG cvs with OSG, it is not a surprise to me, i told before on several
> topics regarding autopilot, that it is not working.
> Nobody but Lee answered to confirm that it is not working.
The default c172p in the current CVS is messed up in ways
that have nothing to do with the autopilot
I routinely observe 135 Kias at 2850 RPM in level flight at 1000 MSL,
using only 13 gph.
I wish I could find a real-life C172 with that kind of performance.

On Thu 8 February 2007 11:13, Thomas F=F6rster wrote:
> Hi,
>
> I hit on a strange problem when using the --flight-plan commandline option
> with the default c172. All controls are working except the ailerons, which
> makes flying around a bit challenging... ;-)
>
> command line: fgfs --airport=3DEDDT --runway=3D26L --flight-plan=3DEDDT-E=
DDC.plan
>
> EDDT-EDDC.plan:
>
> GERGA
> TUVAK
> GORIG
> BESKO
> LUROS
> EBASA
> KOBUS
> GARKI
>
>
> Thomas
If it is FG cvs with OSG, it is not a surprise to me, i told before on seve=
ral=20
topics regarding autopilot, that it is not working.=20
Nobody but Lee answered to confirm that it is not working.
=2D-=20
G=E9rard

To everybody who is interested in ufo alternatives,
the runabout and both shuttles are now out of development, and have undergone
substantial improvements.
http://www.geocities.com/sandreas41/flightgear_aircraft.html
Enjoy!
Stewart
Joacim Persson wrote:
> Ha! You can run but you can't hide from the PS-05/Blue Vixen radar. ;)
Can the emblem or door positions of the bo105 be seen across a network?
Part of me thinks you're joking, but the other part wants to know. :)

Hi Yurik,
Thank you, That was very helpful. I have finished my animations now.
I would like to add, the order in which the <animation>s are placed in the
.xml file is also important. As long as the xml.animations are in the same
order as the ac.objects, back to front, then everything looks good.
Stewart
Yurik V. Nikiforoff wrote:
> Order of transparent object in ac file must be "from rear to front". For
> example, if object A stay behind object B, then object A must be placed in ac
> file before object B.

hi,
I was just happy to test the fresh airport and the rebuilt tile I've
made with taxidraw and terragear.
But... at the first passing by above the airport I hit an invisible
hill/thing! Hopefully, it's safer in real life :)
Well, first, I didn't noticed it with the ufo but now I can see the agl
prop falling to negative values in a particular place of the airport
with the ufo too.
I Really don't know what's going on here, it's just like a step and
narrow hill, or a magical medium sized skyscraper :)
Here a couple of screen shoots:
http://croo.murgl.org/fgfs/scenery/knid-invisible-hill.jpghttp://croo.murgl.org/fgfs/scenery/knid-thing.jpg
On the first picture the A-10 is crashed at '2 ft agl', above the round
aprom (otogon shape made of several pieces of runway), in fact the agl
at this location should be 250 ft.
On the second picture, I tried to point at the thing location with the
ufo's mouse click.
Did any one 'see' such a thing happen before?
I tried to 'see' the exact surface of the thing with the ufo but the
props are refreshing very slow and the ufo moves rather fast for that,
even with [] dimmers. Does anyone have and idea on how to investigate?
Further more, it looks like being a weird 3D shape (spooky shape, potato
shape...) in space and it's more easy to get into it while being 60/120
ft above the 'expected' ground than at 15 ft. I also suspect that the
agl is rather disturbed by the thing than reflecting the actual distance
above/under it. I didn't try to catch it at more than 250 ft 'expected agl'.
I can prepare a set of file of the airport and the tile, if any one
wants to take a look at this, feel free to ask :)
Note: I don't know if it's related to this invisible thing, but once I
did get a bunch of warnings like:
Warning:: Picked up error in TriangleIntersect
(-0.016116 0.006676 0.019626, -0.019361 0.0075 0.007711,
-0.02095 6 0 0.007711)
(nan, nan, nan)
Warning:: Picked up error in TriangleIntersect
(-0.016116 0.006676 0.019626, -0.020956 0 0.007711,
-0.017444 0 0.01 9626)
(nan, nan, nan)
Warning:: Picked up error in TriangleIntersect
(-0.012335 0.012335 0.019626, -0.014818 0.013858 0.007711,
-0.01936 1 0.0075 0.007711)
(nan, nan, nan)
...pages and pages of this, but only once while trying to dive slowly
into it with the ufo. At this time, the fps felt from 110 to 1 or 2.
Other screen shoots of the airport and the buildings, just for fun:
http://croo.murgl.org/fgfs/scenery/knid-h1.jpghttp://croo.murgl.org/fgfs/scenery/knid-h2-h3.jpghttp://croo.murgl.org/fgfs/scenery/knid-h3.jpghttp://croo.murgl.org/fgfs/scenery/knid-overall.jpg
Anyway, I just can speculate on what the thing could be and I would
really appreciate some help or advices.
Thanks,
Alexis