* Curtis L. Olson -- Friday 02 December 2005 18:09: > Again, it's a shame that original functionality is lost when people come > later and make changes to complex code without fully understanding the > intent.
Isn't that one of the reasons why we have flightgear-cvslogs? For code review? Like in any other F/OSS project? > Ok, to summarize, if you can assure everyone that your patch doesn't > change any original behavor (the 'good' original behavior) and is well > tested, then sure go ahead and commit it. OK. Thanks. I will present a patch after that which restores the original, pre-Objects&Terrain behavior. > It appears though that the scenery path semantics and devolved into an > ill understood mess. That's a bit harsh. One feature was added, and another was modified (to the worse). This doesn't make it a mess. I think that the non-set sea tile center is *as* big a "mess", and this was by design. But nothing is set in stone. Everything can be fixed. And if nobody noticed, and nobody cared, then it can't see the tragedy. > We should discuss how we want the pathing to work and make the code do what > we want. Right now it's a bit confusing [...] I know at least FGTileEntry::load() good enough now to not find it confusing. :-) We have to keep in mind that after the change to Terrain/ and Objects/ subdirs we *had* to process further dirs, namely the respective Objects/ directory. Even though we found a scenery file in the Terrain/ dir (which was searched first). Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. ? m. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
