[Flightgear-devel] Next world scenery build

2005-12-20 Thread Curtis L. Olson
In case anyone is wondering, I just wanted to let you all know that I am 
indeed working on the next world scenery rebuild.  I am maintaining a 
little blurb on my home page with status updates and ETA's for those 
that are really keen on tracking my progress.


This next world scenery build will include SRTM2 data.  In the USA I 
have filled the srtm voids from the USGS DEM data, outside the usa, I 
simply interpolate across the voids because there are no other detailed 
data sources generally available.  I have done quite a bit of (subtle) 
work on the airport generator code and there have been a few other bug 
fixes along the way as well.  Right now I am processing the vmap0 - 
shapefile conversion data.  Now that our basic land use/land cover data 
is in shapefile format, the hope is that we will be able to use more 
common tools to fix and update the data for specific locations.  This 
build will also have all the latest objects from Jon's object database.  
My goal is to have everything done (for this round) by Jan 1 of the new 
year.  But I reserve the right to push that date back in case I run into 
any new glitches.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Next world scenery build

2005-12-20 Thread Curtis L. Olson

Vassilii Khachaturov wrote:


Thanks! Don't forget to take the rest on the seventh day of the world
creation :-)
 



As I go through the process of world modeling, it become very clear that 
God is God and I am not even close! :-)  It gives me a renewed 
appreciation for the immensity, complexity, beauty, and variety of our 
little Earth and it's surroundings.  I don't feel so bad about the FG 
scenery shortcoming when I consider who I'm competing against. :-)


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] b1900d logo

2005-12-20 Thread Curtis L. Olson

Jean-Yves Lefort wrote:


As far as I know, rotation speed with no flaps and a service payload
is about 105/110 kts. I could lift it at that speed some weeks ago,
but some changes in the yasim code and/or in the b1900d.xml file
caused a regression.
 



Looking back through CVS, I think the big change was that the fuel load 
got doubled.  If you cut the fuel down to about 2000 lbs total I think 
the aircraft will return.


I made a small change to the config file so the aircraft lift/drag 
solution is computed at 80% fuel capacity rather than 20% fuel capacity 
... this makes a huge difference in bringing the numbers back closer to 
what I'd expect.  This is a WAG though ... we need to find a POH and 
start double checking stall speed and climb performance numbers to make 
sure we are in the right ball park here.  I hate to guess too much.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] OT: Flightdeck UI

2005-12-20 Thread Curtis L. Olson
This is a bit off topic, but I know there are a few sysadmin/unix 
weenies that hang out here (myself included) so this might be of 
interest to a few people.


Flightdeck-UI is an open source/free software project that utilizes the 
ideas in aircraft controls and instruments design for creating general 
purpose user interfaces.


http://www.openlight.com/fdui/

That's intriguing in and of itself.  From the screeshots 
(http://www.openlight.com/fdui/screens.html) and demo 
(http://www.openlight.com/fdui-panels/) it appears to be most useful as 
a system (or multi variable) monitoring tool.


I'm not sure if it's poised to knock KDE/Gnome off the top of the heap, 
but it's an interesting project.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Next world scenery build

2005-12-20 Thread Curtis L. Olson

Paul Surgeon wrote:


We're still stuck not being able to model airports properly.
TaxiDraw is a great tool but I really don't like being limited to rectangular 
taxiway sections - they look awful.


I started playing with the idea of modeling them as a 3D model in Blender and 
sticking that into the terrain instead. Yes it's a lot slower but you can get 
things spot on like the real thing. A few decent, well known airports would 
be nice in FG. I'm sure Curt would love to include a few dozen of them 
everytime he does a scenery rebuild. :P


What would be really helpful though is a way to snap the vertices of the 
terrain in fgsd to the vertices of a placed model to eliminate seams or a way 
of converting a 3D model to one of those special binary model files that the 
airports are in. (*.btg.gz)


In the long term an automatic airport slicer/cutter would be the best option.
Pre-generate or generate an airport on the fly and cut and stitch it into the 
underlying terrain at run time.
 



Hi Paul,

We have had past discussions about making FG specific extensions to the 
X-Plane airport format and possibly maintaining the extra data 
ourselves.  Curved taxiways is very high on that list, as well as some 
(yet to be determined) way to lay down arbitrary taxiway and hold short 
markings on top.


That won't let you do every thing you want to do, but could be a big 
step in the right direction and make future airport building better and 
faster.  (If you haven't noticed, I like to concentrate my effort on the 
db/algorithms side of life, rather than the one-off hand modeling side 
of life.)


In terms of matching airport cutouts, you could provide an exact hole to 
the terragear scenery builder and it would honor that and leave that 
exact hole cut out of the scenery.  There are some issues when a hole 
crosses tile boundaries, you might get some transformation/math errors 
so your points end up being up to a pixel off (from frame to frame) in 
the tiles that don't own the airport object.  One idea to work around 
this problem is to build small skirts around the airport and the 
cutout.  That hides the gaps pretty well if both sides have skirts.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] NOTIFICATION: List server change!!!

2005-12-20 Thread Curtis L. Olson

Please read this message carefully!!!

It applies to YOU!  (and to everyone else involved in the FG project.)

In order to balance resource usage, I am moving the FlightGear mailing 
lists to SourceForge.  (http://www.sourceforge.net)  You do not have to 
be a registered sourceforge user to use the sourceforge mailing lists, 
you can participate with any valid mailing address.


You will be automatically unsubscribed from the 
[EMAIL PROTECTED] mailing lists (very soon), and automatically 
subscribed to the corresponding [EMAIL PROTECTED] mailing lists 
(this is happening now.)  This might be a good time to evaluate which 
lists you want to be subscribed to (or not) and update your subscription 
options.


If you have receive/don't receive options and digest options enabled for 
your flightgear lists, you will have to manually set these options 
yourself on the new lists.


If you have any problems or questions, please ask.  We are trying to 
make this switch-over as seamless and as painless as possible, but there 
are bound to be small glitches here and there.


If you recently subscribed or unsubscribed to any of the FlightGear 
lists, please check to make sure that you are on/off the corresponding 
source forge lists.  I have made every attempt to catch everyone, but I 
know a couple of the most recent subscribes and unsubscribes will be missed.


Thanks for your patience, cooperation, and understanding as we make this 
move to a new list server.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] FlightGear vs. Reality

2005-12-19 Thread Curtis L. Olson

kitts wrote:

The videos are really cool! Just one question... Did you have to do a lot of 
adjustment for the synthetic and reality to match? Except fr maybe the FOV 
and the angle in the synthetic view.
 



We haven't spent much time calibrating the two.  My brother did the 
video editing and I think he slid things around just a bit to get them 
to line up a little closer ... that could be avoided if we spent 10 
minutes calibrating the synthetic view to the camera.


I am particularly interested in the timing (Latency etc.). Did the two 
appear similarly in real time during flight?
 



The do appear similarly in real time ... however, our real time data 
link has some issues where it drops packets.  So in real time the 
synthetic view is somewhat jerky, even though it averages 20fps seconds 
... these come in bursts.  When replaying the data for video purposes, 
we can interpolate through the gaps and make the video much smoother.  
That's sort of cheating I guess (well except that we readily admit to 
it.) :-)


I am curious to know what hardware you use. A newer version of the onboard 
hardware i am working on is currently out for PCB fabrication. This UAV 
business is so exciting! ;-)
 



We have a MIDG-II IMU/INS/GPS which we hope to replace soon with an xbow 
integrated gps/imu/ins/autopilot.  Our wireless serial connection is 
with aerocomm radio modems which we are currently unhappy with.  Video 
is done with Black Widow AV equipment.  Aircraft is a Rascal 110 (110 
wing span.)


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] FlightGear vs. Reality

2005-12-18 Thread Curtis L. Olson
I've posted a few little blurbs about the UAV project I'm involved in, 
so here's another one.


First a word of explanation.

We have an R/C plane with a camera looking 45 degrees down.  The 
airplane also has an expensive sensor that spits out location (lon, lat, 
elevation) and attitude (pitch, roll, yaw).  We have a radio modem 
(wireless serial link) to feed the location/attitude data to the ground 
in real time.  We had a coworker build a photoreal 3d model of our small 
flying area.  Armed with all that we can use FlightGear to show a live 
synthetic view of the UAV.  We can configure the flightgear camera view 
to closely match the real live video camera view.  We have also have a 
video transmitter onboard so we can play the live video + the live 
synthetic view side by side in real time on the ground.  I can't exactly 
show you that, but we do have recordings of both streams that my brother 
edited together into 'web' movies.  My other brother then converted them 
to DivX6 for me.  DivX6 can by played by many open-source movie players 
such as mplayer or xine.  Or there is a free windows media player plugin 
available here:  http://www.free-codecs.com/download/DivX6.htm


The two movies are 50Mb each so they are kind of large.  The first movie 
shows the two views side by side.  The second movie has the real view 
overlayed on top of the synthetic view, blended together.  The second 
movie is my favorite of the two.


One more bit of explanation.  The accuracy of the synthetic view is 
obviously very dependent on the accuracy of our location/attitude 
sensor.  The yaw estimate of our sensor at the beginning of the movie is 
many degrees off, but after a minute or two, it locks on pretty 
closely.  (Note that it eventually gives accurate aircraft heading 
independent of wind or ground track.)  Also you can see places where our 
ground based antenna aimer got lazy and the video fuzzes out, but in 
those cases you still have the synthetic view to fly from.


So here are the video links:

http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/chapt1-divx6.avi
http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/chapt3-divx6.avi

They are about 8-9 minutes each.  Oh and for all the info I have 
available on this project, you can visit my 'unofficial' project page here:


http://www.flightgear.org/~curt/Models/Special/Rascal110_2/

Finally, Lee is building a FlightGear version of this same aircraft so 
hopefully before too long it will be flyable in FlightGear (using one of 
FG's built in flight dynamics engines.)  We have a programmable 
autopilot purchased for this airplane (but not yet installed/running.)  
We are hoping to port FlightGear's PID algorithm to our flight computer 
and hopefully then we can use FG to tune our PID loops (and if we don't 
immediately crash we will definitely be bragging about it.) :-)


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Slashdot: Seasons Givings

2005-12-18 Thread Curtis L. Olson

There is an article on slashdot this evening called Season's Givings.

http://ask.slashdot.org/askslashdot/05/12/18/1453256.shtml?tid=105tid=95tid=4

I feel I must respond because I know that many (if not all?) of you read 
slashdot, and in this season of new hope and giving you might see this 
article and be overwhelmingly tempted to donate something to the 
FlightGear project. :-) 

FlightGear is itself a gift from the flightgear developers, so instead 
of giving to the givers, I encourage you all to set your sites on the 
needier and worthier causes (not just now, but throughout the year.)


We all watch the news and are aware of the many different issues around 
the world where there are people in desperate need of even the simplest 
basic things to survive.  But I (and I suspect many others) get so 
caught up in our day to day stress and struggles that it is really easy 
to lose sight of anything beyond our own little scope of reality.  So 
here's a little reminder and encouragement to those that care about the 
world, to maybe take stock of what you've given in the past year, and 
think about what you might give in this next year, and where you might 
give it most effectively.


Seasons greetings from the Olsons. :-)

http://www.flightgear.org/~curt/images/xmas-2005.jpg

P.S. I can still photoshop out most of my gray hair ... :-)

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Wing motion

2005-12-18 Thread Curtis L. Olson

Jon S. Berndt wrote:


Here's one I'm throwing out simply for discussion, and because it's occurred
to me several times in the past:

Would it be possible to change the visual appearance of wing flex during
flight? I thought it might be interesting to give the wing an amount of flex
dependent on load factor and wing stiffness, etc.  I've got some simple
equations in my old aeroelasticity textbook that might provide a simple
enough algorithm.

Just a thought...
 



Check out the ornithopter in action.  The basic ideas is you draw a 
couple different versions of the wing and then use the FG animation 
system to pick the appropriate one that corresponds to the current 
load.  Or you could hinge the wing sections and animate it that way.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Options saving patches

2005-12-17 Thread Curtis L. Olson

Melchior FRANZ wrote:


Either the 1.0 number means anything, then fgfs better be complete.
Or it doesn't mean anything, then let's release it when it's done
and call the next releases 0.9.10++.

Or is there a compelling reason to rush out 1.0 *now*? One that we
aren't told for whatever reason? Does anyone pay for it whose
business depends on it? (MathWorks?) Or is it that fgfs needs for
some reason to be called 1.0.0 for SCALE 2006? And why? Other
reasons? Do we deserve to know about them? Doesn't look like it.

I'm now sufficiently fed up with the secret 1.0 agenda, that I'll
stop contributing until after this monstrosity is out.
 



Huh!?!  We are making a huge controversy over the difference of plus or 
minus 0.0.1


Maybe we should drop the arbitrary version numbering scheme (and I do 
see the version numbers as 99.9.9% arbitrary) and go with code names for 
our releases.  Would that make people happier?


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Options saving patches

2005-12-17 Thread Curtis L. Olson

Paul Surgeon wrote:


On Saturday 17 December 2005 13:40, Erik Hofman wrote:
 


Melchior FRANZ wrote:
   


Sorry to be annoying yet again, but that's what I'm best at:

* Erik Hofman -- Saturday 17 December 2005 10:48:
 


I must say I like the idea, but given it's current state (no windows
support) I would like to postpone it until after FlightGear 1.0 is
released.
   


And I would like to postpone the 1.0 release, until FlightGear is ready
to be called 1.0.
 


What's this, now you want releases that have missing options for some
OS'es??
   



No, that's not what Melchior implied or said at all.
What he said is that he would prefer if we hold off with ANY 1.0 release until 
FG is ready to be called version 1.0.

He didn't mention any OS's in an exclusion list did he?

 


Give me a patch and I'll commit it, until then there's little room for
discussion.
   



So in other words all the developers, we're going to release 1.0 whether 
they like it or not because you or Curt say so?!


I thought this was a community project but I was clearly wrong.
It would appear that we have zero say over this matter and even less chance of 
getting any honest answers from either you or Curt.



 


