Erik Hofman wrote:
Andy Ross wrote:
Can anyone confirm the same behavior from the 0.9.4 binaries? (I
think it branched sometime right around there.) Is there any
platform dependence to this? I have to admit it's been a long time
since I've have a single fgfs running for that long
I found something that might be a candidate for the overflow. Around
this timeframe, some sprintf(%f) code got added to the atis handler.
The problem is, printf() can generate almost unbounded output for very
large values* and the buffer is only 10 bytes long.
* Try this: int main() {
Ilja Moderau wrote:
- engine sound in cockpit does not differ from outside engine sound
- no cockpit light at night visible
These two are relatively easy. The outside sound handling will
probably require some code, but nothing difficult.
- no jetstream visible
I assume this means contrails?
Gene Buckle wrote:
Andy Ross wrote:
[...] otherwise forgettable Strike Fighters game [...]
I don't know why you'd call it forgettable. There's a huge
following that's been making new aircraft and other things for
it.
It's all eye candy, no meat. Pretty aircraft, beutiful cockpits,
nice
Durk Talsma wrote:
I assumed that your latest yasim fuel code had a lot to do with
this, which would explain why the cvs 747 is performing so much
better (i.e. longer)
Heh, that's because I cleverly introduced a units bug (kgs/lbs) in the
process. :)
It's fixed now, so the 747 should be a
Durk Talsma wrote:
I experienced (some of) these pauses as well when I built FlightGear
without threading support (See my bug reports on fgfs-devel last week,
the smoother performance refers to the absence of the pauses
:-)). After enabling threading again, the pauses went away. So my
guess
Roy Vegard Ovesen wrote:
Is there any way to play sounds from a Nasal script?
Sort of. The current sound model is property-driven. You can create
a new sound event (see the *-sound.xml files under Aircraft for
examples) and drive it from a given set of properties. You can then
set those
Curtis L. Olson wrote:
Andy, one thing that would be useful would be a
globals-get_commands()-addCommand() type function that would load
and play an arbitrary sound file. I don't know if there is a nasal
interface to these commands but if not, that would be a useful thing.
These commands can
Roy Vegard Ovesen wrote:
Very simple. I just want to make a beeping sound or a number of
beeps to use when the autopilot is disengaged (or any other audible
annunciators).
If it is aircraft-specific, then the mechanism of putting it into the
-sound.xml file is probably exactly what you want.
Roy Vegard Ovesen wrote:
I don't think it's possible to put sound configurations into the
instrument configuration XML files, or is it?
No, it has to live under /sim/sound/fx in the global property tree.
We can make a set of global sounds in preferences.xml (or something
included from there)
Vivian Meazza wrote:
wastegate-mp=18.32
[...]
mp-osi = 26.050 - does the wastegate work? - is this psi?
The units are absolute pressure in inches of mercury (I honestly don't
know what the -osi suffix means). The wastegate should indeed work.
However, it is an overpressure release valve. It
Vivian Meazza wrote:
YASim crashes, or perhaps, fails to converge, just by
attempting to run with takeoff-power=1100
takeoff-rpm=1360
Crashing and solution failure ought to be easily
distinguished. :) Maybe the recent logging changes have hidden
the failure message, I'll take a look.
Try
Vivian Meazza wrote:
With these values
eng-power=1140 eng-rpm=2850
cruise-power=2850 cruise-rpm=1359
takeoff-power=1100 takeoff-rpm=1359
YASim appears go into a loop and provides no output.
These settings don't make much sense in combination.
The eng setting is a maximum power
Vivian Meazza wrote:
The takeoff values. Are these the power absorbed by the propeller
at propeller rpm, or the engine output at engine rpm, super- or
un-supercharged?
Un-supercharged. And the equations are solved such that both power
values are the same. Basically, don't sweat this one; it
Jon S. Berndt wrote:
undefined reference to `___gxx_personality_v0'
undefined reference to `__Unwind_Resume'
...
Those are internal g++ things. It looks like you upgraded your
compiler without doing a full rebuild? Versions of g++ are not
binary-compatible between versions*.
Andy
* Well,
I wrote (incorrectly):
The eng setting is a maximum power (at standard sea level) for the
engine without supercharging.
Never mind the last part. The code *does* correctly handle the boost
setting, and assumes that it is at maximum (in most cases, the
wastegate setting) at the specified power.
Giles Robertson wrote:
Not that I've noticed. It would be useful for mingw32. I've tried
building on that, and it compiles fine, but the linker fails because
the input is too long ;).
The linker fails with long file lists? That sounds odd -- this is the
same linker used in Linux, and it's
Lee Elliott wrote:
While I remember, if a YASim a/c only has one tank, the second tank -
tank[1] - seems to be set with a 'nan' level. Doesn't stop the a/c
engine from starting or running but it screws up the tot fuel figure.
Setting the level for tank[1] to zero via the property browser
Vivia Meazza wrote:
As does this (2):
cruise-speed=308 cruise-rpm=2850
This does not (3):
cruise-speed=308 cruise-rpm=1360
Again, these are *wildly* different propoellers you are
specifying. The second one is going to end up with four (!)
times the force
[Starting a new thread. The reply nesting level in my mozilla window
was getting freaky.]
Vivian Meazza wrote:
The engine I'm trying to specify developed 1140 HP at engine
revolutions of 2850 rpm at a boost pressure of 9 psi. It was fitted
with 1:0.477 reduction gearing, which I think means
Vivian Meazza wrote:
Here are some calculations on propeller rpm.
[...]
We can see that 2850 is unlikely to be the rpm of a 10.75 diameter
propeller
Yeah, you're right. This is a real bug. I was playing with it this
morning, and we're hitting an edge case in the propeller solver.
The
Luca Masera wrote:
about YASim: in which units is measured the oil pressure?
In JSBSim the value is holded by oil-pressure-psi and it's
measured in psi; in YASim is holded by epr but the units
are missing.
Er, that's an Engine Pressure Ratio , which is a thrust metric used in
early jets in
David Megginson wrote:
How about allowing the config to contain a couple of sample values
and then interpolating (taking into account outside temperature,
engine temperature, and power setting)?
Sure. That was the idea with the Nasal script, actually. Set it to
poll every second or so and
Curtis L. Olson wrote:
3. The maximum pitch factor that OpenAL allows is 2.0 ... we blow
by that with some of our sound configs ... that's another
thing that will need to be tweaked and looked at.
We can do the down-sampling manually and choose the right one at
runtime; basically
Hermann Schiffer wrote:
The Merlin is a rotary engine, isn't it?
A rotary engine ? As in http://travel.howstuffworks.com/rotary-engine.htm ?
He meant radial, of course, which was true of most WWII era aircraft
engines other than the Merlin.
And if you really want to nit, what you describe is
Durk Talsma wrote:
I've seen this as well, but as far as I can tell, this is due to the
wind blowing against the tail. I've seen this more stronger with heavy
winds, and the yawing of the aircraft in heavy winds appears to change
with changing rudder position, as I expected.
It's a misfeature
Lee Elliott wrote:
will this require an OpenAL (dev) package to be installed, or will
everything needed be included in the FG source?
It will require OpenAL to be installed separately. I just did it
under linux, and it's a relatively benign ./autogen.sh ./configure
make make install kind of
Ampere K. Hardraade wrote:
Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis
runs sideway.
What convention would you have chosen? :)
Coordinate systems are like cuisines. There's no accounting for
taste, and you can't fix things by mixing them together.
Andy
Innis Cunningham wrote:
I am just wondering is there a very good reason that we use zero to
number things in FG. Engines tanks and the like. Because in the real
world of aviation nothing is numbered zero as far as I know.
Why does it matter you may ask. Well it seems a bit strange that a
Mathias Fröhlich wrote:
May be this 'do not use a leading slach' should also show up in that
model animation HOWTO?
Or even generate a runtime warning during parsing. This is a really
easy typo to make.
Andy
___
Flightgear-devel mailing list
I just commited an implementation of GUI layout management, ported
over from my game project last year*. What this means is that you no
longer need to position your widgets manually in dialogs, and can
instead lay them out in tables and boxes like the pros do. :) I've
redone a few of the dialogs
Curtis L. Olson wrote:
I can't seem to set autothrottle speed with the new autopilot
dialog. It keeps reverting 1.0 (might there be anyway to
trim the trailing zeros?)
Oh, whoops. Sorry, I meant to fix this before I checked it in but
forgot. Both the pitch and speed input fields are
I wrote:
Curtis L. Olson wrote:
I can't seem to set autothrottle speed with the new autopilot
dialog. It keeps reverting 1.0 (might there be anyway to
trim the trailing zeros?)
A better solution would be to either write some Nasal to keep the
values synchronized or else think of
Lee Elliott wrote:
Was the stencil shadow stuff for generating object shadows? How far
off usable was it, and did it only work with your terrain engine?
It was decidedly demo quality. But it was part of the model code,
not the terrain engine. Doing shadows on terrain is sort of a 2D
problem,
Giles Robertson wrote:
Just got an error on the following compile:
In file included from C:/msys/1.0/fg/include/plib/pu.h:2140,
from layout-props.cxx:1:
C:/msys/1.0/fg/include/plib/puGLUT.h:36:22: GL/glut.h: No such file or
directory
My fault; I Forgot to test the build on a
Ampere K. Hardraade wrote:
hmm... if FlightGear is to be as realistic as possible, it will be a
good idea to simulate everything down to the very last detail.
Perhaps a translator of some sort can be written?
I can't quite tell if this is a joke or not. If it is, then accept my
apologies.
Bruce Finney wrote:
Andy Ross wrote:
Real Programmers count from zero. Always have, always will.
NOTE: FORTRAN programmers count from 1, always have, always will!!!
So we agree. :)
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http
Jim Wilson wrote:
Erik Hofman checked in:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows. Possible values are: Windows, UNIX
or All. Not specifying the tag equals to 'All'.
Roy Vegard Ovesen wrote:
I get this error when compiling ATCVoice.cxx
It looks like you did a CVS update in FlightGear without grabbing
the required changes from SimGear. Curt changed the API
yesterday.
Andy
___
Flightgear-devel mailing list
[EMAIL
David Luff wrote:
I also got that output from autogen.sh, also on Linux - it appears
to be harmless. Make went fine on Cygwin. No audio output from the
test programs on Cygwin though :-(
It's important to point out that the linux/src/arch/windows
directory in the OpenAL source distribution
Erik Hofman wrote:
After endless times of no discussion and no solutions I hacked
something together that works for every situation. Not acceptable
won't do in this case unless I see something show up that is elegant
and that works in every situation.
Agreed. We need to get something
Here is a page where someone claims to have windows OpenAL building
under MinGW (strictly under a linux cross compiler, which is basically
the same thing). This will/should produce a GNU .a file which you can
use with cygwin.
http://omapi.sourceforge.net/extra/
I'll boot to windows and see
Melchior FRANZ wrote:
Whereby unix would be an alias for n and the line could also be
written as
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't
Jim Wilson wrote:
Not knowing any better, that would be my guess. Is there a bit being
toggled by the _nix drivers? Or is this a completely unpredicatable
effect of the way windows drivers work? If not it seems like this
would be a multiplatform bug in plib.
I think both platforms are
Marco Gugel wrote:
I would like to have an explanation regarding the yasim xml config file.
In particular I want to know more about the coordinate system used on this
file.
There is a README.yasim in the base package, in the Aircraft-yasim
directory.
The YASim coordinate system is X forward,
Frederic Bouvier wrote:
axis 2 and 3 need to be exchanged
Linux 2 == Windows 3 == rudder
Linux 3 == Windows 2 == throttle
axis 4 and 5 are hat on Linux and becomes 6 and 7 on Windows.
Linux 4 == Windows 6 == left/right
Linux 5 == Windows 7 == up/down
This isn't universally
Melchior FRANZ wrote:
Here's my take on the discussed problem: Add an alternative
attribute n_win to all axis definitions that should be different
in Unix and Windows.
Well, once you overcome the initial revulsion to the fact that the
core, low level property array indexing API is being hacked
Frederic Bouvier wrote:
No, we want to define a key differently according to the language,
but it is another problem. Do you want to add n_french, n_spanish
also ?
You don't map keys according to language. The '$' key (keysym, in
X11 lingo) should always create a dollar sign. Non-US
Jim Wilson wrote:
Is this still true? I'm running KDE and can't remember the last
time artsd got in the way. To be honest though, I don't recall what
changed. Maybe I just turned off most of the stupid sounds in the
kde apps.
My impression was that recent versions of arts and esd released
Norman Vine wrote:
Unfortunately I do not have the time to support the libraries I port
so I do not submit them for inclusion with Cygwin but the official
method of doing this is here http://cygwin.com/setup.html
I suspect the OpenAL people should be the first ones to contact. I
doubt the
I actually got interested in all this windows stuff yesterday (no, I
can't explain why), and played around with getting it built. Here's
the proof:
http://plausible.org/andy/fgfs-mingw.zip [2.3 MB]
It's a MinGW* build, using SDL and OpenAL. It works, with sound and
video mode switching.
Marco Gugel wrote:
My idea is to develop a truck simulation inside FlightGear and I
have thought to start from Yasim because it uses the rigidbody
dynamics;
Right. That's the RigidBody/Integrator/BodyEnvironment
implementation. You set masses on the body, calculate forces inside
the
Curtis L. Olson wrote:
Anyone want to take a crack at a new FDM model for the Beech 99
as well? You could probably start with the data for the UIUC
model and go from there.
The Beech 99 is a turboprop, which means that YASim is going to
need new code to support it. I'd be happy to write it
Lee Elliott wrote:
It looks like the fuel was being taken from each tank at the same rate
instead of proportionally, depending upon their capacity, with the
result that the external wing tanks were emptied while the other tanks
still held plenty of fuel, and this caused the engine shutdown.
Lee Elliott wrote:
and the scripts then need to be explicitly invoked.
Presumably, omitting the '![CDATA[' and ']]' bits will then result in the
scripts being executed at start-up.
No, the CDATA stuff is just escaping to prevent the XML parser from
being confused by literal , or characters
OK, I think I've got the kinks worked out of the MinGW work, and
have written up a little README (attached) describing how the
process works. Thanks to Norman and Frederic for the pointer to
the pthread library.
The required changes are in CVS now, and the process has been
tested at least on my
Roy Vegard Ovesen wrote:
I tried this inside an instrument config file, but it didn't work.
It doesn't. The nasal code is read only from under the /nasal/*
subtree of the global properties. Instruments live farther down.
Would it be possible to implement the ability to include nasal
code in
David Megginson wrote:
Lots of GA planes have an option turbocharged (or turbonormalized --
I'm not technie enough to remember the distinction)
I think it's certification. A turbonormalized engine has a wastegate
setting of normal atmospheric pressure. It never develops more power
than the
I wrote:
Lee Elliott wrote:
I could do a script that monitors the tank levels and de-selects
them when they're empty but I don't know how to best invoke it.
Actually, it wouldn't be hard to make this the default. We could set
a kill engines if empty flag on the tank for aircraft where we
Gunnstein Lye wrote:
Thanks for the info. Do you really have to build separate binaries
of gcc for each target? I thought I could use the same binary for
linux (native) and windows (crosscompiling).
Not to my knowledge. The code generation is more or less identical,
but some of the symbol
Norman Vine wrote:
Andy Ross wrote:
You *can* do this with cygwin [...] The compiler supports a
-mno-cygwin flag
Unfortunately it turns out that cygwin doesn't install these tools
under the conventional platform-program names (e.g. mingw32-gcc)
To invoke the the MingW version
Marco Gugel wrote:
as I told to Andy Ross I would like to implement a truck driving
simulation in FlightGear but my doubt regards the collision detection,
which is not implemented! It's only a week that I study FlightGear
code and I have now no idea if the collision detection is reasonably
Erik Hofman wrote:
Why do you think that collision detection is not implemented? You
can crash to the ground and to the buildings (maybe even other
aircraft?), so there must be some logic behind this.
Ground handling right now only uses a flat, horizontal ground plane at
the MSL altitude of
Melchior FRANZ wrote:
Contact points are per model, but the behavior is AFAIK the same for
all models: you can fly through walls, but not through roofs
(neither up nor down). I've no idea if this was intended.
It was. This is the same rule that allows you to fly under bridges;
before that
Jim Wilson wrote:
Maybe I'm misunderstanding why you are doing this. Lower pitch
angle, fast spinning prop. That doesn't makes sense?
Not pitch angle: A lower value of _j0 indicates a low advance ratio,
which increases windmilling speed. This was just a sign bug to the
previous checkin,
Jim Wilson wrote:
Is any of this addressing the low rpm propeller issue discussed last
week? (In other words, should I bother trying to correctly adjust
the p51d prop config yet?)
In theory, yes. I haven't had a whole lot of time to test it yet, but
the slow/windmilling propeller regime
Martin Spott wrote:
Giles Robertson wrote:
This is a multi-part message in MIME format.
--_=_NextPart_001_01C42FC5.F549B62D
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: base64
Do you have a readable translation available ?
Your mail reader can't
Erik Hofman wrote:
There might be one step in between here, which I have been thinking of
a bit. It would be easy to implement a bounding cylinder (2d collision
detection) and only if there is a hit go to the bounding sphere. For
me it looks like that approach would be much less costly as
Martin Spott wrote:
mail2news, inn, tin ;-))
Aside from that, I find it very unfamiliar to post _any_ sort of
human-_un_readable messages to a mailing list. Isn't it ?
It was a perfectly readable text document, it was just flagged with an
encoding of UTF-8, which while more general than
Jim Wilson wrote:
Andy Ross wrote:
Also, the property picker is now non-modal, I presume the modality
wasn't an intentional feature.
It either wasn't an option then or something in pui was
broken...can't remember which. If it works...great! That's
probably been the #1 debugging
ima.sudonim wrote:
Axis 0: Ailerons (-0.5 to +0.4)
Axis 1: Elevator (-0.5 to +0.5)
Axis 2: Throttle (-1 to +0.0)
These three all indicate what appears to be a calibration error.
By convention, all axes have always reported between -1 and 1.
Q2: Is there documentation on the Nasal
Marco Gugel wrote:
Is there someone who can tell me about local coordinates and
global coordinates. What is the difference?
Local coordinates are in the aircraft frame (note that this isn't
the same convention that other FDMs use for their airframe
coordinates). Global coordinates are in the
I started chasing down a font rendering issue in FlightGear on Sunday.
The original issue was a metrics bug in the afm2txf.pl font generator,
a script I wrote for plib a while back. But fixing that didn't quite
solve all the problems, so I spent some time hunting around in the PUI
rendering code
Giles Robertson wrote:
From main.cxx:
if ( idle_state == 1000 ) {
// We've finished all our initialization steps, from now on we
// run the main loop.
fgRegisterIdleHandler(fgMainLoop);
idle_state appears to be declared globally, so you should be able to
test
Josh Babcock wrote:
I just did my first recompile in a few months and everything seemed to
build fine including openal, but at runtime I get this:
fgfs: error while loading shared libraries: libopenal.so.0: cannot
open shared object file: No such file or directory
$ ls -l
Josh Babcock wrote:
cvs update: move away [...]
C data/Scenery/w130n30/w122n37/1Q4.btg.gz
Anybody have any idea what's wrong with my sandbox, or what I can
do to prevent this? It takes forever, basically I am forced to
dl all the demo scenery every time i update.
It looks to me like you
Jim Wilson wrote:
This is aborting on startup. What am I missing?
An abort is an XML parse failure. YASim doesn't catch the exception,
and it percolates up to the top of the call stack and causes an
unhelpful error. I need to fix this.
In this case, though, it's just syntax. Your
Jim Wilson wrote:
Today's cvs: On loading the dc3 flightgear just hangs some time after
the sound init. The p51d hangs (no more display updates) when you
switch to an external view. I'm doing a poll to see if anyone else is
getting this, before I come back to it later this weekend.
Both of
Josh Babcock wrote:
I don't get this with this morning's cvs. dc3 is looking good. The
FOV and exit dialogs are royally screwed up though. Didn't check
any other ones.
Make sure you have truly current code and base package; it sounds like
you're running layout-managed dialogs from the
Melchior FRANZ wrote:
Jim Wilson wrote:
Today's cvs: On loading the dc3 flightgear just hangs some time
after the sound init. The p51d hangs (no more display updates)
when you switch to an external view. I'm doing a poll to see if
anyone else is getting this, before I come back to it
Durk Talsma wrote:
I want to calculate the current position of the aircraft , sssuming
that it travels along a great circle route between these two points
and also assuming that the current time is somewhere between arrival
and departure.
Probably the simplest approximation is to convert both
One of the really cool features of the layout management code is that
it opens up the possibility of automatically generating GUIs according
to dynamic configuration.
This hack turned out just too well: do a rebuild (you'll need a bugfix
in dialog.cxx), update your base package and load up the
Vivian Meazza wrote:
Now the bad news - the new propeller/engine code does not seem to
work for me. These are the input data:
Nothing looks wrong from reading it. Can you post the whole file so I
can test? Thanks.
Andy
___
Flightgear-devel mailing
Bo Shi wrote:
I need to stream information to some custom software
(pitch/yaw/roll) at frequencies on the order of 10 Hz -- what's the
best way to do this? I originally added some code in the main game
loop to dump this but that solution was an ugly hack at best.
There are lots of options.
Jim Wilson wrote:
It'd be great if someone else could look at the P51D fdm. I'm
lost. Flight dynamics is neither my area of expertise or
interest. The only reason I did it in the first place is I had a
3D model that Jon supposedly had a JSBsim config for that never
materialized.
In
Curtis L. Olson wrote:
I don't want to over engineer an ultimate solution right now, I just
want a flag specifying wing icing or not.
You might want to make that a number, specifying a normalized
thickness in millimeters or whatnot. Ice is a progressive effect.
I suppose one could argue
Lee Elliott wrote:
Production Typhoons could exceed 530 mph in dives, with bombs/RPs, and
Tempests could overhaul V1s. I thought the Sea Fury was even faster,
but I don't have a figure off-hand.
The key words being in dives. The solver values are specified in
level flight. And dives can
Vivian Meazza wrote:
Performance: max = 437mph at combat emergency power at 25000ft,
413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph,
climb rate 3475 ft/min. Service ceiling 41,900ft.
How much is combat emergency power? The trick is getting the actual
numbers right, is it possible
Jon S. Berndt wrote:
Please do. It will be interesting to see what kind of relationship
there is between F-15D numbers and P-51D numbers, and how you relate
the two ...
Heh, oops. :)
For folks who didn't get the joke in my typo: the manual I ordered is
a post-war one for the North American
Melchior FRANZ wrote:
hh ... now that makes sense. I couldn't read the word PERCENT. I guess
one needs to be native English speaker to be able to decipher that. OK, I'll
do this instrument now -- only the rotor hand, though, because there's no
turbine RPM in YASim (?). Maybe I'll make the
David Megginson wrote:
The worst b*ds in this whole mess are [...] the enterprise
anti-virus software vendors, who sell systems that automatically
send useless virus warnings every time a message like this comes.
Either
(a) they're complete idiots who couldn't be trusted with the
Roman Grigoriev wrote:
Here is my new VBO code but it's so strange that it doesn't work with
flightgear give me segfault
also notice that it doesn't work with ptherads (I don't know why too)
So I move all vertex,tex,norm,color to constructor from draw method
plib applications work fine but
Josh Babcock wrote:
So maybe airplanes shouldn't be in the interface business. Maybe we
should spend our energy agreeing on property conventions and Nasal
scripts.
Even better would be to take a big audit of all the existing bindings
and re-assign them from scratch. We've accumulated all
David Megginson wrote:
Curtis L. Olson wrote:
So I have made this configurable for those that trust the data more
than I do. Just set /sim/navdb/auto-align-localizers to
true/false in the preferences file to turn this feature on or off in
the code.
I'd be more comfortable fixing the
Lee Elliott wrote:
The problem with using spoilers for roll control in YASim is that
because the spoiler range is clamped to 0 to +1, when you 'split'
the input for differential control it only works on one side of
the a/c - through the 0 to +1 range - to get it to work on the
other side it
Frederic Bouvier wrote:
I am surprised --prop:/sim/rendering/bump-mapping=false don't work for
you. I am also able to turn it on and off with the property browser
during flight.
Someone should put this into the rendering options dialog before we
forget. It's
really easy, try it. :)
Andy
Richard Bytheway wrote:
I have noticed that if I open and close the autopilot setting dialog repeatedly, the grey panel behind the widgets gets a little smaller each time, eventually disappearing.
There was a similar bug with the layout code that got fixed a few weeks
back. Are you
on current
Roy Vegard Ovesen wrote:
I've also thought about using a textured needle instead of an object
colored one. The textured one might look a lot better with variable
alpha creating an anti-alias effect, but I'm concerned about
performance.
Alpha blending is almost free on modern hardware, so I
Chris Metzler wrote:
Sometimes I run into issues with FlightGear -- fgfs, data, scenery,
whatever -- that I'm reluctant to report because I'm concerned that
the developers already know about them;
Indeed, that's a good idea. We've been known to kill and eat
reporters of known bugs. :)
As for
David Culp wrote:
There have been reports of rudder kick when climbing through
atmosphere layers, which might be the same problem you're
seeing. I don't think it was ever resolved though.
I didn't think it was a bug. That's just wind shear, isn't it?
Andy
801 - 900 of 1282 matches
Mail list logo
