Jim Wilson <[EMAIL PROTECTED]> said:
> "Curtis L. Olson" <[EMAIL PROTECTED]> said:
>
> > FWIW, the following two options no longer appear to work:
> >
> >--lon=degreesStarting longitude (west = -)
> >--lat=degreesStarting latitude (south = -)
> >
> > If y
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> FWIW, the following two options no longer appear to work:
>
>--lon=degreesStarting longitude (west = -)
>--lat=degreesStarting latitude (south = -)
>
> If you attempt to use them you end up at lon=0.0, lat=0.0
Michael Selig <[EMAIL PROTECTED]> said:
> * The base package is about 100MB. Over a cable modem, this is not a
>problem. Over a phone modem, it is a nighttime chore. I have not
>heard complaints from those downloading overnight, or from those who
>get it in a "flash" over a cable mo
David Megginson <[EMAIL PROTECTED]> said:
> I'm already concerned about the base-package size. We need to start
> thinking seriously about making most aircraft optional add-ons. It's
> easy for me with a fast cable modem, but I don't want to scare away
> regular users. If the DC-3 (for example)
At 11/12/02, David Megginson wrote:
Jim Wilson writes:
> If Blender becomes the "tool of choice", as it probably should, for
developing
> FlightGear Models then it makes sense to have those files in the CVS
directory
> with the ac files that are derived from them. The CVS is a development
FWIW, the following two options no longer appear to work:
--lon=degreesStarting longitude (west = -)
--lat=degreesStarting latitude (south = -)
If you attempt to use them you end up at lon=0.0, lat=0.0
I don't have time to look into this tonight, but they mu
Jim Wilson writes:
> If Blender becomes the "tool of choice", as it probably should, for developing
> FlightGear Models then it makes sense to have those files in the CVS directory
> with the ac files that are derived from them. The CVS is a development
> repository after all.
I'm already co
Matthew Law writes:
> I always run my CVS updates as root so that didn't appear to be the
> problem.
You probably know this already, but it's not a good idea to do things
like that as root, especially if you're compiling as root as well;
basically, you're giving root priviledges on your machi
On Mon, 11 Nov 2002 17:45:16 -0800 (PST),
Jim Brennan jjb - <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> For the 747-400
>
> Va (Design maneuvering speed) is 330 kts at sl, 334 at 10k,
> 358/.92mach at 29,000
..so yanking the stick into your gut for a snap roll at 330kts,
means
Andy,
That fixed the problem. Thanks!
Jonathan Polley
On Tuesday, November 12, 2002, at 03:21 PM, Andy Ross wrote:
Jonathan Polley wrote:
> I updated plib, SimGear, and FlightGear before rebuilding. I cleaned
> everything on Windows because there were some changes to plib headers
> (MSVC i
David Megginson <[EMAIL PROTECTED]> said:
> I don't think that the base package is the right place, though, and
> the FlightGear CVS repository certainly isn't. Any suggestions?
> Perhaps we need a new base-source CVS repository (we could put the
> original MDL files there as well).
It does get
David Luff wrote:
It looks to me like you've
got 2 too many curly brackets in doEnginePower, although I could be
misunderstanding what you're doing there.
Yes, I have got too many. This is the friction that was applied only
when starting; I was making it permanent but haven't finished with it
Erik Hofman wrote:
[EMAIL PROTECTED] wrote:
I think we have a bit of confusion over the meaning of "offset". I
...
But if you look at the following example:
/engines/engine/rpm
0.0012
[which is calculated as
pitch = (property * factor) + offset
= (rpm * 0.0012) + 1.0
]
You
Thanks for the help guys!
I always run my CVS updates as root so that didn't appear to be the problem.
The update only completes if I explicitly override my config with -z0 to drop
the compression completely. Hopefully if anyone else is having the same
problem then this might work for you too
On 11/12/02 at 12:28 AM Julian Foad wrote:
>Ah, glad you're there. If you're interested and have time to look, my
>current attempt is at
>
> http://www.btinternet.com/~julianfoad/fgfs/JSB_piston_engine.diff
> http://www.btinternet.com/~julianfoad/fgfs/engine_sound.diff
>
>but, as I said, not
Jonathan Polley wrote:
> I updated plib, SimGear, and FlightGear before rebuilding. I cleaned
> everything on Windows because there were some changes to plib headers
> (MSVC isn't always smart enough to properly handle header changes if
> they are not in YOUR project). I haven't cleaned the MacOS
David,
> I don't think that the base package is the right place, though, and
> the FlightGear CVS repository certainly isn't. Any suggestions?
> Perhaps we need a new base-source CVS repository (we could put the
> original MDL files there as well).
IMHO this is a splended idea. This way we could
David Megginson wrote:
Jim Wilson writes:
> My main concern is that if we use Blender, then files that will read into
> Blender should be maintained CVS as source data. We might even want to
> maintain our own version of the python script and at least
I don't think that the base package i
Jim Wilson writes:
> My main concern is that if we use Blender, then files that will read into
> Blender should be maintained CVS as source data. We might even want to
> maintain our own version of the python script and at least
I would be happy to put my original Blender and XCF (Gimp) fil
David Megginson <[EMAIL PROTECTED]> said:
> Fortunately, it's much simpler than that, since Blender has built-in
> Python scripting -- I just export the file to AC3D format from within
> Blender using a 3rd-party export script, and the object names, texture
> mappings, and material colours are pre
Jim Wilson writes:
> If I'm not mistaken the process to get from Blender to flightgear
> is to save the file in blender, run the file through a conversion
> script to crate an ac3d file, and then edit that file in ppe to add
> name labels to objects.
Fortunately, it's much simpler than that,
Martin Spott writes:
> I had the impression these two tools target at different audience. Should
> Blender be capable of being used for 'real' 3D CAD as AC3D does ?
Much more so than AC3D, I'd think -- it has many features that AC3D
lacks, like a UV editor.
All the best,
David
--
David M
Martin Spott <[EMAIL PROTECTED]> said:
> > It is Open Source, while AC3D is commercial, but FlightGear really
> > doesn't care which tool you use. [...]
>
> I had the impression these two tools target at different audience. Should
> Blender be capable of being used for 'real' 3D CAD as AC3D does
> It is Open Source, while AC3D is commercial, but FlightGear really
> doesn't care which tool you use. [...]
I had the impression these two tools target at different audience. Should
Blender be capable of being used for 'real' 3D CAD as AC3D does ?
Martin.
--
Unix _IS_ user friendly - it's ju
[EMAIL PROTECTED] wrote:
Erik Hofman wrote:
Julian Foad wrote:
>
Not totally different. Quite similar. Have you looked at the code? The
I've written the code.
Oh! ... sorry. I'll be very careful then.
:-)
You can always override the default offset, but defaults should have a
sane valu
Jonathan Polley writes:
> I updated plib, SimGear, and FlightGear before rebuilding. I cleaned
> everything on Windows because there were some changes to plib headers
> (MSVC isn't always smart enough to properly handle header changes if
> they are not in YOUR project). I haven't cle
Erik Hofman wrote:
>
> Julian Foad wrote:
> >
> > Not totally different. Quite similar. Have you looked at the code? The
>
> I've written the code.
Oh! ... sorry. I'll be very careful then.
> > way I read it, a negative value causes the (scaled, clamped, etc.) value
> > to be subtracted
Jonathan Polley writes:
> I updated plib, SimGear, and FlightGear before rebuilding. I cleaned
> everything on Windows because there were some changes to plib headers
> (MSVC isn't always smart enough to properly handle header changes if
> they are not in YOUR project). I haven't cleaned
Andy Ross wrote:
>
> If you guys are thinking of changing the way we do "linear function of
> a property value" definitions in configurations, let me argue for a
> slightly different way to do it:
...
> Instead, why not specify a range mapping. That is, input values in
> the range [a,b] get mappe
Curt,
I updated plib, SimGear, and FlightGear before rebuilding. I cleaned
everything on Windows because there were some changes to plib headers
(MSVC isn't always smart enough to properly handle header changes if
they are not in YOUR project). I haven't cleaned the MacOS build
because gcc
Just to double check, David made a change to SimGear and to the some
of the aircraft config files yesterday. Without the change to
simgear, flightgear will crash on startup.
If that's not it, then we'll have to take a closer look, although your
line numbers don't make sense in your back trace ...
Michael Selig writes:
> Any idea on the status of this? I assume this is the tool of choice for
> making models?
It is Open Source, while AC3D is commercial, but FlightGear really
doesn't care which tool you use. I was repulsed by Blender the first
few times I ran it and immediately removed
* Julian Foad -- Tuesday 12 November 2002 00:22:
> Yes, I find it's a compression problem too. I have compression set at
> the default in my ~/.cvsrc so I use "cvs -z0 up" to update FlightGear
> (source), SimGear and TerraGear (which are all on the same server and
> are the only projects with w
>
> Maybe you don't understand the meaning of this value, but the
> result is
> used as a scaling factor for the playback frequency. So an
> offset 0f 1.0
> (and nothing else) will cause the sound to be played in the recording
> speed. An offset of 0.5 (and nothing else)) will cause the
> so
Andy Ross wrote:
If you guys are thinking of changing the way we do "linear function of
a property value" definitions in configurations, let me argue for a
slightly different way to do it:
The problem with specifying a multiplier (e.g. "scaling" or
"rotation") and an offset is that these two opp
Julian Foad wrote:
Erik Hofman wrote:
Julian Foad wrote:
<...>
Anomalies:
1. The pitch offset defaults to 1, but I think that is just a bug.
2. Since the offsets are constant, it is redundant to specify more
than one. This arrangement is therefore not ideal, but I'm not sure
what would be
>That sounds fine. We might want to use this as a replacement for the 4th
>view. The 4th view is a tower view that doesn't track the FDM location as
>the
>3rd view does; that is, you can look around the airport with the mouse.
>Mostly that was something I threw in there as both a test and
>demo
At 9/2/02, David Megginson wrote:
For those of you not currently following it, the Blender fund has been
successful: out of the EUR 100,000 needed to buy the sources from the
NaN shareholders, the fund has collected EUR 96,540 and has another
EUR 9,481 pledged. With luck, we'll have a decent, cro
38 matches
Mail list logo
