Re: [Flightgear-devel] Change in Canonical Build Proceedure ???
Norman Vine wrote: I have been fighting this one for 'awhile' with no success therefore my reccomendation for AC_PREREQ(2.13) It is probably a shell syntax mistake or somesuch :-( although this could be a cascade from autoconf failing with configure.in: 145: error: possibly undefined macro: AC_EXT_DAYLIGHT configure.in: 151: error AC_EXT_TIMEZONE Isn't this the problem where you have to to run: aclocal -I . Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New materials file format
Norman Vine writes: FYI, The old format allowed for this just as easily. It is basically a wavefront materials file that is very successful in several of the 'best' modeling packages available. No it didn't -- the old format was a token reader, and each token knew how many other tokens had to be consumed after it. Any unrecognized token would cause the reader silently to head south, since it wouldn't know how many other tokens to skip before resuming (at least until it hit the closing brace). With the new format, we can experimentally add new fields without breaking older fgfs versions, since all unrecognized fields will silently be skipped. In fact, there was a nasty bug in the old code that had gone undetected for a long time -- $FG_ROOT/materials used the token name emissive while FGNewMat::operator was looking for emission, throwing each read slightly out of sync; every load was causing an invalid-operation FPE under Linux, which was going undetected until I enabled FPEs in my own build. anticapating_a_scenery_dtd_NOT'ly yours I don't see that happening. XML makes sense for short configuration files, like materials, panel, flight model, etc. -- it gives us an a lot of debugging for free, makes the formats easier to understand (once you learn one FlightGear property XML format, you know them all), and makes them more robust. It might make sense to use a master XML file for each tile for object placement, etc, but it would be inefficient for the raw triangle data. You might have noticed that additions to our XML-based property files almost never break older FlightGear binaries, since the old binaries easily skip the new unrecognized fields and new binaries have internal default values for fields that are not specified -- backwards- and forwards-compatibility are critical goals, since we want third parties to be able to develop additions for FlightGear and distribute those separately (we won't always be able to fit everything in the base package), and we *cannot* afford to have our formats changing incompatibly with every CVS checkin. I think it's unacceptable that people update the C++ code on Tuesday and then discover that the base package on Wednesday no longer works with it (and vice-versa). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Babies
Erik Hofman [EMAIL PROTECTED] said: Famous artists ... (but maybe Elvis isn't the best name to chose) ... like Jake and Elwood ... Man, I love that movie. :-) Erik We got our son's name from David Bowie's guitarist, not that he's a famous or an incredibly talented guitarist, we just liked the name. See http://www.reeveswilson.com for more info. =D Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Change in Canonical Build Proceedure ???
Erik Hofman writes: Norman Vine wrote: I have been fighting this one for 'awhile' with no success therefore my reccomendation for AC_PREREQ(2.13) It is probably a shell syntax mistake or somesuch :-( although this could be a cascade from autoconf failing with configure.in: 145: error: possibly undefined macro: AC_EXT_DAYLIGHT configure.in: 151: error AC_EXT_TIMEZONE Isn't this the problem where you have to to run: aclocal -I . Ah Ah - Thank you !! This solves the AC_PREREQ() 'hack' which should no longer be necessary The canonical set of configure commands are then aclocal -I . autoheader automake -a autoconf ./configure --with-LOCAL_OPTIONS Attached find a simple script to set the LOCAL_OPTIONS and write a bootstrap script. translations to alternative languages are expected :-) copy the script to your top FGFS source directory and enter % ./configurator.py then run the script it creates to configure your source tree Gotta love Open Source development and its MANY eyes :-) Cheers Norman configurator.py.gz Description: GNU Zip compressed data
[Flightgear-devel] Aircraft config files and .fgfsrc
The current aircraft config-file approach is a major improvement over what we had before, since the user can use a single option, --aircraft, to get the right aero, panel, sounds, etc. However, it is not easy for the user to provide aircraft-specific overrides. For example, c172-set.xml has panel pathAircraft/c172/Panels/c172-vfr-panel.xml/path visibilitytrue/visibility /panel Let's say that I want to use a different C172 panel by default. If I simply add -prop:/sim/panel/path=Aircraft/c172/Panels/c172r-panel.xml to my .fgfsrc, I'll get the alternative C172 panel for the C172, but I'll also get it for the C182, C310, DC-3, etc. etc. There are a couple of possible approaches. The first one is to have the --aircraft option load properties from a user directory after it loads from the base package, so that --aircraft=c172 will first try to load $FG_ROOT/Aircraft/c172-set.xml, then will try to load something like $HOME/.fgfsd/Aircraft/c172-set.xml for local overrides (it might actually use a $FG_PATH variable to search any arbitrary number of directories). This is the most flexible approach, but will take a bit of work. A simpler but more ungainly alternative is to use aliases in the aircraft config files, so that we have something like this: aircraft c172 panel pathAircraft/c172/Panels/c172-vfr-panel.xml/path visibilitytrue/visibility /panel /c172 /aircraft panel path alias=/sim/aircraft/c172/panel/path/ visibility alias=/sim/aircraft/c172/panel/visibility/ /panel and so on. Then, in .fgfsrc, the user can specify --prop:/sim/aircraft/c172/panel/path=Aircraft/c172/Panels/c172r-panel.xml and the new panel will be used for the C172 but not for any other aircraft. No C++ code changes are required for the second approach -- we can start using it right away. Comments? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Doc: How to position objects in FlightGear scenery
This atg file is the wavefront obj file? It is simply the ascii for of the btg. ATG = Ascii Terra Gear BTG = Binary Terra Gear There is code to convert between them. If you have Windows, I can give you the source for at least one direction. If you have another OS, then you need to call decode_binobj (IIRC, I would have to look it up). []'s Marcio Shimoda Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Doc: How to position objects in FlightGear scenery
It is simply the ascii for of the btg. ATG = Ascii Terra Gear BTG = Binary Terra Gear There is code to convert between them. If you have Windows, I can give you the source for at least one direction. If you have another OS, then you need to call decode_binobj (IIRC, I would have to look it up). Yeah, could be nice. []'s Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Doc: How to position objects in FlightGear scenery
Marcio Shimoda writes: It is simply the ascii for of the btg. ATG = Ascii Terra Gear BTG = Binary Terra Gear There is code to convert between them. If you have Windows, I can give you the source for at least one direction. If you have another OS, then you need to call decode_binobj (IIRC, I would have to look it up). Yeah, could be nice. Everything you need is in SimGear simgear / io / sg_binobj.XXX There is also some code in FlightGear that might help src / Objects / obj.cxx What is it you are trying to do ? Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
