David Megginson [EMAIL PROTECTED] said:
Norman Vine writes:
globals-get_model_mgr()-draw();
globals-get_aircraft_model()-draw();
That's mostly dead code. FGModelMgr::draw is now a no-op and should
be removed (Jim?):
Yes, I noticed that but didn't remove. Was focusing on
Dave Perry wrote:
Attched find an xml file dc3.xml that includes edits that allow
accelleration on the main gear and relativly easy wheel landings.
With these changes, I can leave the tail wheel unlocked for take-off
and landings.
Very cool. I'll try it as soon as I get home.
3. I moved
Andy Ross writes:
Jim Wilson wrote:
I can see what you are saying...but the aircraft (in the cockpit view)
is actually a different scene graph.
But it's under the same camera (oddly, ssg puts the global camera
outside the graph, when it's logically the top-level node of the
graph), and has
Curtis L. Olson wrote:
Julian Foad writes:
The CVS server is not working for me at the moment. It was working
10 hours ago when I last tried it.
$ cvs diff
cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF
Seems to be working for me at the moment.
Yes, it's back
Norman Vine wrote:
Following is IMHO a good explanation as to why having the camera a
node in the scene-graph is not 'necessarily' a 'good idea'
Which is a good point in theory. Their basic idea is that the scene
graph specifies data, and you interpret that data via a camera.
These are two
I was testing some aero changes by flying in mouse mode (which is
easier than pulling out the yoke and clamping it onto my desk) when
something went wrong -- suddenly, the mouse would no longer control
the ailerons, though it still controlled the elevators. I was off
from the runway and heading
Semi-related ...
I was watching a PBS show yesterday called 'chasing the sun.' They
had a portion on the development of the dc-3. Apologies if I have the
name wrong, but I think it was Pan-Am that drove the specification
that the DC-3 was designed to fill.
One of the main factors was safety,
Andy Ross writes:
Which is a good point in theory. Their basic idea is that the scene
graph specifies data, and you interpret that data via a camera.
These are two well-defined and separate areas, and should be kept
separate in code.
The problem is that this leads naturally to precision
David Megginson writes:
I was testing some aero changes by flying in mouse mode (which is
easier than pulling out the yoke and clamping it onto my desk) when
something went wrong -- suddenly, the mouse would no longer control
the ailerons, though it still controlled the elevators. I was off
Curtis L. Olson writes:
I've never, ever seen this problem (and I'm not lying my butt off
about this like some software vendors I currently have to deal with.)
But if you observe this happening again, you might double check that
you didn't inadvertantly activate the wing leveler or
Curtis L. Olson wrote:
But to your other point, I agree that we should start looking into
failure modes. This is one big un-addressed issue. I could make up a
list of interesting failure modes if anyone was interested.
This could actually be done with minimal C++ code. Picture a failure
For those that might be interested I just wanted to point out the
creation of a new open source (space) flight simulation project.
http://www.spacegear.org/
At this point there is no direct code relationship with FlightGear,
but they are in the very early stages of bringing their project up
Curtis L. Olson wrote:
I haven't been following this thread as closely as I should have been,
but there should be no reason why we'd need to have the camera in the
scene graph. I think we just need to be smarter about how we
structure the transforms.
That was my original suggestion: put the
Andy Ross writes:
This could actually be done with minimal C++ code. Picture a failure
manager that walks a property tree under /failures. For each
child, it reads a mtbf-sec property and sets the working boolean
with a random probability that corresponds to the failure rate. This
is
On Mon, 8 Jul 2002 16:54:12 -0500 (CDT)
Curtis L. Olson [EMAIL PROTECTED] wrote:
However, we would also need to be able to turn off the auto-failure
generation module and allow an instructor (or a script) have complete
control over the failures. This way an instructor could use the sim
to
Andy Ross writes
The right solution (ignoring orientation, which is
fine as-is) is this:
Move 0m in the camera
Move +1000m
Draw the terrain
Move ~1m to the aircraft origin
Draw the cockpit
Indeed ... which is why I pointed out 'where' in the code
it was easiest to do this
To
Norman Vine wrote:
I guess I wrongly assumed that everyone would read this as just add
the appropriate offset to move the camera to the origin :-)
Unless I'm still not understanding you, I think you misunderstand the
issue. Just adding an offset to the camera is what's already being
done, and
Andy Ross writes:
Norman Vine wrote:
I guess I wrongly assumed that everyone would read this as just add
the appropriate offset to move the camera to the origin :-)
Unless I'm still not understanding you,
we do seem to have a communication gap :-)
not-all-M$oft-users-use-the-gui'ly yours
Andy Ross writes:
This could actually be done with minimal C++ code. Picture a failure
manager that walks a property tree under /failures. For each
child, it reads a mtbf-sec property and sets the working boolean
with a random probability that corresponds to the failure rate. This
Jon S Berndt writes:
Just as I flared during the last landing he gave me a 100 knot
tailwind. If there would have been a black box, it would have
gotten from me only a What the ... ! before I pancaked in.
If you were flaring, you were probably close enough to the ground to
survive (i.e.
Andy Ross writes:
Unless I'm still not understanding you, I think you misunderstand the
issue. Just adding an offset to the camera is what's already being
done, and it runs into precision problems. The trick is to make sure
that the camera is *never* moved to the scenery centroid
Andy Ross writes:
Just adding an offset to the camera is what's already being
done, and it runs into precision problems. The trick is to make sure
that the camera is *never* moved to the scenery centroid before
rendering the model.
Right ---
So why not leave the camera at 0,0,0 and add an
Jon S Berndt writes:
Just as I flared during the last landing he gave me a 100 knot
tailwind. If there would have been a black box, it would have
gotten from me only a What the ... ! before I pancaked in.
If you were flaring, you were probably close enough to the ground to
survive
David Megginson writes:
Andy Ross writes:
Unless I'm still not understanding you, I think you misunderstand the
issue. Just adding an offset to the camera is what's already being
done, and it runs into precision problems. The trick is to
make sure
that the camera is *never* moved to
Jon Berndt writes:
Actually, I meant the pre-flare, which occurs at about 1800 ft. agl. This
brings the glideslope from about 20 to less than 2 degrees. That's where
he clobbered me. He was toying with me. The operators had some sense of
humour...
Just out of curiosity, what is the
Andy,
I put the main gear back at x=-6.02 and added a ballast under the
cockpit at 700 lbs and it handles very well. I even did some x-wind
take offs and landings. Here the locking tail wheel helps in the
initial acceleration. For strong x-winds, I think one uses differential
power (and
Didn't attach the xml.
Dave
airplane mass=16865
approach speed=58 aoa=13
control-setting axis=/controls/throttle[0] value=0.4/
control-setting axis=/controls/throttle[1] value=0.4/
control-setting axis=/controls/mixture[0] value=1.0/
control-setting axis=/controls/mixture[1] value=1.0/
Does anyone know why cloud.cxx is putting out:
Error: base = 0,-0.00112949
Error: base = 0,0
It's been doing it for a while ...
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
FYI
http://xplusplus.sourceforge.net/index.htm
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Just because something *can* be done doesn't mean it *should* be!
;-)
Jon
Subject: [Flightgear-devel] x++ The World's First XML-Based Programming
Language
FYI
http://xplusplus.sourceforge.net/index.htm
smime.p7s
Description: application/pkcs7-signature
On Mon, 2002-07-08 at 20:52, Norman Vine wrote:
FYI
http://xplusplus.sourceforge.net/index.htm
Bring on the significant whitespace!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Just out of curiosity, what is the shuttle's approach speed, and can
it recover from a stall?
David
I recall reading that initial flights landed at about 205 mph. This page:
http://www-pao.ksc.nasa.gov/kscpao/nasafact/count3slf.htm
says that the landing speed is typically now 213 to 226
On Monday, July 8, 2002, at 11:23 PM, Jon Berndt wrote:
Just because something *can* be done doesn't mean it *should* be!
;-)
Jon
Actually, I was going to say that it was another solution in search of a
problem.
Subject: [Flightgear-devel] x++ The World's First XML-Based Programming
Attached are two patches: one for simgear, and one for flightgear.
The changes are mostly minor except for a few fixes to uninitialized
variables found by valgrind. Here's the list of changes:
== Changes in simgear-cleanups.diff:
simgear/misc/props.cxx
* Rearranged member initializers to shut
34 matches
Mail list logo