I'm now sufficiently fed up with the secret 1.0 agenda, that I'll
stop contributing until after this monstrosity is out.
 


Lighten up, I just started looking at this patch since Fred promised to
fill in the missing gaps.
   



I would also like to know what this urgency for a 1.0 release is but all we 
get are answers that skirt the issue or no answers at all.
 



Look, if we took half the time that we spend worrying about arbitrary 
version numbers and spent it developing code and fixing bugs, we'd be at 
v2.0 by now.  I'm sorry that some people get so bent out of whack over 
something so arbitrary, but I know that we just aren't going to make 
everyone happy all the time.  There's no grand conspiracy here, no 
secrecy.  Let's keep it clean here, there may be children in the room.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Options saving patches

2005-12-17 Thread Curtis L. Olson

Paul Surgeon wrote:

No what would make us more happy is to know why there is such an urgency to 
have two FG releases in the space of a couple of months when up till now 
we've been releasing about once per year.

What has prompted this change?

This decision didn't involve the developers at all.
Not even a guys what do you think about having another release in January 
that just contains bug fixes?


Are we changing to a frequent release cycle or what?
When will the next release be after 1.0? March or April?
 



Look, rolling out a new release is a massive effort.  We need to do a 
release more than once a year.  But my time can be very limited 
depending on what other paying projects I'm involved with during the 
year.  So I try to find a balance between a new release date that is 
appropriate for the project and my available time.


Discussing this with the development community is ok, but at the end of 
the day, I have to pick a time that matches my personal schedule, 
otherwise there will be no release at all.  And we need releases, just 
like we need to invite people over to our homes ... sometimes that's the 
only way certain messes will get cleaned up.


If you want to pay me a fair salary, then you would be most welcome to 
tell me how and when to spend my time doing whatever it is you want me 
to do.  Until then, I need to make my own decisions that strike the best 
balance I can come up with between the needs of this project and the 
needs of my family and jobs.  That means there are external constraints 
to the flightgear release schedule that discussion on the list has no 
affect on.


It's not a perfect world, so I'm sure you and others have and will 
continue to have plenty to complain about.  But I'm getting really sick 
of hearing about version numbers so this is my last message on the topic 
for a while.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Freeglut and game mode

2005-12-15 Thread Curtis L. Olson
I have an application here where I need (a) to build with glut/freeglut 
and (b) I need to go full screen with no window decorations or portions 
of the desktop visible.


(a) I need to run this on a multiheaded system and SDL completely blanks 
and locks out the second display when you run fullscreen.
(b) this is for a full cockpit flight simulator so the only thing I want 
to see in the display monitors is the FG imagery.


In the past with Debin and Glut, specifying --enable-game-mode has 
always worked for me as expected.  But now I'm trying to do the same 
thing with freeglut-2.2.0 and Fedora Core 4.  No matter what 
--geometry=WxH and --bpp=D values I specify, I always get a 640x480 
window with a window title and a portion of the desktop visible.


Is gamemode just broken in freeglut-2.2.0?  Has anyone had this working 
with freeglut?  I would have thought we would get a lot of complaints if 
something this basic didn't work?


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Freeglut and game mode

2005-12-15 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Curtis L. Olson -- Thursday 15 December 2005 19:21:
 

In the past with Debin and Glut, specifying --enable-game-mode has 
always worked for me as expected.  But now I'm trying to do the same 
thing with freeglut-2.2.0 and Fedora Core 4.
   



Don't know if it has anything to do with it:

 
http://mail.flightgear.org/pipermail/flightgear-cvslogs/2005-November/011451.html

Maybe your glut doesn't understand the preferred format.

I run fgfs with SDL, but not with the built-in fullscreen mode,
but manually set to screensize. And I tell my window manager to omit
the window decoration. Don't know if this works with multiscreen.
 



I did some googling and poking around the freeglut mailing list and it 
does appear that freeglut's game-mode (fullscreen) is simply broken.  
There was a reference to OpenGLUT and it sounded like that may be seeing 
more development than freeglut?  I don't track those projects closely so 
I don't know.


sigh

I found some original glut-3.7 rpms, installed those and everything 
works great.  Bye, bye freeglut. :-)


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] panel only

2005-12-15 Thread Curtis L. Olson

Bruce Benneke wrote:

Can anybody tell me how to disable the exterior view?  I have one 
system running just the 2d panels (working on a couple of custom 172 
panels, with hopefully some updated gauges/instruments), and anther 
running the exterior view(and the FDM).

I really have no need to have the exterior view on the panel system.



Hi Bruce,

Try adding this option to your ~/.fgfsrc or the command line:

--prop:/sim/rendering/draw-otw=false

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Freeglut and game mode

2005-12-15 Thread Curtis L. Olson

Stefan Seifert wrote:


Curtis L. Olson wrote:

Is gamemode just broken in freeglut-2.2.0?  Has anyone had this 
working with freeglut?  I would have thought we would get a lot of 
complaints if something this basic didn't work?


I always thought that this was a well known limitation of gamemode in 
FG, so never asked. Did always get 640x480 so I'm using 
fullscreen-mode now.



I have verified that glut game mode works great with the original 
glut-3.7, but it's horribly broken in freeglut. 


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Freeglut and game mode

2005-12-15 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Curtis L. Olson -- Thursday 15 December 2005 21:06:
 

I have verified that glut game mode works great with the original 
glut-3.7, but it's horribly broken in freeglut. 
   



Keyboard handling is also broken in freeglut. That's why I'm using
SDL. (I don't like unfreeglut :-).
 



I'd be using SDL here too if it didn't blank and lockout all the 
secondary displays in a multiheaded system. :-(


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Freeglut and game mode

2005-12-15 Thread Curtis L. Olson

Bruce Benneke wrote:


I take it you got multiheaded working with glut 3.7 on FC4?



I haven't actually configured the multiheaded stuff on FC4.  I have done 
this with glut3.7 and an older version of Debian and didn't encounter 
any surprises.


I'm having general issues with my FC4 box, and haven't got around to 
trying multiheaded yet...

so for multiheaded systems in general
SDL --- blanks second monitor?



I should clarify that SDL in 'fullscreen' mode blanks the second monitor 
and locks the mouse to the first display.



freeglut ---just doesn't work?



Freeglut's gamemode/fullscreen support is badly broken.


glut 3.7 --- ok?



glut-3.7 works great.


Openglut ---?



No idea, hadn't even heard of it before today and have never tried it.

Any other solutions/ideas?  I'm not at this stage yet with my project, 
but will be soon



I'm not expecting any issues with glut-3.7 on FC4 ... should I be?

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] New segfault [bug] activating mini-panels (2d)

2005-12-14 Thread Curtis L. Olson
This problem affects 2d panels.  With 2d panels you can have multiple 
panel versions and switch between them with the 's' key.


Very recently FG has started generating a segfault whenever you type 's' 
to toggle to a minipanel.


This can be reproduced by starting FlightGear with --aircraft=c172p-2dpanel

Once FlightGear is up and running, type 's' to switch to the mini 
panel.  FlightGear will immediate crash.  (This was working fine up 
until a week or two ago.)


The backtrace I get is:

#0  0x08435d2d in SGSubsystemGroup::Member::update (this=0xde5f2d8,
   delta_time_sec=0.32501) at subsystem_mgr.cxx:236
#1  0x08435f80 in SGSubsystemGroup::update (this=0x979db9c,
   delta_time_sec=0.32501) at stl_vector.h:462
#2  0x08435e56 in SGSubsystemMgr::update (this=0x979db94,
   delta_time_sec=0.32501) at subsystem_mgr.cxx:297
#3  0x08051df2 in fgMainLoop () at main.cxx:495
#4  0xb7fccd20 in glutMainLoop () from /usr/lib/libglut.so.3
#5  0x08054a88 in fgMainInit (argc=2, argv=0xbf8f5bc4) at main.cxx:1007
#6  0x08050e50 in main (argc=2, argv=0xbf8f5bc4) at bootstrap.cxx:193

This indicates the crash is in simgear/structure/subsystem_mgr.cxx, line 
#236:


void
SGSubsystemGroup::Member::update (double delta_time_sec)
{
   elapsed_sec += delta_time_sec;
   if (elapsed_sec = min_step_sec) {
   if (!subsystem-is_suspended()) {
   subsystem-update(elapsed_sec);
   elapsed_sec = 0;
   }
   }
}

The specific line of the crash is when the system checks if the 
subsystem-is_suspended().


Does anyone have any ideas what may have changed recently to cause this 
crash?  This is a feature I use and need, I'm not just nitpicking the 
random segfaults I see in FG.


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)

2005-12-14 Thread Curtis L. Olson
I did some more digging and tracked down the offending subsystem.  I 
will contact the developer off line and hopefully this will be a simple fix.


Curt.


Curtis L. Olson wrote:

This problem affects 2d panels.  With 2d panels you can have multiple 
panel versions and switch between them with the 's' key.


Very recently FG has started generating a segfault whenever you type 
's' to toggle to a minipanel.


This can be reproduced by starting FlightGear with 
--aircraft=c172p-2dpanel


Once FlightGear is up and running, type 's' to switch to the mini 
panel.  FlightGear will immediate crash.  (This was working fine up 
until a week or two ago.)


The backtrace I get is:

#0  0x08435d2d in SGSubsystemGroup::Member::update (this=0xde5f2d8,
   delta_time_sec=0.32501) at subsystem_mgr.cxx:236
#1  0x08435f80 in SGSubsystemGroup::update (this=0x979db9c,
   delta_time_sec=0.32501) at stl_vector.h:462
#2  0x08435e56 in SGSubsystemMgr::update (this=0x979db94,
   delta_time_sec=0.32501) at subsystem_mgr.cxx:297
#3  0x08051df2 in fgMainLoop () at main.cxx:495
#4  0xb7fccd20 in glutMainLoop () from /usr/lib/libglut.so.3
#5  0x08054a88 in fgMainInit (argc=2, argv=0xbf8f5bc4) at main.cxx:1007
#6  0x08050e50 in main (argc=2, argv=0xbf8f5bc4) at bootstrap.cxx:193

This indicates the crash is in simgear/structure/subsystem_mgr.cxx, 
line #236:


void
SGSubsystemGroup::Member::update (double delta_time_sec)
{
   elapsed_sec += delta_time_sec;
   if (elapsed_sec = min_step_sec) {
   if (!subsystem-is_suspended()) {
   subsystem-update(elapsed_sec);
   elapsed_sec = 0;
   }
   }
}

The specific line of the crash is when the system checks if the 
subsystem-is_suspended().


Does anyone have any ideas what may have changed recently to cause 
this crash?  This is a feature I use and need, I'm not just nitpicking 
the random segfaults I see in FG.


Thanks,

Curt.




--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)

2005-12-14 Thread Curtis L. Olson

Andy Ross wrote:


Curt wrote:
 


I did some more digging and tracked down the offending subsystem.  I
will contact the developer off line and hopefully this will be a
simple fix.
   



It's much more enlightening if you embarass them publically.  Unless
it's me, of course.
 



I'll give them my usual 30 minutes grace period.  Then I'll bring down 
the hammer.  You hear that Dave, you only have 15 minutes now!


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] FlightGear for PSP??

2005-12-13 Thread Curtis L. Olson

Andy Ross wrote:


bass pumped wrote:
 


I have a wild idea I hope no one kills me for!  Its christmas and
PSP prices are a little lower (i think).  How hard would it be to
put Flightgear on a PSP.  People are already doing homebrew games on
those, ofcourse, not with very complicated graphics.  But it could
be possible could it not??
   



No OpenGL implementation -- I think it's got some sort of 3D hardware,
actually, but we'd need to rewrite all the rendering code to use it.
And then shrink all the textures so they fit in the thing's memory.
You'd probably have to remove all the interesting high-vertex-count
scenery too.

Certainly some sort of flight simulation on the thing is possible
(it's *much* faster than the box I was running FS 4.0 on in the early
90's), but I'm not convinced that porting FlightGear would be any
easier than just starting from scratch...
 



I remember discussing this before.  I don't recall all the specifics, 
but check the PSP's system memory and video memory ... I bet it's going 
to be something really small like 4Mb + 4Mb.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Net protocols

2005-12-08 Thread Curtis L. Olson

John Wojnaroski wrote:

were there any changes to envoking the network/socket connections in 
0.9.9?


this works in 0.9.8

--native-ctrls=socket,in,30,,5700,udp

but fails to start the code in FGNetCtrls2Props() with 0.9.9

Presence of control packets on the LAN has been verified as well as 
LAN integrity



Check the hardwired version number in the packet.  That will get 
incremented when the structure changes.  It's also there if you want to 
get crazy and build a system that can read the packet version and decode 
it differently for different versions.  I suspect there probably was a 
change between 0.9.8 and 0.9.9


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Help with Multiple Instances

2005-12-07 Thread Curtis L. Olson

[EMAIL PROTECTED] wrote:

Also, I got a tip concerning the views to use the --view-offset 
parameter, but I tested it out just using a command line such as:


c:\Program Files\FlightGear\bin\win32fgfs.exe --fg-root=c:\Program 
Files\FlightGear\data --view-offset=-45


and the view didn't change at all.  I tried putting the value in () 
and  but nothing worked.  Is my syntax wrong or am I leaving out a 
necessary parameter or what?  It seems pretty straight forward but is 
producing no change.  I used the --fov parameter to mess around with 
it and it worked fine, but nothing on the view offset.  Thanks
 



For setting up slaved visual channels, here are some of the options I 
have used:


--enable-game-mode (--enable-fullscreen depending on glut vs. sdl)
--prop:/sim/menubar/visibility=false
--prop:/sim/ai/enabled=false (prevents the ai ATC text at the top of the 
screen.)
--prop:/sim/ai-traffic/enabled=false (prevents strange planes from 
flying across a single view)

--prop:/sim/rendering/bump-mapping=false
--fov=35
--prop:/sim/view/config/heading-offset-deg=-35
--prop:/sim/view/config/pitch-offset-deg=3
--native-fdm=socket,in,60,,5505,udp
--native-ctrls=socket,in,60,,5506,udp
--fdm=null


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Flight Director

2005-12-07 Thread Curtis L. Olson
I'm thinking of doing some work to impliment a flight director (such as 
the bendix-king KFC 200.)  Has anyone made an AI that includes a movable 
V-bar?


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 32, Issue 22

