* Erik Hofman -- Thursday 15 June 2006 22:35:
That's why I said I would copy the necessary files (all HUD related
code) to Instrumentation/HUD and rename the class(es) and leave the old
code to rust away.
OK. Done that. For now I've decided to make it a regular subsystem
that's registered by
Melchior FRANZ wrote:
data_scale becomes scale too (both exist currently
for the same thing in different HUD elements,
which hinders abstraction)
It think it would be best to use offset and factor just like most of
the other
* Erik Hofman -- Friday 16 June 2006 09:34:
Melchior FRANZ wrote:
data_scale becomes scale too (both exist currently
for the same thing in different HUD elements,
which hinders abstraction)
It think it would be best to use
* Melchior FRANZ -- Friday 16 June 2006 09:41:
BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what
the assembler parts do, but the fallback implies that it's a quick
rounding function.
Or is it not worth at all to be done in assember nowadays?
m.
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 16 June 2006 09:41:
BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what
the assembler parts do, but the fallback implies that it's a quick
rounding function.
Or is it not worth at all to be done in assember nowadays?
I
Jon S. Berndt wrote:
..another big deal to dig up: Downwash.
There may end up being some things that don't get specifically addressed,
but must be defined by the user with functions and tables. What I'd like
most to do is to provide all the basic building blocks needed so that the
user is
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
(int)rintf() then?
m.
___
Melchior FRANZ wrote:
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
(int)rintf() then?
Hmm, I doubt this will be faster
Curt wrote
Vivian Meazza wrote:
There is one - nearly - as I said orientation/heading-magnetic-deg. But
it's
not derived from an instrument, and therefore has no supply, neither can
it
fail, not does it have any error. Further, use of such a property will
not
stop, AFAIKS, the
Erik Hofman a écrit :
Melchior FRANZ wrote:
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
(int)rintf()
På 16.06.2006 10:19 CEST skrev Vivian Meazza [EMAIL PROTECTED]
snip...
I also have a patch prepared which prevents xmlauto.cxx from generating
spurious instruments, and which uses whichever Heading Indicator that is
present. That's probably a 'fancy waistcoat', and I'm still pondering if
it's
Roy Vegard Ovesen wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:flightgear-
[EMAIL PROTECTED] On Behalf Of
Sent: 16 June 2006 10:26
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Autopilot Bug/Feature
På 16.06.2006 10:19 CEST skrev Vivian
On Fri, 16 Jun 2006 09:54:39 +0200, Erik wrote in message
[EMAIL PROTECTED]:
Jon S. Berndt wrote:
..another big deal to dig up: Downwash.
There may end up being some things that don't get specifically
addressed, but must be defined by the user with functions and
tables. What I'd
Isn't downwash just a matter of a high angel-of-attack?
Erik
When air passes over the wing, an incremental downward redirection is
induced, so the horizontal tail sees a different airflow than the wing.
Jon
___
Flightgear-devel mailing list
Jon S. Berndt wrote:
Isn't downwash just a matter of a high angel-of-attack?
When air passes over the wing, an incremental downward redirection is
induced, so the horizontal tail sees a different airflow than the wing.
Oh, downwash of the aircraft itself. I was thinking because of wind but
I
From talking to others on IRC I understand the cvs version of simgear builds
fine with gcc 4, but with gcc 3.3.6 I get these compile errors added below. Is
there a simple workaround for this?
In file included from mat.cxx:44:
../../../simgear/structure/SGSharedPtr.hxx: In member function `void
Jon S. Berndt wrote:
Isn't downwash just a matter of a high angel-of-attack?
When air passes over the wing, an incremental downward redirection is
induced, so the horizontal tail sees a different airflow than the wing.
Oh, downwash of the aircraft itself. I was thinking because of wind
Jon S. Berndt wrote:
If I understand it correctly it should be possible to simulate the
effects of downwash by creating a function of flap-settings and airspeed
(and possible alpha), no?
Maybe. I haven't thought about that much, yet. Try it. ;-)
I did try something like this, but for
I have created a web page with minimalistic usage instruction about the way the
ac3d Blender exporter plugin works with Blender material definitions. It can be
usefull for newbees who do not like to struggle with all the unnecessary
Blender material attributes.
I guess that will help people
Roberto Inzerillo schrieb:
I have created a web page with minimalistic usage instruction about the way
the ac3d Blender exporter plugin works with Blender material definitions. It
can be usefull for newbees who do not like to struggle with all the
unnecessary Blender material attributes.
Roberto Inzerillo wrote :
I have created a web page with minimalistic usage instruction about the way
the ac3d Blender exporter plugin works with Blender material definitions. It
can be usefull for newbees who do not like to struggle with all the
unnecessary Blender material attributes.
I
Did you get the Sukhoi ?
If you want I can send you a slightly updated model...
rgrds
Enrique
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Frederic Bouvier wrote:
Another tip :
If you can find the file named ac3d_export.cfg ( on windows, in
C:\Program Files\Blender
Foundation\Blender\.blender\scripts\bpydata\config ) you can set
MIRCOL_AS_EMIS to True ( default False ). Then, you can change the 3
components of the emis color
Roberto Inzerillo wrote:
I have created a web page with minimalistic usage instruction about the way
the ac3d Blender exporter plugin works with Blender material definitions. It
can be usefull for newbees who do not like to struggle with all the
unnecessary Blender material attributes.
I
On Friday 16 June 2006 10:18, Erik Hofman wrote:
Melchior FRANZ wrote:
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
Hi,
On Friday 16 June 2006 14:30, Joacim Persson wrote:
From talking to others on IRC I understand the cvs version of simgear
builds
fine with gcc 4, but with gcc 3.3.6 I get these compile errors added below.
Is there a simple workaround for this?
Given the error message, I could imagine
On Sat, 17 Jun 2006, Mathias Fröhlich wrote:
Given the error message, I could imagine a that the attached patch helps.
Can you please tell me if that patch helps?
Compiled without a warning on mat.cxx now.
(Was that all? Couldn't handle that method as inline?)
... I tested with gcc-4.1.1
On Sat, 17 Jun 2006 01:11:27 +0200 (CEST), Joacim wrote in message
[EMAIL PROTECTED]:
On Sat, 17 Jun 2006, Mathias Fr�hlich wrote:
Given the error message, I could imagine a that the attached patch
helps. Can you please tell me if that patch helps?
Compiled without a warning on mat.cxx
Hello all,
Is anyone else seeing a memory leak in current cvs?
After using all my real ram fg starts gobbling through VM at
about 1 mb every 5 seconds or so, even when flying around the
same area.
LeeE
___
Flightgear-devel mailing list
29 matches
Mail list logo
