I am attempting to compile (version 2.4.2-32) MetaKit, which is
included in (version 0.0.17) Simgear. (I am utilizing cygwin to create
binaries on a PC.) The "../unix/configure" command appears to work fine.
However, the "make" command creates the following error message:
g++ -c -O2 -I.
Hi,
On Jan 19 the FGEngInterface and FGGearInterface were removed from the
flight.hxx source. It broke a lot of code in the opengc interface as well as
internal logic to modulate the display symbols.
I have made requests to this group for help in fixing what was broken by
this change. I don't mi
> > Its possible that it might be necessary to write an FGFlightPlan
> > module as well - can someone tell me whether real life ATC
> > actually knows whats in a flightplan after its been filed or is it
> > simply a case of the pilot just requests what's on his/her flightplan?
> ..this depends
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2002 08:26, you wrote:
> David Findlay writes:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > http://www.kflog.org/
> >
> > Check out that for a flight logging program. If only it had flight
> > planning features
> >
..on Sat, 23 Feb 2002 15:42:11 +0100, "Lorenzo Scaldaferro"
<[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>
in newsgroup: rec.aviation.simulators:
..first, I need to apologize for showing bad form in responding by
separate emails too, and for posting this onto the www.flightgea
On Mon, 25 Feb 2002 16:17:29 -0500,
David Megginson <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Arnt Karlsen writes:
>
> > ..another point you guys may be aware of, is that some jets
> > (military only?) tank _cold_ (40-50 Centigrades below zero)
> > fuel, this allows burni
Martin van Beilen wrote:
> Andy Ross wrote:
> > For those with Java experience, consider the Vector class. It's
> > threadsafe, right?
>
> No, it's not. Imagine what happens when one thread is reading it
> while another thread is writing to it. :-)
>
> > Right. Now enumerate over it in o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 25, 2002 at 12:55:07PM -0800, Andy Ross wrote:
> Martin van Beilen wrote:
> > Actually it is fairly easy to make the property manager Thread
> > Safe. All regular r/w locking can happen on a per-node basis, and
> > can be encapsulated
I've just added the first, small support for animating 3D models. The
spinning propeller for the C172 had been hard-coded into the C++, but
now, it's defined in a property file; the propellers on the DC-3 also
spin.
The only type of animation supported right now is "spin" tied to an
rpm property
Erik Hofman wrote:
> Andy Ross wrote:
> > Amen. The only purpose to doing threading in a C/C++ environment is
> > SMP scalability (in Java, you have to use them for I/O multiplexing
> > too; I consider this a bug, but at least there you have language
>
> Well, the main reason for using mult
Erik Hofman wrote:
>
> This would remove the need for locking (expept for OpenGL I gueass).
guess, guess, guess.
(I'm improving).
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
David Megginson wrote:
> I'll probably do that eventually, but as long as I'm still working on
> the models, I like to leave them in Blender's native orientation, so
> that front is front, top is top, etc.
Speacking of which, shouldn't the identifier tag on the panel correspont
to the identifie
Andy Ross wrote:
> Curtis L. Olson wrote:
> > Threading is *really* scarey in a program of this magnitude.
> >
> > I'd be adverse to adding additional threading especially if it
> > involves something like the property manager.
> >
> > There might be specific isolated instances where we can
Hi & Help
"Base package check failed.. Found version [none]"
"Please upgrade to version 0.7.9"
The above is what happens when I try to run ./fgfs (from the terminal).
I am using Mandrake 8.0.
Installed SimGear-0.0.17 (tar version)
Installed FlightGear-0.7.9 @ --prefix=/usr/local/FlightGea
David Findlay writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> http://www.kflog.org/
>
> Check out that for a flight logging program. If only it had flight planning
> features
>
> Anyone know if we could hook it up to FlightGear? Thanks,
Interesting, someone should download
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://www.kflog.org/
Check out that for a flight logging program. If only it had flight planning
features
Anyone know if we could hook it up to FlightGear? Thanks,
David
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 26 Feb 2002 05:57, you wrote:
> Hi,
>
> I´ve found this panel and it seem to be very cool. What do you think ?
>
> http://www.avsim.com/pages/1000/dreamfleet/dffull.jpg
Now that's what we need, but with the yoke removed so all the switches be
On Mon, 25 Feb 2002 08:33:03 -0500,
David Megginson <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Andy Ross writes:
>
> > The effect is happening because the aircraft isn't consuming fuel.
> > If you take off at full tanks, you never get any lighter. A real
> > aircraft woul
Martin van Beilen wrote:
> Actually it is fairly easy to make the property manager Thread
> Safe. All regular r/w locking can happen on a per-node basis, and
> can be encapsulated transparently. The property manager seems like an
> ideal candidate for IPC messaging, so if we want, it can be do
Curtis L. Olson wrote:
> Threading is *really* scarey in a program of this magnitude.
>
> I'd be adverse to adding additional threading especially if it
> involves something like the property manager.
>
> There might be specific isolated instances where we can do it
> reliably, but there is
Jim Wilson wrote:
> Yes agreed. And probably with a 747-400 it is only those longer
> flights like London-Vancouver that get filled to the brim with fuel.
>
> Andy, is the aircraft otherwise considered filled to capacity
> (passenger/cargo) in the fdm?
Um... I'm not sure. :)
The configure
David Megginson <[EMAIL PROTECTED]> said:
>
> Instead, if the /sim/model/path property points to a file ending with
> ".xml", the FGAircraftModel class reads a property file at that
> location to get information about the 3D model. Initially, the
> following properties are recognized:
>
> /p
Sergio Roth <[EMAIL PROTECTED]> said:
> Hi,
>
> I´ve found this panel and it seem to be very cool. What do you think ?
>
> http://www.avsim.com/pages/1000/dreamfleet/dffull.jpg
>
Yes, I saw that one not too long ago. Very nice vinyl texture. And the metal
panel area itself is pretty darn ne
Hi,
I´ve found this panel and it seem to be very cool.
What do you think ?
http://www.avsim.com/pages/1000/dreamfleet/dffull.jpg
All the best.
Sergio Roth
I've just made some changes to how 3D models are configured. The
following properties are no longer used:
/sim/model/heading-offset-deg
/sim/model/pitch-offset-deg
/sim/model/roll-offset-deg
/sim/model/x-offset-m
/sim/model/y-offset-m
/sim/model/z-offset-m
Instead, if the /sim/model
The models are IMHO not illuminated correctly. There's not enough
ambient light considered. The 'sunny side' is OK, but the opposite
side is almost black, which isn't what I see in reality, at least
not in natural situations. Is this a 'feature' of my graphics card
or is some opengl setting that h
Bipen Sehgal, Robert Deters, and Michael Selig recently published a
paper on their smart icing system research, specifically describing
their "Icing Encounter Flight Simulator". [1]
You can view this paper in PDF format here:
http://amber.aae.uiuc.edu/~m-selig/apasim/pubs/
It is a very nice
David Megginson <[EMAIL PROTECTED]> said:
> Andy Ross writes:
>
> > The effect is happening because the aircraft isn't consuming fuel. If
> > you take off at full tanks, you never get any lighter. A real
> > aircraft would have burned off a big chunk of its fuel store in the
> > climb, and
"Curtis L. Olson" wrote:
>
> D Luff writes:
> > Fair enough. I was under the impression that it was the disk
> > access taking the time.
>
> Registering new textures with opengl can take a noticable amount of
> time (especially when they are large.) Freeing memory (and any
> associated garbage
Martin Dressler wrote:
>
> Is Humidity important? Why not report just air density and viscosity.
> IMHO viscosity is importanat for count of Reynolds number.
> Maybe Re don't play big role in currents FDMs but is really important for
> RC modeling.
> OT: What are necessary values for FDM.
> air p
D Luff writes:
> Also, am I right in thinking that the global ATC manager and ATC
> display manager should both be derived from FGSubsystem and
> declared in FGGlobals in order to fit in properly with the future
> direction of FlightGear?
Yes, that would be a good idea.
All the best,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Feb 24, 2002 at 08:27:37PM -0600, Curtis L. Olson wrote:
> Threading is *really* scarey in a program of this magnitude. Even the
> current threaded tile manager is a big time bomb waiting to happen.
> We are getting away with doing stuff th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm releasing my modifications to the props interface so far. A
patch is on its way to Curt.
New commands:
mk(bool|int|long|float|double|string) [VAL]
create of specified type with optional
value [VAL].
D Luff writes:
> Fair enough. I was under the impression that it was the disk
> access taking the time.
Registering new textures with opengl can take a noticable amount of
time (especially when they are large.) Freeing memory (and any
associated garbage collection) can actually be a *big* hit
Curtis L. Olson writes:
> D Luff writes:
> > Surely it is possible to do a byte by byte copy of the tile from disk
> > to memory in a separate thread, without *any* Opengl/ssg/plib
> > dependency, such that the main thread need only access memory
> > and not disk?
>
> Surely it is possible, b
On 25 Feb 2002, at 11:00, D Luff wrote:
> thoroughly mess up radiostack.cxx. Hence I propose that all
> FGRadioStack does is to either just supply the selected comm
> frequencies to an ATC manager, or possibly do the station lookup
> in the Search() function and then flags hits to relevant s
D Luff writes:
> Surely it is possible to do a byte by byte copy of the tile from disk
> to memory in a separate thread, without *any* Opengl/ssg/plib
> dependency, such that the main thread need only access memory
> and not disk?
Surely it is possible, but if your goal is to push all time con
Curtis L. Olson writes:
> David Megginson writes:
> > What you need to do is isolate the tile manager completely, so that it
> > has (almost) no dependencies on the rest of the program, except for
> > one structure for data exchange.
>
> I don't think the solution can be that trivially simple.
David Megginson writes:
> > Anyway, in the back of my head, someday, I want to try to develop a
> > case against the threaded tile pager and maybe figure out a way to to
> > partial per frame model loading and unloading ... not that I don't
> > desparately wish we could do it, it's just that I
Curtis L. Olson writes:
> Textures: any threading that involves portions of opengl needs to be
> handled very delicately.
No, I wouldn't touch OpenGL. I'm talking about generating textures
in-memory; they would then be passed off to the main thread for use by
OpenGL. We're a long way from th
> Someone needs to rewrite the viewer code to allow viewpoints to be added
> at runtime; then, we can define a tower position for specific airports
> and allow you to switch to the nearest tower. And as usual, I don't
> have the time (much less the programming prowess) to take on such a
> task.
On Fri 22. February 2002 23:41, you wrote:
> I've added two new properties tied to the FGEnvironment class (you'll
> see these only if you compile with --with-new-environment):
>
> /environment/temperature-sea-level-degc
> /environment/pressure-sea-level-inhg
>
> I'm sticking with sea-level-eq
--- Martin Dressler <[EMAIL PROTECTED]> wrote:
> On Sat 23. February 2002 01:06, you wrote:
> > The flightgear side really only knows the current
> ground elevation for
> > a specific lon/lat. FlightGear has no way to know
> the dimensions of a
> > specific aircraft or the relative placement of
David Megginson writes:
> Threading is relatively safe if each thread is forced to play in a
> sandbox. A subsystem running in a separate thread must *not* touch
> any other subsystem (including the property manager), and must send
> and receive all information through a single, tightly-controlle
On Sat 23. February 2002 01:06, you wrote:
> The flightgear side really only knows the current ground elevation for
> a specific lon/lat. FlightGear has no way to know the dimensions of a
> specific aircraft or the relative placement of the gear. It would
> seem like the best thing FlightGear ca
Andy Ross writes:
> The effect is happening because the aircraft isn't consuming fuel. If
> you take off at full tanks, you never get any lighter. A real
> aircraft would have burned off a big chunk of its fuel store in the
> climb, and would have an easier time of it. As a workaround, try
Curtis L. Olson writes:
> Threading is *really* scarey in a program of this magnitude. Even
> the current threaded tile manager is a big time bomb waiting to
> happen. We are getting away with doing stuff that's not guaranteed
> to work. We've taken a lot of steps to try to minimize the
>
Martin van Beilen writes:
> Working from a single thread is obviously the easiest solution,
> where possible. However, in the case of our property system,
> potentially any part of the code may want to access those
> properties. We'd have to assign one thread as the property
> manager, and d
On Sat 23. February 2002 04:12, you wrote:
> > Please start with some yasim aircraft and apply parking break.
> > Look at skid ball. I thought that it should be in the middle of tube,
> > when sitting on runway. but it isn't.
>
> Is your runway flat ?
>
I started on KSFO.
Now that 0.7.9 is released I've got round to looking at the subject of
ATC again. This is probably going to be a long post so make sure
you've all had your coffee :-)
I basically hacked the ATIS support into Flightgear, on the grounds
that is was the simplest possible part of ATC to implement
Petru Paler wrote:
> Attached.
>
> It's basically a couple unused variables, an explicit cast, some unused
> functions removed or commented out, and a whole bunch of pragmas
> removed.
>
>
About the pragmas:
Are you sure thay don'r mean anything on other platforms?
Erik
51 matches
Mail list logo