2005-12-07 Thread Curtis L. Olson

syd wrote:

Hi Curt, the B1900D and Bravo have flight director bars as separate 
movable objects ... just waiting for a flight director :)



Perfect, thanks!  I'll take a look at those.

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] FG, opengc, generic gauges

2005-12-06 Thread Curtis L. Olson

Bruce,

There are many different ways to approach this problem.  OpenGC is good 
if you want to get into glass cockpit modeling.  But if you want to 
stick to traditional steam gauges, FlightGear has everything you need 
already built in.


In fact FlightGear includes some nice hires C172-S gauges you could use 
to assemble your own 2d panel.  The basic idea is to draw all the gauges 
on an LCD monitor, strategically placed behind your panel cutouts so 
that they look like real gauges.


I personally do not know a whole lot about opengc, so if you wish to go 
that route, John W. is your best point of contact.  If you are 
interested in this other idea of using FG to do 2d steam gauges, I can 
give you some more details on that.


Best regards,

Curt.



Bruce Benneke wrote:

It was suggested I repost this heresorry for the sloppy formatting 
of this message


*_Summary of this project_*..
For students in air cadetstoo young for actual flight training, 
just trying to get them interested.
Trying to build a 172 cockpit , having 'out the window' view handled 
by at least one system, just the panel handled by another...
In essence, a network of systems, one segment handling view, another 
the gauges, and a third for an instructor to monitor the entire process.

Eventually, on a simple motion base.
Was trying to use opengc for this, but discovered that opengc and FG 
.9.9 dont talk so well under windows (not at all, apparently opengc 
becoming dormant in that area)
Moved to linux boxes, and into a whole new set of issues with getting 
opengc to compile, etc.
Is there a way to do this without using opengc? (or wiring 'actual' 
gauges...doable, but too expensive right now..._zero_ budget would be 
a good description...this is all volenteer)
I'm not sure the 'glass cockpit' approach is what this project needs 
anyway for this simpler cockpit (I'd rather have them be able to scan 
the 'big 6' than glance at a PFD or HUD)

Any advice or links to advice would be GREATLY appreciated.


Bruce B
(btw...I'll try and open source any software we come up with for the 
motion base...still a long way down the road, but any help here would 
also be appreciated)




below I've attached some of the conversation I've had with John W. 
regarding this...it's kinda messy 'cause I just copied and pasted 
it...sorry!!!


Actually, just thinking of the 172 for right now... a basic generic 
cockpit for now(might do a glider as well...air cadets offers a 
gliding program...)
Is there a way to do this without opengc?  (I have a tendency to look 
for the complicated solutions first.then kick myself later.)  Just 
want to have the panel on a seperate screen(computer)...might expand 
the view to 3 screens if I have the time..even just the 'big 6' 
gauges on a seperate screen...
You're right on the money with the virtual desktop solution for the 
InstructorI suppose I could just use VNC as well, that might just 
allow the instructor to point out things.


btwFG running on a Fedora Core 4 box, fresh install.  Can't get 
opengc to compile (with or without cmake), but I've heard theres more 
than one source? (kingmont/sourceforge?)  I'm also having issues with 
cvs on this boxbut thats another story (my old mandrake box was so 
nice to me...FC4 hates me)
The box I sacrificed is an Athlon xp 2000, Nvidia 5200, 512 MB ram, so 
not the highest amount of power out there.

Thats why I want to divide this up amoungst a few older machines.
I've been REALLY busy lately and haven't been able to do much research 
into this, but I'm hoping to get more involved over the holidays.  I'm 
not the best coder out there either(self tought there...I'm a hardware 
guy since the late 70's)


Sorry to keep buggin' you..
Bruce Benneke

John Wojnaroski wrote:



Bruce Benneke wrote:


Great info... thanks...

I'm going to bump the whole project over to linux boxes over the 
weekend and see what happens.
1 running FG, another running opengc and atlas. (maybe mirror it all 
to an instructors station if I can figure out how)
We're also hoping to build a motion base for this sucker as 
well...any sage advice/warnings? 





Consider using the export DISPLAY=machine_name:0.0 command to set up 
X on a remote host?  If you're running fvwm2 under X you can setup 
several virtual desktops on the instructors station.


Are you trying to model any specific aircraft or just a generic 
cockpit?  OpenGC is glass, others may have added the more conventional 
steam gauges but my contributions were only for modern glass displays.
With OpenGC going dormant, the interface is most likely very stale.  I 
suspect that will be one of the problems you face; however all is not 
lost :-) .  If FG is transmitting, you should be able to look at the 
network traffic with a packet sniffer tool.  If you have the OpenGC 
code, look in the DataSources directory for a file called 
openegc_data.hxx. That should match up with the FG packet of the same 
name 

Re: [Flightgear-devel] Re: FG, opengc, generic gauges

2005-12-06 Thread Curtis L. Olson

Bruce Benneke wrote:


Absolutely I would be interested in just using FG to do the gauges.
Any details or a boot in the right direction would be appreciated
Would I be able to seperate the gauges onto a second system?  I'm 
already liking the idea of running 'atlas' as a mapping utility on a 
second compjust trying to distribute as much of this as possible. 
(I've got _stacks_ of older comps to use, but I'm short on newer stuff)




Hi Bruce,

I've done a system where the main FG computer displayed a fullscreen 2D 
panel and didn't draw any scenery.  FG was fully running though in terms 
of modeling internal systems, radios, flight dynamics, etc.  The 2d 
panel just showed the primary flight/engine gauges.  The radio stack was 
handled in hardware.  This was the 'main' or 'master' copy of 
flightgear.  From there you can 'slave' any number of display 
computers.  You could go with a single out-the-window display, or you 
could go with multiple displays for a wrap around system, or you could 
go with LCD projectors and project on a big screen(s) in front of you 
... there are lots of options depending on your budget and space.


Here are a couple pictures:

http://www.atcflightsim.com/products/710/Link/enclosure.html
http://www.atcflightsim.com/products/820/FS/Link/810M-032.html
http://www.atcflightsim.com/products/820/FS/Link/810M-045.html
http://www.atcflightsim.com/products/820/FS/Link/810M-036.html

Minus the FAA certified flight dynamics, you can do all the software 
side of this with stock FlightGear and a little elbow grease.  The 
hardware of course would be something you'd have to buy or build ... the 
sims pictured are a product available for purchase.  In terms of fair 
disclosure, I should state that I'm somewhat involved with the company 
that builds/sells these sims ... I have done much of the software setup 
and configuration.  I only mention them here because it serves as a good 
example of the sort of thing you are trying to do.  Depending on the 
balance between your budget and your goals and your own abilities to put 
these sorts of systems together, these comercial sims might be an option 
for some people.  I'm not trying to be Mr. Salesman here, I'm happy to 
do my best to answer any questions you have about FG if you want to do 
this yourself, but given that these sims run FG and are quite open, they 
might make for a nifty engineering sim or training sim for some people.


Regards.

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: FG, opengc, generic gauges

2005-12-06 Thread Curtis L. Olson

Bruce Benneke wrote:

Interesting option.definitely out of our price range, 
though.(looks pretty cool...good work btw)

How does one go about slaving other comps to the 'master' copy of FG?
Am I missing something in documentation?



There is a file called README.IO which gives a brief overview of how to 
configure the different computers to talk to each other.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Yasim wing incidence

2005-12-03 Thread Curtis L. Olson

Jim Wilson wrote:


If this is just flipping the sign why not just grep and fix all the aircraft in 
CVS that specify incidence?  I guess I don't understand the ritual.  Maybe 
there was more to this change that I'm just not aware of?
 


The big issue is that developers were actually specifying negative wing 
incidence when they thought they were giving positive.

So we could flip all the signs in all the config files so they flew the same as 
before, however, now all our airplanes would have negative wing incidence which 
clearly isn't right.  So we really should go back and tweak all the models so 
they perform correctly with positive incidence.

Regards,

Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)

2005-12-02 Thread Curtis L. Olson

Melchior,

One of the original intentions of the scenery path was to search until 
you found something and then stop.  From what you wrote, it sounds like 
the entire scenery path is searched and objects pulled from anything 
that is found.


The original intention was that you could have smaller updated areas in 
a path ahead of your main scenery and those areas will completely 
override stuff that is later in the path.  Otherwise we could have a lot 
of unwanted object duplication.


Regards,

Curt.


Melchior FRANZ wrote:


This patch reshuffles parts of FGTileEntry::load() to allow mere
sea tiles to contain objects (oil rigs, nav-, weather-buoys, stuff,
etc.), and to prevent fgfs from dropping objects listed in *.stg
files that were loaded before the one containing the first
terrain.btg.gz (- FG_SCENERY).

The current structure is this:

 (A) set center to 0/0/0

 (B) LOOP {
 - check for *.stg files in all FG_SCENERY dirs, and process
   them one after the other, executing all entries right away(!);
 - if terrain.btg.gz entry is found, load the tile (this sets
   center to a meaningful value)
 }

 (C) if no terrain.btg.gz entry was found in the loop, create a
 sea tile and set center accordingly



This has two disadvantages:
1. objects on mere sea tiles will be placed relative to
  center 0/0/0, because a meaningful center is only set
  afterwards. So none of them will show up in the scenery
  (oil-rigs!).
2. also, all objects from *.stg files that were loaded before the
  one with the terrain.btg.gz file are dropped. One can work around
  that by reordering the paths in FG_SCENERY, but this may not be
  obvious for users. It wasn't for me, at least.



The suggested structure is this (see patch):

 (A) LOOP {
 - go through all *.stg files in all FG_SCENERY paths and collect
   data (objects stored in a vector of structures, the
   terrain.btg.gz path stored as string)
 }

 (B) if tile found:
 load tile and set center;
 else:
 create sea tile and set center

 (C) LOOP {
 - go through the vector of stored objects and place them in
   the landscape
 }


This way all objects are placed relative to a valid tile center (and
none at the center of Earth. :-)

NOTE that:
- the patch removes RWY_LIGHTS, because this is only a dummy that
 doesn't do anything else than writing a log message.
- support for OBJECT_RUNWAY_SIGN and OBJECT_TAXI_SIGN isn't only
 kept, I also verified that they do still work. They are crying
 for a revival. (see http://www.flightgear.org/Gallery-v0.9.8/
 near bottom -- for those who don't remember)
- the storage struct is very simply. Hard-core C++ programmers
 might want to see it replaced with a set of inherited classes and
 all. That can be done if it buys us anything. Currently it would
 be overengineered. IMHO.
- the diff looks a lot uglier than the resulting file!   :-]

The patch is valgrind- and EGLL-proof. It works well since a couple
of days.I don't expect any noticable effect on the frame rate.
Please add this to the list of yet to be discussed features for
1.0. Otherwise I'll keep it warm for 1.0.1.  ;-)

m.
 




Index: tileentry.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v
retrieving revision 1.47
diff -u -p -r1.47 tileentry.cxx
--- tileentry.cxx   14 Oct 2005 16:25:14 -  1.47
+++ tileentry.cxx   1 Dec 2005 16:13:57 -
@@ -659,18 +659,48 @@ bool FGTileEntry::obj_load( const string
}


+typedef enum {
+OBJECT,
+OBJECT_SHARED,
+OBJECT_STATIC,
+OBJECT_TAXI_SIGN,
+OBJECT_RUNWAY_SIGN
+} object_type;
+
+
+// storage class for deferred object processing in FGTileEntry::load()
+struct Object {
+Object(object_type t, string token, const SGPath p, istream in)
+: type(t), path(p)
+{
+in  name;
+if (type != OBJECT)
+in  lon  lat  elev  hdg;
+in  ::skipeol;
+
+if (type == OBJECT)
+SG_LOG(SG_TERRAIN, SG_INFO, token  name);
+else
+SG_LOG(SG_TERRAIN, SG_INFO, token  namelon=  
lon
+   lat=  latelev=  elevhdg=  
hdg);
+}
+object_type type;
+string name;
+SGPath path;
+double lon, lat, elev, hdg;
+};
+
+
void
FGTileEntry::load( const string_list path_list, bool is_base )
{
bool found_tile_base = false;

-// obj_load() will generate ground lighting for us ...
-ssgVertexArray *light_pts = new ssgVertexArray( 100 );
-
-ssgBranch* new_tile = new ssgBranch;
+SGPath object_base;
+vectorconst Object* objects;

-unsigned int i = 0;
-while ( i  path_list.size() ) {
+// scan and parse all files and store information
+for (int i = 0; i  path_list.size(); i++) {

bool has_base = false;

@@ -682,243 +712,99 @@ FGTileEntry::load( const 

Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)

2005-12-02 Thread Curtis L. Olson

Melchior FRANZ wrote:


This is still the case for terrain.btg.gz files and airports, just as it
was before. But objects are always set from all stg files, with or without
this patch. The difference is that objects aren't set at center of Earth,
especially in sea tiles.
 



That's too bad, originally object loading was supposed to stop after the 
first btg file was found.


The original intention was that you could have smaller updated areas in 
a path ahead of your main scenery and those areas will completely 
override stuff that is later in the path.
   



That isn't the case since the Terrain/ and Objects/ dirs were invented.
This patch doesn't change this.
 



Again, it's a shame that original functionality is lost when people come 
later and make changes to complex code without fully understanding the 
intent.  I suppose I need to set aside a week and go through the tile 
loading with a fine tooth comb ...


Ok, to summarize, if you can assure everyone that your patch doesn't 
change any original behavor (the 'good' original behavior) and is well 
tested, then sure go ahead and commit it.  It appears though that the 
scenery path semantics and devolved into an ill understood mess.  We 
should discuss how we want the pathing to work and make the code do what 
we want.  Right now it's a bit confusing because it apparently now 
includes some inadvertant side effects as a result changes to it over 
the past year or two.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)

2005-12-02 Thread Curtis L. Olson

Jon Stockill wrote:


Melchior FRANZ wrote:


Is the following behavior OK?

  Generate all objects from all FG_SCENERY paths until we found the
  first OBJECTS_BASE entry (including the other object entries in this
  *.stg file). Then read the matching Objects/ directory, too.
  But *then* stop scanning.



That makes sense.



That makes sense to me too ...

That way you can have a tree containing just additional objects 
followed by detailed scenery, followed by default scenery all on your 
path.



And with the above suggested behavior you can override the 'global' 
scenery with something local or something newer or different ... without 
getting unintended duplication.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] compile problem with plib

2005-12-02 Thread Curtis L. Olson
The very first thing I would check is the contents of the config.log 
file.  That shows the details of the test and the compiler error 
signaling a failure.  That often can be quite helpful.


Curt.


Josh Babcock wrote:


I can't figure out why this is happening. If anyone has any ideas,
please let me know. To me it seems that I have everything I need in all
the right places. Here's the situation:

*brand spanking new Debian sid install*

Package Installed   PreviousNow
State
===-===-===-===-=
libglu1-xorg6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
libglu1-xorg-dev6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-dri6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-gl 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-gl-dev 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
freeglut3   2.4.0-4 2.4.0-4 2.4.0-4
install
freeglut3-dev   2.4.0-4 2.4.0-4 2.4.0-4
install

glxgears has no problems, runs with HW accel
glxinfo looks right, it reports the OS radeon driver, lookslike it used
to when things worked.

but:

./configure --with-x --prefix=/usr/local
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal-1.4... found
checking for working autoconf... found
checking for working automake-1.4... found
checking for working autoheader... found
checking for working makeinfo... found
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... ccache gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ccache gcc accepts -g... yes
checking for ccache gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... ccache gcc -E
checking whether we are using the GNU C++ compiler... yes
checking whether ccache g++ accepts -g... yes
checking how to run the C++ preprocessor... ccache g++ -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... no
checking for pthread_create in -lpthread... no
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: could not find working GL library

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
 




--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] OpenGL and new video card

