I wrote:
Mathias Fröhlich
Hi,
Since one day YASim make use of the groundcache.
That means for aircraft models where the 3d-model animates the gear
compression well (like Vivians seahawk for example), the gears exaclty
follow
the slope of the ground.
Also the aircraft
James Turner wrote
While we are are it, do we already have consensus on which keys to use
for these functions - are the keys consistent across different aircraft
and FDM's ?
The keys do seem to be standard, j/k for spoilers and Ctrl-B for
speedbrake, the issue of course is guessing for
Melchior FRANZ wrote:
* Martin Spott -- Thursday 10 February 2005 19:19:
Great, now we have an accurate definition, we should fix the key
bindings :-)
Does everyone agree on having j/k for the spoilers ? Now, what are we
going to take for the speed brakes ? Simply using Ctrl-B is not
Seamus Thomas Carroll
Hi,
If i was able to find the avialable fuel property i could work out a
kmperlitre based on distance travelled and fuel consumed over a period of
time.
Doesnt a plane run out of fuel after a period of time? I tried grepping
for fuel and the word fuel must have
Innis wrote
Hi All
Erik Hofman writes
I dont think there is a total fuel onboard or fuel remaining property.
I asked about this a couple of weeks back and got no reply(I think).
After a quick search in the code I found this property:
/consumables/fuel/tank[0]/level-gal_us
Yep but
I'm having a problem compiling Simgear-cvs under Cygwin. The compiler stops
with the following error:
In file included from soundmgr_openal.hxx:50,
from xmlsound.hxx:40,
from xmlsound.cxx:38:
/usr/local/include/AL/alc.h:39: error: syntax error before `*' token
Norman Vine wrote
Vivian Meazza writes:
I'm having a problem compiling Simgear-cvs under Cygwin. The compiler
stops
with the following error:
In file included from soundmgr_openal.hxx:50,
from xmlsound.hxx:40,
from xmlsound.cxx:38:
/usr/local
Erik Hofman wrote:
Vivian Meazza wrote:
I'm having a problem compiling Simgear-cvs under Cygwin. The compiler
stops
with the following error:
In file included from soundmgr_openal.hxx:50,
from xmlsound.hxx:40,
from xmlsound.cxx:38:
/usr/local
Norman Vine wrote
Vivian
Haven't got time to investigate but I would try changing
line 4 alctypes.h
from
#if !defined(_WIN32)
to
#if !defined(WIN32)
I won't be back online till late tonight
Already working on that, thanks.
Vivian
I wrote:
Norman Vine wrote
Vivian
Haven't got time to investigate but I would try changing
line 4 alctypes.h
from
#if !defined(_WIN32)
to
#if !defined(WIN32)
I won't be back online till late tonight
Already working on that, thanks.
That works - so far as
Vivian Meazza wrote:
I wrote:
Norman Vine wrote
Vivian
Haven't got time to investigate but I would try changing
line 4 alctypes.h
from
#if !defined(_WIN32)
to
#if !defined(WIN32)
I won't be back online till late tonight
Already working
Erik Hofman wrote:
Jim Wilson wrote:
not part of cvs logtext
Note the diff file has been renamed from the earlier submission. This
version
works better with more complex models.
/not part of cvs logtext
This patch adds support to the model animation system for modifying
emissive
Fred wrote
Erik Hofman wrote :
Jim Wilson wrote:
not part of cvs logtext
Note the diff file has been renamed from the earlier submission.
This version
works better with more complex models.
/not part of cvs logtext
This patch adds support to the model animation system for
Erik Hofman wrote
Frederic Bouvier wrote:
AFAICS, it is still there with the ufo. Could you check by putting fgfs
in chase view and do some actions on the throttle.
Yes, but that one is not textured. So maybe we've tracked it down to
textured objects only.
The Reflector on the Gun
Fred wrote
Vivian Meazza a écrit :
Erik Hofman wrote :
Jim Wilson wrote:
not part of cvs logtext
Note the diff file has been renamed from the earlier submission.
This version
works better with more complex models.
/not part of cvs logtext
This patch adds support to the model animation
Fred wrote:
Vivian Meazza a écrit :
Fred wrote
Erik Hofman wrote :
Jim Wilson wrote:
not part of cvs logtext
Note the diff file has been renamed from the earlier submission.
This version
works better with more complex models.
/not part of cvs logtext
This patch
Luca wrote
-Original Message-
From: [EMAIL PROTECTED] [mailto:flightgear-devel-
[EMAIL PROTECTED] On Behalf Of Luca Masera
Sent: 26 January 2005 09:16
To: flightgear-devel
Subject: [Flightgear-devel] Screenshots about particles
Hi Lee,
Are there any screen shots yet Luca?
Erik wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:flightgear-devel-
[EMAIL PROTECTED] On Behalf Of Hofman
Sent: 26 January 2005 09:49
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Screenshots about particles
Vivian Meazza wrote:
Luca wrote
Erik wrote:
Vivian Meazza wrote:
Erik wrote:
Vivian Meazza wrote:
Luca wrote
Are there any screen shots yet Luca?
I've send some screenshots to Vivian.
If you would see them, ask her or send me an e-mail. I don't
have a private web page to put them.
He will put them on his
Paul Surgeon wrote:
On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote:
After reading the glPointSize doc, I think the problem is in using point
sizes bigger than 1 and point antialiasing at the same time
I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and
see it
Jim Wilson wrote
Andy Ross said:
Jim Wilson wrote:
The min/max range, does that refer to engine RPM or propellor?
Propeller. It's a setting for the governor. With the newer syntax,
the engine and propeller are separate XML tags, so hopefully it should
be clearer which is which.
Andy Ross
Vivian Meazza wrote:
Yes - perhaps Andy will recall our long discussion of a year ago?
Only vaguely, and I currently lack the time to crawl through the
archives. You keep hinting that you want something done. Can you be
more specific?
Yes - sorry. I redid the Merlin engine
Oliver wrote
--(en/dis)able-enhanced-lighting
This is in CVS now ( should show up in a few hours on SF ). In the
meantime, a screenshot :
http://frbouvi.free.fr/flightsim/fgrun-basic.jpg
Very nice.
But i suggest to move the enhanced-lighting option into the advanced menu
or at
Erik Hofman wrote:
Vivian Meazza wrote:
On a Pentium 4 2.8 with a GeForce 5200 I get similar results. In
addition,
checking this option during run-time changes the colours in the cockpit
of
the some 3d models (I haven't tested them all). Unchecking it doesn't
change
the colour
Erik wrote:
Vivian Meazza wrote:
Thanks for this explanation. Why does it only seem to work one way? The
description 'enhanced lighting' is not particularly helpful.
Oh, this is about enhanced (runway) lighting. That's a different story,
I was talking about specular highlights which
Erik Hofman wrote:
Vivian Meazza wrote:
Right, so ignore all the foregoing - why does 'enhanced lighting
(runway)'
change the colour of some 3d panels? Perhaps an artifact of the video
card?
And why isn't it reversible?
I'm not sure about the change in color of the 3d panels, I've
Dave Martin wrote:
On Monday 24 Jan 2005 13:37, Oliver C. wrote:
On Monday 24 January 2005 11:05, Erik Hofman wrote:
Vivian Meazza wrote:
Thanks for this explanation. Why does it only seem to work one way?
The
description 'enhanced lighting' is not particularly helpful.
Oh
Erik Hofman
Dave Martin wrote:
On Monday 24 Jan 2005 14:01, Oliver C. wrote:
I assume that this feature is not supported by the hardware on the
consumer
video cards.
So OpenGL falls back to software mode.
That's why we get 1-3 fps here.
Well, thats interesting; would that also
Dave Martin wrote:
On Monday 24 Jan 2005 14:47, Erik Hofman wrote:
Dave Martin wrote:
How about basic poly with a tiny texture set as 'spherical' (much as
is
done with the bo105 lights)
Would that allow for better performance on consumer hardware or is
that
too simmilar to
Erik wrote:
Vivian Meazza wrote:
Erik Hofman
An alternative might be to use pentagonal vertex-fans and alpha blending
^^^
And in English that is ... ? :-) Is that some voodoo?
Oh sorry, just a disc constructed from five polygons
Dave Martin wrote
On Monday 24 Jan 2005 20:22, Vivian Meazza wrote:
Erik wrote:
Vivian Meazza wrote:
Erik Hofman
An alternative might be to use pentagonal vertex-fans and alpha
blending
^^^
And in English
Erik Hofman wrote
Martin Spott wrote:
Curtis L. Olson wrote:
I could also wish a few things.
1. That we treat everyone with respect.
Yes please, with no exception!!
The logical consequence would be that you (and maybe Arthur as well)
give a _credible_ signal to us that you
Fred wrote
Erik Hofman wrote :
Frederic Bouvier wrote:
This is in CVS now ( should show up in a few hours on SF ). In the
meantime, a screenshot :
http://frbouvi.free.fr/flightsim/fgrun-basic.jpg
If you're going this path (and it certainly does look good) then you
might want to
Fred wrote:
Erik Hofman a écrit :
Frederic Bouvier wrote:
I implemented something in between :
http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg
The popup on this window is modal and stay as long as FG is running :
http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg
Much
Jim Wilson wrote:
Here is my local config for the p51d yasim propeller. Most of these
values
are pretty much on target according to actual specifications. The problem
is
that it appears to not produce sufficient thrust.
Is it possible that we have a flaw in the thrust calculation?
Innis Cunningham wrote
Hi All
Could someone who uses FGRUN to start FG confirm
that the 172 fullscreen hi res Cessna starts at night
with the panel upside down and no scenery even
if you have noon selected in FGRUN.
Nope - it's fine apart the panel upside down, and the aircraft up to its
Fred wrote:
Quoting Martin Spott :
Frederic Bouvier wrote:
Martin Spott wrote :
This is what I meant: I run FlightGear and it actually reads most of
the values in my manually written 'system.fgfsrc', except a single one
(as far as I can tell), which is the aircraft to use. I've
Chris Metzler wrote:
p51d - A classic WWII fighter ... also well done. Full 3d cockpit.
Just out of curiosity, what remains to be done with the Spitfire? If
it's in production, are there any reasons to favor it over the P-51,
or vice versa?
Nothing major remains to be done, although,
Erik Hofman wrote
Paul Surgeon wrote:
How would I model for instance the ECAM switching on an A340 at the
moment?
The switches are located on the center pedestal but the displays are on
the
center panel. Would I have to add them to the properties tree?
How do I control the logic of
Dave Martin wrote
On Monday 17 Jan 2005 15:31, Martin Spott wrote:
Dave Martin wrote:
http://www.airshowphotography.com/videos/videos2.html
Nice, a 45 degree turn just one wing-span AGL :-)
Martin.
I've been playing with the FDM and changing the line in the yasim file:
flap1
Curt wrote:
I did another round with google adds today and here's what I've come up
with which seems (to me) like it could work out.
1. No adds at all on the main/front page of our site. Adds only on the
subpages.
2. I've had mixed results filtering out MSFS stuff, but that's mostly
Martin Spott wrote:
Curtis L. Olson wrote:
Now that plib-1.8.4 is released, I'd like to push forward with the
FlightGear v0.9.8 release. Does anyone have any changes that need to
get put in before the release?
Now that Mathias' patch is part of PLIB release maybe it makes sense to
Curt wrote:
I just received email from Steve Baker, and plib is very close to it's
v1.8.4 release. They have a release candidate available:
http://plib.sourceforge.net/dist/plib-1.8.4_RC.tar.gz
Can we have a few people fetch this and build Flight/SimGear against
this and report if
Curt wrote:
Melchior FRANZ wrote:
after a while I forget who on this list is completely insane and who
isn't. :-)
I am only partly insane. I'm trying to hide it as good as I can. ;-)
I'm still trying to decide where I fall in the continuum ... and I'm
still waiting for a few
David Megginson wrote:
On Mon, 10 Jan 2005 14:20:45 -0600, Curtis L. Olson
[EMAIL PROTECTED] wrote:
I was just flying in the SFO area with the DHC2-F and flightgear crashed
with the following message:
Unknown exception in the main loop. Aborting...
Possible cause: Success
Jon Stockill
Yes, they do need fixing - I can see terrain through the furthest hangar
where you're looking through the mesh of the door runners. Anyone know
how to fix this? Is it just an object ordering problem?
Probably. I've sent you a modified version off-list with separate objects
Erik Hofman wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:flightgear-devel-
[EMAIL PROTECTED] On Behalf Of
Sent: 05 January 2005 09:00
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Individual aircraft downloads
Jim Wilson wrote:
Unzip is
Dave Martin wrote:
Christian Mayer wrote:
Dave Martin schrieb:
I could make a really scathing comment about that using words like
plib,
OpenAL and SimGear...
But those are for *developers* and not *users*.
I was more making the point that unless a Linux *user* uses one of the
Jon Stockill wrote:
Curtis L. Olson wrote:
I've never noticed any holes in the instrument panels of either of
these. How about the Citation-II that looks good here too, but is by
the same author ... (?)
I'll try it when I get home, and grab some screenshots.
A quick look in AC3D
Jon Stockill wrote:
David Megginson wrote:
On Wed, 05 Jan 2005 12:58:57 -0800, Alex Romosan
[EMAIL PROTECTED] wrote:
i see the same thing (instruments are holes in the panel on the dhc2)
on linux/nvidia with the latest plib from cvs.
Are you running at 16 bpp or 24 bpp?
Here
Martin Spott wrote:
David Megginson wrote:
On Wed, 05 Jan 2005 12:58:57 -0800, Alex Romosan
[EMAIL PROTECTED] wrote:
i see the same thing (instruments are holes in the panel on the dhc2)
on linux/nvidia with the latest plib from cvs.
Are you running at 16 bpp or 24 bpp?
If it
Curt wrote:
Here's a preview of something I'd like to have working in time for the
0.9.8 release. As we go forward it would be nice to have thumbnail
images for each aircraft.
Do you want aircraft designers to do anything about this?
Regards,
Vivian
Jon Stockill
Chris Metzler wrote:
On Thu, 23 Dec 2004 10:28:23 -0600
Curtis L. Olson wrote:
I'm sure I'm using plib-1.8.3 here without problems. Anyone else seeing
a problem?
I'm currently dloading, to see what the status is of CVS bugs discussed
here recently . . .
A
Dave Martin wrote:
On Friday 24 Dec 2004 11:00, Ronny Standtke wrote:
It would be great if as many people as possible could download this
pre-release and give it a try and let us know if there are any
problems.
After a long time not using fgfs I tested this version and run straight
Jon Stockill
Vivian Meazza wrote:
Curt has stated the policy of only using the released version of plib
etc.
This makes sense to me. That decision really only affects the 'crease'
in
our models - the released version of the data cannot include them. And,
as
you said, we miss out
I wrote:
This morning I updated FGFS cvs and tried to compile under Cygwin - it
failed with
configure: creating ./config.status
config.status: creating \
.infig.status: error: cannot find input file: \
This evening I downloaded the whole file system to a new directory - same
This morning I updated FGFS cvs and tried to compile under Cygwin - it
failed with
configure: creating ./config.status
config.status: creating \
.infig.status: error: cannot find input file: \
This evening I downloaded the whole file system to a new directory - same
result. There are no other
Lee Elliott wrote:
On Thursday 16 December 2004 21:17, Jon S Berndt wrote:
[snip...]
Also, ask yourself the question, does the normalized value of,
say, 0.5 really correspond to 30 degrees of flaps when the
total range is 0 to 60?
Are you not assuming a linear transition here?
Lee Elliott wrote
[snip...]
How do FDMs handle Fowler flaps? i.e. the first part of the
action extends the flap rearwards without any rotation, acting
only to increase wing area, then for the rest of the action
rotate downwards?
Easy enough to 3d model with a normalized input:
-
Vivian Meazza [EMAIL PROTECTED] wrote:
A quick search revealed that most, if not all, the 3d models in the
current inventory use normalized values for animating the control
surfaces.
See, this further raises a red flag for me. How does the 3D model know
how far to move
Jon Berndt
Do 3D models use a normalized range to model aerosurface rotation, or
actual degree
magnitude? I've been looking at the JSBSim flight control code and the
addition of the
code that normalizes aerosurface (elevator, aileron, etc.) rotation
positions confuses
the code, and appears
Melchior FRANZ wrote
* Martin Spott -- Wednesday 15 December 2004 18:09:
1.) Do you have any plans if/when to deal with Michael's already
well-known ;-) 'crease' stuff -
s/Michael/Mathias/
We shouldn't forget that Mathias' so-called 'crease patch' also brings with
it significant
Jon S Berndt wrote:
On Wed, 15 Dec 2004 18:22:30 -
Vivian Meazza [EMAIL PROTECTED] wrote:
There are several points here.
1. The fact is that most 3d (I think all, but I haven't checked)
rightly or wrongly already use normalized values. It would be a
significant task to change
Vivian Meazza
3. For consistency, and remember that some 3d models are used with
both YASim and other FDMs, we need normalized values.
This is just plain wrong. If an aircraft can deflect the elevator +/-
30 degrees that's the way it is. Regardless of FDM. We are talking
about
Curt wrote:
As a project, FlightGear needs to depend on the stable releases of the
stuff it depends on, not cvs development trees. That get's to be too
big of a mess. Many distributions include the latest stable version of
plib, and that is often easier to build. It's ok for developers to
Erik Hofman wrote:
Vivian Meazza wrote:
So we have the situation where at least some of the current binary
releases,
do not follow this policy. The Windows for one seems to accept the
crease
token.
The policy is not meant for the binary releases. A binary-release
maintainer may
Melchior FRANZ
* Jon Stockill -- Tuesday 30 November 2004 16:39:
At 03:47 today.
Modified Files:
nimitz.ac
Log Message:
Remove crease tag so that people without custom patched versions of
plib can still run FlightGear. :-)
Yes, and at ... um ... right *now*:
$ cd
David Megginson
On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza
[EMAIL PROTECTED] wrote:
Sorry guys, I sent today's Nimitz before I realized that Curt was
removing
crease tokens. Mind you, after all the effort we went to get it in ...
I'm a
bit confused here. Mathias submitted
Melchior FRANZ wrote:
* Martin Spott -- Tuesday 30 November 2004 15:55:
Erik Hofman wrote:
Comment out the nimitz for now.
Hm ? I thought Curt just made it working with stock PLIB - is it still
broken ?
Yes, he did. But Vivian's changes from today refer to a file nimitz-
Martin Spott
No, it's just a matter of stability. We don't want FlightGear
releases to have to depend on prerelease CVS versions of plib, so we
have to wait until the next plib official release.
I'm not convinced that this actually is the point. FlightGear has a
history of depending
Melchior FRANZ wrote:
* Vivian Meazza -- Tuesday 30 November 2004 20:47:
Melchior FRANZ wrote:
WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\
Models/Geometry/Nimitz/nimitz-complex.ac' for
reading
Fatal error: Failed to load 3D model
Heckel wrote:
I encountered a compile error when make the simgear-0.3.7 for
FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have
plib and Zlib done.
What I did:
- download OpenAL from CVS.
- put the openal in /usr/local/source
- cd openal/linux
$ ./autogen.sh
$
Dale E. Edmons wrote
[EMAIL PROTECTED] wrote:
Hi, all,
I encountered a compile error when make the simgear-0.3.7 for
FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have
plib and Zlib done.
... snip ...
Got to /etc/ld.so.conf and see if it has /usr/local/lib or
Vance Souders wrote:
Nope, it doesn't work. The interpolation table doesn't seem to handle the
small values necessary for texture translation. For instance, you would
think an input value of 29.90 into the following table would give you an
output value of 0. No dice. You get .9 no
Martin Spott wrote
[...]
Did you manage to take off?
With a BO105 it's pretty easy, it is feasible with the C172 but for the
TSR-2 the strip is too short. I was too lazy to shift the starting
position to the beginning of the 'runway', otherwise it _might_ have
worked out. So I crashed
Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 16:53, Vance Souders wrote:
Here's a snippet of code to convert the inhg property value to mbar and
then use this to rotate the left-most digit on the mbar display. The
code
doesn't seem to work; Is this the correct usage of the
Martin Spott wrote
Melchior FRANZ wrote:
It isn't anywhere in the scenery yet -- just in cvs. You have to add
it yourself, or replace the saratoga with it. I added this in file
$FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg:
OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590
Melchior FRANZ wrote
Mathias has put all the necessary stuff here:
ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/
The code that he sent me works well, but I haven't tried it from that
location yet.
I applied all the stuff and it worked very well. My first carrier landing
Melchior FRANZ wrote:
To be honest: I don't see any carrier.
It isn't anywhere in the scenery yet -- just in cvs. You have to add
it yourself, or replace the saratoga with it. I added this in file
$FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg:
OBJECT_SHARED
Martin Spott wrote:
Sent: 16 November 2004 17:26
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Vivian Meazza wrote:
I think you will only see one carrier very close to KSFO. Mathias' code
only
works for JBSim FDM models, so if you use a YASim
Martin Spott wrote:
Vivian Meazza wrote:
Martin Spott wrote:
Did I miss a mail ?
No - the code is available at:
ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/
I know, this is _my_ server ;-))
Yes, of course, I had forgotten. Then I didn't understand the question
Frederic Bouvier wrote
Quoting Martin Spott:
Ampere K. Hardraade wrote:
http://forums.avsim.net/dcboard.php?az=show_topicforum=147topic_id=17270
0mode=full
Probably we never want to. Looking from this height the terrain
definitely looks different.
Does anyone know where they
Frederic Bouvier wrote:
In fact, in is not implemented in XML. It is in your favorite 3D modeller
that
you choose to add emission light to a material, and then texture it with
your
modulation texture.
In Blender, I choose the AC3D exporter option 'Mir2Emis' that means the
Blender's Mir
Norman Vine wrote
Oh please do keep telling that story as it points out the absurdity of
thinking
in lat lon with it's requirement for transcendentals so well, which by the
way,
are not necessary when using a sphere of one Earth Radius :-)
Oblate spheroid? ;-)
It is kind of like using
Melchior wrote:
While we are at it: even though filenames containing spaces are understood
by most file systems, they are still ugly and can cause problems
(especially
when given as an argument to badly written scripts or command lines ;-).
Could these, too, be changed please?
$
David wrote:
Is there an aircraft currently in flightgear that is a good example of
proper 3D cockpit construction?
I don't know about 'good', but the J3 Cub and the PA-28-161 both have
pure 3D cockpits (no 2D panel code).
You can add the Spitfire to that list. It might not be good,
Paul wrote:
Either I'm a bit thick or something is wrong with the
Spitfire and Seafire. I cannot get them to start.
Fuel cocks open, magnetos on, mixture rich, a bit of
priming, crank ... crank ... crank ... crank ...
With the Spitfire and the Coffman starter it doesn't
even kick the
..well, oxygen is fed to pax thru constant flow masks while the cockpit
crew uses on-deman masks, so that problem is solved, and if they need
night vision, they can have it, AFAIK. Dave C, you have experience
here, does airline pilots ever use oxygen to boost night vision?
No, but in
Ampere wrote:
Until someone writes a bone class that allows us to model characters more
easily (using XML), having pilots in the cockpit is not going to happen.
Ever used the Hunter, Seahawk, Comper Swift ?
It's not easy, but it can be done.
Vivian
Fred wrote:
Lighting is important. How can one use FG for night
training at the moment if you can't see the ground
properly? Why even bother with runway and taxiway
lights then?
I would love to see decent lighting added.
There isn't much we (as modellers) can do about this. =(
If
-Original Message-
From: [EMAIL PROTECTED] [mailto:flightgear-devel-
[EMAIL PROTECTED] On Behalf Of Frederic Bouvier
Sent: 07 November 2004 20:31
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] The Rant
Vivian Meazza a écrit :
Fred wrote:
Lighting
Fred wrote:
Hmm, I don't think that will do. White numerals by day, illuminated by
red
at night, and black faces. I was thinking of making the white figures
semi-transparent with a selectable white (non-emissive) /red (emissive)
background. Unless you would care to do a demonstration of
Paul wrote:
Either I'm a bit thick or something is wrong with the
Spitfire and Seafire. I cannot get them to start.
Fuel cocks open, magnetos on, mixture rich, a bit of
priming, crank ... crank ... crank ... crank ...
With the Spitfire and the Coffman starter it doesn't
even kick the
I wrote:
If there is a trick to getting them started can you
maybe add an engine startup section to the pilot
notes?
Oh dear, you have described the procedure correctly, it should work, I
don't
think you should need to hot wire it. I haven't tried for ages, been too
busy with
Paul Surgeon wrote:
There are several unused textures in the terrain folders.
Shouldn't they be moved to unused?
Also some of the material to texture mappings are a bit odd considering
that
there are more appropriate textures available.
That unused forest-test texture looks great!
Arnt Karlsen wrote:
7) Add pitching and rolling deck capability
..heave too.
Someone like to write a Ship Dynamic Model? :-)
Regards
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Mathias Froelich has also got some work underway, so we can add to the
schedule
project schedule:
1) Derive a new AICarrier class (me, just did it)
2) Refine the carrier visually (Vivian, doing it now)
3) Make the decks solid.
4) Improve FDM gear reactions to accomodate moving
project schedule:
1) Derive a new AICarrier class (me, just did it)
2) Refine the carrier visually (done, set to Erik for upload to cvs)
3) Make the decks solid.
4) Improve FDM gear reactions to accomodate moving ground (Mathias)
5) Improve FDM to include external forces
David Culp wrote:
3) Make the decks solid.
9) Make island solid
Here's how I think we can solidify the decks and island. First we need to
define some rectangles (2? 3? a variable list?).
http://home.comcast.net/~davidculp2/decks.jpg
Mathias Froelich ahs done some work for areas
Andy Ross wrote:
Matthias Froelich wrote:
This case kind of works for the arrester wires. The braking force is
just hacked into the gear code. But this is just to be able to test.
What would probably be a better idea (at least for YASim) would be to
model the braking force as a
201 - 300 of 588 matches
Mail list logo
