Welcome!

Welcome and thanks for Howto:Convert objects with ModelConverterX.

While it is something I will probably not use myself I appreciate your effort and the quality of your first wiki article here.

Johan G (Talk | contribs) 20:32, 26 April 2014 (UTC)

apt.dat 810 vs. 850 vs. 1000 formats

I saw you recent edits related to the apt.dat formats, in particular this one. I do not know how many outside the developer and/or the scenery development/enhancement communities that are aware of the following, but it seems to go by word of mouth.

According to some forum posts ([1], [2]) it seems that genapts support both apt.dat formats 810, 850 and 1000, but unfortunately the terragear developers are not very clear on what formats terragear and/or genapts actually support, in fact can't find it in terragear's readme files.

In other words it seems for now that in FlightGear lingo 810 represents X-plane apt.dat 810 and older formats while 850 represents 850 and newer formats, if that is any help. I do not really like the inconsistency and ambiguity of that.

Johan G (Talk | contribs) 10:24, 3 May 2014 (UTC)

Feel free to fix my edits, I'm definitely not the expert one here! Rather, I think you're right keeping an eye on me. PS: documenting this project sure is a considerable endeavour.
This unsigned comment was added by Bigstones (Talk | contribs) 11:48, 3 May 2014 (UTC)
I guess I could have fixed this one. But I only now a little more than you on this subject. ;-) I also guess I was venting a bit of frustration about the lack of detail in some of the documentation.
And yes I am sort of keeping an eye on you, though not on you specifically. This wiki is still not busy enough that one can, most of the days, see all that is going on looking at the Recent changes link in the menu to the left and the diff's.
Also I moved your reply here and signed it. Wikis usually have replies on the same talk page as it kind of helps in following a conversation. Also, please sign you messages (easiest done using four tildes ~~~~ or the sign button   above the text box).
Johan G (Talk | contribs) 13:24, 3 May 2014 (UTC)


A property rule to regulate lightmaps with the sun

First, I'm not sure if using a shader lightmap is the best way to lighten up scenery buildings. It only works with the right shader settings, and poeple with older computers can't/ won't use them. Then every buidling need a .xml file with the nasal-script --> perfomance issues raises up!

I still prefer the old way to lighten up buildings. (Described somewhere here in the wiki)

Nethertheless, I do understand your problem. I'm using lightmaps on the EC130 B4. (and Dornier 328 but not yet in my repo) Especially the EC130 B4 shows how to deal with it,

The magic property is sim/time/sun-angle-rad. You have to multiply the lightfactor with the sim/time/sun-angle-rad. How exactly you will find in the lightmap.nas of the current EC130 B4 in FGData.

Cheers --HHS (talk) 10:47, 4 May 2014 (UTC)

Hi HHS, thank you for the interest. My computer is already getting old (6 y.o., graphics card 4 y.o.) and I have no problems with shaders, only Rembrandt shadows seem to be heavy. For when I'm done, my computer will be definitely old, so I hope using lightmaps is ok. Anyway, I don't know if you've read my forum post, but I'm already using sun-angle-rad directly and I am not satisfied (details in the post). Also, there's no need for nasal to simply use that as a factor (see Howto:Lightmap, using Effect/model-combined-deferred is just more verbose - BTW, I'm not satisfied with this second effect and I'll post about that too).
The idea is to use a single script in one of the models, which would add an adjusted 'sun-angle-rad' to the property tree, and use that as a factor for lightmaps. LOWI is already doing that, its version of your script is linked in my forum post.
Cheers, --Bigstones (talk) 12:44, 4 May 2014 (UTC)

wiki restructuring

