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
