RE: [Flightgear-devel] [Repost] Simulating ground activity (fwd)
Seamus Thomas Carroll writes: Can you direct me to where i can find HitList::fgCurrentElevation()? i have run grep on simgear and flightgear plus searched in google and I still cant find mention of this function. FGFS_SRC / Scenery / HitList Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec -- preliminary
John Barrett wrote: Here is a quick and dirty 1st cut at a wire protocol definition, and some requirements for the message handling classes that will implement the protocol Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Objection. Use network byte order (ntohl and the like) instead. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
Martin Spott wrote: David Luff [EMAIL PROTECTED] wrote: On 11/5/03 at 1:38 PM John Barrett wrote: I'm aware of the basic raw multiplayer and the OLK code (which I peeked at and am still trying to figure out the details) and what is the 3rd one ?? Dont see anything in CVS for it.. I think that was probably the Ace project. It never went into CVS as far as I know - I think it might have been a student project. Thanks - that's what I meant, but I could'nt remember the name, http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
David Luff [EMAIL PROTECTED] wrote: On 11/5/03 at 1:38 PM John Barrett wrote: I'm aware of the basic raw multiplayer and the OLK code (which I peeked at and am still trying to figure out the details) and what is the 3rd one ?? Dont see anything in CVS for it.. I think that was probably the Ace project. It never went into CVS as far as I know - I think it might have been a student project. Thanks - that's what I meant, but I could'nt remember the name, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec --
John Barrett [EMAIL PROTECTED] wrote: Unless there are objections, byte order is little endian, and floats are = intel FPU standard (ok -- i'm making it easy on the PCs that will likely = be used to run display clients :) I'm not qualified to comment on the float size, others may do. But I'd recommend to stick to common convention regarding byte order. This should comply to network byte order (big-endian in most cases I usually deal with). Anyway I'm delighted to see a documented wire protocol proposal. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compliation of CVS Source Error --ssgCullandDraw
Seamus Carrol got the same problem - now I am getting it too! (src, simgear and plib all cvs versions). Did anybody manage to fix it? Melchior and Andy will appreciate that this is a HUGE advance in the build, thanks to their patient explanations of CVS and other mysteries. Thanks, R - Original Message - From: Will Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 31, 2003 10:57 AM Subject: [Flightgear-devel] Compliation of CVS Source Error Hello: I cannot get the CVS source to compile. I updated at 5:30am GMT. Here is the final error in the ./scene/sky directory: /usr/local/src/flightSim/SimGear/simgear/scene/sky/cloud.cxx:453: undefined reference to `ssgCullAndDraw(ssgRoot*)' /usr/local/lib/libsgsky.a(sky.o)(.text+0x7fc): In function `SGSky::preDraw(float, float)': /usr/local/src/flightSim/SimGear/simgear/scene/sky/sky.cxx:175: undefined reference to `ssgCullAndDraw(ssgRoot*)' collect2: ld returned 1 exit status ++Peace, -- Will Howard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Repost] Simulating ground activity (fwd)
On 11/6/03 at 2:28 PM Seamus Thomas Carroll wrote: I now have cubes and cylinders of various colours moving around in the flightgear world. Currently I specify a starting lon, lat and the roaming distance in meters in either the lon, lat direction. I can have about 100 vehicles being updated 3 times a second each before my p4 1.4ghz really begins to slow down (20fps). Currently the vehicles move in a rondom direction at a randomly changing speed. The min and max speed limit is expressed in km/h so accurate movement is not dependant on the number of frames per second. I would like to say thanks to those that have helped me so far. The next step is to have the vehicles move down the real road networks (stored in postgres using the postgis module) at the proper speed limits. Before I do this I am trying to eek out better performance. Here is my question: Is it possible to determine if a vehicle is in the viewing area of the plane using the lon, lat of the vehicle? If this is so I will be able to eliminate large amounts of computation. You might want to make sure you know whether it's displaying the models or computing their position that's slowing the code down. Should be quite easy - just compare displaying them as statics, displaying them with computed movements, and just computing movements without displaying them. Sorry if I'm teaching my Grandmother to suck eggs!!! (But I would be interested in the results!) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flightgear CVS undefinded reference error
Did you get your ssgCullAndDraw error fixed? I have the same thing! Tks, R ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cvs guest oops ??
I was working on the directory layout and autoconf for my server module, and the CVS app I'm using requires that everything be added to the repository before a patch can be created -- without thinking, I added src/Server, and the cvs guest account allowed me to do it !! Doing patches is a new thing for me -- whats the correct diff command line to produce a patch given the current cvs tree and my modified tree ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
* [EMAIL PROTECTED] (Norman Vine) [2003.11.06 05:51]: Melchior FRANZ writes: * Norman Vine -- Thursday 06 November 2003 10:10: John Barrett writes: primary goal: blow them outa the sky !! FWIW Historicaly FlightGear has resisted being a Military SIM. (actually resisted is not a strong enough word) From the FAQ (http://www.flightgear.org/Docs/FAQ.shtml#7.4): | 7.4 - Is there support for any military scenarios like dog | fighting or bomb dropping? | | No, we do not currently support combat. Most of our developers | are primarily focused on civilian aviation. We aren't explicitly | excluding these features -- we just haven't had anyone who seriously | wanted to develop these areas. | | However, FlightGear does contain several military aircraft, albeit | without munitions. Doesn't sound like such a strong resistance. :- There is a *huge* differeance between having military aircraft in a 'flight' simulator and a 'combat' simulator. If you want to simulate combat please make it a separate project Nothing wrong with building atop of FGFS, and in fact FGFS tries to be accomodating in that respect. I wrote that FAQ entry after seeing several discussions about combat in FG. I never heard anyone say what you are saying Norman (ie. go away. we aren't going to do combat). I believe I also sent that entry to Curt before publishing it to make sure I wasn't off base. Now, there are a few people involved in FG that are very opposed to a combat framework, but there are an equal number of people that are very interested in adding it. The rest of us (including me) fall somewhere in the middle: if we don't have combat or if we do, I'm still going to enjoy FG. Having said that, I think the addition of combat capabilities should be done in a modular, non-intrusive way. I don't think we should force someone to create a fork of FG just so they can implement projectiles and a damage model. To the folks that want combat, work real hard to support a --with-combat=no option, or you're gonna get shot down real fast. ;-) -- Cameron Moore / The other day, I went to a tourist information booth and asked, \ \ Tell me about some of the people who were here last year./ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
David Megginson [EMAIL PROTECTED] said: Paul Surgeon writes: 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) That's pretty ancient. Our current 172 looks a fair bit better. U... that release is less than two weeks old ;-). There are a couple of 172's and they are fairly low poly models. Some work is being done in the 3D engine to improve rendering, which might be part of the complaint. Anyway, IMHO there is nothing wrong with low poly models, especially ones as well done as these. This doesn't mean that a high poly version would not be welcome as an alternative if you want to build one Paul. It'd be nice to have a full set of 3D instruments to go in it as well :-) Recently I aquired a copy of the latest MSFS. It's the first I've bought since MS took it over from SubLogic! (No I haven't gone crazy and joined the other side. It was USED and very cheap so my rational was it would not put money directly into the pockets of the microsoft billionaires club :-)). After spending a two or three hours with it my impression is that there are two ways to value eye candy...quality and quantity. The MS has a lot more quantity because of all the bodies they threw at it. We're there, or better, with the quality. For those inteterested in the appearance of the scene and the aircraft, all they need to do is go to work and build some models. BTW I can also say now that I understand now how much of a threat the FLY! series was to the microsoft product. Too bad it failed...but it looks like FlightGear is destined to someday be a major influence in the popular arena. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Jim Wilson writes: That's pretty ancient. Our current 172 looks a fair bit better. U... that release is less than two weeks old ;-). I'm losing track of release numbers, then, but the clunky 172 model with the yellow tint on wings has not been our default for a long time. Maybe he got it by specifying --aircraft=c172r-3d or something similar. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Instrument and Panel README
Is there a README, FAQ, or manual on making instruments for a panel and/or creating the panel itself? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
- Original Message - From: Cameron Moore [EMAIL PROTECTED] To the folks that want combat, work real hard to support a --with-combat=no option, or you're gonna get shot down real fast. ;-) -- Already there and them some :) I'm working up the protocol base classes at the moment, and I went so far as to make the entire client/server code enabled/disabled by configure option, then, as added protection for those not interested in what I'm adding on, I added a new executable target to the Main makefile -- fgmp -- when you build, you get a stock FG binary, and if enabled, the multiplayer version that uses the client/server extensions. That should keep everyone happy who does not want a tainted binary, and allow easy performance/etc comparison between stock fgfs and fgmp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Friday, 7 November 2003 06:39, Nick Coleman wrote: As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) That's odd - once I had set up and saved a default flight it was just a matter of starting the sim and away I went. I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. I'm not trying to rain on the OP's parade; I think he has some good ideas. It's just that I would prefer to see development take priority in the fields I am interested in, naturally enough. Well my point is that I'll do the development in the eye candy department. It does not have to detract from anyone elses time. :) I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. Thanks for your input though - I do understand where you are coming from even if I don't quite understand your reasons. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
David Megginson wrote: Jim Wilson writes: That's pretty ancient. Our current 172 looks a fair bit better. U... that release is less than two weeks old ;-). I'm losing track of release numbers, then, but the clunky 172 model with the yellow tint on wings has not been our default for a long time. Maybe he got it by specifying --aircraft=c172r-3d or something similar. It might be caused by the fact that he is probably using the configuration for slower machines which I posted last week, which is not a good test case because it also reduced the fmd update to 60 Hz. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon wrote: On Friday, 7 November 2003 06:39, Nick Coleman wrote: As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. IMHO there are two kinds of eye candy. The ones that are necessary for learning (snow/rain, fog) and the once that don't add anything but nice views (dust clouds on touchdown and such). So far I've mostly concentrated on the first type by adding better textures and sunset/sunrise effects. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Version[s]
Suggestion: for debugging purposes (if nothing else) it would be useful to have this command: fgfs --version also spit out info on other pertinent version numbers, e.g. for: plib simgear jsbsim yasim etc. JSBSim has this available in a header file, and IIRC it is also available in a function call. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Bring on the eye candy :) and a good config gui to control how much candy you eat (along with everything else that a config gui should do -- joystick calibration, screen resolution, sounds and sound volume, load/save config) I personally have a problem with relying on a seperate project to create the config gui for FG, as there will always be lag from when FG releases new features until the gui catches up -- there needs to be a startup gui included that gets updated right along with each new feature -- nothing fancy, just enough to control all the features. Re: priority on fast frame rates -- I've always had a problem with the idea of frame rates faster than the display refresh speed - I've seen plenty of Quake III benchmarks that claim 150-300 fps, which technically is impressive, but as far as actual usage, seems pretty useless on a display that only updates 80 fps at best. Get FG up around 60-80 fps (on a 2ghz machine + GeForce2/64mb or better) with most if not all the eye candy options turned on, and I'll be very happy. - Original Message - From: Paul Surgeon [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 07, 2003 4:31 AM Subject: Re: [Flightgear-devel] Some thoughts and ideas (LONG) On Friday, 7 November 2003 06:39, Nick Coleman wrote: As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) That's odd - once I had set up and saved a default flight it was just a matter of starting the sim and away I went. I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. I'm not trying to rain on the OP's parade; I think he has some good ideas. It's just that I would prefer to see development take priority in the fields I am interested in, naturally enough. Well my point is that I'll do the development in the eye candy department. It does not have to detract from anyone elses time. :) I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. Thanks for your input though - I do understand where you are coming from even if I don't quite understand your reasons. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon [EMAIL PROTECTED] said: I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. There are several people working on this stuff and more is certainly welcome. If you keep looking I think you'll find some pretty amazing visual work already in FlightGear. Have you headed north from the default runway yet (toward downtown)? BTW if you've got talent, be it in modeling or coding, it is hard for me to imagine that you won't get an enthusiastic response from at least some of the users. There will always be a wide range of interests here and I think flightgear provides the flexibility to satisfy many. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Version[s]
* Jon S Berndt -- Friday 07 November 2003 19:15: Suggestion: for debugging purposes [...] JSBSim has this available in a header file, and IIRC it is also available in a function call. ... and not only that: $ ident `which fgfs` m. ;-) BTW: you can easily invent new ident keywords, like $YASim: v12.34 $ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
- Original Message - From: Jim Wilson [EMAIL PROTECTED] There are several people working on this stuff and more is certainly welcome. If you keep looking I think you'll find some pretty amazing visual work already in FlightGear. Have you headed north from the default runway yet (toward downtown)? Ok -- try this idea on for size -- we've already heard mention of handling different periods of time re: aircraft capabilities, extend that idea to terrain modeling -- i.e. you could have chicago details for each decade since 1930, have the scenario system decide which specific terrain overlay to apply to a region -- I'm not suggesting that there be an intensive effort on anyones part to create a broad range of overlays, just that the ability be there so that scenario designers can select existing overlays, or create them using an overlay editor BTW if you've got talent, be it in modeling or coding, it is hard for me to imagine that you won't get an enthusiastic response from at least some of the users. There will always be a wide range of interests here and I think flightgear provides the flexibility to satisfy many. Hehehe -- what gets me is the stay out of my sandbox crowd -- would rather find ways to work together :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument and Panel README
On Friday 07 November 2003 12:10 pm, Jon S Berndt wrote: Is there a README, FAQ, or manual on making instruments for a panel and/or creating the panel itself? Try F1 Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: On Friday, 7 November 2003 06:39, Nick Coleman wrote: I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I see no conflict at all between eye candy and frame rates as long as it's all user configurable. I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. Ultimately, the only votes that really count come with patches attached :-) If no one want's any visual improvements in FlightGear then I better not waste my time. Believe me, any visual improvements you make would/will be much appreciated, just as the work of Fred Bouvier, Erik Hofman, Lee Elliot, Jim Wilson and many others in the visual department has been and is much appreciated. Personally I agree with Jim's comment that the main area we suffer in currently is quantity - the single biggest eye candy improvement that could be made now that downtown LA and the Bay bridges have been/are being done would be to populate the World's (or at least the Bay area's) airports with buildings and the odd static. So far KSFO is the only one with anything. And with a .za address, you might like to dig out FALA's runways from their trench ;-)) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Alpha channels in textures
Obviously FG supports alpha channels in textures used for 3D objects like trees but is the same true for ground textures? i.e. Can FG do multitexturing (blend two textures together based on an alpha channel)? Thanks Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Saturday, 8 November 2003 02:08, David Luff wrote: And with a .za address, you might like to dig out FALA's runways from their trench ;-)) Haha! Not only FALA but FAJS and many others too. I found the approaches rather exciting although not very realistic. :) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Alpha channels in textures
Paul Surgeon wrote: Obviously FG supports alpha channels in textures used for 3D objects like trees but is the same true for ground textures? i.e. Can FG do multitexturing (blend two textures together based on an alpha channel)? Not yet. I've been playing a bit with the idea to make the water textures semi transparent and draw the cloud layers at the same, but negated altitude to create a reflection effect. I've done just very limited testing and didn't get it working at that point. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compliation of CVS Source Error --ssgCullandDraw
I am thinking back as hard as I can and I cant pin point how things began working. I was having problems with CVS not updating files I had modified with cvs update -d -P. I downloaded a brand new cvs for flightgear and it began to compile (and maybe simgear). HTH, Seamus On Fri, 7 Nov 2003, Richard Hornby wrote: Seamus Carrol got the same problem - now I am getting it too! (src, simgear and plib all cvs versions). Did anybody manage to fix it? Melchior and Andy will appreciate that this is a HUGE advance in the build, thanks to their patient explanations of CVS and other mysteries. Thanks, R - Original Message - From: Will Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 31, 2003 10:57 AM Subject: [Flightgear-devel] Compliation of CVS Source Error Hello: I cannot get the CVS source to compile. I updated at 5:30am GMT. Here is the final error in the ./scene/sky directory: /usr/local/src/flightSim/SimGear/simgear/scene/sky/cloud.cxx:453: undefined reference to `ssgCullAndDraw(ssgRoot*)' /usr/local/lib/libsgsky.a(sky.o)(.text+0x7fc): In function `SGSky::preDraw(float, float)': /usr/local/src/flightSim/SimGear/simgear/scene/sky/sky.cxx:175: undefined reference to `ssgCullAndDraw(ssgRoot*)' collect2: ld returned 1 exit status ++Peace, -- Will Howard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 7, Issue 24
On Sat, 8 Nov 2003 09:30 am, [EMAIL PROTECTED] wrote: Message: 8 Date: Sat, 8 Nov 2003 00:08:30 + From: David Luff [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Some thoughts and ideas (LONG) To: FlightGear developers discussions [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Paul Surgeon writes: On Friday, 7 November 2003 06:39, Nick Coleman wrote: I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I see no conflict at all between eye candy and frame rates as long as it's all user configurable. Totally agree, Nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Nick Coleman wrote: On Fri, 7 Nov 2003 11:46 am, [EMAIL PROTECTED] wrote: Preface == I would like to see the sim become more friendly to casual users especially on the eye candy side of things. This does not need to detract from the scientific/academic nature of FlightGear - you guys can carry on with the great work. My reason for this is that a lot of people who play with sims can also develop addons but there needs to be an incentive to get them involved and screenshots say more than a thousand words can. As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) Yes, I agree as well! IMO we should make FG as CPU friendly as possible and should maintain the ultra-realism as a primary goal. Ground trees, super detailed objects and 3d clouds should always be optional if they eat more than 20% FPS altogether. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Sat, 8 Nov 2003 09:30 am, [EMAIL PROTECTED] wrote: Message: 3 Date: Fri, 7 Nov 2003 15:31:29 -0500 From: John Barrett [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Some thoughts and ideas (LONG) To: FlightGear developers discussions [EMAIL PROTECTED] Re: priority on fast frame rates -- I've always had a problem with the idea of frame rates faster than the display refresh speed - I've seen plenty of Quake III benchmarks that claim 150-300 fps, which technically is impressive, but as far as actual usage, seems pretty useless on a display that only updates 80 fps at best. Get FG up around 60-80 fps (on a 2ghz machine + GeForce2/64mb or better) with most if not all the eye candy options turned on, and I'll be very happy. The quake engine uses framerates for its calculations, so faster is always better, even if the display can't use it. The fraggers always used to complain when someone else is jumping all around them 'cause their framerate was higher ;). As well, there is some modulo framerate that is optimal (125 from memory). I don't know how fgfs uses it, so can't comment. Sorry if my comments came out negative, I didn't mean them to be. I was just offering another viewpoint from someone who uses fgfs more for things like IFR nav practice, rather than zooming about shooting at things (not that there's anything wrong with that--Seinfeld). I totally agree that eyecandy should be able to be included, as long as it is a configurable option for those who don't want it, either in the make stage or in the startup stage. Nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Saturday, 8 November 2003 01:05, Nick Coleman wrote: totally agree that eyecandy should be able to be included, as long as it is a configurable option for those who don't want it,either in the make stage or in the startup stage. What about in the menu system? Switch it off and it stays off for good without having to complicate build procedures or always having to launch with a string of I don't want that or that or that ... parameters. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon wrote: On Saturday, 8 November 2003 01:05, Nick Coleman wrote: totally agree that eyecandy should be able to be included, as long as it is a configurable option for those who don't want it,either in the make stage or in the startup stage. What about in the menu system? Switch it off and it stays off for good without having to complicate build procedures or always having to launch with a string of "I don't want that or that or that ..." parameters. Paul Yes, that would be perfect. But IMO you should also be able to access *all* the possible options in menu via command line parameters as well. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
* [EMAIL PROTECTED] (John Barrett) [2003.11.07 11:12]: - Original Message - From: Cameron Moore [EMAIL PROTECTED] To the folks that want combat, work real hard to support a --with-combat=no option, or you're gonna get shot down real fast. ;-) -- Already there and them some :) I'm working up the protocol base classes at the moment, and I went so far as to make the entire client/server code enabled/disabled by configure option, then, as added protection for those not interested in what I'm adding on, I added a new executable target to the Main makefile -- fgmp -- when you build, you get a stock FG binary, and if enabled, the multiplayer version that uses the client/server extensions. That should keep everyone happy who does not want a tainted binary, and allow easy performance/etc comparison between stock fgfs and fgmp In case you are misunderstanding what I am talking about, let me clarify. Noone (that I know of) is opposed to multiplayer/multipilot capabilities being in FG. What we are debating is combat -- ie. modelling projectiles such as bombs, bullets, and rockets and their resulting damage to objects. These are two separate problems, though one is a prerequisite of the other. -- Cameron Moore [ So what's the speed of dark? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Version[s]
* [EMAIL PROTECTED] (Jon S Berndt) [2003.11.07 12:16]: Suggestion: for debugging purposes (if nothing else) it would be useful to have this command: fgfs --version also spit out info on other pertinent version numbers, e.g. for: plib simgear jsbsim yasim etc. JSBSim has this available in a header file, and IIRC it is also available in a function call. How about putting them in the property tree? /versions/fgfs = 0.9.4 /versions/plib = 1.6.0 /versions/simgear = 0.3.4 /versions/jsbsim = 0.9.4 ... Then you could just loop through /versions/* and spit out the values. This way, any component can register its version for the user to view. -- Cameron Moore / Right now I'm having amnesia and deja vu at the \ \ same time. I think I've forgotten this before. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
Cameron Moore writes: In case you are misunderstanding what I am talking about, let me clarify. Noone (that I know of) is opposed to multiplayer/multipilot capabilities being in FG. What we are debating is combat -- ie. modelling projectiles such as bombs, bullets, and rockets and their resulting damage to objects. These are two separate problems, though one is a prerequisite of the other. Indeed multiplayer, multipilot and even remote pilot capability has always been a desired capability, and AFAIK one of the primary motivators of FGFS being made 'network' aware. Speaking of which it's been awhile since I have checked up on the remote jpeg server capability. IMO It would be really neat if a 'web jockey' were to integrate the jpg server and the http interface into a single served page. When I was developing the thing I mucked around with a remote proxy server a couple of lines of python put that the http interface and the jpeg into frames so both were on the same page, this was pretty cool in that I could monitor/control FGFS running on my machine at home that was on a dialup from just about anywhere :-) cheers norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
