Re: [Flightgear-devel] Electrical system work..
.Gene Buckle wrote: Avionics power ratings are always available as nominal and max normal draw. Electrical systems are designed with a bit of extra capacity to deal with power on rush current, etc. The only time an aircraft author would have to give the the current draw any thought at all is if they're also building special avionics and even then, they only really need to specify the nominal draw. The only time the breakers will pop is either on command from an instructor station or via a random systems failure routine. But then there is no need to define amperage in the instruments, is there? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Curtis L. Olson writes: Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. Norman Vine writes: - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile It's easy to chop up polygons on tile boundaries, but you are probably referring to airport areas. :-) I am referring to any polygon whether or not they are part of an airport area is immaterial :-) This has been discussed before and I do appreciate the 'pain' factor on the construction side of things but having to special case airports to cross tile boundaries is a killer when it comes to subdivision and or indexing schemes. - Ability to page terrain / textures so continuous flights around the world are still possible. :-) I only say this because I've seen a lot of ROAM type demos that look cool for a small area, but I get the sense that it's a bit trickier to build an entire seamless earth. It's probably been done in commercial games (?) but I haven't seen this done in the open souce world. Hence my smiley, also I am not convinced that FGFS should adbandon using pretesselated scenery in favor of a ROAM approach. This doesn't necessarily mean that we can't have scenery LOD though Modeling the entire world is a good way to keep yourself honest. :-) You are preaching to the choir here :-) I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler We have to be careful though of objects floating up and down noticable as the underlying terrain LOD changes. Yes and the Local Z simplification really only applies to ROAM like tesselations not TINs We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. My understanding is that roads, rivers, lakes, cities, etc. (all that stuff we handle with 2d polygons right now) could be embedded in the aerial photos / textures that we are draping over the terrain, so there would be no need to cut them in as polygons. I am not necessarily suggesting a ROAM approach as the data requirements are humongous both for the textures and the elevations. What I think would be most beneficial is to write an abstract interface for terrain first so that the actual mechanism used is not exposed to the rest of the SIM. What we have is a good start on this. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Who is John Ridouts?
On Fri, 14 Nov 2003, Lee Elliott wrote: Hello list, Basically more for info and speculation than anything else. I've just received an e-mail from a 'John Ridouts' that consists of nothing but an attachment titled '~WRD0564.scr' It's a virus - new mimail variant. The reason I mention it here is that it was also addressed to a number of people I recognise from this place. It harvests addresses from your machine, so it's someone who's seen your address somewhere, and presumably the flightgear list too. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
.Gene Buckle wrote: Avionics power ratings are always available as nominal and max normal draw. Electrical systems are designed with a bit of extra capacity to deal with power on rush current, etc. The only time an aircraft author would have to give the the current draw any thought at all is if they're also building special avionics and even then, they only really need to specify the nominal draw. The only time the breakers will pop is either on command from an instructor station or via a random systems failure routine. But then there is no need to define amperage in the instruments, is there? Yes there is. That's where the load definition belongs. The load figure should follow the equipment, not the bus it's connected to. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
Gene Buckle wrote: .Gene Buckle wrote: Avionics power ratings are always available as nominal and max normal draw. Electrical systems are designed with a bit of extra capacity to deal with power on rush current, etc. The only time an aircraft author would have to give the the current draw any thought at all is if they're also building special avionics and even then, they only really need to specify the nominal draw. The only time the breakers will pop is either on command from an instructor station or via a random systems failure routine. But then there is no need to define amperage in the instruments, is there? Yes there is. That's where the load definition belongs. The load figure should follow the equipment, not the bus it's connected to. Ah, I didn't realize those where two separate issues. So we need the nominal power consumption for the battery lifetime and such. That makes sense. This would be an excellent improvement. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cygwin js-server build error
make[2]: Entering directory `/cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/source/utils/js_server' g++ -g -O2 -L/usr/X11R6/lib -o js_server.exe js_server.o -lplibjs -lplibnet -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x366): In function `_ZN10jsJoystick4openEv': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 99: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x6e4): In function `_ZN10jsJoystick7rawReadEPiPf': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin js-server build error
- Original Message - From: John Barrett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 10:47 AM Subject: [Flightgear-devel] cygwin js-server build error make[2]: Entering directory `/cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/source/utils/js_server' g++ -g -O2 -L/usr/X11R6/lib -o js_server.exe js_server.o -lplibjs -lplibnet -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x366): In function `_ZN10jsJoystick4openEv': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 99: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x6e4): In function `_ZN10jsJoystick7rawReadEPiPf': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? Forget that question -- needed $(audio_LIBS) added to js_server_LDADD in utils/js_server/Makefile.am ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin js-server build error
- Original Message - From: John Barrett [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 14, 2003 11:01 AM Subject: Re: [Flightgear-devel] cygwin js-server build error - Original Message - From: John Barrett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 10:47 AM Subject: [Flightgear-devel] cygwin js-server build error make[2]: Entering directory `/cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/source/utils/js_server' g++ -g -O2 -L/usr/X11R6/lib -o js_server.exe js_server.o -lplibjs -lplibnet -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x366): In function `_ZN10jsJoystick4openEv': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 99: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x6e4): In function `_ZN10jsJoystick7rawReadEPiPf': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? Forget that question -- needed $(audio_LIBS) added to js_server_LDADD in utils/js_server/Makefile.am same change needed for 3dconvert ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin js-server build error
John Barrett wrote: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? Forget that question -- needed $(audio_LIBS) added to js_server_LDADD in utils/js_server/Makefile.am same change needed for 3dconvert Odd. Anyhow, it's added to CVS. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin js-server build error
- Original Message - From: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 14, 2003 12:53 PM Subject: Re: [Flightgear-devel] cygwin js-server build error John Barrett wrote: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? Forget that question -- needed $(audio_LIBS) added to js_server_LDADD in utils/js_server/Makefile.am same change needed for 3dconvert Odd. Anyhow, it's added to CVS. They both needed the windows multimedia library, and that was listed in $(audio_LIBS) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Weight Balance data...
After looking through the various instrumentation files, I noticed that there is no weight data associated with the instruments. For those that don't know, each instrument that goes into the panel is labeled with its weight. This is done to make sure that an accurate dry weight can be calculated. Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: FlightGear presence on the Net
I'm amazed at how many times I've searched for info on wgs84 and projections and datums on Google and get FlightGear mailing lists appearing on the first page. It's good to see that FlightGear/TerraGear are so highly regarded in the GIS world. ;) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] automake question
I've got some code from another project that I'm trying to hook into FG... it uses a short compiled program to generate a header file used by the rest of the package... I've added the program to Makefile.am, and it builds, now, how do I get that program to execute before the library that depends on the header is compiled ?? (library code in the same folder and same Makefile.am as the header generator program) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] automake question
John Barrett writes: I've got some code from another project that I'm trying to hook into FG... it uses a short compiled program to generate a header file used by the rest of the package... I've added the program to Makefile.am, and it builds, now, how do I get that program to execute before the library that depends on the header is compiled ?? (library code in the same folder and same Makefile.am as the header generator program) This is starting to get into some tricky automake/autoconf voodoo if you want to run compiled programs in the middle of the build. Also consider that this could hose anyone who might want to cross compile. I don't know anyone who does, but last time I tried the win32 cross compiler on linux, it ran about 10x faster than natively on windows on the same hardware. That was years ago though and I'm sure cygwin has drastically improved it's performance on windows in the mean time. Anyway, this sort of stuff can really up the complexity of the build system so I'd *really* like to avoid it if at all possible. That said, the autoconf configure script works by generating little programs and executing them (or at least testing if they can be compiled, linked, etc.) So it might be possible to work something into the configure script if it was simple enough ... not that I'm excited about the idea ... Is there anyway you can restructure things to avoid needing to do this? Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Weight Balance data...
On Fri, 14 Nov 2003 11:20:42 -0800 (PST) Gene Buckle [EMAIL PROTECTED] wrote: Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. The only problem with that I think is that it won't do much good unless the entire aircraft is itemized, and most of the components' weights won't be known or knowable. I don't think it would buy us anything in noticable dynamic effects. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Weight Balance data...
Gene Buckle writes: After looking through the various instrumentation files, I noticed that there is no weight data associated with the instruments. For those that don't know, each instrument that goes into the panel is labeled with its weight. This is done to make sure that an accurate dry weight can be calculated. Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. I don't think we need to worry -- anything semi-permanently installed in the plane (seats, gauges, radios, intercom, etc.) is already included in the published empty weight and moment (which is ammended by an AME [Canada] or IA [U.S.] whenever anything is installed or removed). In a 172 or Cherokee, even the oil is already included in the empty weight. In fact, some things are easily removeable -- most avionics pop out of their trays so that you can bring them in for repair, take them home, etc., without any signoff from an AME/IA. I have also removed and reinstalled VOR and ADF heads, which are a little trickier, but mostly because of the limited working space on the floor under the panel (I needed an AME signoff to reinstall them, but not to take them out). In theory, pilots should ammend the WB whenever they take anything out temporarily or put it back in, but in practice, the weight is so small and so close to the CG that people don't seem to bother. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Weight Balance data...
Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. The only problem with that I think is that it won't do much good unless the entire aircraft is itemized, and most of the components' weights won't be known or knowable. I don't think it would buy us anything in noticable dynamic effects. Thanks Jon. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Who is John Ridouts?
On Friday 14 November 2003 11:11, Jon Stockill wrote: On Fri, 14 Nov 2003, Lee Elliott wrote: Hello list, Basically more for info and speculation than anything else. I've just received an e-mail from a 'John Ridouts' that consists of nothing but an attachment titled '~WRD0564.scr' It's a virus - new mimail variant. The reason I mention it here is that it was also addressed to a number of people I recognise from this place. It harvests addresses from your machine, so it's someone who's seen your address somewhere, and presumably the flightgear list too. -- Jon Stockill [EMAIL PROTECTED] Yeah - what I figured (didn't know the varient). Curious about it being so far out of date though. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Electrical system work..
Also, on some small twin's you can't run everything on only one bus. So if you have a problem with one of the buses or the alternator you will have to shut down some extra stuff or risk draining your battery. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman Sent: Friday, November 14, 2003 9:42 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Electrical system work.. Gene Buckle wrote: .Gene Buckle wrote: Avionics power ratings are always available as nominal and max normal draw. Electrical systems are designed with a bit of extra capacity to deal with power on rush current, etc. The only time an aircraft author would have to give the the current draw any thought at all is if they're also building special avionics and even then, they only really need to specify the nominal draw. The only time the breakers will pop is either on command from an instructor station or via a random systems failure routine. But then there is no need to define amperage in the instruments, is there? Yes there is. That's where the load definition belongs. The load figure should follow the equipment, not the bus it's connected to. Ah, I didn't realize those where two separate issues. So we need the nominal power consumption for the battery lifetime and such. That makes sense. This would be an excellent improvement. Erik ___ 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] Airport vehicle (driving) sim
Today I had a chance to see a driving sim located at KMSP. They use it to train drivers for driving around on the airport grounds (taxiways, runways, service roads, tunnels, etc.) The really interesting thing about this sim is they had a beautifully done model of the airport. Every light, every sign, every painted line, every building, probably every tree and squirrel was modeled and placed accurately. You got a very good sense of being at the actual airport without having to rely on memory/imagination. They said they started with cad drawings of the airport and then someone came out and took about 3000 digital pictures of everything. It took them over a year to complete the modeling. Supposedly they have about $1.5 million into it in terms of equipment and labor. Aside from the beautiful modeling job, they had a real fire truck cab to sit in, and a 3 projector 180 degree cylindrical visual system. They had one windows machine to interface with the cab hardware, but other than that, everything was running linux on commodity PC's. Pretty nifty system ... Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
On Friday 14 November 2003 15:42, Erik Hofman wrote: Gene Buckle wrote: .Gene Buckle wrote: Avionics power ratings are always available as nominal and max normal draw. Electrical systems are designed with a bit of extra capacity to deal with power on rush current, etc. The only time an aircraft author would have to give the the current draw any thought at all is if they're also building special avionics and even then, they only really need to specify the nominal draw. The only time the breakers will pop is either on command from an instructor station or via a random systems failure routine. But then there is no need to define amperage in the instruments, is there? Yes there is. That's where the load definition belongs. The load figure should follow the equipment, not the bus it's connected to. Ah, I didn't realize those where two separate issues. So we need the nominal power consumption for the battery lifetime and such. That makes sense. This would be an excellent improvement. Erik I'm not an eletrics scientist... ...but I have a reasonable founding in it (from about eight years old). Each individual instrument will try to draw it's own current. Assigning ratings to the instruments makes a lot of snese to me, as would the supply capacity of the generator system and batteries. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Weight Balance data...
On Friday 14 November 2003 19:20, Gene Buckle wrote: After looking through the various instrumentation files, I noticed that there is no weight data associated with the instruments. For those that don't know, each instrument that goes into the panel is labeled with its weight. This is done to make sure that an accurate dry weight can be calculated. Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. g. I think the others have said that there's no immediate need for it but I can't see how it could be a bad thing. While it may not be needed now, it offers more options and possibilities and should be possible with a low overhead. As long as any scheme could be easily integrated, without any maintenance overhead, it sounds like a good idea, to me - if someone wants to do it:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
On Friday 14 November 2003 23:50, Curtis L. Olson wrote: Today I had a chance to see a driving sim located at KMSP. They use it to train drivers for driving around on the airport grounds (taxiways, runways, service roads, tunnels, etc.) The really interesting thing about this sim is they had a beautifully done model of the airport. Every light, every sign, every painted line, every building, probably every tree and squirrel was modeled and placed accurately. You got a very good sense of being at the actual airport without having to rely on memory/imagination. They said they started with cad drawings of the airport and then someone came out and took about 3000 digital pictures of everything. It took them over a year to complete the modeling. Supposedly they have about $1.5 million into it in terms of equipment and labor. Aside from the beautiful modeling job, they had a real fire truck cab to sit in, and a 3 projector 180 degree cylindrical visual system. They had one windows machine to interface with the cab hardware, but other than that, everything was running linux on commodity PC's. Pretty nifty system ... Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http:// www.flightgear.org Interesting. It's something I think about whenever I start a model - what can I see what do I include? In many respects, the finer into the detail you go, the easier it becomes to model. However, the longer it takes to complete the scene, as a consequence. I think it's because the more you break something down, the easier the individual parts become to identify and model, but you then need a lot more parts to complete the picture, so it can take longer. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Airport vehicle (driving) sim
Curtis L. Olson writes: Today I had a chance to see a driving sim located at KMSP. They use it to train drivers for driving around on the airport grounds (taxiways, runways, service roads, tunnels, etc.) The really interesting thing about this sim is they had a beautifully done model of the airport. Every light, every sign, every painted line, every building, probably every tree and squirrel was modeled and placed accurately. You got a very good sense of being at the actual airport without having to rely on memory/imagination. If they ever need a volunteer to taxi around a virtual plane, getting in the drivers' way, let me know. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Airport vehicle (driving) sim
David Megginson writes: If they ever need a volunteer to taxi around a virtual plane, getting in the drivers' way, let me know. They actually had a pretty neat scripting system. You could click a starting point, ending point, and a midpoint. The system would figure a reasonably optimal route throught the taxiway network. Planes would yield to each other and even to vehicles if the vehicle forced the issue. There were magic spots on the end of the runway that if you took the path to those, then the airplane would continue with a take off, fly around for 10 minutes and come back and land. It wasn't perfect, but from a ground vehicle perspective it looked really convincing. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] automake question
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 14, 2003 5:07 PM Subject: Re: [Flightgear-devel] automake question John Barrett writes: I've got some code from another project that I'm trying to hook into FG... it uses a short compiled program to generate a header file used by the rest of the package... I've added the program to Makefile.am, and it builds, now, how do I get that program to execute before the library that depends on the header is compiled ?? (library code in the same folder and same Makefile.am as the header generator program) This is starting to get into some tricky automake/autoconf voodoo if you want to run compiled programs in the middle of the build. Also consider that this could hose anyone who might want to cross compile. I don't know anyone who does, but last time I tried the win32 cross compiler on linux, it ran about 10x faster than natively on windows on the same hardware. That was years ago though and I'm sure cygwin has drastically improved it's performance on windows in the mean time. Anyway, this sort of stuff can really up the complexity of the build system so I'd *really* like to avoid it if at all possible. That said, the autoconf configure script works by generating little programs and executing them (or at least testing if they can be compiled, linked, etc.) So it might be possible to work something into the configure script if it was simple enough ... not that I'm excited about the idea ... Is there anyway you can restructure things to avoid needing to do this? Yes I could, later on... I'm integrating the SpiderMonkey JS engine and it uses this small program to detect compiler/cpu specific things, so I presume its pretty portable in and of itself ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] automake question
John Barrett wrote: I've got some code from another project that I'm trying to hook into FG... [which turns out to be:] I'm integrating the SpiderMonkey JS engine Into the client? Yikes. There was a big flame war the last time this was mentioned. That interpreter is almost bigger than the rest of FlightGear. Please investigate PSL first (or Nasal, but I won't push :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AI over SFO
I've generalized the AITanker into AIAircraft and freed it from KEMT, so now I can put any airplane(s) anywhere (as well as boats and waterskiers). Here's a picture of the KC-135 over San Francisco. http://home.comcast.net/~davidculp2/KC-135_over_SFO.jpg Now I'd like to sail a ship through the bay. Does anyone have an aircraft carrier model that I can use? If not, any boat will do. As a last resort I'll use an airplane. This is still experimental stuff, based on David Luff's AI classes. I made a new AIManager class, a pared-down version of David's AIMgr. It just instantiates an AI object and tells it to update. The AI objects are based on an AIBase class that contains an AI object's position and orientation, and draws it. Classes derived from this one could be airplanes, boats, cars, buildings, waterskiers, etc. The airplane pictured is an AIAircraft class, derived from AIBase, that contains some movement calculations for airplanes, a rudimentary FDM. Ships will be easy. Cars are a different story, as Seamus knows, since they must know where the ground is. These are minimalist classes. They don't speak, don't hear, and don't know where the ground is. My vision of AI in FlightGear is that most AI traffic would be of this type - minimalist, non-interactive, and scripted to follow simple paths. The smart AI, that knows where the ground is and can communicate, should, I think, be derived from the minimalist classes in order to reduce the overhead of filling the sky with traffic. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: FlightGear presence on the Net
* [EMAIL PROTECTED] (Paul Surgeon) [2003.11.14 13:20]: I'm amazed at how many times I've searched for info on wgs84 and projections and datums on Google and get FlightGear mailing lists appearing on the first page. It's good to see that FlightGear/TerraGear are so highly regarded in the GIS world. ;) I don't know how highly regarded we are, but Google seems to think we know what we're talking about. :-) -- Cameron Moore / If a man says something in the woods and\ \ there are no women there, is he still wrong? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Who is John Ridouts?
Lee Elliott [EMAIL PROTECTED] said: The e-mail addresses could be harvested from a number of places but it's curious that the data that was obtained was so old and didn't include my current ID. One theory might be that it is someone who was subscribed to the list at some point, then unsubscribed, but still has an out folder with flightgear stuff on their harddrive. These viruses usually harvest from folders and address books, but don't keep them...just use them to worm their way along. These happen quite often with the flightgear list, compared to other lower volume lists in my inbox. I don't know the stats, but I'd guess there's a pretty good number of folks lurking about on the flightgear lists. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Stupid idea: Has anyone thought to make a simple FDM for ground vechicles? I admit it might get boring quickly, but in a multiplay situation, it might be intresting to allow someone to simply watch takeoffs from the ground, with a mobile camera. It's half-assed, and since I can barely get FG to compile on my own, it's probably not worth implementing. Curtis L. Olson wrote: David Megginson writes: If they ever need a volunteer to taxi around a virtual plane, getting in the drivers' way, let me know. They actually had a pretty neat scripting system. You could click a starting point, ending point, and a midpoint. The system would figure a reasonably optimal route throught the taxiway network. Planes would yield to each other and even to vehicles if the vehicle forced the issue. There were magic spots on the end of the runway that if you took the path to those, then the airplane would continue with a take off, fly around for 10 minutes and come back and land. It wasn't perfect, but from a ground vehicle perspective it looked really convincing. Regards, Curt. -- A scientist claims in court that the reason he ran a red light is that, due to his speed, the color was blueshifted till it appeared green. Needless to say, the charges of running the red light were dropped and he lost his license for speeding excessively. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