2005-12-01 Thread Curtis L. Olson

Jon Berndt wrote:


I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. 
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm 
trying to get
some answers out of the card and driver manufacturer, but if anyone here has any
suggestions, I'd appreciate hearing them
 



I could be trying too hard to read between the lines here, but generally 
with nvidia based cards, it's a really good idea to skip the 
manufacturer provided drivers (in this case eVGA) and go straight to the 
nvidia site and get the latest drivers from there.  The manufacturer 
drivers typically are buggy and lag horribly.  And I wouldn't be 
surprised if you'd be hard pressed to find an engineer inside eVGA who's 
ever heard of opengl. :-)


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Possible new thinking for 2D/3Dcockpitinstruments

2005-12-01 Thread Curtis L. Olson

Norman Vine wrote:


Steve  Hosgood writes:
 


Agreed, but if we've got a better scheme, why keep the dialog boxes?
Every disjoint aspect to the GUI is just another thing waiting to go
wrong, as with the Cessna autopilot where the dialog box is invisibly
disconnected from the real autopilot.
   



Steve 


Apparently I wasn't clear in my initital response

FlightGear is more then just a first person sim

These other uses may have reasons to want 


dialog box displays.

Again  if you don't ike the dialog boxes don't use them

but please do not advocate taking them away.

FWIW they are also the simplest interface to build and 


as such are useful in development and debugging
 



And just to put words in Norman's mouth (which I'm sure he will 
appreciate) :-) ...


Norman isn't saying blindly keep dumb or broken stuff.  What he is 
saying is entirely compatible with a discussion about fixing bugs or 
making the gui work better or be more intuitive or less confusing.  
There is ample room for this sort of thing.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments

2005-12-01 Thread Curtis L. Olson

Ralf Gerlich wrote:

Heh, I'd like to see you looking at the Autopilot _and_ out of the 
window in a real plane. ;-)


As was mentioned, the nearest you could come to the flow in the 
cockpit IRL - not looking at the instrument and still changing its 
setting - is probably using the keyboard...at least as far as I see 
that as a pure simulation pilot ;-)



This touches on one of the *big* differences between a 'toy' and a real 
pilot training tool.  Having the entire instrument panel available at 
it's correct scale and location as well as having all the cockpit 
controls in their right location with the right amount of force feedback 
is a *huge* thing in terms of making the simulator realistic.


This is why all those oddball home/hobby cockpit builders aren't as far 
off their rockers as it might first appear.  They are taking a huge step 
towards a more realistic simulation environment.  And I'm sure all these 
people have spouses who understand the importance of a realistic flying 
experience.


You could have *perfect* flight dynamics that nailed all the numbers and 
all the nuances of the model exactly right, but if you are sitting at 
your desk, holding a $20 joystick in one hand and typing on your 
keyboard with another, while peering at a 17 monitor ... it's just not 
going to ever be all that realistic of an 'experience.'


I will even go so far as to assert that when creating a 'realistic' 
flying experience,  having the flight model right exactly on, is less 
important than having a full scale cockpit with controls that have the 
right amount of force feedback at the right times.  An enclosure is a 
huge addition because it blocks out many of the real world distractions 
that can snap you back to reality.  In addition, assembling a wrap 
around visual system that projects a field of view that exacatly matches 
the field of view covered by your display device is also very helpful.


All of this is said from the perspective of creating a realistic flying 
experience.  If you are using flightgear for other purposes (such as an 
engineering simulator or visualization tool, running it on a desktop PC 
or laptop may be exactly what is needed.)


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments

2005-12-01 Thread Curtis L. Olson

John Wojnaroski wrote:

One of the knocks from the May show ( which is totally my fault) was 
the cheezy joystick.  So here we were with a full scale 747 glass 
cockpit with a large screen plasma OTW display running top of the line 
flight dynamics (JSBSim), world class scenery (FlightGear), high 
fidelity subsystem models (Mathworks), and a noodle for control.


If we had had a decent control system, we could have faked the rest ;-)



Come on Jack, when are you going to drive up to Mojave with your 
hacksaw?  I can get you past the fence, the rest is up to you. :-)


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2

2005-12-01 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Melchior FRANZ -- Friday 02 December 2005 01:43:
 


But ... we weren't really returning the address of an auto var.
   



Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;

 float
 XDR_decode_float ( const xdr_data_t  f_Val )
 {
 float* tmp;
 xdr_data_t dummy;

 dummy = XDR_decode_int32 (f_Val);
 tmp = (float*) dummy;
 return (*tmp);
 }

 



Here you are just returning the contents of a memory location, not the 
pointer itself (aka a value).  So this should be perfectly safe.  My bet 
is that the value didn't get decoded properly, but whatever got decoded 
incorrectly was returned correctly.  I'd check the value if (*tmp) 
before it get's returned to see if it looks like what you think it should.


I'll bail out here before I get to the x86 assembler portion of your 
message. :-)


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] No 0.9.9 scenery yet?

2005-11-30 Thread Curtis L. Olson

Stefan Seifert wrote:


Why the need for an odd subtree then?
Normal end users use the released packages on the webpage (currently 
0.9.9). Everyone else, including developers and bleeding edge people 
already check out from CVS.


One could branch the 1.0 tree in CVS and provide small fixes on that 
while development of big stuff goes on on CVS trunk, but that's no 
need for any change in version numbering. 1.0.x gets updated until 
trunk is stable enough to release 1.1 or so. Like Curt said, a flight 
simulator is not an essential system service where many other things 
build upon and need a stable base. Normally pretty everyone should 
want future updates as soon as they are stable enough for end users.
Linux Kernel versioning has change a _lot_ since 2.6. There is not 
even a real development branch anymore.



I think as flightgear develops and matures, there argument for an 
even-stable/odd-devel release system will grow a lot stronger, but for 
the moment, development has been moving so quickly with so many new 
important features being added, that our attempts at a stable release 
have largely been ignored, simply because the devel releases ahead of it 
were so much better.


It is interesting to have this discussion though.  At the start of this 
project, the big focus was to get anyone interested.  I was very focused 
on generating enough forward progress to keep people from giving up and 
moving on to other stuff.  At that point I felt like I largely carried 
the project on my back and if I would have dropped it, the whole thing 
would have quickly died.


That emerged into a period where we seemed to hit a critical mass.  
FlightGear still had a *long* way to go and many important features that 
were missing.  But I felt that we had enough interest, enough 
developers, enough people committed to using it that the project was 
starting to take on a life of it's own.


Now as we look forward, we are talking less about a mad scramble to add 
basic features (although there are a few important things left to add) 
and more about stability and content (aircraft, scenery, etc.)


So this discussion of odd/even releases may be a bit premature at the 
moment, but it is something we should consider again sometime after our 
1.0 release.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] No 0.9.9 scenery yet?

2005-11-30 Thread Curtis L. Olson

Stefan Seifert wrote:


Why the need for an odd subtree then?
Normal end users use the released packages on the webpage (currently 
0.9.9). Everyone else, including developers and bleeding edge people 
already check out from CVS.


One could branch the 1.0 tree in CVS and provide small fixes on that 
while development of big stuff goes on on CVS trunk, but that's no 
need for any change in version numbering. 1.0.x gets updated until 
trunk is stable enough to release 1.1 or so. Like Curt said, a flight 
simulator is not an essential system service where many other things 
build upon and need a stable base. Normally pretty everyone should 
want future updates as soon as they are stable enough for end users.
Linux Kernel versioning has change a _lot_ since 2.6. There is not 
even a real development branch anymore.



I think as flightgear develops and matures, there argument for an 
even-stable/odd-devel release system will grow a lot stronger, but for 
the moment, development has been moving so quickly with so many new 
important features being added, that our attempts at a stable release 
have largely been ignored, simply because the devel releases ahead of it 
were so much better.


It is interesting to have this discussion though.  At the start of this 
project, the big focus was to get anyone interested.  I was very focused 
on generating enough forward progress to keep people from giving up and 
moving on to other stuff.  At that point I felt like I largely carried 
the project on my back and if I would have dropped it, the whole thing 
would have quickly died.


That emerged into a period where we seemed to hit a critical mass.  
FlightGear still had a *long* way to go and many important features that 
were missing.  But I felt that we had enough interest, enough 
developers, enough people committed to using it that the project was 
starting to take on a life of it's own.


Now as we look forward, we are talking less about a mad scramble to add 
basic features (although there are a few important things left to add) 
and more about stability and content (aircraft, scenery, etc.)


So this discussion of odd/even releases may be a bit premature at the 
moment, but it is something we should possibly consider again sometime 
after our 1.0 release.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] KLN89 GPS added

2005-11-30 Thread Curtis L. Olson

Erik Hofman wrote:

Well, I object. How could I tell others to postpone their contribution 
until after the release of FlightGear 1.0 if you are allowed to add 
this rather comprehensive peace of code?



This is a fair point to make ...

1. Let me say though that this code was ready to go before the 0.9.9 
release so it had already been waiting for some time.  If you wait too 
long, the underlyiing structure can change and make it almost impossible 
to merge in this code later.


2. Ok, a kln89 is no garmin 530, however, a *real* working gps is a 
*huge* feature we are missing.  I really wanted this to make it into the 
code before 1.0.


3. I have some of my own selfish reasons for wanting to see the gps code 
get added, because it has the potential to be a big benefit to some of 
the other projects I'm involved in.


I understand you could build a strong argument in the other direction 
too, but in this case there was enough advantages in my view to tip the 
scales in favor of adding it.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: KLN89 GPS added

2005-11-30 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Erik Hofman -- Wednesday 30 November 2005 09:56:
 


How could I tell others to postpone their contribution until after the
release of FlightGear 1.0 [...]
   



Good question, indeed! How could you? There was no discussion about
this topic on flightgear-devel before this order was announced, and
every discussion after that was passively suppressed by ignoring valid
arguments. How was this decision made and by whom? Is FlightGear no
longer cooperative (as in working together)? Are we minor
developers now working for an elite that makes important decisions
off-list? This decisions making process sucks!

This is not to say that KLN89 needed to be in 1.0.0, but other
features urgently need to, unless 1.0.0 is meant to be a joke.
 



I don't want to passively supress your points, but I'm also afraid I 
might say something less than helpful in response here.


By giving certain developers cvs write access, we are imparting a large 
amount of trust.  Trust that they will be careful and test what they 
commit.  Trust that they will do their best to act with the best 
interests of the project in mind.  But also that implies some amount of 
autonomy ... within reasonable limits of course.


Don't forget that if a developer does commit something that turns out to 
be a *really* bad idea, we have peer pressure, advanced shaming 
techniques, ridicule, and the ability to back things out of cvs.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] KLN89 GPS added

2005-11-30 Thread Curtis L. Olson

Vassilii Khachaturov wrote:


For example I'd strongly consider the missing options saving a bug that
has to be fixed before we give FlightGear to all the people out there.
They are used to this behavior from nearly every program they use, and
will expect the same from FG. Others may think, that we lived without
this feature (who doesn't have his own private preferences.xml in the
search path?) and it would be too an intrusive change. But that's the
difference between a developer and an end user release.

Nine
   



I agree that this is a very serious feature for 1.0 inclusion.
Maybe if we just have several people signing off the patch before
inclusion (by 1) reading the code 2) testing it locally 3) sending an
email to the list it's OK from their point of view for the 1.0)
this will help.

Personally, I will be willing to do this to the above patch.
 



For what it's worth.  There are many people that say, We can't do a 
v1.0 release without feature XYZ and then do nothing to impliment 
feature XYZ.  Or they might say, how can we include feature A without 
including feature B, but no one has stepped forward to work on feature B 
but someone has finished feature A.


Not to sound like a broken record, but in the open source world, if no 
one steps forward to work on a particular feature, it just isn't going 
to happen.  It won't get added to v1.0 if no one takes the 
responsibility upon themselves to do it.


So that said, your offer to actually work on a suggested feature is like 
a beacon in the darkness! :-)


