Using a Saitek stick, I've noticed a peculiar bug in the brakes which I
still haven't pinned down. The nasal function interpolate() works on left
wheel only, not the right wheel, making the plane twist when brakes are
applied (or released). One can see it by watching the internal properties
On Wed, 9 Nov 2005, Andy Ross wrote:
Which stick, and which aircraft?
Saitek Cyborg Evo (but the code is copied from Saitek to other sticks)
And it's the same for all aircrafts I've tested, including uiuc-models (so
it's probably not the FDM engine. Not that I have full understanding of
how
On Wed, 9 Nov 2005, Andy Ross wrote:
Theory: the right brake property is flagged as a boolean in the
property tree, and is clamping all values to 0 or 1. This can be
complicated to debug -- you need to figure out where it's created.
Sounds plausible. Some sort of type mismatch. But I figure
On Wed, 9 Nov 2005, Andy Ross wrote:
Theory: the right brake property is flagged as a boolean in the
property tree, and is clamping all values to 0 or 1.
Confirmed.
I tried a setprop to 0.3 for right wheel in the js config file, and got a
1.0 in the browse internal props dialog. Somewhere
On Wed, 9 Nov 2005, Melchior FRANZ wrote:
Is this the development version (cvs/head)?
Yes, but it has been the same for shipped versions too.
How can I tell which version of fgfs I'm running? fgfs --version didn't
work on the version I have installed in /usr/local/... anyway. Think it's
the
I have pinned down the exact moment in gdb when brake-right is set to 1.0
(without a cause, so to speak), but I feel I don't have enough knowledge
about how FG is designed to come further.
gdb backtrace below. This is after initialisation is done, FG is up and
running and the fire button (apply
On Wed, 9 Nov 2005, Andy Ross wrote:
Something odd is going on -- apparently some other stick's binding for
the right brake only is being picked up by your configuration. Have
you modified the name properties of any of you joysticks files? Can
you verify that your base package is unmodified?
On Thu, 10 Nov 2005, George Patterson wrote:
To find out which copy is being loaded when you type fgfs, open up a
terminal and type which fgfs and you should get something like
/usr/local/bin/fgfs.
I meant version as in version number.
Perhaps a command line parameter could be added to
The inner gear (right and left) were hanging down and the main gear well was
sticking out from the fuselage with gear up. (I decided to hide the well
when the gear is up, rather than messing with the .ac-file.) I also
somewhat sorted out the numbering of the gears, in case someone in the
future
Well I'm not seeing any cloud shadows either.
Hardware/libGL thing? (Or are shadows drawn underground for some of us?)
I have: Nvidia GeForce FX 5200 with 256M, X-server at 24 bpp, fgfs with --bpp=24
with or without --enable-fullscreen. libGL is nvidias No 7676 driver
(latest)
I've been spying
On Sun, 20 Nov 2005, Harald JOHNSEN wrote:
We don't have cloud shadows in FG.
Oh, I misunderstood Rodrigues then. ;)
The other shadows look great. ...well, the shadow from the propeller should
be about as transparent as the propeller disc, but that's probably no news.
BTW: cloud shadows
This must be one of the lesser flewn models in FG. Two years has passed
since the last patch, and noone has noticed that Erik forgot (tsk tsk) that
there are /two/ rotors on the Chinook.
Make also the other rotor (collective) work the same way as the first
rotor. (and same as bo105, i.e.
On Tue, 22 Nov 2005, Josh Babcock wrote:
Ampere K. Hardraade wrote:
Having some stereoscopic photographs of an aircraft may help modellers make
estimations better. (Okay, this is just a theory, but this would be a good
opportunity to vertify my theory with an experiment.) :P
Good theory,
On Tue, 22 Nov 2005, Ampere K. Hardraade wrote:
On November 22, 2005 10:51 am, Joacim Persson wrote:
How about simply taking photos from various angles,
...
I don't see how that's going to work unless one has a fisheye lense and is
able to take pictures with exactly 180 degrees view
fgfs --airport=EGLL --aircraft=ufo
...puts you in a mysterious place with thick fog, where ground level is
about 6 million m below sea level. This must be the airport of Hell.
While trying to investigate this, I found the following peculiar logic in
FDM/groundcache.cxx, line 364:
if (0
On Sat, 26 Nov 2005, Mathias Fröhlich wrote:
Seriously, I can reproduce, I am currently investigating ...
Hmm, was too fast, I had some changes because of your mail in this area. These
changes made me able to 'reproduce'.
That is:
I have no problem with this.
I have no idea if that line had
On Sat, 26 Nov 2005, Melchior FRANZ wrote:
boundary. I'm just not aware of any recent changes that could have
this effect. :-|
Probably not a /new/ bug, rather an old one which hasn't propagated before.
I've had problems with EGLL before. Night approach and fps drops to 7 or
something. (not
On Sun, 27 Nov 2005, Mathias Fröhlich wrote:
Both work for me.
What scenery do you use?
Is this the 0.9.9 I am currently downloading? :)
... I still use the 0.9.8 normally.
Don't know about Melchior, but I'm using terrasync -- whichever version it's
feeding me with, I simply don't know. Ask
(tested with c172p, ufo, and other modelss with same result. Airplane
standing still on the ground.)
Compare the properties:
/instrumentation/heading-indicator/offset-deg
and
/environment/magnetic-variation-deg[0]
The former is drifting (decreasing).
Is this some reality-feature about
OK forget it. Did my homework now. ;)
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
On Sun, 27 Nov 2005, Mathias Fröhlich wrote:
What compiler do you use?
gcc 3.3.6
That extendent precision on intels cpu's covers and uncovers some problems
unpredictable - depending on some compile flags and compiler
implementations ...
AMD here, if that matters.
Do you use some
(I don't give a hoo about patch politics and version number
supersticion.)
I'm curious about the choice of language/linkage for the implementation:
Why have a specific vendor model hard-coded in c++? Seems more like task
for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++)
On Thu, 1 Dec 2005, David Luff wrote:
I have no experience of plugin architectures, and don't feel competent to
attempt it at the moment.
First of all: there's obviously no panic. (If there were fifty-seven
hard-linked GPS models, AP's etc it would be a problem, ;)
I don't know in detail how
On Wed, 30 Nov 2005, Adam Dershowitz wrote:
However if people each develop a plugin that only works on their
personal development machine it will complicate things.
Hm. Yes. But the same fault (writing non-portable code) could be done under
ordinary static linking too. It would be noticed
I just struck me that it's already possible to get a better look at the
instruments, both 2D and 3D, in a very simple way: I think all OS's and
windowmanagers have a magnifier tool. It can't magnify beyond the screen
resolution of course (640x480 would still be 640x480), but it solves the
problem
On Thu, 1 Dec 2005, Andy Ross wrote:
AN-225/AN-225-yasim.xml
The patched Yasim spitted it out again.
No twist set in that file, only incidence (4° positive).___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
I've discovered a difference between how fgfs calls the yasim solver, and
how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which
doesn't pass yasim(-test) but which fgfs accepts... ?:-P
So what is the difference? Number of iterations?
On Sat, 3 Dec 2005, Erik Hofman wrote:
Jim Wilson wrote:
If this is just flipping the sign why not just grep and fix all the
aircraft in CVS that specify incidence? I guess I don't understand the
ritual. Maybe there was more to this change that I'm just not aware of?
Most modelers (if not
On Sat, 3 Dec 2005, Andy Ross wrote:
That sounds like a bug. They are intended to produce identical
behavior. Is it possible you have a yasim binary build from a
different version of the code than your fgfs?
My first thought too.
The file I used was the AN-225-yasim.xml with the only
I couldn't help but notice that the JSB version of the 747 has a lift-ratio
which would make a sailplane pilot envious. One can glide about with full
flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;)
When running it with --debug-level=debug I get some numbers on JSB's idea
On Sun, 4 Dec 2005, Dave Culp wrote:
As far as the drag values go, the CD0 looks good, and matches aeromatic well.
...
The flap drag looks good.
Then for some reason all those numbers are ignored. Either in jsbsim
internally or in the fg--jsbsim interface.
The plane glides virtually
Nothing to do with Stuart's work on the c310, but a tip on the fdm (jsbsim
version):
Move the CG forward a bit, at least a 10--15. (the correct CG location
should be taken from the type certificate, which I haven't been able to
find on a quick google) The plane flies a lot better then. (better
On Sun, 18 Dec 2005, Jon S. Berndt wrote:
Would it be possible to change the visual appearance of wing flex during
flight?
Look at the rotor animations for the bo105. (when rotor is slowing
down/speeding up)
___
Flightgear-devel mailing list
On Sun, 18 Dec 2005, Jon S. Berndt wrote:
The TCDS suggests the CG should be in the range, 37-42 inches (assuming our
datum is the same).
I think the datum is the same. (p33 in the type cert.):
Datum Forward face of fuselage bulkhead forward of rudder pedals.
And from 310.xml:
The
The magnetic compass in the defailt 2d panel has been broken for some time.
(worked in 0.9.8) This is the built-in magnetic compass defined in
Cockpit/panel.*xx and Cockpit/built_in/FGMagRibbon.cxx
I've got it back in operation, allthough I don't quite understand why.
Putting back the
35 matches
Mail list logo
