Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Erik Hofman wrote: Yes. Maintaining can be done using CVS and when the official release is out it can be just a matter of letting a script generate the tarballs for the static scenery. It may be something which would benefit from a more regular snapshot though - so that new scenery is available as soon as it's uploaded. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
On Sat, 31 Jul 2004 10:17:48 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Chris Metzler wrote: I've been waiting to post this until after the release went out, hoping there'd be more discussion when things were a tiny bit calmer . . . Over time, various people have done a lot of work on ground structures, etc., to add to the scenery for FlightGear. Frederic's did a lot of work on the bridges + downtown for SF; that's now distributed with the default area scenery. Franz Melchior did Vienna's Donaturm tower, complete with Actually it's Melchior Franz. Dangit. I assumed the reverse order because I know someone with Franz as a first name, and someone else with the (similar) last name of Melchiori. Sorry to Melchior if reading. 1. It's probably *not* the best idea for it to all just get added into the FlightGear scenery archives, to be there automatically when the terrain for an area gets downloaded from scenery.flightgear.org or its mirrors. There are already people having a hard time with framerates just with the structure in the default area. I imagine a scenario where a user fetches updated scenery files for an area they've been flying around for a while, and discovers suddenly that it's unusable now for them because of a recent addition of a bunch of framerate- crushing eye candy. I think that (now that we have a separate Objects directory) it is possible quite easily to add a command-line option to disable the static scenery objects. Fair enough. But with ground structures that are installable separately, it's possible for a user to pick and choose what to install. For example, someone could wish to see a set of landmarks in Paris, but not the buildings at Orly (wanting smoother framerates during landing/takeoff, but not caring so much when flying over the center of the city), or something like that. So while I really like having the separate Objects directory, and agree that being able to toggle on/off the static scenery objects would be a good thing, I think being able to pick and choose what (non-random) static structures to install is *also* a good thing. So what we discussed was a webpage/site which would (eventually) do for FlightGear what avsim.com/flightsim.com's file libraries do for MSFS. At least at first, it'd provide upload/browse/download capability. Eventually, it could also be a place to fetch useful scripts, programs, scenery-making tutorials, etc. It wouldn't necessarily require a chunk of Curt's time or hardware; it need not even be in the flightgear.org domain, although I think it'd be a good thing if it was (unfortunately, scenery.flightgear.org is occupied, hehe). Mat Churchill and I are both enthusiastic about such a scenery website. My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). Well, having user-developed scenery in a CVS repository would be nice in that it'd make available all of the CVS infrastructure; no need to create or port a bunch of applications to maintain it all. And it would be easy to integrate with everything else, and add to mirrors, and so on. But from the users' perspective, it may not be ideal in that it's not very *browseable* -- to look through what's available in a nice friendly form, with images and so on, and pick out what you like and dload it. Browsing a CVS repository is possible, of course; but kinda ugly and more oriented towards developers than users. I don't know much about user-friendly CVS clients, especially for Windows. The other thing is that I think it'd be good to avoid putting any more work upon the existing developers (e.g. not asking Curt to take on more website work). If the CVS archive ran on outside machines, and was linked to off the website on baron.flightgear.org, that might work OK, I dunno. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpTMIEmacj4p.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: On Sat, 31 Jul 2004 10:17:48 +0200 Erik Hofman [EMAIL PROTECTED] wrote: I think that (now that we have a separate Objects directory) it is possible quite easily to add a command-line option to disable the static scenery objects. Fair enough. But with ground structures that are installable separately, it's possible for a user to pick and choose what to install. For example, someone could wish to see a set of landmarks in Paris, but not the buildings at Orly (wanting smoother framerates during landing/takeoff, but not caring so much when flying over the center of the city), or something like that. Regarding that particular issue it might even make somewhat more sense to add another option to selectively adjust scenery complexity for certain areas - that way, the scenery itself would be available, while its actual level of complexity could be customized for specific purposes at runtime, so I could decide for a high level of detail during approach/final segment while reducing scenery complexity on the enroute segment. As you mentioned this would not need to be restricted to certain phases of flight, but rather could really be specifically customized to certain sections during flight. So, this would be a bit more tweakable than the usual approach to decide for ONE specific detail/rendering profile, which usually is not changed during flight... So while I really like having the separate Objects directory, and agree that being able to toggle on/off the static scenery objects would be a good thing, I think being able to pick and choose what (non-random) static structures to install is *also* a good thing. yes, it would allow for some more flexibility My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). Browsing a CVS repository is possible, of course; but kinda ugly and more oriented towards developers than users. I don't know much about user-friendly CVS clients, especially for Windows. There are a couple I know of, but to be honest for a NORMAL windows *user* in general it cannot be considered user-friendly to require installing a cvs client. If you really want to keep using CVS for these purposes it might rather make more sense to look into more powerful web-frontends to CGI, as even a windows user :-) can deal with a browser, and wouldn't have to install any extra software, nor would a windows user require to get familiar with a new interface if a browser can be used for these purposes. As a workaround one might try to make CVS (via browser !) itself a bit more end-user-friendly by including things like screenshots in the repository (like in a specific folder named previews) - while this is certainly not what CVS is meant for, it would provide some convenience for users to really be able to tell what a specific scenery addon is all about and who are not really familiar with developer frontends. The other thing is that I think it'd be good to avoid putting any more work upon the existing developers (e.g. not asking Curt to take on more website work). yes, gotta agree on that one too, to be honest: being new to this mailing list my current impression is really that most of the developers are simply way too busy to take care of all the suggestions that keep being made by users, not necessarily talking of my own suggestions here: I've spoken to several people who have similar impressions, this is really not meant to be critique, but rather something you ought to think about: it seems to be a matter of fact, that the current infrastructure for the FlightGear project requires a lot of decision making of the right people (mostly Curt and the main-developers). So, while these people are - understandably - very busy new ideas which might benefit the normal user (usually, more than developers !) are not necessarily addressed properly. I don't mean to say that the project itself should be separated into parts, but rather some more of the responsibility should be shared, so that there's really less interaction by the main people required. Talking of the webpage, which currently seems to be maintained -also by means of - CVS, is such an example: if there was a simple CMS (content management system) running, the webmaster could assing different sections of the page to different people for maintenance. So, Curtis would not have to make changes to the page by himself, but could rather ask someone else to take care of things like updating the news section or whatever, this might even be done by a general request to the mailing list. That way even those users who are not familiar with CVS etc. could help keeping the webpage updated (adding downloads etc.) and they would not require to be familiar with any special software. Currently, all this seems really to be a pretty static solution which seems to
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Jon Stockill wrote: Erik Hofman wrote: Jon Stockill wrote: Erik Hofman wrote: My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). That makes life very easy for us, but it's far from newbie friendly. What's wrong with the way world wide terrain data can be downloaded for FlightGear right now? Nothing at all - point and click is good, and makes is incredibly easy for anyone who can use a browser to get the scenery they want. Maybe I misunderstood what you meant - I thought you were talking about just having a cvs repository for all the extras, I'm thinking now you intended for it to be checked out onto a server in the same way as the website is - is that correct? Yes. Maintaining can be done using CVS and when the official release is out it can be just a matter of letting a script generate the tarballs for the static scenery. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: Fair enough. But with ground structures that are installable separately, it's possible for a user to pick and choose what to install. For example, someone could wish to see a set of landmarks in Paris, but not the buildings at Orly (wanting smoother framerates during landing/takeoff, but not caring so much when flying over the center of the city), or something like that. So while I really like having the separate Objects directory, and agree that being able to toggle on/off the static scenery objects would be a good thing, I think being able to pick and choose what (non-random) static structures to install is *also* a good thing. Agreed. Well, having user-developed scenery in a CVS repository would be nice in that it'd make available all of the CVS infrastructure; no need to create or port a bunch of applications to maintain it all. And it would be easy to integrate with everything else, and add to mirrors, and so on. But from the users' perspective, it may not be ideal in that it's not very *browseable* -- to look through what's available in a nice friendly form, with images and so on, and pick out what you like and dload it. Browsing a CVS repository is possible, of course; but kinda ugly and more oriented towards developers than users. I don't know much about user-friendly CVS clients, especially for Windows. The other thing is that I think it'd be good to avoid putting any more work upon the existing developers (e.g. not asking Curt to take on more website work). If the CVS archive ran on outside machines, and was linked to off the website on baron.flightgear.org, that might work OK, I dunno. I've already explained this to Jon, but I was really aiming at a two stage approach. Maintaining can be done using CVS. Making it available for users could be done like downloading the terrain data right now: Using a webpage. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
On Sun, 01 Aug 2004 10:32:31 +0200 Erik Hofman [EMAIL PROTECTED] wrote: I've already explained this to Jon, but I was really aiming at a two stage approach. Maintaining can be done using CVS. Making it available for users could be done like downloading the terrain data right now: Using a webpage. That seems sensible; I hadn't been aware that the terrain data is managed by CVS behind the scenes. If the intent is to make it easy for users to contribute their own stuff to the community, then maybe user uploads go to some quota'd directory and someone then checks that stuff into CVS, and makes it available on webpage, after looking at it (quota'd to avoid maliciousness / crapflooding / etc.). I think the front end should be browsable (with a related image or two of each set) and searchable; obviously there's not much stuff to browse through/search through now, but it's good to have that functionality planned in from the start, rather than having to deal with it later. I'll start playing around with this stuff to see if I can set up a system that works well. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpDNWZSIBaGK.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: I've been waiting to post this until after the release went out, hoping there'd be more discussion when things were a tiny bit calmer . . . Over time, various people have done a lot of work on ground structures, etc., to add to the scenery for FlightGear. Frederic's did a lot of work on the bridges + downtown for SF; that's now distributed with the default area scenery. Franz Melchior did Vienna's Donaturm tower, complete with Actually it's Melchior Franz. ot agree with): 1. It's probably *not* the best idea for it to all just get added into the FlightGear scenery archives, to be there automatically when the terrain for an area gets downloaded from scenery.flightgear.org or its mirrors. There are already people having a hard time with framerates just with the structure in the default area. I imagine a scenario where a user fetches updated scenery files for an area they've been flying around for a while, and discovers suddenly that it's unusable now for them because of a recent addition of a bunch of framerate- crushing eye candy. I think that (now that we have a separate Objects directory) it is possible quite easily to add a command-line option to disable the static scenery objects. So what we discussed was a webpage/site which would (eventually) do for FlightGear what avsim.com/flightsim.com's file libraries do for MSFS. At least at first, it'd provide upload/browse/download capability. Eventually, it could also be a place to fetch useful scripts, programs, scenery-making tutorials, etc. It wouldn't necessarily require a chunk of Curt's time or hardware; it need not even be in the flightgear.org domain, although I think it'd be a good thing if it was (unfortunately, scenery.flightgear.org is occupied, hehe). Mat Churchill and I are both enthusiastic about such a scenery website. My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: [...] So what we discussed was a webpage/site which would (eventually) do for FlightGear what avsim.com/flightsim.com's file libraries do for MSFS. At least at first, it'd provide upload/browse/download capability. Even though I agree with Erik that it would make sense to keep everything in a central place I do also think that it should be easily possible for the mentioned user contributions to be added easily BY users - without the need for developers/project managers to take care of such things. So, I think the idea in general is pretty good, but regarding browser based file uploads there might be a problem when it comes to scenery packages: these files are usually pretty large, so it would be more realistic to provide anonymous FTP access for these uploads - also more convenient, I wouldn't want to wait for a large file to upload via browser without any status information at all... Eventually, it could also be a place to fetch useful scripts, programs, scenery-making tutorials, etc. As long as it would be running via some kind of CMS this would really be an advantage, as it could become a central repository for designers in general - be it scenery or aircraft. So that everybody could easily make direct contributions. Also, such a webpage could offer scenery download based not only on certain clickable areas but really based on certain towns/airports or even navaids. This would merely be a cross lookup between the navaids file and the actual scenery folders in order to determine which scenery package needs to be picked for a certain town/airport or navaid. One could even provide a flight plan in order to determine the necessary scenery downloads, I am not sure if TerraGear is using such an approach already, as I keep having problems with it ... It wouldn't necessarily require a chunk of Curt's time or hardware; No, as it sounds it would have the legitimation to become a separate webpage if necessary, probably one could even use a sourceforge project for that purpose...that way at least the resource problem would be solved ;-) it need not even be in the flightgear.org domain, although I think it'd be a good thing if it was (unfortunately, scenery.flightgear.org is occupied, hehe). Mat Churchill and I are both enthusiastic about such a scenery website. actually, it's not long ago that I sent an eMail to Curtis asking for other additions to the original FlightGear page that I suggested. I mentioned both of these already in previous postings on this mailing list, unfortunately there were not any reactions to these - absolutely contrary to the reactions to my usual posting ;-) On the one hand I suggested installing a bugtracker script and on the other hand a dynamic FAQ system. I did offer to take care of the installation/setup etc. - so it would not require much effort from other people in order to get these things done. So if Curtis should decide that he doesn't want to put something like that on FlightGear.org I would love to join your efforts so that we could put all these things on a different webpage, which should still be linked to from FlightGear.org - Curtis could set up a specific subdomain for exactly that purpose, so he would still keep his recource usage low(er). - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Jon Stockill wrote: Erik Hofman wrote: My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). That makes life very easy for us, but it's far from newbie friendly. What's wrong with the way world wide terrain data can be downloaded for FlightGear right now? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Erik Hofman wrote: Jon Stockill wrote: Erik Hofman wrote: My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). That makes life very easy for us, but it's far from newbie friendly. What's wrong with the way world wide terrain data can be downloaded for FlightGear right now? Nothing at all - point and click is good, and makes is incredibly easy for anyone who can use a browser to get the scenery they want. Maybe I misunderstood what you meant - I thought you were talking about just having a cvs repository for all the extras, I'm thinking now you intended for it to be checked out onto a server in the same way as the website is - is that correct? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
