Hi David
From: David Megginson writes
Innis Cunningham wrote:
Anything I ever saw in 707's thru to 767's looked pretty rock
solid to me. But I may be wrong.
It may have been driven by an FMS in that case, which would be taking input
from INS, LORAN, DME, GPS, etc. What's your experience in thos
Found the solution.
When the client is shutdown the server netChannel
still thinks the connection is valid and has a handle != -1. This causes
a SIGPIPE errors on a send or recieve making an assert to fail. To avoid
this problem MSG_NOSIGNAL is passed into the send or recv with this
descrip
Hi David
From: David writes
> From what I can see on the T38 the only thing that moves without being
> adjusted is
> the deviation bar.I dont see any pointer moving as I fly around a radio
> station
Actually, the needle *should* stay still if you fly a circle around a
station.
If you fly in som
> Reminds me of the time I was 4 years old and flying in a Catalina and
Are you serious? I'm jealous. One of my favorites.
> went looking for the bathroom, because of course, all airplanes have
> bathrooms (something I was very convinced of when I was 4.)
Did it?
___
David Culp writes:
> I brought my son to work for a day, and he had a wonderful time.
>
> http://home.comcast.net/~davidculp2/kidsday.jpg
Reminds me of the time I was 4 years old and flying in a Catalina and
went looking for the bathroom, because of course, all airplanes have
bathrooms (something
Paul Surgeon writes:
> On Wednesday, 3 December 2003 01:19, Curtis L. Olson wrote:
> > Right now we just yell at people (semi-randomly) who we think might be
> > using up too much texture RAM. :-)
>
> I suppose the people who have 64MB video cards start yelling before the ones
> with 128MB video
On Wednesday, 3 December 2003 01:19, Curtis L. Olson wrote:
> Right now we just yell at people (semi-randomly) who we think might be
> using up too much texture RAM. :-)
I suppose the people who have 64MB video cards start yelling before the ones
with 128MB video cards.
Using sound levels to guid
I'm going to have nightmares, now. :-)
Jon
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David Culp
> Sent: Tuesday, December 02, 2003 10:14 PM
> To: flightgear-devel
> Subject: [Flightgear-devel] (OT) Kid's day at work
>
>
> I brought my son to
Oh, now that is just PURE EVIL. Funny, but evil just the same ;)
On Tuesday, December 02, 2003, at 10:13PM, David Culp <[EMAIL PROTECTED]> wrote:
>I brought my son to work for a day, and he had a wonderful time.
>
>http://home.comcast.net/~davidculp2/kidsday.jpg
>
>Dave
>--
>***
I brought my son to work for a day, and he had a wonderful time.
http://home.comcast.net/~davidculp2/kidsday.jpg
Dave
--
David Culp
davidculp2[at]comcast.net
___
Flightgear-devel mailing list
[
Melchior FRANZ <[EMAIL PROTECTED]> said:
> * Jim Wilson -- Tuesday 02 December 2003 22:49:
> > Just keep the overlap down to about 1 pixel width on the edge and you should
> > have no trouble. In other words use a crescent shape instead of a disc for
> > the rotor shadow.
>
> Sorry, but I'm afra
On Tue, 02 Dec 2003 20:40:51 -0500
Norman Vine <[EMAIL PROTECTED]> wrote:
> Seamus Thomas Carroll writes:
> >
> > On the client side I thought about using netChannel::close to inform the
> > server that the socket is closed but the function is never
> > called. netChannel::close is called in t
Seamus Thomas Carroll writes:
>
> I put a cerr << "delete globals" << endl; where you have "delete globals;"
> in the code below and when I exit flightgear "delete globals" is not
> printed. Does the same happen for you?
oops that what I get for not testing code suggestions
we are exiting fro
I put a cerr << "delete globals" << endl; where you have "delete globals;"
in the code below and when I exit flightgear "delete globals" is not
printed. Does the same happen for you?
Seamus
On Tue, 2 Dec 2003, Norman Vine wrote:
> Seamus Thomas Carroll writes:
> >
> > On the client side I
Seamus Thomas Carroll writes:
>
> On the client side I thought about using netChannel::close to inform the
> server that the socket is closed but the function is never
> called. netChannel::close is called in the clients destructor but the
> destructor is never called because FGGlobals *global
Hi,
I have got the netChannel figured (thanks Bernie) out and the server is
accepting multiple
clients. The problem is if a client flightgear program is shut down the
server still tries to send it information and the server crashes. I tried
using netChannel::isConnected() but it returns true
David Megginson writes:
>
> Paul Surgeon wrote:
>
> > A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
> > would require about 311 GB of storage space using S3TC compression with a
> > texture resolution of 1 meter/pixel.
>
> Probably half, that, actually, since a lo
> > A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
> > would require about 311 GB of storage space using S3TC compression with a
> > texture resolution of 1 meter/pixel.
You can buy 320MB of hard disk space for a mere USD 275 (GBP 160) if you shop
around. What sounds
Paul Surgeon wrote:
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
would require about 311 GB of storage space using S3TC compression with a
texture resolution of 1 meter/pixel.
Probably half, that, actually, since a lot of the trip is over ocean.
All the best,
Dav
Curtis L. Olson wrote:
I would recommend using even smaller sized textures if you can.
Right -- keep it to 64x64 or 64x32 whenever possible. There will be some
special cases (such as the Statue of Liberty or Big Ben) where we want a
more detailed texture, so going light on other buildings saves
On Tuesday 02 December 2003 22:19, Melchior FRANZ wrote:
> * Jim Wilson -- Tuesday 02 December 2003 22:49:
> > Just keep the overlap down to about 1 pixel width on the edge and you
should
> > have no trouble. In other words use a crescent shape instead of a
disc for
> > the rotor shadow.
>
> So
Paul Surgeon writes:
> Is there any "guide" to creating scenery models for FlightGear?
>
> What is the max recommended texture size?
> I'm using 128x128 pixels (without alpha channel/mask) which means 100 unique
> models in a single scene would use less than 5 MB of video memory.
I would recomme
* Jim Wilson -- Tuesday 02 December 2003 22:49:
> Just keep the overlap down to about 1 pixel width on the edge and you should
> have no trouble. In other words use a crescent shape instead of a disc for
> the rotor shadow.
Sorry, but I'm afraid I don't understand. :-)
The effect that I don't kn
Melchior FRANZ <[EMAIL PROTECTED]> said:
> * Maik Justus -- Monday 01 December 2003 19:25:
> > looks good. Maybe someone could add this to the bo105? (Melchior?)
>
> Yes, I had it on my TODO list all the time. But I'll schedule
> it for this week. I'm not sure, however, if having both fuselage
>
Simon Hollier writes:
> With gcc3.2.2(Redhat 9), I had to rescope t[T]wy_list_iterator to
> compile :
Oops, thanks for posting the fix, bit of an embarassing one that!
Another Linux gotcha I've found - Ctrl+L doesn't work to toggle the taxiway
centerlines on or off but grows the taxiways lengthw
* Maik Justus -- Monday 01 December 2003 19:25:
> looks good. Maybe someone could add this to the bo105? (Melchior?)
Yes, I had it on my TODO list all the time. But I'll schedule
it for this week. I'm not sure, however, if having both fuselage
=and= rotor shadow will be possible in an acceptable
Is there any "guide" to creating scenery models for FlightGear?
What is the max recommended texture size?
I'm using 128x128 pixels (without alpha channel/mask) which means 100 unique
models in a single scene would use less than 5 MB of video memory.
Is each model unit equal to one meter in FG?
On Tue, 2003-12-02 at 12:33, David Luff wrote:
The latest version of TaxiDraw is now up at:
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-w32bin.zip
- Windows Binary (statically linked) [322K]
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-src.tar.gz
- source and makefile f
Erik Hofman wrote:
Andy Ross wrote:
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
Hmm the problem of Nasal getting into an endless loop still exists.
Andy Ross <[EMAIL PROTECTED]> wrote:
> Oliver C. wrote:
>> Does dumping plib mean that we can choose something like the SDL
>> library for the OpenGL initialization?
> No, that means dumping glut. Earlier plib versions had a glut
> dependency, but I believe that has been removed from current vers
[Heh, this turned out longer than I expected when I started writing...]
Curtis L. Olson wrote:
> I would recommend doing a net search for CLOD (continuous level of
> detail) and ROAM (I forget what that stands for.) There are a lot of
> spiffy demos out there. However, there are some non-trivial
Andy Ross wrote:
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
Hmm the problem of Nasal getting into an endless loop still exists. At
first I only ha
Curtis L. Olson wrote:
I would recommend doing a net search for CLOD (continuous level of
detail) and ROAM (I forget what that stands for.)
Real-time Optimally Adapting Meshes.
--
Russ
Conway's Law: "The structure of a system tends to mirror the
structure of the group producing it."
-- Mel
On Tuesday, 2 December 2003 19:15, Curtis L. Olson wrote:
> If a person is working on some feature that won't be finished for 2
> years, then I think it is reasonable to try to predict card
> performance that far out and write to future hardware. In large part,
> that is what we did when we starte
Russell Suter wrote:
Curtis L. Olson wrote:
I would recommend doing a net search for CLOD (continuous level of
detail) and ROAM (I forget what that stands for.)
Real-time Optimally Adapting Meshes.
Sorry forgot the page:
http://www.cognigraph.com/ROAM_homepage/
--
Russ
Conway's Law: "The s
Innis Cunningham wrote:
Anything I ever saw in 707's thru to 767's looked pretty rock
solid to me. But I may be wrong.
It may have been driven by an FMS in that case, which would be taking input
from INS, LORAN, DME, GPS, etc. What's your experience in those planes?
There is no way to get direc
Andy Ross wrote:
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
So, you got me FlightGear crashing every time I use the bo105?
;-)
It's fixed, thanks.
E
On Tuesday 02 December 2003 18:15, Curtis L. Olson wrote:
> > Ok, do you know any good documentation and information about this
> > particular real time rendering topic. That doesn't mean that i will
> > write such an engine, but i just want to read the basic stuff so
> > that i know what i am ta
The latest version of TaxiDraw is now up at:
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-w32bin.zip
- Windows Binary (statically linked) [322K]
www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-src.tar.gz
- source and makefile for Linux [56K], requires wxGTK-dev.
Summary of chang
[EMAIL PROTECTED] writes:
> On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote:
> >
> > > But when the data is allready in the RAM we wouldn't need
> > > to load the data from the slow hard drive.
> >
> > Right, but sending that much data across the AGP bus isn't fast
> > either, especially
> From what I can see on the T38 the only thing that moves without being
> adjusted is
> the deviation bar.I dont see any pointer moving as I fly around a radio
> station
Actually, the needle *should* stay still if you fly a circle around a station.
If you fly in some path other than that, then
[EMAIL PROTECTED] writes:
> On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote:
> > Gene Buckle writes:
> > > > Unfortunately, plib (our scene graph engine) doesn't support
> > > > multitexturing at this point in life. :-(
> > >
> > > From what I've read, this isn't the only thing it doesn't
On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote:
>
> > But when the data is allready in the RAM we wouldn't need
> > to load the data from the slow hard drive.
>
> Right, but sending that much data across the AGP bus isn't fast
> either, especially when you want/need to draw at 60hz. Sur
Gene Buckle writes:
> I can imagine this would be a complex undertaking, but wouldn't it be the
> best solution in the long run?
Sure, and it's on the todo list (or to investigate list) somewhere.
However, there is always a significant time shortage.
> If it would be easier, why not just fork pli
David Culp writes>
>
Assuming the T-38 in the base package is reasonably current, the VOR needle
works well, as far as I can tell. Make sure you set the radio:
From what I can see on the T38 the only thing that moves without being
adjusted is
the deviation bar.I dont see any pointer moving as
On 09:56 Tue 02 Dec , Curtis L. Olson wrote:
> This is something that has been considered, but it will be a massive
> amount of work to do this and preserve all the existing functionality.
>
> Massive might be slightly overstated, but it probably means tearing
> everything down and rebuilding
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
Andy
+++ props.nas 2 Dec 2003 16:25:49 -
@@ -33,10 +33,10 @@
# Static constructor. Accepts a has
Oliver C. wrote:
> Does dumping plib mean that we can choose something like the SDL
> library for the OpenGL initialization?
No, that means dumping glut. Earlier plib versions had a glut
dependency, but I believe that has been removed from current versions.
We can keep the plib parts that we use
> Maybe David Culp with his everyday experence could enlighten
> us here.
Assuming the T-38 in the base package is reasonably current, the VOR needle
works well, as far as I can tell. Make sure you set the radio:
--prop:/radios/nav[1]/frequencies/selected-mhz[0]=115.8
The VOR needle instrum
On Fri, 2003-11-28 at 17:46, Julian Foad wrote:
> Matthew Law wrote:
> >
> > Speaking of which, would it be possible to change the texture above a
> > certain height AGL? We could have a texture with more detail for low
> > altitudes and a shinier, more gaussian texture for higher altitudes...
>
> Gene Buckle writes:
> > >
> > > Unfortunately, plib (our scene graph engine) doesn't support
> > > multitexturing at this point in life. :-(
> > >
> >
> > From what I've read, this isn't the only thing it doesn't support that
> > would make life easier for you guys. Why not just dump it for a sc
On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote:
> Gene Buckle writes:
> > > Unfortunately, plib (our scene graph engine) doesn't support
> > > multitexturing at this point in life. :-(
> >
> > From what I've read, this isn't the only thing it doesn't support that
> > would make life easie
Hi David
David Megginson writes
Curtis L. Olson wrote:
Looking in the code, if I understand your request correctly, you may
want:
/radios/nav[%d]/radials/actual-deg
No, that is not the right solution. What he needs is a delta between the
inverse of the current VOR radial and the indicated he
Curtis L. Olson wrote:
Looking in the code, if I understand your request correctly, you may
want:
/radios/nav[%d]/radials/actual-deg
No, that is not the right solution. What he needs is a delta between the
inverse of the current VOR radial and the indicated heading on the RMI,
normalized to
Thanks Curt
"Curtis L. Olson" writes
Ok, so this sounds less like a bug report with the current VOR's and
more of a feature request so you can impliment more complex
instrumentation, right?
That is correct
Looking in the code, if I understand your request correctly, you may
want:
/radios/nav[%
Gene Buckle writes:
> >
> > Unfortunately, plib (our scene graph engine) doesn't support
> > multitexturing at this point in life. :-(
> >
>
> From what I've read, this isn't the only thing it doesn't support that
> would make life easier for you guys. Why not just dump it for a scene
> graph lib
Innis Cunningham writes:
> Yes I have got that system working perfectly.But what the list either
> does not know or does not understand is that in commercial aviation
> and probably many other areas they have what is called a RMI or ADF
> VOR guage and on such guages there is two needles one for VO
>
> Unfortunately, plib (our scene graph engine) doesn't support
> multitexturing at this point in life. :-(
>
>From what I've read, this isn't the only thing it doesn't support that
would make life easier for you guys. Why not just dump it for a scene
graph library that does the job you need it
Thanks Curt
"Curtis L. Olson writes>
>
Can you report a specific location, heading, frequency, altitude,
etc. where you see a problem?
Everywhere. see below for details
Based on your description of the problem, you might not be aware that
the VOR needle does not point to the VOR station. Instead
[EMAIL PROTECTED] writes:
> > 1. Threre is a big difference between having texture data loaded into
> > main RAM vs. having the texture data loaded into your cards video
> > RAM. (There are probably a few exceptions, the only one I can
> > think of at the moment is the sgi O2 which ha
Oliver C. wrote:
> Couldn't we load the whole data into RAM before?
> 1 GB Ram are cheap today.
It's not nearly that simple. If you want to draw something on the
screen, it has to get into the video card's memory at some point
during the frame. Even 256MB Übercards are going to thrash* with a
1G
On Tuesday 02 December 2003 13:57, Curtis L. Olson wrote:
> [EMAIL PROTECTED] writes:
> > Couldn't we load the whole data into RAM before?
> > 1 GB Ram are cheap today.
>
> 1. Threre is a big difference between having texture data loaded into
> main RAM vs. having the texture data loaded into
Curtis L. Olson writes:
>
> Andy Ross writes:
> > That was my thinking when I started, too. But your math is a little
> > off. Getting to a worst case resolution of 1 texel per screen-space
> > pixel with unique texturing requires *vast* amounts of memory.
Yup, I doubt if we get to the 1 texel
Paul Surgeon wrote:
Yeah that's because the scenery is pre-rendered. Who said we have to
pre-render the scenery? :)
Rendering in real time would only require a library of geodata which would be
similar in size to the current FG scenery.
In that case, it wouldn't look like TerraScene scenery --
[EMAIL PROTECTED] writes:
> On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote:
>
> > My understanding of systems that impliment these basic ideas is that
> > step 1) is to give up the idea of seamless, non-blurry textures in the
> > distance. Every system I have seen blurs the textures exc
Innis Cunningham writes:
> Hi Guys
> I know this has been discussed before but the VOR pointer
> seems to malfunction.Sometimes 180 deg to the station sometimes
> 90deg and sometimes anywhere.
> I am using the property radios/nav/radials/actual-deg.
> There is a property for the ADF called needle-
On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote:
> My understanding of systems that impliment these basic ideas is that
> step 1) is to give up the idea of seamless, non-blurry textures in the
> distance. Every system I have seen blurs the textures excessively as
> you go further in the
Hi Guys
I am in the process of making some 2D panels and am wondering
if it would be possible to do some things.
1 Would it be hard to change the background texture so it is in the
foreground. That way all the instruments the parts like an enlarged
compass rose that would stick out the side and bo
Hi Guys
I know this has been discussed before but the VOR pointer
seems to malfunction.Sometimes 180 deg to the station sometimes
90deg and sometimes anywhere.
I am using the property radios/nav/radials/actual-deg.
There is a property for the ADF called needle-deg this property
works perfectly.The
69 matches
Mail list logo
