Am 29.12.2011 06:43, schrieb J. Holden: > At the same time I do not support the inclusion of some sceneries > I've created in the main FlightGear repository, as users with > lower-end machines may wish to use the vmap0 scenery over the more > detailed ones - plus there is now a marked difference in scenery > versions between scenery compatible with 2.4 and scenery not > compatible with 2.4. The user should be allowed to choose.
All valid points which need to be addressed, especially the compatibility issue. However, the current conclusion, that we therefore need many separate scenery projects, and should even actively proclaim the use of various external sources, doesn't sound right to me. Do these issues really mean that our central scenery project is limited for ever? Just in comparison: what would happen if Fred provided patches for the new shadow support on his private site only, Mathias did the same for HLA and OSG support, Torsten for the NAV radio and environment code etc. Then we create some central website listing all available patches, so people can choose (according to their hardware/performance/interests). And to make it "easier" for users: we create a large compatibility matrix, describing which patches fit seamlessly together, and which probably don't. That's a possible solution - but neither does that sound right to me... ;-) Results in the same nightmare that Oliver described for scenery. Instead we all contribute to a central Git repo and try to make features configurable - so you can disable 3D clouds, AI traffic, shaders, multiplayer, ... So we should also discuss other solutions for scenery. It'd be possible to abandon the current TerraSync server and switch to a new one. So, FG 0.1 - 2.4 users keep using existing scenery, while new developments (compatible with FG>=2.6) are stored on a new central repository. Or we could extend the scenery project to provide two levels of scenery: a lower quality scenery for older FG versions/older machines, and a high quality version for new/powerful machines and recent FG versions (in a somehow separate directory structure). Maybe we have more options. But we need a _common_ solution for these issues here - and I don't think that the scenery compatibility issue was really discussed here yet (but I may be wrong). There'll always be some external scenery projects, same as there are external FG core or Nasal patches. That doesn't matter much as long as these are small compared to the work on the common project. But it gets to be real trouble when almost everyone works on his separate private projects, and therefore progress of the common project slows down significantly. So, rather than forking development into many little subprojects, and finding ways to better support these forks, we should find solutions, so that scenery developers keep joining forces and improve our common scenery world (uh, that sounds cheesy, right?). cheers, Thorsten ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