I think that if you could get this working well, it would be worthy of 
inclusion in 1.0.  However, I suspect there are a number of *really* 
tricky issues to deal with and that's probably why the feature doesn't 
work correctly now.


So before you get too far, I think I would be very interested in hearing 
how you plan to attack this, and perhaps what the scope of your patch 
might be.


Things to consider ... dumping out the entire property tree and reading 
it back will not accomplish the task because many properties represent 
derived values.  And much of the simulator 'state' is maintained 
internally in the C/C++ code and will not react correctly if the 
appropriate initialization functions (and sequence of function calls) is 
not called.  It can become really tricky stuff.


You may want to attack this in small steps ... for instance start out 
with just getting save/load of aircraft position working.  Then move on 
to other chunks of the property tree adding and testing them one by one ...


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,

2005-11-30 Thread Curtis L. Olson

Martin Spott wrote:


I'm very much surprised to see that you intend to use YASim for an
aircraft, that you want to model based on existing flight data.
Do you actually expect YASim to be the right tool for that job or is it
simply leftover from using the Cub layout as basis ? I might miss the
point but to my understanding it is expected be much easier to feed
real data into JSBSim.

Just being _very_ curious  ;-)
 



Well right now there is no rascal specific dynamics model for any of our 
core fdm engines, so there's not really all that much to be curious 
about ...


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,

2005-11-30 Thread Curtis L. Olson

Martin Spott wrote:


I'm very much surprised to see that you intend to use YASim for an
aircraft, that you want to model based on existing flight data.
Do you actually expect YASim to be the right tool for that job or is it
simply leftover from using the Cub layout as basis ? I might miss the
point but to my understanding it is expected be much easier to feed
real data into JSBSim.

Just being _very_ curious  ;-)
Martin.
 



We went out and flew our Rascal today to collect some more video and 
data.  I posted some pictures here:


http://www.flightgear.org/~curt/Models/Special/Rascal110_2/

We had very light / calm winds so I'm hoping the 
position/attitude/velocity data comes out pretty clean.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] RenderTexture bug

2005-11-30 Thread Curtis L. Olson

Ampere K. Hardraade wrote:


On November 26, 2005 10:50 pm, Ampere K. Hardraade wrote:
 


I finally managed to compile Xorg from source today and managed to get more
information from gdb.  I have also filed a bug report with Xorg:
https://bugs.freedesktop.org/show_bug.cgi?id=5142

Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
   



Ah ha!  A reply!
https://bugs.freedesktop.org/show_bug.cgi?id=5142
 


What should I write in response?



Perhaps explain to them what our code is attempting to do, and then ask 
if they know of a GLX supported way to do it.  It sounds like the reply 
is suggesting that they have no support for pbuffers at all.


If this is indeed the case, then a GLXUnsupportedPrivateRequest error 
might indeed be exactly what's going on.  We are trying to do something 
RenderTexture that is not supported by GLX.  The question is, can we do 
what we need with some approach that is supported by GLX?


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] No 0.9.9 scenery yet?

2005-11-29 Thread Curtis L. Olson

Steve Hosgood wrote:


PS:
Is it planned that after 1.0.0, there will be a 'development' tree of
1.1.x, with the next proper release becoming 1.2.x? Opinions differ on
whether or not this scheme is good or bad, but the FG project gods
probably need to think it through pretty soon.
 



This scheme seems to work really well for things like the linux kernel 
or desktop environments where they are 'core' services that people 
depend on to run their machine.  For an end user app, this seems to be 
less beneficial.  For what it's worth, we did use this version numbering 
scheme for a while.  Officially 0.8.0 is our 'stable' release.  However, 
as soon as we released 0.8.0 and made 0.9.0 available, *everyone* 
ignored 0.8.0 and ran with 0.9.x.


So we tried this approach and it died a natural death of being ignored.  
At some point it might make sense to revive this scheme, but right now 
I'm not ready to do it.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Addresses in mailing list distribution (was Re: Landing Lights)

2005-11-29 Thread Curtis L. Olson

Jim Wilson wrote:


Actually it doesn't seem to do that either (not, as you say, it would do that 
much good).  And no, another thread on how to do email or whatever is not 
required.  But I feel compelled to ask how hard it could possibly be for the 
software to simply filter email addresses out.  I don't recall any time that 
someone wanted to post an email address.
 



The mailing list archiving software will make a reasonable attempt to 
obfuscate addresses of the posters and replyers.  However, if someone 
posts an email address in clear text in the body of a message, as far as 
I know that will not get obfuscated.


Also note there are external mailing list archivers (well at least one) 
that have subscribed to our list and archive the messages.  I have no 
control over what they do with obfuscating email addresses.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Displaying Multiple Views/Using cockpit controls

2005-11-29 Thread Curtis L. Olson

Ryan Kellar wrote:

I am new to using FlightGear and am currently working on a project 
that involves a flight simulator with a Cessna cockpit and a screen 
that is divided into 3 sections in sort of a wrap around(not fully, 
but tilted to give a more panoramic view. Each board is displayed 
using a different projector run by three separate computers. Also, the 
cockpit controls are being read in as voltages to a separate computer. 
I am completely new to flight simulation and this software, and have 
some C++ software experience but never any software hardware 
integration so I’m a little lost. My questions are is there a way to 
display a simultaneous panoramic view using the three computers each 
running an instance of FlightGear and if so, how?




Yes, mutliple displays are well supported in FlightGear. There is a 
document called README.IO that touches on this. If you need more help, 
just ask. Note to document writers: this might be a good subject to add 
to the manual.


Also, how can I go about reading in the cockpit controls(which are now 
being read as voltage values) into the program to control the airplane?




If your hardware already exists, then this is something you will likely 
have to figure out on your own. You will need to write some glue code 
that can read the voltage values and translate them into a control input 
position. FlightGear uses normalized control input positions so yoke, 
wheel, rudder pedals, etc. are mapped to [-1, 1]. Throttle, flaps, 
mixture, etc. are mapped to [0,1]. Once you are able to read in your 
voltage values and normalize them, it is pretty straightforward to send 
that data over to FlightGear. It's possible to embed some code into 
FlightGear, or you could just write a separate application that sends 
the data to FG over the network.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Flightgear 0.9.9 RPMs for Fedora Core 2, 3, 4 on i386

2005-11-29 Thread Curtis L. Olson

Hi Steve,

Many thanks for making these available.  I have put them on the 
FlightGear ftp server and they should soon propagate to our mirrors.


Best regards,

Curt.


Steve Hosgood wrote:


Please help yourselves to my RPMs:

ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/RPMS/i386/FlightGear-0.9.9-0.FC.i386.rpm
ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/RPMS/i386/openal-20050209-0.FC2.i386.rpm

Ignore the 'FC2' suffix on the openal package: it should be fine for FC2
onwards. For the convenience of non-techie users (not that there are any
using Fedora Core!) the Flightgear RPM adds a launcher to the 'Games'
category of the Red Hat Start tool (bottom left of the screen). Yes,
it probably should create a category called 'Simulators' and put the
icon and launcher in there instead. However, I couldn't work out how to
do that - if anyone knows how, please post and tell me.

   ---

You don't need the 'devel' RPMs unless you plan building the SRPMs for
flightgear. If you do want the SRPMs, they are in the directory:

ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/SRPMS/

(of course).

Scenery RPMs (for the UK, Ireland and Faroe Islands) coming soon using
the scheme I used for 0.9.8. Not to everyone's taste I know, but
convenient if you like keeping your software under RPM's control.

Steve.


PS: Could someone mirror these RPMs somewhere please. They're currently
hosted on rather a puny machine on a slow WAN.

Thanks in advance.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
 




--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Displaying Multiple Views/Using cockpit controls

2005-11-29 Thread Curtis L. Olson

Buchanan, Stuart wrote:


--- Curtis L. Olson  wrote:
 

Yes, mutliple displays are well supported in FlightGear. There is a 
document called README.IO that touches on this. If you need more help, 
just ask. Note to document writers: this might be a good subject to add 
to the manual.
   



Hint taken ;). I was thinking of writing a section on various features
such as the Nimitz, multiplayer and multiple displays anyway. 


Unfortunately I only have a single PC, so I'll be writing blind. Would you
be able to review my text for me?
 



Adding sections for some of our more interesting or more asked about 
features would be great.


Certainly I would be happy to review your text ...

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] FlightGear FDM

2005-11-27 Thread Curtis L. Olson

bass pumped wrote:


oops...   disregard the above ouput.  I found an error in what I had
done.   Right now I can only confirm that the data being put on the
network is wrong.  I have matlab running on another computer reading
the output as -398976952544137610.00 insead of
2.58802.  I know my matlab code is working... it worked perfectly with
0.9.8.

I'll keep everyone updated
 



Note that there are FGNetFDM structure changes between v0.9.8 and v0.9.9.

I have instances of FG talking to other copies of FG as well as an 
external FDM talking to FG using the same structure.  There can be 
packing differences between compilers, but we were pretty careful with 
the current structure (all values are 4 or 8 bytes) and we don't know of 
any compilers that pack the structure differently from any other compilers.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Presentation

2005-11-24 Thread Curtis L. Olson

Manuel Vélez wrote:


Hello !

I am Manuel Vélez, author of IOCards Project www.opencockpits.com

I want to connect those electronic cards for use in cockpits with
FlighGear.

A free project like IOCards should can connect with a open project like
Flighgear.

Actualy, IOCards can connect with Flight Simulator, X-plane and LOCK-ON 
FC.
 



FlightGear has a number of pretty simple/straightforward interfacing 
options.  It's a holiday here in the USA so I can't spend much time 
online today (and probably not tomorrow either) but I and probably 
others would be more than happy to help you find a clean way to 
interface your stuff.  FlightGear has been interfaced to a couple other 
physical cockpits so most if not all of the hooks you might need should 
be available.


Best regards,

Curt.

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 0.9.9 compile problem

2005-11-23 Thread Curtis L. Olson

Brian,

What compiler are you using.  This looks a bit strange.  Most often, 
ifyou link against a library, it only pulls in the required routines 
from that library and ignores everything else.  But in this case it 
almost looks like your linker is requiring all symbols in the 
libsgenvironment.a to get resolved, even if they are part of functions 
that aren't referenced or used.  The sgi compilers have this tendency, 
but gcc is usually very smart about this.  The quick fix would be to add 
the additional libs ... -lsgmath -lplibsg -lGL, etc.


But it would be interesting to know which compiler you are using to see 
if it makes sense that it should squawk about this or not ...


Regards,

Curt.


Brian Thomason wrote:

I'm attempting to compile FlightGear 0.9.9 on Linspire 5.0.  Compiling 
simgear 0.9.9 went fine, but FlightGear fails with the following error:

/
g++ -DPKGLIBDIR=\/usr/share/games/FlightGear\ -g -O2 -D_REENTRANT  
-L/usr/X11R6/lib -L/usr/lib -o metar  metar_main.o -lsgenvironment 
-lsgio -lsgbucket -lsgmisc -lsgstructure -lsgdebug -lsgprops 
-lsgserial -lsgxml -lplibnet -lplibul  -lz -ldl -lm  -ljpeg
/usr/lib/libsgenvironment.so: undefined reference to 
`ssgContext::loadModelviewMatrix(float (*) [4])'

/usr/lib/libsgenvironment.so: undefined reference to `glRotatef'
/usr/lib/libsgenvironment.so: undefined reference to 
`sgMakeRotMat4(float (*) [4], float, float const*)'

/usr/lib/libsgenvironment.so: undefined reference to `sg_random'
/usr/lib/libsgenvironment.so: undefined reference to `glVertex3f'
/usr/lib/libsgenvironment.so: undefined reference to 
`calc_gc_lon_lat(Point3D const, double, double)'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::CloudVis'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGSoundSample::set_source_pos(float*)'
/usr/lib/libsgenvironment.so: undefined reference to 
`sgMakeCoordMat4(float (*) [4], float, float, float, float, float, 
float)'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGBbCache::startNewFrame()'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::get_CacheSize()'

/usr/lib/libsgenvironment.so: undefined reference to `glDisable'
/usr/lib/libsgenvironment.so: undefined reference to `glDepthMask'
/usr/lib/libsgenvironment.so: undefined reference to `glBegin'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::set_CloudVis(float)'

/usr/lib/libsgenvironment.so: undefined reference to `_ssgCurrentContext'
/usr/lib/libsgenvironment.so: undefined reference to `glLineWidth'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::set_CacheSize(int)'

/usr/lib/libsgenvironment.so: undefined reference to `glColor4fv'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::set_density(float)'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::set_enable3dClouds(bool)'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::density'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGSoundMgr::is_playing(std::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const)'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::get_CacheResolution()'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGSoundMgr::find(std::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const)'

/usr/lib/libsgenvironment.so: undefined reference to `glPopMatrix'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGNewCloud::cldCache'
/usr/lib/libsgenvironment.so: undefined reference to 
`sgMakeTransMat4(float (*) [4], float const*)'
/usr/lib/libsgenvironment.so: undefined reference to 
`sgSetCoord(sgCoord*, float const (*) [4])'
/usr/lib/libsgenvironment.so: undefined reference to 
`ssgContext::getModelviewMatrix(float (*) [4])'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::enable3D'

/usr/lib/libsgenvironment.so: undefined reference to `glPushMatrix'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGCloudField::set_CacheResolution(int)'

/usr/lib/libsgenvironment.so: undefined reference to `glBindTexture'
/usr/lib/libsgenvironment.so: undefined reference to `glEnable'
/usr/lib/libsgenvironment.so: undefined reference to 
`SGSoundSample::play(bool)'
/usr/lib/libsgenvironment.so: undefined reference to 
`calc_gc_course_dist(Point3D const, Point3D const, double*, double*)'

