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 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: 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
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: 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
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
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
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
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. I agree with that one, as a developer you must not forget that most FlightGear users are likely (hopefully !) to be non-developers and hence what might seem feasible/easy and logical to you is not necessarily the best approach for those users who are not used to things like CVS/FTP etc. So, there is some justification for such a thing - as a user you usually don't want to have to learn about all the steps involved, but would much rather want to keep things as simple as possible ... - 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
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. -- 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
Chris Metzler wrote: > Mat Churchill and I are both enthusiastic about such a scenery > website. > > What do people think? I think some sort of centralised list of what people have been working on is a great way to go - for both finished scenery, and models too - obviously there are limits to what can be included in the base package, and you have to draw the line somewhere. A place where aircraft, scenery, scenarios, traffic manager schedules, etc can all be brought together as a single resource seems like an extremely good idea. -- 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
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
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
[Flightgear-devel] RFD: how to handle add-on ground scenery distribution
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 animations, and made the model available for download. Mat Churchill has recently shown off some great stuff with the airport in Nice. Josh Babcock and I are slowly doing stuff around the Washington, D.C. area. I'm sure lots of other people are doing things as well. The question is, what should happen to this stuff when people create it and choose to make it available? Mat Churchill and I recently had a discussion about what we thought of this, and the following points got mentioned (which are of course just opinions, and which you may or may not 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. A better idea is to leave this stuff out of the official scenery, but to make it available for those who are interested to install as they wish . . . 2. . . .which is basically how things are right now. The problem is that there's no easy way for anyone to know what others have done and what's available to them. Right now, what's typically done is that the creator puts stuff up on their personal ftp/website, and makes a post to flightgear-users or -devel announcing what's available. Over time, this gets forgotten. In the MSFS world, that role is played by sites like avsim.com and flightsim.com and so on; they provide searchable file repositories, with pictures, etc., to which people can upload, and from which people can download. Stuff gets a lot more exposure this way. 3. Some users like eye candy. The more of it there is (and the easier it is to obtain), the more fun some people will have, and probably the more users there'll be. And consequently, the more project/scenery/etc. contributors there'll be. And so forth. In particular, making attractive ground structures available will inspire other people to join in and create some themselves, and so on. 4. Some models, textures, etc. that are already out there cannot be distributed with FlightGear because of licensing incompatible with the GPL (e.g. "Freeware" licenses). But that doesn't prevent them from being *used* with FlightGear; it simply prevents them from being bundled with and distributed with FlightGear. As an example of what I mean, not all the theme/icon/background/etc. stuff available for KDE or GNOME online is GPL'd. Stuff with licensing incompatible with the GPL can't be merged into KDE and distributed as part of KDE; but that doesn't mean it can't be made available on kde-look.org, for people to fetch and use as they desire. 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. What do people think? -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 pgpdzmORZebvS.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
