Re: [Flightgear-devel] [OT] Graduate Schools
On Sun, 02 Feb 2003 19:05:19 -0600, JD Fenech [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I know it isn't quite development related, but you guys seem like the best folks to ask this question... I'm a fifth-year senior, CompSci major with physics and math minors... I have an interest in cosmology/astronomy/simulation/etc. I'm looking for a good grad school where I can put these aptitudes to work, except my GREs weren't exactly stellar (they were average). Since a lot of you are in the academic areas, you probably have a far better idea than me of where would be good to look at. I only have one major stipulation and that's basically that I don't want to go any further west than I am now (especially not California!) Perferably in the South. ..your track record here, may be worthwhile to put on your cv, to bring up your academic score. ..for example, we don't yet have a helicopter fdm. And, we require OpenGL which again means we require rather high spec video hardware. ..writing a chopper fdm, or a low spec (ncurses, svga, framebuffer?) video interface is a _tangible_ thing for human resource admin etc trained staff, who recruits people at your favorite university etc. ..for ideas: http://autopilot.sourceforge.net/ or http://decopter.sourceforge.net/ ..another set of ideas is model the space shuttle launch, and show whether or not the last crash could have been prevented by aborting the launch after that foam piece was seen hitting the left wing, or, show whether a Twin Otter is controlable after shedding its tail after a midair, or, whether that Air France Concorde could have survived riding a 747 wing vortice. And, we have athmosfaeres on most planets around here. ;-) ..I think a _tangible_ Here.-response to a Show Me! from your average non-engineer academic, and documented in classic academic report style, is worthwhile. It also allows building your own _custom!_ academic career launch pad. Thanks, JD -- The modern definition of 'racist' is someone who is winning an argument with a liberal. --Peter Brimelow ..heh, I have great fun proving them (liberals) racists. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] switching views (trivial)
Hi all, I always wanted to be able to hit shift v to be able to cycle through views the other way. That way you can toggle between 2 views without having to go through them all, which can be uncomfortable if you're about to run into a mountain or something. It looked like the code was all there to do it so I have made these minor modifications to enable it. It works fine for me but be warned I know just enough C++ to be dangerous ;) Diffs are against current cvs. There is one patch for the base: home.pacific.net.au/~greendog/flightgear/rev-view-cycle-fgfsbase.diff and one for Flightgear: home.pacific.net.au/~greendog/flightgear/rev-view-cycle-FlightGear.diff Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] switching views (trivial)
Hi Geoff, I've got several changes and fixes to the viewer code, one of which changes the view manager to allow what you are describing. It is actually a little more flexible than just reversing, you can select the view through a property. This allows going forward, backward and directly to any specific view without using a special command. It's been done for a couple weeks now. I'll try and get it together and submit the changes in the next day or two. Best, Jim Geoff Reidy [EMAIL PROTECTED] said: Hi all, I always wanted to be able to hit shift v to be able to cycle through views the other way. That way you can toggle between 2 views without having to go through them all, which can be uncomfortable if you're about to run into a mountain or something. It looked like the code was all there to do it so I have made these minor modifications to enable it. It works fine for me but be warned I know just enough C++ to be dangerous ;) Diffs are against current cvs. There is one patch for the base: home.pacific.net.au/~greendog/flightgear/rev-view-cycle-fgfsbase.diff and one for Flightgear: home.pacific.net.au/~greendog/flightgear/rev-view-cycle-FlightGear.diff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] some 737 goodies
Here some 737 files I've been working on. First the general config. http://home.attbi.com/~davidculp2/737/737-set.xml http://home.attbi.com/~davidculp2/737/737-sound.xml It's a JSBSim model with a generic electrical system, it's own sound config, a transparent mini panel, a hud based on the engineering hud, and the 747 exterior. The flight dynamics and engine models are at: http://home.attbi.com/~davidculp2/737/737.xml http://home.attbi.com/~davidculp2/737/CFM56.xml It flies nicely, although not everything works yet as I haven't broken the code on the flaps. Anyway, takeoff power is about 90% throttle, rotate at about 140 knots, climb at about 15 degrees pitch and about 180 knots to 1500 feet, then raise flaps and climb at 210 knots to 3000 feet, then climb at 250 knots (about 12 degrees pitch) to 1 feet, then climb at 300 knots (about 8 degrees pitch until mach 0.75, then hold 0.75 to level-off. For landing, downwind with flaps 1 and 200 knots, base with flaps 10 and 170 knots, final with gear down, flaps 30 and 140 knots. The flaps aren't working properly so you'll have to fake it. The 2D HUD, based on the engineering HUD, is at: http://home.attbi.com/~davidculp2/737/hud/default.xml http://home.attbi.com/~davidculp2/737/hud/Instruments/hudladder.xml http://home.attbi.com/~davidculp2/737/hud/Instruments/hudcard.xml http://home.attbi.com/~davidculp2/737/hud/Instruments/instrlabel.xml http://home.attbi.com/~davidculp2/737/hud/Instruments/fgtbi.xml I expanded the ladder a bit to help with precise pitch control; the card removes the radio altitude display for now; the instrlabel config removes beta and nlf, which weren't working anyway, removes lat/lon and attempts to display speed. The fgtbi is shortened a little to make room for the mini-panel, which is at: http://home.attbi.com/~davidculp2/737/737-trans-mini-panel.xml http://home.attbi.com/~davidculp2/737/737-trans-mini-bg.rgb The texture is the extant transparent texture without the ghost-edge on top. The first instrument is a standard Boeing 450-knot airspeed indicator: http://home.attbi.com/~davidculp2/737/asi-450-knot.xml http://home.attbi.com/~davidculp2/737/asi-450-knot.rgb The MACH and KNOTS odometer-style displays aren't installed. The needle functions until about 170 knots and then wanders (compared to the hud display). The calibration has been checked closely, so I'm not sure what the problem is there. The Vmo/Mmo needle, also called a barber pole doesn't quite work yet. I'm trying to have it start at 350 knots and then decrease with altitude, linearly, to about 260 knots at 5 feet. That's a good approximation. Unfortunately I haven't quite grokked the config. My next step is to add an internal bug and four external ones. The 737 flap control is at: http://home.attbi.com/~davidculp2/737/737-flaps.xml http://home.attbi.com/~davidculp2/737/737-flaps.rgb Slick, but not yet fully functional. Again a grokking problem. http://home.attbi.com/~davidculp2/737/N1-0.xml http://home.attbi.com/~davidculp2/737/N1-1.xml The above N1 gauges are based on the standard N1 gauge, with only a minor change. n1-0.xml uses property /engines/engine[0]/n1 and n1-1.xml uses property /engines/engine[1]/n1. Neither work yet, but they look slick. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Harrier Data
I had a trip to the South Yorkshire Air Museum this weekend - and now have silly amounts of data. I currently have in my grubby little mitts a Harrier GR3 aircrew manual, and a cd with a boat load of cockpit photos. I also have the offer of access to a lightning F3 to get cockpit photos should we want to model one (apparently an awful lot of the instruments are common to both). I'll go through the Harrier photos and see if I can get any straight on instument pics that are useable for modelling. The photographer is happy for the pics to be used to generate a cockpit model, but would rather not have the photos openly accssible on the net, due to some of his pics being used without consent before. If there's info that anyone desperately needs, I'll see what I can come up with. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DAFIFT progress
Okay, so I have FG working with the DAFIFT NAV and WPT data (replaces default.fix and default.nav). Now, I need some advice: - What things to test that may have broken. I've extended 'testnavs' quite a bit and everything in there works, but this is a minute sample compared to what's out there. So, any suggestions for things to try? Other than 'fly around a bit, tuning the radios lots'.. - I uncovered some API inconsistencies between the fixlist and the navlist (some routines taking degrees, others radians, for lat / lon) : which do we prefer? (I'll fix the offenders) - I'm getting a bunch of odd records from the DAFIFT NAV file: they have no frequency defined (which renders them rather useless except as waypoints). They appear on my SimCharts from Jeppesen, along with frequencies. Examples: In the UK: SAT ODH In the US: VBG TOL SSC PAM In the netherlands: TWN SSB At least the UK ones all have the 'TAC' prefix on my SimCharts. So does anyone know what these things are? I'm guessing it's something military related. The have frequencies in the VOR range (eg 117.7 Mhz based on SimCharts). Now, I can happily ignore them, but I'd like to know what I'm looking at before I do that. - The current code detects the datafile format dynamically, so with a trivial patch to fg_init, I can dynamically use FG_ROOT/DAFIFT instead of FG_ROOT/Navaids if the DAFIFT files are present ... assuming I do this, shall I go ahead and send my changes out for some wider testing? Curt / Dave, which of you is less busy? - Next stop, airways and I almost have a 737 to fling about them, thanks to Dave Culp :-) HH James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT progress
In the UK: SAT ODH At least the UK ones all have the 'TAC' prefix on my SimCharts. So does anyone know what these things are? I'm guessing it's something military related. The have frequencies in the VOR range (eg 117.7 Mhz based on SimCharts). Now, I can happily ignore them, but I'd like to know what I'm looking at before I do that. The UK ones appear to be TACANs at Odiham and St Athan: http://www.nightstop.freeola.com/beacon%20decodes/beacon%20decodes.htm Mally --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/03 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT progress
James Turner wrote: - I'm getting a bunch of odd records from the DAFIFT NAV file: they have no frequency defined (which renders them rather useless except as waypoints). They appear on my SimCharts from Jeppesen, along with frequencies. Examples: In the netherlands: TWN SSB Those are millitary airfields which are open for civillian transport between 17.00 hour and 8.00 hour and in the weekends. That might be part of the problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT progress
James Turner wrote: - I'm getting a bunch of odd records from the DAFIFT NAV file: they have no frequency defined (which renders them rather useless except as waypoints). They appear on my SimCharts from Jeppesen, along with frequencies. Examples: In the netherlands: TWN SSB At least the UK ones all have the 'TAC' prefix on my SimCharts. So ... You are right, its TACAN. They will be replaced by ILS this year. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT progress
James Turner wrote: Okay, so I have FG working with the DAFIFT NAV and WPT data (replaces default.fix and default.nav). Now, I need some advice: Just out of curiositty, does EHAM already contain the 6th runway? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT progress
On Mon, 3 Feb 2003, Erik Hofman wrote: Just out of curiositty, does EHAM already contain the 6th runway? It's not finished yet, but they were testing the ILS last week. I heard some misgivings about actually having to land on a runway before getting certification for the ILS ;-) Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] DAFIFT progress
James Turner writes: - I uncovered some API inconsistencies between the fixlist and the navlist (some routines taking degrees, others radians, for lat / lon) : which do we prefer? (I'll fix the offenders) In general, we prefer degrees on the user side and radians on the math/physics side. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TACANs (was DAFIFT progress)
James Turner writes: So, armed with the knowledge that TACANs are UHF, not VHF, and that they use military channel codes, I went and looked at the DAFIF fields again ... and guess what the field two after FREQ is? Yeah, it's the channel. Boy do I feel silly. It's more complicated than that. DME receivers (which are UHF) can use TACANs to get distance information -- usually, you do that by tuning in a fake paired VOR frequency. For example, if I tune my DME to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance readings from the UPP TACAN at CYOW, even though there's no VOR. Can the paired frequency be deduced from the channel? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TACANs (was DAFIFT progress)
On Mon, 3 Feb 2003, David Megginson wrote: It's more complicated than that. DME receivers (which are UHF) can use TACANs to get distance information -- usually, you do that by tuning in a fake paired VOR frequency. For example, if I tune my DME to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance readings from the UPP TACAN at CYOW, even though there's no VOR. Can the paired frequency be deduced from the channel? ISTR there being a lookup table for this in the back of the british isles/north atlantic en route supplement - I'll have a look when I get home. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier Data
On Mon, 2003-02-03 at 08:47, Jon Stockill wrote: I had a trip to the South Yorkshire Air Museum this weekend - and now have silly amounts of data. I currently have in my grubby little mitts a Harrier GR3 aircrew manual, and a cd with a boat load of cockpit photos. I also have the offer of access to a lightning F3 to get cockpit photos should we want to model one (apparently an awful lot of the instruments are common to both). Lightnings would be so cool, another high performance jet. Like some people over here described it, its just a large engine with wings tacked on. Guess thats a good way to describe it. I'll go through the Harrier photos and see if I can get any straight on instument pics that are useable for modelling. The photographer is happy for the pics to be used to generate a cockpit model, but would rather not have the photos openly accssible on the net, due to some of his pics being used without consent before. So he is OK with cockpit renditions? If there's info that anyone desperately needs, I'll see what I can come up with. What planes do you have access to in the Museum? Maybe a better way to ask is what do they have there? Matt PS Is it worth getting a flightgear-modeler mailing list? I don't care either way, just a thought... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier Data
On 3 Feb 2003, Matthew Johnson wrote: Lightnings would be so cool, another high performance jet. Like some people over here described it, its just a large engine with wings tacked on. Guess thats a good way to describe it. I can arrange as many cockpit pics as we need for this, with the added bonus that there's no seat in it at the moment, making photography rather less cramped. So he is OK with cockpit renditions? No problem with that at all - this is the reason he game me the pics. What planes do you have access to in the Museum? Maybe a better way to ask is what do they have there? Chipmunk, Vampire, Jet Provost, Lightning, Scout, lots of stuff in the workshop. I don't know who owns all the aircraft, but I've been told that access to the lightning isn't a problem. Their web site is here: http://www.syam.freehosting.net/ I'm reading through this harrier manual at the moment - there's an awful lot of information (it's about 2 thick, A4 sized, with pullouts for A3 diagrams). The diagrams look very useful for putting together a 2d panel background, onto which we can add instruments which is where the photos should come in handy. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Return of the BPCVS
Arnt Karlsen wrote: On Sun, 02 Feb 2003 19:39:28 -0500, John Check [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Base package cvs is back, now with more cvsweb http://rockfish.net/cgi-bin/cvsweb/ ..imaginary folder like directory icons? ;-) I see this effect too. No image is displayed by a HREF=FlightGear/img SRC=/doc/cvsweb/dir.gif ALT=[DIR] BORDER=0 WIDTH=20 HEIGHT=22/a; just an empty square. Maybe the path /doc/... is wrong or inaccessible. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] BAC Lightning F.Mk.6
Lightnings would be so cool, another high performance jet. Like some people over here described it, its just a large engine with wings tacked on. Guess thats a good way to describe it. Try this, it's a blast. It uses BAC Lightning F.Mk.6 metrics, Rolls-Royce Avon 301 engines, and T-38 coefficients. If you figure out how to get the afterburners lit, please let me know. (But as you can see, this airplane does fine without them.) http://home.attbi.com/~davidculp2/BAC/lightning-set.xml http://home.attbi.com/~davidculp2/BAC/lightning.xml http://home.attbi.com/~davidculp2/BAC/Avon301.xml Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Possible change in FAA FTD rules
From: nafi [EMAIL PROTECTED] http://www.nafinet.org/ FTD NPRM to Increase Oversight The FAA is proposing to amend current flight simulation device qualification requirements to include increased regulatory oversight of all operators. While the FAA proposal does not cover personal computer-based aviation training devices (PCATD), it would increase regulatory oversight of flight schools and establish a mandatory simulator quality assurance program. The notice of proposed rulemaking (NPRM) would establish FAR Part 60-Flight Simulation Device Initial and Continuing Qualification and Use. The FAA also proposes to modify Part 1-Definitions and Abbreviations, Part 61-Certification: Pilots, Flight Instructors, and Ground Instructors, Part 141-Pilot Schools, and Part 142-Training Center. Part 60 would also require the mandatory use of an FAA-approved quality assurance program that requires pilot schools and training centers to adopt certain flight simulation device maintenance regimes, recurrent inspections and maintenance evaluations, operating procedures, and record keeping and reporting to identify and correct any deficiencies. It also requires the development of all-inclusive manuals that fully describe the procedures to be followed. For years, general aviation pilot schools have used flight simulation devices to enhance flight training and proficiency under the FAA's current rules and advisory circular guidance without incurring any known safety problem. The use of flight simulation devices gives general aviation pilots access to important procedures and proficiency training opportunities in a safe environment that helps enhance safety. The proposed flight simulation device regulations will significantly increase the complexity and operational costs to all general aviation pilot training schools that use flight simulation devices for pilot training, pilot evaluation, or required flight experience, according to AOPA. The costs associated with the proposed regulations could cause many general aviation pilot schools, which cater to these types of aircraft operators, to discontinue providing necessary simulator-based training, thus undermining general aviation's use of simulators as an effective training and proficiency tool. The text of the NPRM is available at www.aopa.org/whatsnew/regulatory/regfsd.html. The FAA is accepting public comments on the NPRM until February 24, 2003. Comments may be sent to the Docket Management System, U.S. Department of Transportation, Room Plaza 401, 400 Seventh Street, SW., Washington, DC 20590-0001, or can be sent through the Internet to http://dms.dot.gov http://dms.dot.gov/ . ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TACANs (was DAFIFT progress)
On Monday, February 3, 2003, at 07:40 pm, David Megginson wrote: It's more complicated than that. DME receivers (which are UHF) can use TACANs to get distance information -- usually, you do that by tuning in a fake paired VOR frequency. For example, if I tune my DME to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance readings from the UPP TACAN at CYOW, even though there's no VOR. Can the paired frequency be deduced from the channel? Right now, I think the answer is no. I was hoping that such TACANs simply listed the fake frequency in their FREQ column, but I've got checks for that in place and I'm not hitting them (just got that code working). That said, the UPP TACAN is not listed in NAV.TXT, if you know of any others, please let me know and I'll check. (Or did you mean UUP, 'Uplands'?) HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: question about Atlas build - missing files on MacOS X
I can't find any information on building Atlas from CVS to use with
flightgear. I've modified configure.ac to get past autogen.sh and
configure. I have the following build problems.
LoadPng.o: Where/what is png.h
MapMaker.o: What is dirent.h? The problem is the uint parts of this
struct
struct dirent {
u_int32_t d_fileno; /* file number of entry */
u_int16_t d_reclen; /* length of this record */
u_int8_t d_type; /* file type, see below */
u_int8_t d_namlen; /* length of string in d_name */
#ifdef _POSIX_SOURCE
char d_name[255 + 1]; /* name must be no longer than this */
#else
#define MAXNAMLEN 255
char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */
#endif
};
OutputGL.o: where's all this stuff defined?
I am using MacOS 10.3 with 12/2002 dev tools, gcc 2.95, latest plib, fg
from cvs, simgear is recent
thank you, Ima
make all-recursive
Making all in data
make[2]: Nothing to be done for `all'.
source='LoadPng.cxx' object='LoadPng.o' libtool=no \
depfile='.deps/LoadPng.Po' tmpdepfile='.deps/LoadPng.TPo' \
depmode=gcc /bin/sh ../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I/Desktop/FlightGear/fgdev9.1/include
-DFGBASE_DIR=\/Desktop/FlightGear/fgfsbase\ -g -O2 -c -o LoadPng.o
`test -f 'LoadPng.cxx' || echo './'`LoadPng.cxx
LoadPng.cxx:24: png.h: No such file or directory
make[2]: *** [LoadPng.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
g++ -DHAVE_CONFIG_H -I. -I. -I/Desktop/FlightGear/fgdev9.1/include
-DFGBASE_DIR=\/Desktop/FlightGear/fgfsbase\ -g -O2 -c -o MapMaker.o
`test -f 'MapMaker.cxx' || echo './'`MapMaker.cxx
In file included from /usr/include/dirent.h:64,
from MapMaker.cxx:24:
/usr/include/sys/dirent.h:73: syntax error before `;'
/usr/include/sys/dirent.h:74: syntax error before `;'
/usr/include/sys/dirent.h:75: syntax error before `;'
/usr/include/sys/dirent.h:76: syntax error before `;'
make: *** [MapMaker.o] Error 1
[:src/atlas/src] root# make ./MapPS.o
[:src/atlas/src] root# make ./OutputGL.o
source='OutputGL.cxx' object='OutputGL.o' libtool=no \
depfile='.deps/OutputGL.Po' tmpdepfile='.deps/OutputGL.TPo' \
depmode=gcc /bin/sh ../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I/Desktop/FlightGear/fgdev9.1/include
-DFGBASE_DIR=\/Desktop/FlightGear/fgfsbase\ -g -O2 -c -o OutputGL.o
`test -f 'OutputGL.cxx' || echo './'`OutputGL.cxx
OutputGL.cxx: In method `void OutputGL::closeOutput()':
OutputGL.cxx:76: `png_structp' undeclared (first use this function)
OutputGL.cxx:76: (Each undeclared identifier is reported only once
OutputGL.cxx:76: for each function it appears in.)
OutputGL.cxx:76: parse error before `='
OutputGL.cxx:78: `png_ptr' undeclared (first use this function)
OutputGL.cxx:81: `png_infop' undeclared (first use this function)
OutputGL.cxx:81: parse error before `='
OutputGL.cxx:82: `info_ptr' undeclared (first use this function)
OutputGL.cxx:84: `png_infopp' undeclared (first use this function)
OutputGL.cxx:84: parse error before `0'
OutputGL.cxx:88: implicit declaration of function `int setjmp(...)'
OutputGL.cxx:89: implicit declaration of function `int
png_destroy_write_struct(...)'
OutputGL.cxx:94: implicit declaration of function `int png_init_io(...)'
OutputGL.cxx:95: `PNG_COLOR_TYPE_RGB' undeclared (first use this
function)
OutputGL.cxx:96: `PNG_INTERLACE_NONE' undeclared (first use this
function)
OutputGL.cxx:96: `PNG_COMPRESSION_TYPE_DEFAULT' undeclared (first use
this function)
OutputGL.cxx:97: `PNG_FILTER_TYPE_DEFAULT' undeclared (first use this
function)
OutputGL.cxx:97: implicit declaration of function `int
png_set_IHDR(...)'
OutputGL.cxx:98: implicit declaration of function `int
png_write_info(...)'
OutputGL.cxx:100: `png_byte' undeclared (first use this function)
OutputGL.cxx:100: `row_pointers' undeclared (first use this function)
OutputGL.cxx:100: parse error before `*'
OutputGL.cxx:102: parse error before `)'
OutputGL.cxx:106: implicit declaration of function `int
png_write_image(...)'
OutputGL.cxx:110: implicit declaration of function `int
png_write_end(...)'
make: *** [OutputGL.o] Error 1
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TACANs (was DAFIFT progress)
James Turner writes: That said, the UPP TACAN is not listed in NAV.TXT, if you know of any others, please let me know and I'll check. (Or did you mean UUP, 'Uplands'?) That's it -- I was giving the ident from memory. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: question about Atlas build - missingfiles on MacOS X
On Mon, 3 Feb 2003, Ima Sudonim wrote: I can't find any information on building Atlas from CVS to use with flightgear. I've modified configure.ac to get past autogen.sh and configure. I'm not a MacOS X user myself, but meddling with configure.ac is deep magic :-) I have the following build problems. LoadPng.o: Where/what is png.h You'll need to install libpng and the associated header files. MapMaker.o: What is dirent.h? The problem is the uint parts of this It's an interface to the operating system directory structure. On older MacOS's it was an emulation of a UNIX interface, on MacOS X it probably maps directly to the underlying BSD code. It's there to support the opendir(3) family of library calls. The uint_xxx stuff can be dragged in by including sys/types.h before dirent.h. Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Partially Offtopic: Help open up the FSDprotocol
On Tue, 28 Jan 2003, Mathew McBride wrote: I have some more info on this in a seperate thread: http://seneca.me.umn.edu/pipermail/flightgear-devel/2003-January/014707.html My message is probably fully off-topic here, but then again; maybe not... I'm a rookie here. Don't want to know the virtual damage I've done to the virtual planes I flew. I'd like to throw in a few observations based on comments you made, and some of my own. 1) IVAO. This is more of a european network, but with much better connections in other parts of the world (Australia). I belive they use their own server, and you can download it from http://www.ivao.org/network/default.htm. I use this network They've got a nice assortment of info in addition to the virtual live world. But it once again struck me that there is no open (as in, at least GPL/LGPL, or BSD styled) repository of aviation related data. I've pieced together some databases myself (country registration prefixes, airline data, aircraft data, ACARS codes), but I rate this collection Personal Use because of unclear licensing of the base data gleaned from web sites (and the way data is presented, such as on the IVAO web site, makes it pretty obvious that you're not supposed to feed that data into your personal database). Is there any web site that has a meta-database of available info, that specifies license restrictions? Am I overlooking any sources of data? Would a Sourceforge project dedicated just to avdata make sense to anyone? It's all window dressing as far as I'm concerned, but it is nice to be able to augment PH-HZF HV0992 H1 #M1BPRG/FNHV0992/DTEHAM,19R,77,014711,29C98F with B737-8K2 delivered 06/11/99 Flight: Transavia 992 Destination: Schiphol Apt, Amsterdam, The Netherlands Runway: 19R ETA: 01:47:11 without having to perform a gazillion of web lookups, followed by parsing the HTML response. Some other FG comms stuff on my long term radar: 1) ACARS. Hey, aircfaft don't communicate over voice completely. They do use Text comms some times. In my copious spare time, I've been playing the sorcerors apprentice at DSP coding and come up with a Unix tool to decode ACARS from a radio receiver with a sound card. It sort of works (I'm not really impressed with the number of packets I decode successfully, but when working from recorded chirps my code seems to beat SkySweeper, and it certainly beats WACARS and KRACARS that I never got to work properly :-) Given how sparse ACARS info is, I think that free-text is the only viable part of ACARS to emulate. Even something as simple as a position report comes with many options to represent the data (some conflicting with observed practice; possibly as a result of comms error on board, but not showing up through parity error or CRC failure). As an illustration of just how perilous parsing ACARS data is without access to the airline specs, I've seen WACARS decode a weather report for traffic enroute to EGLL into Wanxian - China simply because WXN was in the string. The biggest brick wall I run into is lack of redistributable reference data; and, of course, lack of documentation on the data that travels ACARS. My personal impression is that most people collecting and publishing such data got bitten by con artists taking off with the fruits of their labor; a practice that seems common in the MSFS and MSTS communities; in that sense (as well as many others), FlightGear is a breath of fresh air. Anyway, I'm looking for guidance on how to approach this ACARS toy project of mine. It's easy enough to register the thing on SourceForge and put some code out, but it's a different thing altogether to bundle it with enough data to make sense of the packets, and not run afoul of licensing issues. The DSP bits probably make more sense in the HAM community, but the ACARS data components drag if firmly back into the realm of the aviation emulators (how's about the AI Tower Controller warning you about conflicting traffic that actually is overhead of where you're playing FlightGear, or even warning that TransAvia flight that there is a rogue Cessna in the pattern and would the Cessna turn left _now_?). Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Return of the BPCVS
On Monday 03 February 2003 5:54 pm, Julian Foad wrote: Arnt Karlsen wrote: On Sun, 02 Feb 2003 19:39:28 -0500, John Check [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Base package cvs is back, now with more cvsweb http://rockfish.net/cgi-bin/cvsweb/ ..imaginary folder like directory icons? ;-) I see this effect too. No image is displayed by a HREF=FlightGear/img SRC=/doc/cvsweb/dir.gif ALT=[DIR] BORDER=0 WIDTH=20 HEIGHT=22/a; just an empty square. Maybe the path /doc/... is wrong or inaccessible. - Julian Okay, now I know what he meant. Maybe I'll just pull the plug. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: question about Atlas build - missing files on MacOS X
On Tuesday, February 4, 2003, at 01:38 am, Ima Sudonim wrote: I can't find any information on building Atlas from CVS to use with flightgear. I've modified configure.ac to get past autogen.sh and configure. I have the following build problems. I'll give Atlas a shot today :-) LoadPng.o: Where/what is png.h Get libPng via Fink, hopefully Atlas has a ./configure --with-libpng= option, otherwise we'll need to add one. 'fink install libpng' or pick it from the list using dselect. Or you can just build it from source, Apple already supply 'zlib' which libpng requires. MapMaker.o: What is dirent.h? The problem is the uint parts of this struct This sounds a bit strange, possibly pulling in sys/types will help (as Bert Dreihuis suggested) but I think that should have been done automatically.. I am using MacOS 10.3 with 12/2002 dev tools, gcc 2.95, latest plib, fg from cvs, simgear is recent Is there any reason you're using 2.95 rather than 3.2? It's a much better compiler for C++ And unlike other OS-s, switching back and forth is simple. HH James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