Hi,thanks for taking the time to write down all this. I do agree that improving the wiki structure would be great. Then again, we'll want to do that without introducing any "breakage" - thus, it would be important to do this alongside the existing structure, possibly in some form of "sandbox", with just a few articles (e.g. picking the most popular ones). Also, please keep in mind that the current state of things already represents hundreds of hours contributed by volunteers like you. Roughly 8 years ago it was Gijs who didn't like the wiki structure and then spent dozens of hours coming up with a new scheme, but he made sure not to break anything by implementing his own structure as a suggestion alongside the existing system. That is something that I would also suggest to do here. If you need an extensions to be installed, better discuss this with Gijs first, so that he can review your ideas and then get in touch with Simon (who's maintaining the server).--Hooray (talk) 08:49, 6 May 2014 (UTC)

Hi, I will of course discuss all this with the maintainers (by posting about it on Village pump and Documentation forum). For now this is "private" only because writing it down helped to clarify my mind on some things. I didn't consider possibility of breakage, so that's going to be interesting. I'll soon publish this thing, when ready.--Bigstones (talk) 09:55, 6 May 2014 (UTC)
I made a similar write-up when I had been here for only a short time, Essay:The FlightGear Wiki — Its structure, content and ease of use, though I did it as a subpage to my user page. While you are at it you might want to have a look at the pages listed under User:Johan G#Wiki related subpages. Maybe there is enough ideas around for a wiki quality portal under the wiki portal. ;-)
I think we to some degree have come to similar conclusions, though my focus rather was at having some help for new editors. One thing I spent a lot of time on is documenting the templates (I am still not done). Note that I hardly mentioned categories, they were nearly non-existant (in fact nearly all the images was uncategorised). Unfortunately most editors seem to see them as tags as you have noted, though my biggest grief is when they use a category together with the parent category. I don not believe in strictly one category per page, but if I understood you right, neither do you. What I do believe in though is splitting up too large categories. It is often a lot of work, but needs to be done now and then. As for arranging the categories in a tree structure, I tend to see it like tree with some cobwebs. ;-)
One thing to note about the FlightGear project as a whole is that it is much, much more of a bazaar than a cathedral (if you are familiar with wikipedia:The Cathedral and the Bazaar by Eric S. Raymond. If not it is well worth a read). In essence each contributor tend to do what they care for and find worth while. As for development teams and hierarchy, there pretty much is none. This is probably reflected on the wiki as well for better and worse.
Anyway I am sure we will find more things we agree on (and probably things we disagree on as well).
Johan G (Talk | contribs) 16:37, 6 May 2014 (UTC)
Hi,
That's a lot to discuss! Just a few quick preliminary comments:
I see that categories are used as tags, that is, they're combined so that by looking at an article categories one has an idea of what it talks about.
Not sure I understand this. Do you mean that one has to look at the categories at the bottom of an article to see what the article is about? I've never used it that way myself...
giving each article one single category
Why would you want to do that? The definition of a category is that it is a group of several articles that fit a certain subject (or category). A category with just a single article in it means it is redundant and the article should be moved to the parent category.
CategoryTree extension
We used to have this one, but its maintainer had to fix a bug (see FlightGear wiki:Village pump#Found bugs to make it work with the current version of MediaWiki. I just noticed there have been some updates to it lately, so I'll see if I can re-enable it now. (EDIT: re-enabled!)
linking an article in a portal and its parents is duplication.
Often that's true, but there are exceptions. I originally designed the portals to guide people as quickly as possible to the article they're looking for. Portal:Developer for example should only list some of the most used aircraft articles.
Looking forward to the final version of your "review". Always nice to have a fresh impression of our documentation!
Gijs (talk) 19:03, 6 May 2014 (UTC)
I'm really glad and relieved to see these comments, I'd say these ideas are welcome to discussion and that's great. To answer rapidly Gijs:
  • By categories used like tags I mean that instead that using a particular, deep enough category one prefers to use two categories, unrelated, that combine to make a particular one. Details are where I talk about "orthogonal categories" (the too long part).
  • With "one category per article" I mean that each article should belong to only one category. I try my best with english, I'll try to clarify that.
  • I've just read about Extension:CategoryTree in Village pump! I wondered why there wasn't such a useful tool here.
  • OK. If people did like I did with the MCX article, I see why it could have lost quality.
My review is pretty much complete, I see already 3 admins/maintainers (or major contributors?) have read it, how many others do you think will be interested? Do you think it's possible to start a collaborative version of this plan and then condense it in a guideline? That is, avoiding the "wiki quality portal" (cit. Johan).
I'll give a read at Help:Categories and Johan's essay, maybe I can tune my paper towards those to ease discussion (any other document I should consider?). I'll move it to a user page like Johan.
(ps: I've read Raymond's essay a long time ago, much more recently How the FlightGear project works, I'm just fine with that)
--Bigstones (talk) 20:01, 6 May 2014 (UTC)
right, the 3 main wiki admins/maintainers who are currently involved/active have responded here already. As long as you keep your proposals optional, alongside the existing structure, I do not mind you proceeding directly from here, and I am sure that Johan & Gijs are also supportive of your contributions. Just let me say that we do not necessarily need suggestions/proposals or guidelines as much as people willing to actually implement something that works and "release & often", while responding to any community feedback provided. We've seen quite a few people in the last 18 months who expressed an interest in helping with our docs (including the wiki), but I have yet to see anything significant materializing from it, beyond massive discussions, or even fairly critical elaborations about our existing "system" that "just sucks". That is not to say that such criticism would be totally wrong, but we need to come up with something that works for all the parties involved here, especially those volunteering to help with maintaining entities like the wiki or the forum (which is mainly people like Gijs & Johan ATM). Obviously, nothing is "perfect" here, and there's lots of room for improvement - but recently, the FlightGear project seems to attract quite a few people who have a fairly poor signal/noise ratio, in other words if all the time spent debating with others would be spent contributing directly, we'd be in a pretty good shape actually. And even some of the more seasoned contributors seem to be falling victim to this recently, I know it happened to me... Overall, I am in favor of keeping the portal-based system - it's served us well, and hasn't even been adopted completely yet. Regarding more specific feedback, see below:
abandoned project articles
not sure about this one, keep in mind that we have quite a few projects and efforts that had a shelf life of 12-18+ months, I definitely would not delete them unless the author/contributor agrees to do so.
old site/outdated stuff
the website is beyond outside our control, Curt is the one "maintaining" it, and obviously been busy with other stuff - many people have discussed the official website, its design and outdated info, fairly critically - but I'd just suggest to ignore it for the sake of simplicity. Otherwise, Curt would need to provide volunteers with admin/moderator privileges so that they can help maintain it, or move things over to the wiki where we actually have contributors doing exactly that.
rules for contributors
sounds like a good idea, maybe we could have something like the "upload wizard" just for new articles, where the whole thing would be based on a few parameters and customize a few templates, i.e. automatically adding stuff like {{stub}}, {{WIP}} or {{Non-stable}}, based on checking a few check boxes ? Hopefully, there's some kind of extension for "wizard-based" article creation ?--Hooray (talk) 20:24, 6 May 2014 (UTC)