--- Erik Hofman [EMAIL PROTECTED] wrote:
Norman Vine wrote:
how about
vector v;
v.erase(v.begin()+index);
Yep. that was it.
Thanks Norman
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
From: ace project [EMAIL PROTECTED]
--- Erik Hofman [EMAIL PROTECTED] wrote:
Norman Vine wrote:
how about
vector v;
v.erase(v.begin()+index);
Yep. that was it.
Thanks Norman
Erik
___
Flightgear-devel
How about this one, is it wrong ?:
vector_of_elements.erase(element[index]);
Or should it be :
vector_of_elements.erase(vector_of_elements[index]);
I think your are making the too rapid assumption
that
an iterator is a pointer to an element.
Cheers,
-Fred
Thats the one I ment
Alex Perry writes:
David replies:
I probably made a stupid mistake on the math. I'll take another look
at it tomorrow morning when my brain is fresh.
Ok, I found the problem. You're computing the dynamic pressure in
psf and adding it to the static pressure in inHg to form the
Frederic Bouvier writes:
Or should it be :
vector_of_elements.erase(vector_of_elements[index]);
I think your are making the too rapid assumption that
an iterator is a pointer to an element.
Don't iterators override the '+' operator if they're not just
pointers?
All the best,
ace project writes:
How about this one, is it wrong ?:
vector_of_elements.erase(element[index]);
Or should it be :
vector_of_elements.erase(vector_of_elements[index]);
I think your are making the too rapid assumption
that
an iterator is a pointer to an element.
Hi Guys!
Today I tested 3D clouds
Looks very very good!
But have some questions:
1) How can we populate clouds? because clouds are placed above runway
2) Is there any tool to crate clouds volumes?
3) When I saw clouds3d code I came across to GL_ARB_MULTITEXTURE under
Win32. So does clouds3d
I want to know how you guys want the property list to
be organised. Do we use something like:
/network/pilot[n]/callsign
/network/pilot[n]/position/ (lat,alt, etc)
/network/pilot[n]/[network-module-name]/ (module
specific stuff)
I will need this soon(3 weeks tops), as my little
coding is
On Mon, 7 Oct 2002 07:36:53 -0400
David Megginson [EMAIL PROTECTED] wrote:
Frederic Bouvier writes:
Or should it be :
vector_of_elements.erase(vector_of_elements[index]);
I think your are making the too rapid assumption that
an iterator is a pointer to an element.
Don't
On Mon, 7 Oct 2002 08:09:32 -0400
Norman Vine [EMAIL PROTECTED] wrote:
ace project writes:
vector_of_elements.erase(vector_of_elements[index]);
I think your are making the too rapid assumption that
an iterator is a pointer to an element.
Thats the one I ment Fred (my
During the ground portion of my flight test in August, the examiner
asked me how I could detect a static port blockage. I decided to list
everything, just to be safe: I mentioned the behaviour of the ASI and
he looked impatient; I mentioned the VSI freezing and he still looked
impatient;
I was bored, so I made a Poor English translation,
as an excersise to understand the english language better.
I am a native english speaker, but I find it quite fun
to decipher/encypher the messages of non-native speakers.
I tried to synthesize the different patterns and the
sheer literalness
David Megginson wrote:
Frederic Bouvier wrote:
I think your are making the too rapid assumption that
an iterator is a pointer to an element.
Don't iterators override the '+' operator if they're not just
pointers?
Indeed. That's the whole genius (madness, whatever) behind the idea.
Many
Bernie Bright wrote:
Only random access iterators support the '+' operator. Fortunately
std::vector and std::deque provide just such iterators.
I thought there was a variant that supported incrementation but not
decrementation. You don't need the full-on random access variant in
this case.
I is like the way you spoke so deliciously :-)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Brandon
Bergren
Sent: 07 October 2002 06:21 PM
To: [EMAIL PROTECTED]
Subject: [Flightgear-devel] OT: Poor English Translation
I was bored, so I made a
Alex Perry writes:
Do remember that you're not going to do that routinely during cruise
so it isn't the thing that will _initially_ make you suspicious.
Flying along, completely trimmed in smooth air (esp at night),
it is quite feasible for the altimeter to change by less than 20 ft
in
Andy Ross writes:
Of course, the cost of that elegance is a library that almost no one
understands.
[David raises his hand in acknowledgement.]
That's the problem, really. Having any standard container library is
a godsend for coding and debugging, and STL is serving FlightGear well
-- I
David Megginson wrote:
-- I think that plib's avoiding STL is just silly --
I can understand it: it saves them from all the STL related cruft that
FlightGear has to carry along. I think STL wasn't matured enough when
FlightGear started to use it, but it's staring to come along lately
If you have access to CNN you may want to catch the
evening news. Hopefully they'll show the video from
today's launch of the space shuttle. I just got back from
an auditorium onsite at Johnson Space Center where I
watched the launch live, in stereo, with multiple camera
angles, including a
Does anyone have any specific dimensions for the layout and size of a
VASI system?
From what I've been able to find, the VASI/PAPI system should be 50'
off the side of the runway and about 950ft/285m from the threshold. I
know that each of the 4 PAPI lights is spaced about 9m/30ft apart.
But,
David Megginson writes:
Even a sub-$200 non-aviation hand-held mounted on the yoke could be
a useful part of a VFR or IFR scan.
Speaking of el-cheapo GPS receivers, I just found some Perl scripts
that allow me to flash a new database into my very low-end Magellan
GPS 315, so I went ahead
Curtis L. Olson writes:
Does anyone have any specific dimensions for the layout and size of a
VASI system?
From what I've been able to find, the VASI/PAPI system should be 50'
off the side of the runway and about 950ft/285m from the threshold. I
know that each of the 4 PAPI lights
Yes, there are definitely complications, but right now our data has
N=none, V=vasi, P=papi, so I'm planning to start simple.
What I'm looking for is somethingn to the effect that a VASI light bar
is a row of n lights spaced x meters apart. VASI light bars are
spaced y meters apart along the
For the U.S., the numbers are documented in the AIM to give the angles etc
for both 2-bar and 3-bar VASI and normal PAPI systems. Generalizing:
A 2 bar VASI is simply a 3 bar VASI with one of the bars missing
so I recommend doing 3 bar units consistently everywhere.
The PAPI unit has all the
Curtis L. Olson writes:
What I'm looking for is somethingn to the effect that a VASI light bar
is a row of n lights spaced x meters apart. VASI light bars are
spaced y meters apart along the length of the runway.
And if I'm really lucky I'd get the difference in degrees in alignment
David Megginson writes:
Curtis L. Olson writes:
What I'm looking for is somethingn to the effect that a VASI light bar
is a row of n lights spaced x meters apart. VASI light bars are
spaced y meters apart along the length of the runway.
And if I'm really lucky I'd get the
Have you checked the
* AIM description of the visual aid
* Airport construction recommendations
* TERPS description of approach/landing tolerances
... ?
Well, I'm all googled out and I still haven't come up with anything
for VASI (although I have good data for PAPI.) I guess I'll just have
Alex Perry writes:
Have you checked the
* AIM description of the visual aid
* Airport construction recommendations
Yes, as far as a I know, although I'll never claim I've exhaustively
searched all FAA docs.
* TERPS description of approach/landing tolerances
What is terps and where can I
Curtis L. Olson writes:
What I'm looking for is somethingn to the effect that a VASI light bar
is a row of n lights spaced x meters apart. VASI light bars are
spaced y meters apart along the length of the runway.
And if I'm really lucky I'd get the difference in degrees in
Norman Vine writes:
Curtis L. Olson writes:
What I'm looking for is somethingn to the effect that a VASI light bar
is a row of n lights spaced x meters apart. VASI light bars are
spaced y meters apart along the length of the runway.
And if I'm really lucky I'd get the
On Mon, 07 Oct 2002 09:53:09 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Bernie Bright wrote:
Only random access iterators support the '+' operator. Fortunately
std::vector and std::deque provide just such iterators.
I thought there was a variant that supported incrementation but not
* TERPS description of approach/landing tolerances
What is terps and where can I find it?
The US standard for TERminal instrument ProcedureS ...
http://www.terps.com/
http://av-info.faa.gov/terps/
Warning, for those on dialup, the actual TERMS manual is a HUGE PDF!
Curtis L. Olson writes
Norman Vine writes:
Curtis L. Olson writes:
What I'm looking for is somethingn to the effect that a VASI light
bar
is a row of n lights spaced x meters apart. VASI light bars
are
spaced y meters apart along the length of the runway.
And
According to the U.S. Navy:
http://www.efdlant.navfac.navy.mil/Lantops_15/topics/Facilities/NAVAIR_51-50
AAA-2.PDF
see Section 003-11 for VASI, Section 003-12 for PAPI
The first (downwind) VASI bar should be 600 feet from the runway threshhold,
and subsequent bars should be 700 feet upwind.
Curtis L. Olson [EMAIL PROTECTED] said:
Norman Vine writes:
maybe this would help
http://www.faa.gov/aim/Chap2/aim0201.html#2-1-1
That gives a good overview of how the VASI works from a pilot's
perspective, but it still doesn't show exactly how the vasi bars are
positioned relative the
Duh, wrong mailinglist.
Erik
---BeginMessage---
Hi,
I was just thinking;
Does somebody have some spare time to design a FlightGear Aircraft Paint
Scheme? This could be usefull for de-politicalizing FlightGear (and it
is just fun to have).
Erik
---End Message---
36 matches
Mail list logo
