I fully agree with Jacob. I thought that is why we have seperate Terrain/Object/Airport folders in the first place...
Eric On 03/17/2012 11:15 PM, Jacob Burbach wrote: > On Sat, Mar 17, 2012 at 4:57 PM, Martin Spott<martin.sp...@mgras.net> wrote: > >> Anders Gidenstam wrote: >> >> >>> While the (old) new behaviour is as Martin expects it is not what most >>> that has read Docs/README.scenery would expect (I'd think). However, I >>> would not consider Docs/README.scenery a normative source (i.e. not how >>> it should be but rather how it was) - but Martin's expectation (as far as >>> I know about it) is also not the behaviour I'd like or want. >>> >> Well, to put it a bit harsh, if you ask every user, you'll probably >> have to implement two dozend exceptions from the rule. This doesn't >> make neither the developer happy nor the users, because it's getting >> too confusing - and the same users will start complaining again .... >> >> Let me explain it this way: >> Nowadays we/you are confronted with a steadily growing number of >> private Sceneries. There might be a scenario for France, one for Great >> Britain, one for Germany and, because everybody needs to have their own >> Scenery kingdom and these were the only ones left, one for BeNeLux and >> one for Denmark. Because it's easier to maintain, the boundaries of >> all these scenarios are aligned with full degrees. All these scenarios >> are added to the scenery path. >> Now think of an item which is situated somewhere in the German Bight in >> a tile which doesn't have terrain, how often is every single windmill, >> oil rig, buoy, light ship or whatever else going to be drawn in >> FlightGear ? ;-) >> >> Therefore I'd say the only really consistent way of dealing with the >> scenery path is to stop searching the path whenever a terrain _or_ an >> object tile is found in a scenery path item. >> > Seems logical to me that objects and terrain should be considered > separately. The loader should not stop looking for an object bucket > just because it finds a terrain bucket...and vice versa. The loader > knows what bucket it is looking for, so should just need to look > through each path until it finds the first existing bucket of each > type (or none) and load the data for that bucket/type as appropriate. > Once it has found a particular type of bucket it no longer looks for > it anymore, but continues looking for the other types until it finds > one, or not. Seems simple enough to me, avoids any problem with things > loading twice, and gives a very logical and expected behavior for > loading..no? > > cheers > Jacob > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
