Template talk:Fgdata effect

Generalisation

This may better be generalized to also support effects outside fgdata/fgaddon, e.g. see [1] -Hooray (talk) 06:31, 21 August 2016 (EDT)

I have just converted this to a subtemplate of {{repo link}}, via {{fg root file}}. For aircraft specific effects, I would suggest a new {{fg aircraft effect}} template which is a subtemplate of {{fg aircraft file}}, placing it into the {{repo link}} family as well. For a good organisation of these templates, see Category:Repository link templates. Oh, you forgot to sign off Hooray.

Bugman (talk) 06:25, 21 August 2016 (EDT)

Note that this template can be very easily expanded to include any of the {{fg root file}} parameters as well. To have access to more of the {{repo link}} parameters, then both this template and {{fg root file}} would need to be expanded.

Bugman (talk) 06:27, 21 August 2016 (EDT)

Yeah, I just saw your edit - thank you, I didn't realize that we should prefer one over the other, this may be better documented at some point --Hooray (talk) 06:32, 21 August 2016 (EDT)

I guess it would be better not to add too much functionality to this, maybe some kind of intermediate template would be better, i.e. one sitting on top of repo link and in between templates wrapping file links, for example:

• Template:GUI dialog
• Template:Canvas Widget
• Template:PUI widget

Sooner or later, we will probably also have templates wrapping links to shaders (fragment, vertex, and geometry) - from the standpoint of the wiki, it is a good idea to organize these resources, and to clearly encourage the use of these templates, so that we can more easily update/maintain such URLs if/when the need arises. Thus, my suggestion would be not to add too much generic functionality to individual templates, but rather introduce a wrapperr - kinda like the file/path handling discussion we've been having regarding your python script to track fgdata resources, because that really is what this is about after all.--Hooray (talk) 06:37, 21 August 2016 (EDT)

The {{repo link}} family is essentially designed like this. For any FlightGear infrastructure changes, URL changes, or GitHub/GitLab/Gitorious/SourceForce URL changes, only the {{repo link}} template needs updating, and then the whole family of templates will point to the correct resource. For shaders and other special elements, we can simply subclass the {{fg root file}} and {{fg aircraft file}} templates to create subfamilies of these templates. The new templates can then be expanded as necessary, as the parent {{repo link}} parameters allow for any URL imaginable to be constructed.

Bugman (talk) 07:09, 21 August 2016 (EDT)

I was also specifically thinking in terms of fgdata/fgaddon-level changes, e.g. consider moving, renaming or introducing new folders that would need to be reflected by updating dozens of articles referencing $FG_ROOT/Effects, $FG_ROOT/Shaders - for the time being, we would be facing the same dilemma that we were facing after the gitorious/sf.net transition. Thus, it makes sense to have one template that is updated/maintained as necessary - if in doubt, we could obviously add this functionality to the repo link template, but that would mean having a huge switch/case (conditional) block to map arguments to paths. --Hooray (talk) 07:14, 21 August 2016 (EDT)

I'll create the subfamilies of templates, and update Howto:Multi-channel lightmap using these. I think you'll be pleased ;) There will be zero switching/cases involved.

Bugman (talk) 07:31, 21 August 2016 (EDT)

Thanks for taking a look, but I don't think we need to make this a priority currently - However, it's certainly a worthwhile thing to aim for (over time). For instance, imagine refactoring the base package to clean up certain directories, such as grouping Rembrandt and ALS effects/shaders into separate directories.

Equally, in the light of the recently revamped release scheme, and particulaly changing airports for each release, there's now an increasing trend to move hard-coded stuff to preferences.xml, or separate XML files in $FG_ROOT (for better jenkins/release automation) - so, over time, some of our long-standing defaults may end up being moved to different locations and use different file names.

For example, see Torsten's commit/message at [2]. Or just look at Erik's recent suggestion/request . Thus, it seems increasingly likely that preferences.xml will be refactored and cleaned/split up over time , which is something that Stuart was already supportive about years ago , back when we originally discussed "refactoring the base package, and preferences.xml specifically" --Hooray (talk) 07:55, 21 August 2016 (EDT)