On Mon, 6 Aug 2012 11:09:15 +0000 (UTC), Martin Spott <martin.sp...@mgras.net> wrote: > Tim Moore wrote: >> On Mon, Aug 6, 2012 at 10:00 AM, Martin Spott <martin.sp...@mgras.net> >> wrote: > >>> Therefore I think trying to guide "2nd-row developers" is a waste of >>> time in most cases. >> >> How does scenery production, including airport modeling, scale without >> 2nd (and 3rd and 4th)-row developers? > > Badly. The point is that there are only very few who like to be > guided, Yves is one of the rare exceptions - and from my understanding > he doesn't need much guidance because he already has identified pretty > well what needs to be done ;-) > > I don't think that 'guidance' works in this context. These are all > (mostly !?) grown-up people and after they've decided to grow their > private Scenery ecosystem, you hardly convince them otherwise. You can > try offering an appealing toolchain .... but, as everybody knows, Rome > wasn't built in a day either and many of the addressees simply don't > (want to) understand how sensitive as well as laborious the topic is. > > Cheers, > Martin.
I think it's hard to convince some devs that there's no other way than to create your own "private Scenery ecosystem". Scenery is not only about a few cheap objects placed here and there in a river or on a misplaced road. It has always been recommended to start your "custom scenery" development with fixing or adding the missing airfield layout and objects you saw or used in real life. After all, you start from the base, at home! I don't see the point to add airport objects on a missing/wrong/outdated airport layout if you can't taxi back or respect the procedures. Even more if this will interfere or kill the flight experience. Sometimes it's better not to have something, than having something that doesn't work at all. I think peoples working on scenery tries to make the scenery as close as it is (technically) possible. Some document them and watch how the scenery is in real life. I believe that scenery devs use what they made, and hope their data could be useful for other aviation enthusiasts. Peoples have wasted tons of time in the past tweaking an useless and outdated apt.dat file format. But even for that there's no way to get that airport/Terrain included into the terrasync repository. Which, we must admit!, make terrasync only usable for a less interesting and minor 50%! Once the new scenery dev realize that, he move on to create his own "private Scenery ecosystem" in the hope he could ever merge his data. What would you think if you need to upload your source code updates, file by file in a webform, or send by mail and where i should strip out some useful data? Or your new lovely wip private aircraft, which i will need to strip out and maybe commit its FDM the next coming 2 years? It has been proven that the current scenery dev workflow is a waste of time and bother both concerned sides. We need to find a practical way for maintenances. For SG/FG/FGDATA, you must prove your skills for some time and then later you get commit rights if you want to continue your contribs. I don't think svn/git commit rights is a nice solution for scenery devs (mind also big binary history), but the workflow is. There's maybe a need for a much more complex scenery (web) managing tool with specific rights. That would maybe already motivate scenery devs to maintain 2 copies of sceneries, in awayting that the major Terrain issue get fixed. On the other side, a bunch of custom sceneries here and there on the web isn't nice to manage and break the initial goal of the awesome terrasync system. I guess that also many efforts are just wasted and (will be) lost in the cyberspace. It bother myself that my scenery terrain tiles interfere with data in terrasync. It's annoying to inform peoples, and for these peoples themselves, that they need to merge by hand data with data in terrasync if they want to do a bit more as your lovely GA VFR cross-country flights. At user side, the scenery updater system(terrasync) is close to be perfect. But these days, it isn't for those who need to fill in the gaps with a massive amount of data. I know that there's currently still a few technical issues with the toolchain and it's next generation scenery it can produce. But it's encouraging that some devs are working on the toolchain and related tools. The thing is that we need to move forward and work for our future, instead for our non-fixable past. Regards, David (itchi) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
