Hello Curt,
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/Rascal
In directory baron:/tmp/cvs-serv29111
Added Files:
README.Rascal Rascal110-set.xml Rascal110.xml
rascal-electrical.xml thumbnail.jpg
[...]
flight-modelyasim/flight-model
Martin Spott wrote:
I'm very much surprised to see that you intend to use YASim for an
aircraft, that you want to model based on existing flight data.
Do you actually expect YASim to be the right tool for that job or is it
simply leftover from using the Cub layout as basis ? I might miss the
Martin Spott wrote:
I'm very much surprised to see that you intend to use YASim for an
aircraft, that you want to model based on existing flight data.
Do you actually expect YASim to be the right tool for that job or is it
simply leftover from using the Cub layout as basis ? I might miss the
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049/Models
In directory baron:/tmp/cvs-serv7950/Models
Modified Files:
Lockheed1049_twa.xml
Log Message:
Thierry:
Sets correctly the VRP at the nose :
Yep, the VRP appears actually to be located at
On Sunday 27 November 2005 05:19 pm, Martin Spott wrote:
Sets correctly the VRP at the nose :
Yep, the VRP appears actually to be located at the nose, but the offset
to the CG is still missing :-)
Have a try, look at the aircraft from an outside view (chase view w/o
yaw), activate the HUD
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049
In directory baron:/tmp/cvs-serv14998/Lockheed1049
Log Message:
Directory /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049 added to the
repository
The Constellation looks pretty nice, but has a
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/c182
In directory baron:/tmp/cvs-serv2788
Modified Files:
c182-set.xml
I can't resist the suspicion that there's something wrong with the 3D
model. At least I get the glider to see and I yet didn't find yout why.
--- Martin Spott [EMAIL PROTECTED] wrote:
I can't resist the suspicion that there's something wrong with the 3D
model. At least I get the glider to see and I yet didn't find yout why.
Several XML files and the AC file do have DOS line endings but this
doesn't cause the trouble I've
Buchanan, Stuart wrote:
Have you synced Instruments-3d ?
The new C182 model requires the new yoke, flaps and trimwheel that I
submitted at the same time. I assume they were all checked in at the same
time.
Oops, they hadn't.
Erik
___
Martin Spott wrote:
I can't resist the suspicion that there's something wrong with the 3D
model. At least I get the glider to see and I yet didn't find yout why.
Several XML files and the AC file do have DOS line endings but this
doesn't cause the trouble I've already removed all of them,
Curtis L. Olson wrote:
Martin Spott wrote:
I can't resist the suspicion that there's something wrong with the 3D
model. At least I get the glider to see and I yet didn't find yout why.
Several XML files and the AC file do have DOS line endings but this
doesn't cause the trouble I've
Martin Spott wrote:
I have the impression that the changes to the FlightGear subtree didn't
make it into CVS - at least they didn't appear on checkout. Am I the
only one who misses these changes ?
Silly me: I set a Tag in my CVS tree last week
Sorry,
Martin.
--
Unix _IS_ user
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/ATC
In directory baron:/tmp/cvs-serv30924/src/ATC
[...]
* Use const string rather than string in function calls when appropriate.
[...]
I have the impression that the changes to the FlightGear subtree didn't
make it into CVS
Martin Spott wrote:
I have the impression that the changes to the FlightGear subtree didn't
make it into CVS - at least they didn't appear on checkout. Am I the
only one who misses these changes ?
I guess so, the CVS changelog was sent out to me by mail.
Erik
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/src/Systems
In directory baron:/tmp/cvs-serv25673
Modified Files:
vacuum.cxx vacuum.hxx
Log Message:
Allow a single vacuum system to be driven by multiple pumps.
That's fine. This topic becomes even more interesting
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/sr20
In directory baron:/tmp/cvs-serv4330/Aircraft/sr20
Added Files:
sr20-set.xml
Log Message:
Add some missing files.
I'd suggest these changes to get things going:
--- data/Aircraft/sr20/sr20-set.xml~Sat Oct
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/sr20
In directory baron:/tmp/cvs-serv4330/Aircraft/sr20
Added Files:
sr20-set.xml
Log Message:
Add some missing files.
I'd suggest these changes to get things going:
Ehm, allright. Done.
Erik
Dave Culp wrote:
This sounds more like HAA (height above airport) or HAT (height above
touchdown). Height AGL should be the current height above the ground
directly below the aircraft.
Height AGL should change as the terrain below the aircraft changes.
What would expect the HUD to
Quoting Erik Hofman:
Dave Culp wrote:
This sounds more like HAA (height above airport) or HAT (height above
touchdown). Height AGL should be the current height above the ground
directly below the aircraft.
Height AGL should change as the terrain below the aircraft changes.
What
Frederic Bouvier wrote:
So the HUD is displaying the height for the last known QFE ?
I think so. I suppose it just a barometric instrument with a digital
display. It is synchronized by ATC reports.
Erik
___
Flightgear-devel mailing list
Curt,
Is on my todo list for tomorrow (friday) since I saw Melchior's patch.
Greetings
Mathias
On Dienstag 04 Oktober 2005 20:52, Curtis L. Olson wrote:
For what it's worth, I don't like this patch. It shouldn't make much
difference on 24/32 bit cards, which is probably most
On Dienstag 04 Oktober 2005 22:17, Melchior FRANZ wrote:
* Curtis L. Olson -- Tuesday 04 October 2005 22:02:
You've been granted CVS commit access so use your best judgement.
Yes. I don't usually touch such things, because I don't understand much
of this. I did it anyway, because:
- this
Melchior FRANZ wrote:
* Curtis L. Olson -- Tuesday 04 October 2005 22:22:
Somewhere since the last release, that got broke and it must get fixed.
If that was fixed you wouldn't be seeing a hole in the carrier deck.
The bug was AFAIK there ever since we have helicopters. The same holes
were
So what basically happens now is that at the (startup) airport the AGL
would be reported correctly, but once the terrain elevation increases
the reported AGL won't change (like in real life).
This sounds more like HAA (height above airport) or HAT (height above
touchdown). Height AGL should
For what it's worth, I don't like this patch. It shouldn't make much
difference on 24/32 bit cards, which is probably most everyone now
anyway, but I think there is a different problem brewing somewhere.
I haven't had time to look into it, but the AGL reading on the HUD no
longer reads
* Curtis L. Olson -- Tuesday 04 October 2005 20:52:
For what it's worth, I don't like this patch.
I find the hole more annoying. Unfortunately, I can't fix what
you think is the real problem. Shall I revert for now?
m.
___
Flightgear-devel mailing
Melchior FRANZ wrote:
* Curtis L. Olson -- Tuesday 04 October 2005 20:52:
For what it's worth, I don't like this patch.
I find the hole more annoying. Unfortunately, I can't fix what
you think is the real problem. Shall I revert for now?
I'm not saying the hole isn't annoying,
* Curtis L. Olson -- Tuesday 04 October 2005 22:02:
You've been granted CVS commit access so use your best judgement.
Yes. I don't usually touch such things, because I don't understand much
of this. I did it anyway, because:
- this change was already in cvs since a great while, and only had
Melchior FRANZ wrote:
* Curtis L. Olson -- Tuesday 04 October 2005 22:02:
You've been granted CVS commit access so use your best judgement.
Yes. I don't usually touch such things, because I don't understand much
of this. I did it anyway, because:
- this change was already in cvs
* Curtis L. Olson -- Tuesday 04 October 2005 22:22:
Somewhere since the last release, that got broke and it must get fixed.
If that was fixed you wouldn't be seeing a hole in the carrier deck.
The bug was AFAIK there ever since we have helicopters. The same holes
were on rooftops.
m.
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/c150/Models/Vintage
In directory baron:/tmp/cvs-serv14308/Models/Vintage
Added Files:
README.TXT c150-01.rgb c150-02.rgb c150-int.rgb c150-int2.rgb
Log Message:
Add Mark Miller's c150 vintage look livery.
(See
Martin Spott wrote:
No such message as this one ?
cc-1020 cc: ERROR File = arch/irix/iris.c, Line = 415
The identifier AL_FORMAT_QUAD8_LOKI is undefined.
case AL_FORMAT_QUAD8_LOKI:
Ah, yes, now that you mention it.
You will need to add #include AL/alext.h right after AL/al.h
Erik
Erik Hofman wrote:
You will need to add #include AL/alext.h right after AL/al.h
Yep, looks good adding to that I suggest to replace alut.h with
alext.h or simply remove it in simgear/sound/sample_openal.hxx, line
50, maybe line 47 as well as alut now lives in a separate tree in the
OpenAL
Martin Spott wrote:
Yep, looks good adding to that I suggest to replace alut.h with
alext.h or simply remove it in simgear/sound/sample_openal.hxx, line
50, maybe line 47 as well as alut now lives in a separate tree in the
OpenAL source,
O.k., I see, this is the wrong approach
Hello Erik,
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear
In directory baron:/tmp/cvs-serv29428
Modified Files:
configure.ac
Log Message:
Prepare for OpenAL 1.1 and a separate alut lubrary.
Did you actually manage to compile current OpenAL CVS on IRIX ?
Cheers,
Martin Spott wrote:
Hello Erik,
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear
In directory baron:/tmp/cvs-serv29428
Modified Files:
configure.ac
Log Message:
Prepare for OpenAL 1.1 and a separate alut lubrary.
Did you actually manage to compile current OpenAL CVS on
Erik Hofman wrote:
Martin Spott wrote:
Did you actually manage to compile current OpenAL CVS on IRIX ?
Sure, just make sure there are no old headers (and library) installed
somewhere and do a fresh make (dist)clean and make install.
No such message as this one ?
cc-1020 cc: ERROR File =
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/b1900d
In directory baron:/tmp/cvs-serv4749
Modified Files:
b1900d-set.xml b1900d-sound.xml b1900d.xml
Log Message:
Syd Adams:
Here are some updates to the b1900d:
The panel looks pretty nice it's just
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/BAC-TSR2/Models
In directory baron:/tmp/cvs-serv26968/Models
Modified Files:
BAC-TSR2-model.xml
[...]
I really like this aircraft - it spreads some sort of 'charisma', very
much like the Concorde !
Thanks,
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/Citation/Panel
In directory baron:/tmp/cvs-serv18501/Panel
Added Files:
Citation-II-panel.xml adf-radio.xml dme-40.xml radios.xml
transparent-bg.rgb
Log Message:
Syd Adams:
Changes to the Citation II:
Melchior Franz wrote:
Update of /var/cvs/FlightGear-0.9/data/gui
In directory baron:/tmp/cvs-serv29971
Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der
Zwischenzeit den halben FlightGear um :-)
Tschuess,
Martin.
--
Unix _IS_ user friendly - it's just selective
* Martin Spott -- Saturday 09 July 2005 11:51:
Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der
Zwischenzeit den halben FlightGear um :-)
No, I'm not going to rewrite fgfs while the others are on vacation. :-)
Although these changes look extensive, they aren't really.
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth
In directory baron:/tmp/cvs-serv20421
Modified Files:
Makefile.am
Log Message:
Fix another dependency.
[...]
GPSsmooth_LDADD = \
! -lsgtiming -lsgmisc -lsgdebug -lplibnet -lplibul \
Martin Spott wrote:
Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that
are introduced by '-lplibnet',
Does $(opengl_LIBS) work as well?
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/utils/GPSsmooth
In directory baron:/tmp/cvs-serv15890
Modified Files:
Makefile.am
Log Message:
Attempt to add -lwinmm for windows builds (untested.)
I'd like to suggest another fix, as the IRIX build lacks -lm, which
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth
In directory baron:/tmp/cvs-serv8203
Modified Files:
Makefile.am
Log Message:
IRIX fixes.
Thanks - works,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth
In directory baron:/tmp/cvs-serv8203
Modified Files:
Makefile.am
Log Message:
IRIX fixes.
Thanks - works,
'course it works, it's tested on IRIX :-)
Erik
Martin Spott wrote:
BTW, did we have a consensus on the use of EMAil addresses in The
Manual ?
Because the manual gets posted online, and because of the huge spam
problem with any email addresses that are posted online, I'd recommend
against putting email addresses into the manual.
Curtis L. Olson wrote:
Because the manual gets posted online, and because of the huge spam
problem with any email addresses that are posted online, I'd recommend
against putting email addresses into the manual.
O.k., that's fine with me - I just wanted to get some feedback before
removing
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/FDM
In directory baron:/tmp/cvs-serv27859/FDM
Modified Files:
groundcache.cxx
Log Message:
Mathias Fröhlich:
this is basically the past patch I sent to the list and which should now
really (...!?!?) fix the no
* Martin Spott -- Thursday 02 June 2005 13:35:
Mathias Fröhlich:
this is basically the past patch I sent to the list and which should now
really (...!?!?) fix the no ground below aircraft problem.
Unfortunately the 'quick hack' was a better solution for my setup.
Could you elaborate
On Montag 30 Mai 2005 08:50, Melchior FRANZ wrote:
The FDMs are currently the only users of the groundcache, and yes, they
benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't
been done before Mathias implemented the ground cache. And probably it
would have been a big
On Montag 30 Mai 2005 14:21, Jon Stockill wrote:
I'm not certain the area that the ground cache covers, but I suspect it
has applications beyond just contact points. ISTR Lee was wanting to
know ground elevation a distance ahead of the aircraft for the terrain
following mode of the TSR2s
* Jon Berndt -- Monday 30 May 2005 00:26:
Melchior FRANZ wrote:
When you fly over a beacon, the ground cache has to eat all these
triangles,
which makes the FDM stutter or even hang.
Is the ground cache for the benefit of the FDM?
The FDMs are currently the only users of the
Still, I didn't mean to blame the problems on the
FDMs. I just called it FDM stuttering because this is what the user sees
(and because the ground-cache code is in the FDM/ directory :-) But the FDM
only stuttered, because it wasn't called in time, because of unfortunate
groundcache/beacon
* Dave Culp -- Monday 30 May 2005 09:27:
The groundcache/beacon interaction was only effecting the Yasim FDM, correct?
I've only tested it with YASim (bo105, b1900d) where I saw it before, but
not after fixing it. I can't say if it happened with JSBSim, although
I use both regularly.
m.
Is the ground cache for the benefit of the FDM?
The FDMs are currently the only users of the groundcache, and yes, they
benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been
done before Mathias implemented the ground cache. And probably it would have
been a big
Jon Berndt wrote:
Is the ground cache for the benefit of the FDM?
The FDMs are currently the only users of the groundcache, and yes, they
benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been
done before Mathias implemented the ground cache. And probably it would have
On Mon, 30 May 2005 08:50:43 +0200, Melchior wrote in message
[EMAIL PROTECTED]:
* Jon Berndt -- Monday 30 May 2005 00:26:
Melchior FRANZ wrote:
When you fly over a beacon, the ground cache has to eat all
these triangles, which makes the FDM stutter or even hang.
Is the ground
On Monday 30 May 2005 13:21, Jon Stockill wrote:
Jon Berndt wrote:
Is the ground cache for the benefit of the FDM?
The FDMs are currently the only users of the groundcache,
and yes, they benefit from it. A lot.
Per-wheel/contact-point ground awareness hadn't been done
before Mathias
On Monday 30 May 2005 13:21, Jon Stockill wrote:
I'm not certain the area that the ground cache covers, but I
suspect it has applications beyond just contact points. ISTR
Lee was wanting to know ground elevation a distance ahead of
the aircraft for the terrain following mode of the TSR2s
Melchior Franz wrote:
Update of /var/cvs/FlightGear-0.9/data/Models/Airport
In directory baron:/tmp/cvs-serv27845
Modified Files:
beacon.xml beacon.ac
Jon, are you going to update the respective entry in our database ?
Martin.
--
Unix _IS_ user friendly - it's just selective about
Martin Spott wrote:
Melchior Franz wrote:
Update of /var/cvs/FlightGear-0.9/data/Models/Airport
In directory baron:/tmp/cvs-serv27845
Modified Files:
beacon.xml beacon.ac
Jon, are you going to update the respective entry in our database ?
It's not in there. Though there are database
* Jon Stockill -- Sunday 29 May 2005 20:38:
Martin Spott wrote:
Melchior Franz wrote:
Modified Files:
beacon.xml beacon.ac
Jon, are you going to update the respective entry in our database ?
[...] there are database entries for the objects in the base package just
so
Melchior FRANZ wrote:
For those who care: these changes to the beacon solve one of the recently
discussed problems with hanging FDM: The beacon is a quite expensive structure.
It consists of about 1000 vertices and 950 triangles, all on the same spot.
When you fly over a beacon, the ground
* Jon Stockill -- Sunday 29 May 2005 21:02:
Melchior FRANZ wrote:
With these changes most of the 950 faces are invisible to the ground cache.
There's only a simple invisible pyramid instead for intersection tests.
Is this something that people should consider for any high poly
structures
Melchior FRANZ a écrit :
In less verbosity: this technique does only make sense for objects with high
face
*density*, not high face *number*.
The beacon has a lot of vertical, or near vertical, faces.
-Fred
___
Flightgear-devel mailing list
* Frederic Bouvier -- Sunday 29 May 2005 21:32:
Melchior FRANZ a écrit :
In less verbosity: this technique does only make sense for objects with high
face
*density*, not high face *number*.
The beacon has a lot of vertical, or near vertical, faces.
I saw them when I edited it in
Melchior FRANZ wrote:
For those who care: these changes to the beacon solve one of the recently
discussed problems with hanging FDM: The beacon is a quite expensive
structure.
It consists of about 1000 vertices and 950 triangles, all on the same spot.
When you fly over a beacon, the
From: Jon Berndt
Melchior FRANZ wrote:
For those who care: these changes to the beacon solve one of the recently
discussed problems with hanging FDM: The beacon is a quite expensive
structure.
It consists of about 1000 vertices and 950 triangles, all on the same
spot.
On Montag 30 Mai 2005 03:55, Jim Wilson wrote:
To answer your question, the ground cache is for the benefit of the
pilot. :-)
I could not say that better!!!
:)
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/AIModel
In directory baron:/tmp/cvs-serv670/src/AIModel
Modified Files:
AIAircraft.cxx
Log Message:
Solaris fixes
^^
+ #elif defined(sun) || defined(sgi)
+ # include ieeefp.h ^^^
Hehe ;-)
Thanks
Martin Spott wrote:
Modified Files:
AIAircraft.cxx
Log Message:
Solaris fixes
^^
+ #elif defined(sun) || defined(sgi)
+ # include ieeefp.h ^^^
Hehe ;-)
Thanks for applying these fixes !
So far for my hope to sneak it in ;-)
Erik
___
Erik Hofman wrote:
All these patches have been committed now. I still have to look into the
-pthread issue.
Oh, there's no hurry !
This weekend I replaced the Sparc20 on my internet gateway with an
Ultra2. While I successfully renewed the whole OS core for the 64-bit
architecture (kernel,
Martin Spott wrote:
Martin Spott wrote:
I found a third location:
Great, with the patches I posted these days and an additional
'-lpthread' to the final linker run we're up to date with Solaris
portability,
All these patches have been committed now. I still have to look into the
-pthread issue.
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/src/Network
In directory baron:/tmp/cvs-serv347
Modified Files:
net_ctrls.hxx net_fdm.hxx
Log Message:
32 bit integers are somewhat magical and handled pretty well across platforms
in terms of predictable packing and
Martin Spott wrote:
I found a third location:
Great, with the patches I posted these days and an additional
'-lpthread' to the final linker run we're up to date with Solaris
portability,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
On 6 Apr 2005, at 09:46, Erik Hofman wrote:
Modified Files:
fg_os_sdl.cxx
Log Message:
Melchior FRANZ:
Make SDL window resizable; This exposes the same problem that many
GLUT users have: resizing up may cause a temporary switch to software
rendering if the card is low on memory. Resizing
* James Turner -- Wednesday 06 April 2005 11:37:
Bad news - I've had this change in my tree for a few months now, and it
doesn't work right on OS-X
So then add a #ifdef for OS-X around the resize event, so that it is
simply ignored? Did you send a bug report to the SDL people?
#ifdef OSX //
* Melchior FRANZ -- Wednesday 06 April 2005 12:14:
Did you send a bug report to the SDL people?
Or the plib people? Anyway, we allow glut windows to be resized, and
I wouldn't understand if we wouldn't allow it for SDL on all systems,
just because of broken OSX or broken OSX support in plib.
m.
On 6 Apr 2005, at 11:14, Melchior FRANZ wrote:
So then add a #ifdef for OS-X around the resize event, so that it is
simply ignored? Did you send a bug report to the SDL people?
I think you misunderstand, it's not an SDL bug:
*FlightGear is relying on assumption about how OpenGL implementations
* James Turner -- Wednesday 06 April 2005 12:28:
Of course, we can certainly live without the feature on Mac - just be
aware the fault lies with FG / PLIB for not providing an API that is
somewhat important in real-world situations. I for one would love to be
able to switch from full-screen
On 6 Apr 2005, at 12:53, Melchior FRANZ wrote:
Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's
a suspicious comment in there:
* WARNING, we need to make sure that the previous mode hasn't
* already been freed by the video driver. What do we do in
*
* James Turner -- Wednesday 06 April 2005 14:17:
- Making PLIB / FG support vid restarts would be a very good thing to
do, but would be a lot of work and invasive. I would be happy to give
it a go if I thought the patches would be accepted!
Sigh ... that's not so sure.
- We can live with
* Melchior FRANZ -- Wednesday 06 April 2005 13:19:
So it's the glViewport() in FGRenderer::resize() that doesn't work with
plib/fgfs on OSX?
Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's
a suspicious comment in there:
* WARNING, we need to make sure that the
Hello Erik,
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/fokker100/Models
In directory baron:/tmp/cvs-serv14144
Modified Files:
f70_cabin.ac fokker70.ac fokker70.xml
Log Message:
Some final changes, fixes and updates for some time
The model looks very nice
Martin Spott wrote:
The model looks very nice and the handling feels pretty easy. It's only
Thanks.
that I'm missing the cabin door being coupled to the parking brake as
it was in your first version ;-)
No, it's not ...
:-)
Erik
___
Flightgear-devel
Erik Hofman wrote :
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv24714
Modified Files:
fg_init.cxx
Log Message:
Geoff Air:
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Erik
Well, reading this piece of code, I don't see how it could work. see
below :
Index: fg_init.cxx
===
RCS file:
Erik Hofman wrote :
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Or do both, because the current patch seems useless.
Is it windows specific ?
-Fred
___
Flightgear-devel mailing list
Frederic Bouvier a écrit :
Erik Hofman wrote :
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Or do both, because the current patch seems useless.
Is it windows specific ?
This one seems better ( move the added block 3 lines upward )
Frederic Bouvier wrote:
Frederic Bouvier a écrit :
Erik Hofman wrote :
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Or do both, because the current patch seems useless.
Is it windows specific ?
This one seems better ( move the
Update of /var/cvs/FlightGear-0.9/data/Huds/Default
In directory baron:/tmp/cvs-serv19455/Huds/Default
Modified Files:
default.xml
Log Message:
Disable the runway outline in the hud for now until a few more issues get
resolved. (It's a nifty feature though.)
What do you think
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Models/Weather
In directory baron:/tmp/cvs-serv5714
Modified Files:
rain.ac rain.xml
Log Message:
Model changes and add some select's.
Great idea, especially because there's no 'cigar' around the cockpit
anymore ;-)
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Models/Weather
In directory baron:/tmp/cvs-serv28318/Models/Weather
Added Files:
rain.ac rain.rgb rain.xml
Log Message:
Add a basic model for rain. Test w. the pc-7
This looks quite interesting but I realize that this might
On Monday 03 Jan 2005 16:11, Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Models/Weather
In directory baron:/tmp/cvs-serv28318/Models/Weather
Added Files:
rain.ac rain.rgb rain.xml
Log Message:
Add a basic model for rain. Test w. the pc-7
This
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Models/Weather
In directory baron:/tmp/cvs-serv28318/Models/Weather
Added Files:
rain.ac rain.rgb rain.xml
Log Message:
Add a basic model for rain. Test w. the pc-7
This looks quite interesting but I realize that this
On Monday 03 Jan 2005 17:32, Erik Hofman wrote:
Well, this will only cover a part of the rain problem.
I had an idea a while back that being able to change the specular material
setting for runways / taxiways 'on the fly' could produce the sort of wet
'sheen' you get on asphalt when it
Dave Martin wrote:
On Monday 03 Jan 2005 17:32, Erik Hofman wrote:
Well, this will only cover a part of the rain problem.
I had an idea a while back that being able to change the specular material
setting for runways / taxiways 'on the fly' could produce the sort of wet
'sheen' you get on
* Martin Spott -- Monday 13 December 2004 22:14:
I can confirm that the VSPEED display in the 737 PFD actually always
shows the number 0 but I'd say this is still better than a fps
display - at least for a real pilot. If the display sticks to 0 the
pilot will realize very soon that it is
1 - 100 of 537 matches
Mail list logo