/usr/lib/libsgenvironment.so: undefined reference to `glShadeModel'
/usr/lib/libsgenvironment.so: undefined reference to `glTranslatef'
/usr/lib/libsgenvironment.so: undefined reference to `glColor4f'
/usr/lib/libsgenvironment.so: undefined reference to `glBlendFunc'
/usr/lib/libsgenvironment.so: undefined reference to 
`sgPostMultMat4(float (*) [4], float const (*) [4])'

/usr/lib/libsgenvironment.so: undefined reference to `glEnd'
/usr/lib/libsgenvironment.so: undefined reference to 
`sgPreMultMat4(float (*) [4], float const (*) [4])'

collect2: ld returned 1 exit status
make: *** [metar] Error 1/

The 

Re: [Flightgear-devel] Re: 0.9.9 compile problem

2005-11-23 Thread Curtis L. Olson

Alex Romosan wrote:


Curtis L. Olson [EMAIL PROTECTED] writes:

 

What compiler are you using.  This looks a bit strange.  Most often, 
ifyou link against a library, it only pulls in the required routines 
from that library and ignores everything else.  But in this case it 
almost looks like your linker is requiring all symbols in the 
libsgenvironment.a to get resolved, even if they are part of functions 
that aren't referenced or used.  The sgi compilers have this tendency, 
but gcc is usually very smart about this.  The quick fix would be to add 
the additional libs ... -lsgmath -lplibsg -lGL, etc.


But it would be interesting to know which compiler you are using to see 
if it makes sense that it should squawk about this or not ...


Regards,

Curt.


Brian Thomason wrote:

   


I'm attempting to compile FlightGear 0.9.9 on Linspire 5.0.
Compiling simgear 0.9.9 went fine, but FlightGear fails with the
following error:
/
g++ -DPKGLIBDIR=\/usr/share/games/FlightGear\ -g -O2 -D_REENTRANT
-L/usr/X11R6/lib -L/usr/lib -o metar  metar_main.o -lsgenvironment
-lsgio -lsgbucket -lsgmisc -lsgstructure -lsgdebug -lsgprops
-lsgserial -lsgxml -lplibnet -lplibul  -lz -ldl -lm  -ljpeg
/usr/lib/libsgenvironment.so: undefined reference to
`ssgContext::loadModelviewMatrix(float (*) [4])'
/usr/lib/libsgenvironment.so: undefined reference to `glRotatef'
/usr/lib/libsgenvironment.so: undefined reference to
`sgMakeRotMat4(float (*) [4], float, float const*)'
/usr/lib/libsgenvironment.so: undefined reference to `sg_random'
/usr/lib/libsgenvironment.so: undefined reference to `glVertex3f'
/usr/lib/libsgenvironment.so: undefined reference to
`calc_gc_lon_lat(Point3D const, double, double)'
/usr/lib/libsgenvironment.so: undefined reference to
`SGCloudField::CloudVis'
/usr/lib/libsgenvironment.so: undefined reference to
`SGSoundSample::set_source_pos(float*)'
/usr/lib/libsgenvironment.so: undefined reference to
`sgMakeCoordMat4(float (*) [4], float, float, float, float, float,
float)'
/usr/lib/libsgenvironment.so: undefined reference to
`SGBbCache::startNewFrame()'
/usr/lib/libsgenvironment.so: undefined reference to
`SGCloudField::get_CacheSize()'
/usr/lib/libsgenvironment.so: undefined reference to `glDisable'
/usr/lib/libsgenvironment.so: undefined reference to `glDepthMask'
/usr/lib/libsgenvironment.so: undefined reference to `glBegin'
/usr/lib/libsgenvironment.so: undefined reference to
 



he is linking against shared libraries. i see the same thing (having
modified my build environment a long time ago to build shared
libraries) but in my case i just modified the Makefiles and added the
extra libraries needed.

and, yes, there are a lot of interdependencies (including circular
ones) between the simgear libraries that don't show up in the current
makefiles.
 



Ahh, ok, I missed seeing the .so's

I realize that some people really love shared libraries, but in the case 
of flightgear/simgear, who are you sharing them with.  It makes the 
binary a bit smaller, but you don't have a zillion apps all linking 
against the same libraries like you do with X or kde or gnome.


If you have a choice, I'd recommend building simgear as static libraries 
and rolling it all into the executable.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 3D modelers

2005-11-22 Thread Curtis L. Olson

Vassilii Khachaturov wrote:


Not being an aircraft modeller myself, I don't know exactly what's
needed; but those with specific requirements could also try posting
in the rec.aviation.* newsgroups (the .piloting and .simulators come
to mind), and folks out there will probably respond. Google before
you go, because somebody ahead of you on these newsgroup may have posted
the very info you're looking for.

BTW, there hasn't been an announcement of the 0.9.9 in the
rec.aviation.simulators, so one can probably do the 2 things
at one go.
 



Yeah, a while back I stopped posting me email address on usenet news.  
It gets into the web archives, goes all over the internet and the world, 
and pretty soon you are back to measure your spam in messages per second 
... :-(


But if anyone else is feeling brave, be my guest.

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Realistic daytime skycolor

2005-11-22 Thread Curtis L. Olson

Vassilii Khachaturov wrote:


Like in the dawn screenshot where I tried to show that off;

http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg

   


[snip]
 


I don't know anything about the theory of it all, but I do know that the sky
in FG looks truly amazing at dawn and dusk in particular (colours, moon
phases, star positions etc) - and I think we are _really_ underselling FG by
not having a few screenshots illustrating that on the website.
   



Agreed 100%.

 


I'm sure others can come up with much nicer ones than I have... they're all
going to offend the darkness police whatever :-)

   



A trivial solution comes to mind --- create a decent out-of-cockpit
screenshot facing a scene like that. Your particular image would offend
not just the darkness police but the FAA as well for not sporting
the exterior aircraft lighting when it should be on!
 



I forget who posted this original 'dark' screen shot, but here's the 
issue, due to gamma differences, this image comes out completely black 
on my screen.  From that standpoint, it's not a useful screen shot.  
Many people that download it are going to say, huh!  This isn't an easy 
problem to circumvent because there is a wide swath of gamma 
configurations and monitors out there.  But in this case, we simply need 
something with more light to make it widely useable.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] RenderTexture bug

2005-11-22 Thread Curtis L. Olson

Enrique Vaamonde wrote:


Hi Erik,
I have tried tonight the cvs version and although I'm not suffering the
RenderTexture problem (I use ATI's propietary binary driver - latest
version 8.19.10), I have found the following error when starting up FG.

RenderTexture Error: glXCreateGLXPbufferPtr() failed

The program loads fine after that tho', however, I am still experiencing
a segmentation fault when flying at night in the default San Francisco area.

It only happens at night in this area, it won't happen when flying
during the day in SF or when flying at night somewhere else (at least in
the other scenery where I fly). When I take off (usually default runway
28R), I'd fly runway heading for some 15 to 30 seconds and then comes
the segmentation fault. So far, running the program inside gdb gives
little (at least to me), but I am pasting part of the output below, just
hoping it can help anyone to track this issue:

0xafc361b3 in __glim_R200TCLDrawArrays ()
  from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so

#0  0xafc361b3 in __glim_R200TCLDrawArrays ()
  from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
#1  0xafc35a19 in __glim_R200TCLDrawArrays ()
  from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
#2  0xafc35a19 in __glim_R200TCLDrawArrays ()
  from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
.
.
.
and goes on and on

If you or anyone need any information or additional testing please let
me know ... I will try to use the open source driver in the next few
days to see how it goes for me.
 



The fact that the crash is inside the ati driver makes me just a little 
suspicious of a driver bug.


What would be possibly useful is to see the lines further along in the 
backtrace so we can see where in the flightgear/simgear code the crash 
happen.


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] RenderTexture bug

2005-11-22 Thread Curtis L. Olson

Enrique Vaamonde wrote:


Hi Curt,
as a matter of fact, the last line of the bt is this:

#24939 0xafc88a19 in __glim_R200TCLDrawArrays ()
  from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
(gdb)

...after that it's all empty...any clues? am I missing something?

thank you :)
 



There are situations where gdb barfs and says nothing useful.  Not to 
pick on gdb ... I've never got the borland debugger to tell me anything 
useful after any crash, but that's a different story.  Tracking down the 
specific spot of a crash can sometimes be easy (if gdb plays along) or 
can turn into an art form if the easy tricks fail ...


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] RenderTexture bug

2005-11-22 Thread Curtis L. Olson
Hnmm, according to this you are crashing trying to draw the ambient 
ground light points.  That should just be a collection of simple points 
with no strange opengl calls, unless you've turned on some of the fancy 
point lighting effects.  If you have those on, you might want to turn 
them off.  Otherwise, it looks like the driver is crashing just drawing 
simple untextured/colored points ... ( ? )


Curt.


Enrique Vaamonde wrote:


Hi Curt,
disregard the last message, I must have screwed up somewhere...
anyway...here's the bt after the ATI driver errors:

#87344 0x08418821 in ssgVtxTable::draw_geometry (this=0xecd8ba8)
   at ssgVtxTable.cxx:635
#87345 0x08417fe9 in ssgVtxTable::draw (this=0xecd8ba8) at
ssgVtxTable.cxx:560
#87346 0x08405a1b in ssgSelector::cull (this=0xebd9bb0, f=0x8dd0020,
   m=0xbf8d62ec, test_needed=1) at ssgSelector.cxx:73
#87347 0x0840feea in ssgRangeSelector::cull (this=0xebd9a98, f=0x8dd0020,
   m=0xbf8d62ec, test_needed=1) at ssgRangeSelector.cxx:92
#87348 0x0840deb7 in ssgTransform::cull (this=0xebdc4d0, f=0x8dd0020,
   m=0x8dcffc8, test_needed=1) at ssgTransform.cxx:83
#87349 0x083f8230 in ssgBranch::cull (this=0xa719b18, f=0x8dd0020,
   m=0x8dcffc8, test_needed=1) at ssgBranch.cxx:276
#87350 0x083fa22b in ssgContext::cull (this=0x1bfc, r=0x0)
   at ssgContext.cxx:260
#87351 0x083f6102 in ssgCullAndDraw (r=0xa719b18) at ssg.cxx:303
#87352 0x08056ca8 in FGRenderer::update (refresh_camera_settings=true)
   at renderer.cxx:673
#87353 0x08054b7d in FGRenderer::update () at renderer.hxx:34
#87354 0x08081cc1 in GLUTdraw () at fg_os.cxx:118
#87355 0xb7f70884 in glutJoystickGetCenter () from /usr/lib/libglut.so.3
#87356 0xb7f74478 in fgEnumWindows () from /usr/lib/libglut.so.3
#87357 0xb7f70d6f in glutMainLoopEvent () from /usr/lib/libglut.so.3
#87358 0xb7f717fe in glutMainLoop () from /usr/lib/libglut.so.3
#87359 0x08051a82 in fgMainInit (argc=2, argv=0xbf8d6934) at main.cxx:1007
#87360 0x08051259 in main (argc=2, argv=0xbf8d6934) at bootstrap.cxx:193

I will try to understand this but like I mentioned before...I'm not
really a graphics programmer.
thanks for the help!
-E

Curtis L. Olson wrote:

 


Enrique Vaamonde wrote:

   


Hi Erik,
I have tried tonight the cvs version and although I'm not suffering the
RenderTexture problem (I use ATI's propietary binary driver - latest
version 8.19.10), I have found the following error when starting up FG.

RenderTexture Error: glXCreateGLXPbufferPtr() failed

The program loads fine after that tho', however, I am still experiencing
a segmentation fault when flying at night in the default San
Francisco area.

It only happens at night in this area, it won't happen when flying
during the day in SF or when flying at night somewhere else (at least in
the other scenery where I fly). When I take off (usually default runway
28R), I'd fly runway heading for some 15 to 30 seconds and then comes
the segmentation fault. So far, running the program inside gdb gives
little (at least to me), but I am pasting part of the output below, just
hoping it can help anyone to track this issue:

0xafc361b3 in __glim_R200TCLDrawArrays ()
 from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so

#0  0xafc361b3 in __glim_R200TCLDrawArrays ()
 from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
#1  0xafc35a19 in __glim_R200TCLDrawArrays ()
 from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
#2  0xafc35a19 in __glim_R200TCLDrawArrays ()
 from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
.
.
.
and goes on and on

If you or anyone need any information or additional testing please let
me know ... I will try to use the open source driver in the next few
days to see how it goes for me.


 


The fact that the crash is inside the ati driver makes me just a
little suspicious of a driver bug.

What would be possibly useful is to see the lines further along in the
backtrace so we can see where in the flightgear/simgear code the crash
happen.

Thanks,

Curt.
   




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
 




--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] .tgz extractors for windows

2005-11-21 Thread Curtis L. Olson
Can someone post a link to a good, free, unencumbered windows 
uncompresser that handles the .tgz format?  I'd like to post a link on 
the aircraft downloads page to assist those windows users who aren't 
familiar with this format and don't happen to have a working extractor 
already installed on their systems.


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] getstart manual

2005-11-21 Thread Curtis L. Olson

Is there any plans to update the .html version of the getting started guide?

Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] getstart manual

2005-11-21 Thread Curtis L. Olson

Martin Spott wrote:


Curtis L. Olson wrote:
 


Is there any plans to update the .html version of the getting started guide?
   



Yes, there is, but unfortunately I won't have the time to do this
before this weekend,

 



Ok, just send me a note when you have something and I'll update the 
links at that time.


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling CVS on SuSE 10.0

2005-11-19 Thread Curtis L. Olson
This looks very much like you do not have the matching version of 
simgear compiled/installed, or you have multiple versions on your system 
and the compiler is finding the wrong one.


Regards,

Curt.


Steve Knoblock wrote:


I checked out the CVS base lat night and tried to compile with an older
tarball source, which failed. I received advice through FG irc that I
should check the latest FG source out from CVS. I did that tonight and
the configure seemed to go normally, but the make failed:

Making all in ATC
make[2]: Entering directory
`/usr/local/source/FlightGear-CVS/source/src/ATC'
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
-I/usr/X 11R6/include -I/usr/local/include  -g -O2 -D_REENTRANT -MT
ATC.o -MD -MP -MF .d eps/ATC.Tpo -c -o ATC.o ATC.cxx; \
then mv -f .deps/ATC.Tpo .deps/ATC.Po; else rm -f .deps/ATC.Tpo;
exit 1; f i
ATC.cxx: In member function ‘void FGATC::Render(std::string, const
std::string , bool)’:
ATC.cxx:230: error: invalid conversion from ‘unsigned char*’ to ‘const
char*’
ATC.cxx:230: error:   initializing argument 1 of
‘SGSoundSample::SGSoundSample(c onst char*, const char*, bool)’
ATC.cxx:230: error: invalid conversion from ‘int’ to ‘const char*’
ATC.cxx:230: error:   initializing argument 2 of
‘SGSoundSample::SGSoundSample(c onst char*, const char*, bool)’
make[2]: *** [ATC.o] Error 1
make[2]: Leaving directory
`/usr/local/source/FlightGear-CVS/source/src/ATC'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/source/FlightGear-CVS/source/src'
make: *** [all-recursive] Error 1
linux:/usr/local/source/FlightGear-CVS/source #

Advice appreciated.

Steve



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
 




--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: website problem

2005-11-19 Thread Curtis L. Olson

Pigeon wrote:


Curt, the link is on the front page... I just checked and go the same
404 error. 
   



   To be a bit more precise, it's the screenshots link at the bottom
of the page.

   The one on the left is fine, which points to
http://flightgear.org/Gallery-v0.9.9/



Ok, I got the one in the sidebar, but not at the bottom, thanks all for 
catching this.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Curtis L. Olson

Oliver C. wrote:

I don't think so, in my opinion the status of version 1.0 will decide how many 
new contributers and public interest this project will get.
In other words, my estimation is (when i look into my crystal ball :) ), that 
we will get more people that start contributing to FlighGear with things like 
creating 3d models and aircrafts when it's possible to switch aircrafts 
during runtime. 
When this isn't the case, people might think/say:
OK, this looks nice, but i will wait with contribution until this issue is 
fixed,.

or:
Hm, i think i will give the project a next try when version 2.0 is out.

On the other side we will get more attention even in none computer specific 
newspapers when the issues are fixed and people start to say:

Wow, this is so perfect, this looks so great, what a wonderfull simulator...

That's why we should be carefull about which version we call 1.0
In my opinion version 1.0 is an important release, it's not just a number.
 



I am *very* adverse to 'marketing' via version numbers because it is all 
so meaningless, so I'm not even sure why I'm participating in this 
thread, but the flip side of this is if we stay at 0.9.x too long, all 
these same people are going to look at FG and say ... ohh, they've been 
diddling around with 0.9.x versions for ever,  they must not be doing 
anything serious over there.  I think the issue can be argued both 
ways, but time (and version numbers) marches on.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Aircraft for v0.9.9

2005-11-18 Thread Curtis L. Olson

Aircraft authors (or other interested parties.)

Take a look at the latest aircraft download page:

http://www.flightgear.org/Downloads/aircraft/

There are quite a few aircraft with no thumbnail.jpg created for the web 
page.  We need a 171x128 pixel image for each aircraft that has a 3d 
model.  This needs to be saved as thumbnail.jpg in the aircrafts top 
level directory ... you can look at other aircraft for examples.


It would be great if we could have pictures for everything before we 
spam the world with our v0.9.9 release.


Thanks!

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Release of v0.9.9 source code

2005-11-18 Thread Curtis L. Olson

Hello everyone,

FlightGear v0.9.9 is now final.  The source code is propagating through 
to the mirrors.  If you have built an 'official' binary version of 
FlightGear in the past, it would be great if you could build a binary 
for v0.9.9 as well.  I'm going to make an 'official' v0.9.9 announcment 
in a day or two and I'd like to have precompiled binaries available for 
as many platforms as possible.


Also, we could use a few more screen shot submissions.  Think about 
things that highlight new aircraft, or new features, or just pull 
together a combination of things for a nice or interesting view.


Think about turning *on* anistotropic texture filtering for nicer 
rendering, turn *off* menus (unless that is what you are trying to 
show.)  Turn on shadows, 3d clouds, etc. if you like.


Screen shots need to pass through my 'artistic' filter to be included on 
the web site.  I don't want to hurt anyone's feeling, but I've had a lot 
of screen shot submissions in the past that just didn't make the cut.


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Release of v0.9.9 source code

2005-11-18 Thread Curtis L. Olson

Arthur Wiebe wrote:


Finally! :)

Is there an official major changes list? Something to tell users what
has really changed since 0.9.8?
 



Yup, I began assembling this list with the first v0.9.9 pre release.

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] RenderTexture::BeginCapture(): Texture isnotinitialized!

2005-11-18 Thread Curtis L. Olson

Arthur Wiebe wrote:


I have found the problem. My Xcode projects seem to be buggy. The PLIB
project is fine but something is wrong with the SimGear project.

I just built using the autoconf system and everything worked fine. It
even fixed my spash screen problem! :)
I'll try to have it fixed by tomorrow afternoon if possible.
 



Woohoo!

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org

2005-11-18 Thread Curtis L. Olson

Ampere K. Hardraade wrote:

Perhaps we can have a weekly screenshot competition?  The best screenshot of 
the week get uploaded to FlightGear's frontpage.
 



Sounds like a great idea.  Are you volunteering to manage it? :-)

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org

2005-11-17 Thread Curtis L. Olson

Andy Ross wrote:


Melchior FRANZ wrote:
 


I also wanted to show the Crusader in one shot.  But now that it has
been withdrawn from CVS (with very questionable arguments
   



Not to start a flame war, but maybe someone could bang out a quickie
YASim model for the F-8 so it can be shipped in the 0.9.9 release?
 



Problem is that the entire 3d model has been removed from cvs (by 
request of the author.)  And I'm not going to start playing 
cvs-ping-pong ... either it's in or it's out, and by request of the 
author it's out.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] freeglut issue with recent cvs update

2005-11-17 Thread Curtis L. Olson

Dave Perry wrote:


Since a
cvs update -dP
and recompile of cvs plib, cvs SimGear, cvs fgfs, and data, I am 
getting the following error in the Log Window when I run fgfs from fgrun.


fgfs:freeglut_window.c:300:fgOpenWindow:Assertion 
'window-Window.VisualInfo != ((void*)0)' failed


I am running Fedora Core 3 that is up2date.  rpm -q freeglut returns
freeglut-2.2.0-14.

I have tried changing the color depth from 24 to 16 and get the same 
error.  Was working great with last weekend cvs update.  Anyone else 
having similar experience with current cvs?



One dumb thing to check if you run nvidia hardware.  If you upgraded 
your kernel or other libs with up2date you might have overwritten parts 
of your opengl driver installation (at least with the nvidia drivers 
this can happen.)  It might be worth verifying that you can run other 
opengl programs and if not, take a look at reinstalling your drivers.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Missing Data/ directory in pre3 base package

2005-11-15 Thread Curtis L. Olson

Pigeon wrote:


Hi all,


   It seems the Data/ directory is missing in the pre3 package, which 
basically contains only Data/AI/ at the moment, and hence explains a

few people not able to use the nimitz carrier (Data/AI/nimitz_demo.xml),
and fgfs will simply terminate with a very vague message saying
terminate called after throwing an instance of 'sg_io_exception'
(reported by azuron on IRC).
 



Argh!  Can we pick a different more intuitive name for this directory.  
It got created because the old 3d clouds demo needed it's stuff there, 
but we really need a more intuitive name beyond data/Data ... !


Thanks,

Curt

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] impending v0.9.9 release

2005-11-15 Thread Curtis L. Olson

Hi all,

I would really like to get v0.9.9 out the door this week ... maybe 
committing to the final source code version on thursday or friday.  
However, I would like to give everyone the opportunity to mention any 
show stopping bugs that we should be concerned about.  It's ok to report 
bugs, but at this point we really need people reporting *fixes*.  The 
magic source code gods have this week off so we are going to have to fix 
all the bugs ourselves. :-)


At this time I'm not referring to missing features, and I'm probably not 
interested in discussing long standing limitations.  Right now we need 
to find any recently introduced, or big show stopping problems and fix 
them in the next day or two.


I really really want to get v0.9.9 done this week.  If we wait until 
next week we run into the Thanksgiving holiday here in the USA.  And if 
we put things off another week after that, who knows what my schedule 
will be like.  I really want to get this out this week!  And barring 
something really awful, I plan to do the official v0.9.9 release 
thursday or friday.  So that will be the cutoff and we will take 
whatever we have in cvs as of then.


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] impending v0.9.9 release

2005-11-15 Thread Curtis L. Olson

Christian Mayer wrote:


Great!

Will there be a Windows binary prerelease to test it?
 



Fred is the windows build guru.  I believe he posts his latest builds 
someplace, although I haven't tracked the url lately.  Might be able to 
find it if you search the archives, or maybe Fred will be willing to 
remind us again if he's still awake.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] impending v0.9.9 release

2005-11-15 Thread Curtis L. Olson

Vassilii Khachaturov wrote:


I'm very much concerned about the buggy exception throwing pattern that
flightgear and simgear have (ab)used, and have circa 100 throws to verify
and modify their vicinity in some cases. I have not started this work yet,
so if somebody wants to do it before Friday night, go ahead. Furthermore,
I can not commit at anything right now, because things happen outside of
flightgear (e.g., 15 minutes ago my 3-year-old daughter turned out to have
fever, and this may steal whatever free time I have planned for the next
week altogether).
 



Hi Vassilii,

I do share your concern, however, our exception throwing implimentation 
is not anything new.  If we do have something messed up, it's been that 
way for several releases.  So let's get this next release out and then 
attack this problem before the following release.


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] local time?

2005-11-15 Thread Curtis L. Olson
Question: I see that simgear has functions to return current time 
(GMT).  I see that the simgear sg_time.cxx keeps track of a local 
timezone offset in seconds.  Is there any easy way to get the 'local' 
time split out into HH MM SS.  Are these already tucked away in our 
property system some place?


Thanks,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] SimGear compile dying in MSVC6

2005-11-14 Thread Curtis L. Olson

bass pumped wrote:


Ok... I myself have been having problems with compiling FG with MSVC
7.1, but I've been told this much.  Its way to hard to compile with
MSVC6.  But ofcourse, I submit to the judgement of the masters.  They
know way better.

 



Yes, the general consensus I've heard in the past is that MSVC6 is 
simply too old and buggy to compile a project like flightgear which is 
designed for more modern compilers (and by modern I mean compilers that 
adhere somewhat well to the established C++ standards.)  So it seems 
like your best choices for windows are MSVC7 or cygwin/mingwin if you 
want to go the open-source (free) route.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects

2005-11-14 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Curtis L. Olson -- Monday 14 November 2005 15:12:
 

Let's stick with .../.../Scenery/[Terrain|Objects] on all platforms 
please.  Individuals are welcome to call it whatever they want on their 
system and use the --fg-scenery= option to point to their favoritely 
named directory.
   



Maybe I missed something, but as far as I've understood this thread
is not about renaming $FG_ROOT/Scenery/. It's only about whether to
suggest a standard in the user documentation for where to install
additional scenery, especially when using terrasync. Dumping terrasync
fetched data into $FG_ROOT/Scenery/ is a Really Bad Idea[TM].
 



Not to get overly pedantic, but someone suggested 
.../.../WorldScenery/{Terrain|Objects} for *nix platforms, and the 
person doing the documentation work said ok, so my response was a plea 
to keep things consistent across platforms and just use 
$FG_ROOT/data/Scenery as the root of the scenery tree.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects

2005-11-14 Thread Curtis L. Olson

Melchior FRANZ wrote:


This dir doesn't exist. There's no such thing as $FG_ROOT/data/.
 



Of course there is. :-)

$FG_ROOT/source/
$FG_ROOT/data/
$FG_ROOT/data/Aircraft/
$FG_ROOT/data/Scenery/

This is the prefered structure ...

Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects

2005-11-14 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Curtis L. Olson -- Monday 14 November 2005 16:34:
 


Melchior FRANZ wrote:
   


This dir doesn't exist. There's no such thing as $FG_ROOT/data/.
 



 


Of course there is. :-)
   



Sheesh. I resign.  :-}


 


$FG_ROOT/source/
$FG_ROOT/data/
$FG_ROOT/data/Aircraft/
$FG_ROOT/data/Scenery/

This is the prefered structure ...
   



Not by me. Sourcecode doesn't really belong into /usr/local/share/,
and even less into the shared FlightGear data. But you are the
chief. And I keep my installation sane.  :-P
 



This is a hopeless conversation because everyone wants to do it 
different and there are so many possibilities.


If you are a normal user on a normal unix system you aren't going to be 
able write to /usr/local so that's not even part of the discussion.  And 
a user might want multiple versions of FG on their system so they could 
set up


~/Projects/FG-v0.9.8/source/
~/Projects/FG-v0.9.8/data/
~/Projects/FG-v0.9.8/bin/
~/Projects/FG-v0.9.8/lib
~/Projects/FG-v0.9.8/include
~/Projects/FG-v0.9.8/AddOnScenery

... and ...

~/Projects/FG-v0.9.9/source/
~/Projects/FG-v0.9.9/data/
~/Projects/FG-v0.9.9/bin/
~/Projects/FG-v0.9.9/lib
~/Projects/FG-v0.9.9/include
~/Projects/FG-v0.9.9/AddOnScenery

... and ...

~/Projects/FG-CVS/source/
~/Projects/FG-CVS/data/
~/Projects/FG-CVS/bin/
~/Projects/FG-CVS/lib
~/Projects/FG-CVS/include
~/Projects/FG-v0.9.9/AddOnScenery

Ok, so now the system administrator comes by and you want to install 
this at a system level so everyone can have access ... it's not common 
convention to install the source code.  Instead but you might want to 
have multiple versions of FG installed so you could setup an $FG_ROOT 
for each version.  But this discussion will go in endless circles 
because everyone who cares has their own opinions about how it should be 
done ...


Fortunately people who care usually know what they are doing and why so 
they can set it up however they like.  But this discussion I believe 
started out so we could define what should be in the documentation so my 
only point was that $FG_ROOT officially contains the data/ directory.  
(And for backwards compatibility, the code still supports the old way 
where $FG_ROOT is the data directory.)


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects

2005-11-14 Thread Curtis L. Olson

Martin Spott wrote:


Curt, this does not necessarily work. Apparently you have been
misunderstood by several people for a long time. This makes the
topic really funny  :-)
Looking at the facts, 'fgfs' actually does find the aircraft model,
when data/ resides _below_ $FG_ROOT, but it does _not_ find the
Scenery,
 



Well unless I have some thing else going on locally that I'm not aware 
of, this works out ok for me ... (?)


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects

2005-11-14 Thread Curtis L. Olson

Buchanan, Stuart wrote:


OK, so I think I'd like to suggest that for the Getting Started Guide we
suggest for Windows

whatever_path_to_FG/data/Scenery
whatever_path_to_FG/Scenery

and for *nix

$FG_ROOT/Scenery
/usr/share/FlightGear/Scenery

I'm expecting that *nix users will be familiar enough with their file
system to change it as they see fit, but I'd like to be more prescriptive
for Windows users who are _generally_ not going to be as happy messing
with $FG_SCENERY on their 


Apologies for the confusion that has clouded already muddy water.

 



Stuart,

We can suggest different default locations of $FG_ROOT for different 
systems, but below $FG_ROOT we should use the same structure for all 
platforms.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects

2005-11-14 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Curtis L. Olson -- Monday 14 November 2005 16:54:
 

This is a hopeless conversation because everyone wants to do it 
different and there are so many possibilities.
   



We are talking about different things. You talk about the organization
of source and data in your home directory.



I believe I referenced both situations ... but discussed the home 
directory situation first as justification for the overall structure.



I talk about correct
installation of fgfs on a multiuser system, with system wide FG_ROOT.
Of course, FG_ROOT is not in a user's home dir then. And, of course,
it doesn't contain the source. The source is in my home directory, is
not accessible by other users, and does neither follow the organization
that I described in the thread, nor what you consider preferred.
Also, I wouldn't want to discuss the organization of my home dir in
the fgfs documentation. That's secret!  :-]
 



Ok, I will drop 10 and punt.

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects

2005-11-14 Thread Curtis L. Olson

Vassilii Khachaturov wrote:


I thought about a dedicated account for terrasync (non-root),
with right permissions only to the /var/share/FlightGear/Scenery/Terrain
(or WorldScenery/Terrain).
 



Terragear is sufficiently crude and unrefined and user unfriendly that I 
think we should leave it out of the getting started guide.  We are going 
to send unsuspecting users down a wild goose chase and they'll be 
disappointed.  We can mention it and forward them to more information, 
but I think we are asking for a lot of trouble if we try to document it 
in the getting started guide.  For instance, it requires rsync to be 
installed on your system.  Probably ok for most modern linux/freebsd 
systems, but a big problem for the typical windows user ... and even 
sun/sgi probably don't have it installed by default.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Runtime error 0.9.9 on Debian/Testing

2005-11-12 Thread Curtis L. Olson

Vassilii Khachaturov wrote:


It looks to me that this will be a recurrent issue following 0.9.9 release
as well. Can an autoconf guru please add a relevant check into the
configuration scripts?
 



I see that freeglut-2.2 defines FREEGLUT_VERSION_2_0 = 1

Can anyonen with freeglut-2.4 look and see if it leaves any 
differentiable defines that are different from freeglut-2.2 and 
different from freeglut-cvs?  It's probably possible to craft some sort 
of ugliness into the configure script, but I'd be a little nervous about 
doing something this close to the v0.9.9 release.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Runtime error 0.9.9 on Debian/Testing

2005-11-12 Thread Curtis L. Olson

Alex Perry wrote:


From: Curtis L. Olson [EMAIL PROTECTED]
 


Alex Perry wrote:
   


freeglut  ERROR:  Function glutSetCursor called \
without first calling 'glutInit'.
 

Hey Alex, this has been a 'common' issue that has bit a lot of people.  
There appears to be a problem with freeglut 2.4.  The solution has been 
to downgrade to freeglut 2.2 or run freeglut-cvs.  You could also build 
with sdl (configure --enable-sdl) and that might side step the issue 
altogether.
   



Debian is packaging 2.4.0 under the name freeglut3.
Is there a specific upstream release that contains the fix,
so that I can file a bug against the existing package ?
Otherwise, Debian will be unable to build a current FGFS release.
 



From what I've heard, freeglut-2.2.0 works and freeglut-CVS

It's a shame that this bug crept into Freeglut, because it kind of hurts 
us on a *lot* of platforms. :-(


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)

2005-11-12 Thread Curtis L. Olson

Josh Babcock wrote:


Stefan Seifert wrote:
 


Martin Spott wrote:

   


Ampere K. Hardraade wrote:


 


On another note, this was taken in Singapore recently:
http://www.airliners.net/open.file/957790/L/

Compare to what we have in FlightGear now:
http://www.students.yorku.ca/~ampere/fgfs-screen-005.jpg
 
   


You might want to ignore the two Windows PeeCees for your model  ;-)


 


Are they even Windows? Didn't see an answer in the comments.

Nine

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

   



I wouldn't ignore them, just texture them with this for extra realty:
http://www.sirgalahad.org/paul/sw/winlock/img/bsod.png
Josh
 



How about a spyware popup ... Oh I see you just typed the word Paris, 
here are some great hotel + airfare combinations you might be interested 
in, and would you like me to search ebay for berets?


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: OT: FYI, mac os x developers,

2005-11-12 Thread Curtis L. Olson

Melchior FRANZ wrote:


* Martin Spott -- Saturday 12 November 2005 20:43:
 


Z2h0Z2Vhci1kZXZlbAo+IDJmNTg1ZWVlYTAyZTJjNzlkN2IxZDhjNDk2M2JhZTJkCj4KCgoKLS0K
PEFydGh1ci8+Ci0gaHR0cDovL3NvdXJjZWZvcmdlLm5ldC91c2Vycy9hcnRvb3JvLwotIGh0dHA6
Ly9hcnRvb3JvLmJsb2dzcG90LmNvbQo=
 


So, why are you posting this crap ? Please stop it,
   



This is very standard base64 encoding. Every semi-decent mailer should
be able to display this. Of course, it would be better in readable
ASCII, but I wouldn't say it's crap. Your mailer *is* crap!  :-P
 



Hey, what's wrong with ed /var/mail/curt ...

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: OT: FYI, mac os x developers,

2005-11-12 Thread Curtis L. Olson

Stefan Seifert wrote:

Topposting makes only more sense, when you are too lazy to quote 
selectively instead of just quoting the whole mail (probably including 
signatures and ads...). And to have some context is not only nice when 
reading through an archive, but also when reading a lot of mail each 
day. So it's the easies if you can just open a mail, read a few lines 
to know what the topic is and then read the answer to that and not to 
open a mail, read a sentence, have no clue what it's talking about, 
scrolling to below and start searching for some this vital info.



I can share one little story.  At a company I used to work for, there 
was a long thread of discussion about something between a bunch of 
managers.  In the course of the conversation the messages and replies 
were top posted, bottom posted, multiple comments inserted in the middle 
in some of the quoted messages ... stacked up layer upon layer since 
this conversation had gone on quite a while.  It's hard to even explain 
but one person top posted, then next person bottom posts quoting 
everything from before, and on and on about 15 levels deep.


So at the end of the day, my manager forwards me this huge mish mash of 
nonsense and says, Please fix, see attached.


I spent the next whole day trying to disassemble the message and the 
various layers to try to reconstruct the original conversation.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Announcement: First TerraGear landcover database

2005-11-12 Thread Curtis L. Olson

Arnt Karlsen wrote:

On Thu, 10 Nov 2005 14:11:00 -0600, Curtis wrote in message 
[EMAIL PROTECTED]:


 


I should also point out that the next scenery build (which is
happening  concurrent to the v0.9.9 release and causing my head to
spin 3x faster  than normal (not factoring in beer)) will be based on
this data export.
   



..how much size growth, compared to the (0.9.7?) last scenery?   
(url to the new?)


 



I haven't really started building a lot of tiles yet.  I'm still hung up 
on a shapefile processing issue.  Might be  shade bigger, but I'm not 
expecting a huge difference ...


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] FlightGear v0.0.9-pre3 xglobe licence issue

2005-11-11 Thread Curtis L. Olson

Erik Hofman wrote:


Yes, that's the code.
I now have a fully working version without any of the affected code, 
just a routine which was written by Curtis anyhow.


How should we proceed at this point; add it prior to 0.9.9, or add it 
for 1.0 and provide a patch for 0.9.9?



Erik,

If you could run the clock forward a year or two or five or 10 and 
verify that the new code matches the results of the existing code within 
acceptable tolerences, then I think I'd be ok with sneaking it into v0.9.9


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 0.9.9 scenery?

2005-11-11 Thread Curtis L. Olson

Steve Hosgood wrote:


The main fgfs website only lists scenery for 0.9.8

Is world scenery for 0.9.9 waiting for a stable, offical 0.9.9 release
first?
 



There is a current world scenery rebuild in progress. We are currently 
hung up on a data processing glitch that is being worked on.  The 
scenery and the source release can and will happen independently.  
Rebuilding the world (and trying to fix bugs and improve the result at 
the same time) is a massive undertaking.  The new world will be based on 
SRTM v2 data supplimented with USGS DEM data to fill in the voids where 
possible, i.e. in the usa.  The grand canyon and rhode island will be 
much better. These places glitched out in SRTM and portions never got 
properly mapped.  I also did a complete overhaul of the airport surface 
generation scheme and tossed the old nurbs approach because the nurbs++ 
code is not maintained and is increasingly difficult to compile on 
modern systems.  We are now trying to process the shapefile conversion 
of the vmap data.  If we can crack this, then that opens the doors to 
future user fixes and contributions of land cover/land use data, lakes, 
rivers, roads, etc.


I've been posting very brief notes and updates on the scenery rebuild to 
my personal web page (along with a variety of other stuff that probably 
isn't of great concern to most people in FlightGear land.)


   http://www.flightgear.org/~curt/

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 0.9.9 scenery?

2005-11-11 Thread Curtis L. Olson

Paul Surgeon wrote:


There is 100% void free SRTM data here : http://srtm.csi.cgiar.org/

 



As best as I can see from their site, they just interpolated through the 
voids.  That generally works fine and is pretty much what we did for the 
current scenery, but when you are missing big chunks of things like the 
grand canyon or tops of moutains, then what?  For the USA where we have 
an alternative data source, I filled in the voids from that data which 
is good for things like the grand canyon and rhode island that are 
missing huge chunk.  It might bite me elsewhere, but I hope not too 
much.  Outside the USA our algorithm still just interpolates through the 
holes.


Regards,

Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 0.9.9 scenery?

2005-11-11 Thread Curtis L. Olson

Oliver C. wrote:


On Friday 11 November 2005 18:40, Curtis L. Olson wrote:

 


As best as I can see from their site, they just interpolated through the
voids.  That generally works fine and is pretty much what we did for the
current scenery, but when you are missing big chunks of things like the
grand canyon or tops of moutains, then what?  For the USA where we have
an alternative data source, I filled in the voids from that data which
is good for things like the grand canyon and rhode island that are
missing huge chunk.
   



Isn't SRTM data version 2 allready corrected manually?

That's what i thought, when i heard sth. about SRTM v2.
 



SRTM still has all the voids as far as I know.  They've done other 
corrections, but not void filling (as far as I know.)  I can vouch for 
the fact that it still does have a lot of voids, although I can't say 
for sure if it's all the same ones or fewer or more.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] V9.9 test run

2005-11-11 Thread Curtis L. Olson

[EMAIL PROTECTED] wrote:

I compiled 9.9 test version on my Thinkpad T42 (I'm on the road) and after loading the cloud file, it worked for the default Cessna.  However, when I tried the Citation I got the following messages, and it would not take off.  It also had a couple of the instruments on the left side o f the panel (clock and the one above it)  that were largely obscured by 
gray lines.  Couldn't do much else without a joystick, which is not where I am.


Hope this helps somebody,

Rex


fgfs --aircraft=Citation-II
Dent: ..Dent: EHAMDent: .opening file: 
/usr/local/share/FlightGear/data/Navaids/carrier_nav.dat
/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat
RenderTexture Error: Couldn't find a suitable pixel format.
open /dev/[sound/]dsp: Device or resource busy
Audio initialization failed!
WARNING: ssgLoadAC: Failed to open 
'/usr/local/share/FlightGear/data/Aircraft/c172r/Models/c172-dpm.ac' for reading
Reading xml electrical system model from 
/usr/local/share/FlightGear/data/Aircraft/beech99/beech99-electrical.xml
Failed to load electrical system model: 
/usr/local/share/FlightGear/data/Aircraft/beech99/beech99-electrical.xml
netAddress::set: Resource temporarily unavailable
Initialising callsign using 'Aircraft/Citation/Models/Citation-II.xml'
 



Ahhh, good catch.  The citation-ii has an external dependency on an 
aircraft not distributed with the base package.  This will be fixed in 
the next round ...


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] FlightGear v0.0.9-pre3

2005-11-11 Thread Curtis L. Olson

Jon Stockill wrote:



The following files probably *shouldn't* be there:

Aircraft/A-10/.#A-10cl-set.xml.1.6
Aircraft/c172/Models/.#c172p.ac.1.1
Aircraft/c172/Panels/.#default.xml.1.3
Aircraft/c172/Panels/.#c172-panel.xml.1.8
Aircraft/c172/Panels/.#c172-panel.xml.1.4
Models/Trees/.#deciduous-tree.ac.1.3
Scenery/Terrain/w130n30/w123n37/.#KSFO.btg.gz.1.2



Ok, sorry about the emacs droppings, I'll get rid of those for the next 
round.  Thanks for catching this.


Curt.

--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


  1   2   3   4   5   6   7   8   9   10   >