https://wiki.flightgear.org/w/api.php?action=feedcontributions&user=Bigstones&feedformat=atomFlightGear wiki - User contributions [en]2024-03-29T15:34:32ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=73477FlightGear wiki:Instant-Refs2014-06-29T14:36:00Z<p>Bigstones: /* The Script */ oops</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br/><br />
<br/><br />
This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br/><br />
<br/><br />
For more info, I suggest to check out:<br/><br />
<br/><br />
[[MapStructure#Porting_the_map_dialog]]<br/><br />
[[File:MapStructureDialog.png|250px]] <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case [http://sourceforge.net/p/flightgear/mailman/message/31936560/]{{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
* gitorious links converted to wiki markup could/should probably use the "Git link" template, e.g. see the quote at [http://wiki.flightgear.org/Canvas_ND_Framework#Design]<br />
<br />
== The Script ==<br />
<syntaxhighlight lang="javascript"><br />
// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @require http://code.jquery.com/jquery-1.11.1.min.js<br />
// @require https://code.jquery.com/ui/1.11.0/jquery-ui.min.js<br />
// @resource jqUI_CSS https://code.jquery.com/ui/1.11.0/themes/smoothness/jquery-ui.css<br />
// @grant GM_addStyle<br />
// @grant GM_getResourceText<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var jqUI_CssSrc = GM_getResourceText ("jqUI_CSS");<br />
GM_addStyle (jqUI_CssSrc);<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
phpBB_smilies2text(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
}<br />
};<br />
<br />
var OUTPUT = OutputMethods().msgbox;<br />
<br />
function OutputMethods() {<br />
var methods = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
},<br />
<br />
// XXX: experimental<br />
// show msg in a jQuery UI dialog<br />
jqueryDiag: function(msg) {<br />
var diagDiv = $('<div id="MyDialog"><textarea id="quotedtext" rows="10" cols="80" readonly>' + msg + '</textarea></div>');<br />
<br />
var diagParam = { title: "Copy your quote with CTRL-C",<br />
modal: true,<br />
buttons: [{ text: "Select all", click: function () { $('quotedtext').select(); } },<br />
{ text: "Cancel", click: function () { $(this).dialog("close"); } }]<br />
};<br />
<br />
diagDiv.dialog(diagParam);<br />
}<br />
<br />
};<br />
<br />
return methods;<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
// automatic links to the wiki (we don't use the displayed text)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>https?:\/\/wiki.flightgear.org.*?<\/a>/g, "[[$1]]");<br />
// links to the wiki with custom text (we preserve it)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
html = html.replace(/<a[^(?:href)]*href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
return html;<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/(?:[0-9]+px-)?([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
bbhtml = bbhtml.replace(/<span class="posthilit">(.*?)<\/span>/g, "$1");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// converts smilies images from phpBB.<br />
// Must be used BEFORE img2link(), because it makes a broken link of them<br />
function phpBB_smilies2text() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<img.*?src="\.\/images\/smilies\/icon_.*?\.gif".*?alt="(.*?)".*?>/g,"$1");<br />
}<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/12034334<br />
var entityMap = {<br />
"&": "&amp;",<br />
"<": "&lt;",<br />
">": "&gt;",<br />
'"': '&quot;',<br />
"'": '&#39;',<br />
"/": '&#x2F;',<br />
"\n": "<br/>"<br />
};<br />
<br />
function escapeHtml(string) {<br />
return String(string).replace(/[&<>"'\/]|[\n]/g, function (s) {<br />
return entityMap[s];<br />
});<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=73475FlightGear wiki talk:Instant-Refs2014-06-29T14:34:32Z<p>Bigstones: /* Chopped strings and stripped \n's: we need an alternative output */ updates on jQuery UI</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/ (also supports images: [https://code.google.com/p/flightgear-bugs/issues/detail?id=1295])<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== too greedy non-greedy regexes ===<br />
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can still be incorrect: say I have<br />
<nowiki><a someprop="href" href="http://www.link.org" ... ></nowiki><br />
If I want to mach anything between a and href, I use <tt><nowiki>[^(?:href)]*</nowiki></tt>, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].<br />
<br />
So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using ''only'' xpaths *sobs*.<br />
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
=== Postings that break our script for some reason ===<br />
* http://forum.flightgear.org/viewtopic.php?f=19&t=23365<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: {{done}}. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}} --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)<br />
<br />
=== Chopped strings and stripped \n's: we need an alternative output ===<br />
At first, the limitation of the alert dialog was only on the length of the text. Now radi reports that Firefox strips the newlines (as in \n) making the string hardly readable, and I can confirm this on Iceweasel (Debian's re-branded Firefox). It seems that the most flexible way out of this is a superimposed div. I made some experiments, however it seems that all of this could be handled easier through some library like jQuery. I think I don't even know how to include a library inside a JS script. To escape the html code to show it in the html body (like br's and others) a nice and easy solution is [http://stackoverflow.com/a/12034334 here].<br />
<br />
:: I agree that we should explore adding alternate OUTPUT methods, probably using jQuery. I experimented with that a while ago, and adding external dependencies/scripts should be a no-brainer once we modify the document to inject additional script tags [http://stackoverflow.com/questions/10113366/load-jquery-with-javascript-and-use-jquery][http://stackoverflow.com/questions/11212809/load-jquery-dynamically][http://www.sitepoint.com/dynamically-load-jquery-library-javascript/]. That way, we could also use HTML to create custom message boxes/dialogs, or directly modify the DOM like you suggest. So I am not opposed to using an external "library" for such purposes, because we could easily customize the whole thing - in fact, we could even present a "wizard"-like interface at some point. A few weeks ago I played with an AJAX output method to directly modify a wiki text box by inserting the modified cquote. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:11, 22 June 2014 (UTC)<br />
<br />
::: I added a jQuery dialog output method. Right now it is not very usable. There should be the autoselection of the content, I went for a textarea but it could be anything. Importing the jQuery UI css works, but then it has relative urls to the images... Another not-really-an-issue is that selecting the text in the textarea triggers the script again (failing). However ctrl-a ctrl-c does the job of selecting and copying, I guess it gets automatically the focus. It also breaks the normal selection (you can cancel, but the selection is gone).<br />
::: It needs to be enabled by setting OUTPUT = OutputMethods().jqueryDiag;<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:34, 29 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=73467FlightGear wiki:Instant-Refs2014-06-29T14:18:11Z<p>Bigstones: added an *experimental* jquery dialog output + escapeHtml for code snippets quoting (not yet used)</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br/><br />
<br/><br />
This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br/><br />
<br/><br />
For more info, I suggest to check out:<br/><br />
<br/><br />
[[MapStructure#Porting_the_map_dialog]]<br/><br />
[[File:MapStructureDialog.png|250px]] <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case [http://sourceforge.net/p/flightgear/mailman/message/31936560/]{{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
* gitorious links converted to wiki markup could/should probably use the "Git link" template, e.g. see the quote at [http://wiki.flightgear.org/Canvas_ND_Framework#Design]<br />
<br />
== The Script ==<br />
// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @require http://code.jquery.com/jquery-1.11.1.min.js<br />
// @require https://code.jquery.com/ui/1.11.0/jquery-ui.min.js<br />
// @resource jqUI_CSS https://code.jquery.com/ui/1.11.0/themes/smoothness/jquery-ui.css<br />
// @grant GM_addStyle<br />
// @grant GM_getResourceText<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var jqUI_CssSrc = GM_getResourceText ("jqUI_CSS");<br />
GM_addStyle (jqUI_CssSrc);<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
phpBB_smilies2text(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
}<br />
};<br />
<br />
var OUTPUT = OutputMethods().msgbox;<br />
<br />
function OutputMethods() {<br />
var methods = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
},<br />
<br />
// XXX: experimental<br />
// show msg in a jQuery UI dialog<br />
jqueryDiag: function(msg) {<br />
var diagDiv = $('<div id="MyDialog"><textarea id="quotedtext" rows="10" cols="80" readonly>' + msg + '</textarea></div>');<br />
<br />
var diagParam = { title: "Copy your quote with CTRL-C",<br />
modal: true,<br />
buttons: [{ text: "Select all", click: function () { $(this).select(); } },<br />
{ text: "Cancel", click: function () { $('quotedtext').dialog("close"); } }]<br />
};<br />
<br />
diagDiv.dialog(diagParam);<br />
}<br />
<br />
};<br />
<br />
return methods;<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
// automatic links to the wiki (we don't use the displayed text)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>https?:\/\/wiki.flightgear.org.*?<\/a>/g, "[[$1]]");<br />
// links to the wiki with custom text (we preserve it)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
html = html.replace(/<a[^(?:href)]*href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
return html;<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/(?:[0-9]+px-)?([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
bbhtml = bbhtml.replace(/<span class="posthilit">(.*?)<\/span>/g, "$1");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// converts smilies images from phpBB.<br />
// Must be used BEFORE img2link(), because it makes a broken link of them<br />
function phpBB_smilies2text() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<img.*?src="\.\/images\/smilies\/icon_.*?\.gif".*?alt="(.*?)".*?>/g,"$1");<br />
}<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/12034334<br />
var entityMap = {<br />
"&": "&amp;",<br />
"<": "&lt;",<br />
">": "&gt;",<br />
'"': '&quot;',<br />
"'": '&#39;',<br />
"/": '&#x2F;',<br />
"\n": "<br/>"<br />
};<br />
<br />
function escapeHtml(string) {<br />
return String(string).replace(/[&<>"'\/]|[\n]/g, function (s) {<br />
return entityMap[s];<br />
});<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Property_tree&diff=73406Property tree2014-06-28T15:18:35Z<p>Bigstones: restructured</p>
<hr />
<div>{{PropertyTree}}<br />
The so called '''Property Tree''' is considered [[FlightGear]]'s central nervous system and one of its greatest assets. It is the interface to low level, run time state variables via a very intuitive tree-like hierarchy, allowing for FlightGear's behavior to be easily controlled and manipulated at run time.<br />
<br />
The concepts and mechanisms behind the Property Tree may not be immediately obvious to FlightGear beginners. This page is meant to help new users familiarize themselves with the FlightGear property tree.<br />
<br />
== The purpose of the Property Tree ==<br />
The property system - or property tree - represents most of the internal state of all systems within FlightGear, like for example the flight dynamics model, or the weather simulation. The content of these internal state variables are presented in a hierarchically manner and can easily be accessed through a well known API. A system may present its current state to other systems and let them change its current state by allowing to write to its own properties.<br />
<br />
One might think of the property system as a global, normalized communication platform, where subsystems may publish variables and access other subsystem's variables. In addition, ''callbacks'' can be registered to invoke code upon read/write access of properties, which serves as the backbone for a very simple, but powerful, ''signalling mechanism'' in FlightGear. Thus, the property system acts as a routing interface, both between different high-level FG sub-systems and the outside world. Data that is required by one FG sub-system can be exposed in the property tree, where it can then be read or modified, either by other internal FG sub-systems, or by & for external input/output. <br />
<br />
=== Examples of use ===<br />
For example, a left banking joystick input is exposed in the property tree where it is read by the FG FDM sub-system. The FG FDM subsystem then in turn outputs an aileron deflection back to the property tree where it is then read by the FG animation subsystem to animate the aileron deflection in the 3D model.<br />
<br />
Alternatively the joystick input, once exposed in the property tree, can be read and modified by an external application via the [[FlightGear I/O subsystem]], such as an external FDM. The output from the external FDM can then be fed back to FlightGear by writing its data back to the property tree, once again, via the FlightGear I/O subsystem.<br />
<br />
There are several subsystems that implement a full API on top of the property tree, such as the AI traffic system, the multiplayer mode, but also Canvas - basically, setting certain properties (e.g. via Nasal's setprop()), triggering certain code (through listener callbacks) - with arguments and return values passed through the property tree, which in turn allows arbitrary 3D models to be placed, but also AI traffic to be created / controlled, as well as OpenGL textures to be created and modified and run-time, which is what we use to implement HUDs, GUIs, instruments, MFD avionics, and even liveries or scenery textures (VGDS).<br />
<br />
== The organization of the tree ==<br />
Naming a property is very much like naming a file in a file system, with levels of hierarchy, e.g.: <br />
<pre><br />
/sim/aircraft = A333<br />
<br />
/position/<br />
/position/longitude-deg = '-122.3576677' (double)<br />
/position/latitude-deg = '37.61372424' (double)<br />
/position/altitude-ft = '28.24418581' (double)<br />
/position/altitude-agl-ft = '22.47049626' (double)<br />
<br />
/controls/seat/eject/initiate<br />
/controls/electric/APU-generator<br />
</pre><br />
<br />
Some of these variables are "calculated" within the sim (i.e. updated regularly, e.g. at frame rate), whilst others can be manipulated. Writing a variable is as easy as<br />
/* Its my turn to play the sim */<br />
set('/controls/seat/eject/initiate', 1)<br />
<br />
What makes FG powerful is that a new aircraft can easily be designed with its unique set of properties that somehow affect the simulation. The Aircraft model has an xml file of properties within the property tree.<br />
<br />
== Customizing and manipulating the property tree ==<br />
An important feature of the property tree interface is that it can be tailored and new entries added as required through [[Nasal]] scripts, without requiring C++ changes. If you wish to use a custom-written subsystem, such as your own Terrain Following and Avoidance subsystem, for example, and perhaps implemented in [[Nasal]], adding new property tree branches and nodes to handle your unique data presents no problems.<br />
<br />
The property tree is read, written, accessed and manipulated in a variety of ways, such as<br />
* startup arguments via <nowiki>--prop:/sim/foo=bar</nowiki><br />
* XML files<br />
* internal compiled code within FG - the c/c++ code<br />
* [[Nasal]] scripts - this is javascript-like scripting with read/write to the property tree. This is the way most aircraft are implemented.<br />
* Using native protocols, implemented in C++ (see [https://gitorious.org/fg/flightgear/trees/next/src/Network $SG_SRC/Network]. [[Property Tree/Sockets]]<br />
* Using the generic protocol, either in/out/bi - this allows send/receive to the FG sim via the [[Generic Protocol]]<br />
* telnet interface - query and fly the plane on the command line or using a scripted session (see [[Telnet usage]])<br />
* html interface - access the property tree using a conventional web browser like firefox/safari or chrome<br />
* using the built in [[Property browser]]<br />
* using other GUI dialogs<br />
* using cockpit bindings<br />
* using joystick bindings etc<br />
<br />
So they can come from many places, thus there's no single source file where you'll find ALL properties/types. You will need to look at the corresponding subsystem/component. $FG_SRC/Network is the right pace to look for hardcoded protocols, make sure to also understand their inheritance (the interface being implemented).<br />
<br />
== XML and property lists ==<br />
The property tree maps very nicely to XML. This is convenient for initializing the property tree and saving its state. Values in the tree are typed, but they can also be untyped strings which will be converted to a typed value when read.<br />
<br />
PropertyList-encoded XML files are mapped to a/the property tree - typically, such XML files are not manually processed, they are "transparently" processed by FlightGear, loaded and mapped into a Property Tree.<br />
<br />
== Protocols to access the property tree ==<br />
In addition to the protocols supported by the FlightGear I/O subsystem, other interfaces are provided by a built-in [[Property Tree/Web Server]] and a built-in [[Telnet usage|Telnet server]], which allow property tree data to be read and modified via these interfaces, i.e. using a telnet client or a conventional web browser, at run time.<br />
<br />
Note that you can setup as many of these servers as you want, for instance, just to be obscene you could do:<br />
<pre><br />
fgfs --httpd=5400 --httpd=5401 --httpd=5402 --telnet=5403 --telnet=5404 --telnet=5405<br />
</pre><br />
<br />
Now there are six network interfaces running that you can access from anywhere ;-)<br />
<br />
>> "can I borrow your ipod please?" "why?"<br />
<br />
=== Protocol Options ===<br />
Usually the "best" way depends on your specific circumstances. Will the two applications be running on the same machine? If not, do the two machines have a high speed network connection or some slow radio modem type connection? How much data are you sending and at what rate? Do you need really tight timing or can you get by with some delays and sloppiness in the communication?<br />
<br />
<br />
== Reference documentation to the property tree ==<br />
By what was said above, the property tree is not consistent with fixed variables, they are created dynamically, to represent a propeller plane vs Jumbo or even a "Caspian Sea Monster", or depending on which subsystems are active. Many properties availability may even depend on the startup/runtime settings you are using.<br />
<br />
There are a bunch of "common" properties - especially among similar FDMs and aircraft. Obviously, different FDMs/aircraft will use different properties (single piston, helicopter, jet, twin turbine helicopter etc). You may want to have a look at $FG_ROOT/Docs/README.properties.<br />
<br />
There are a couple ways that they are set, but a fair amount of them just "appear" without being documented anywhere. There are several places to look for properties; one is in the aircraft files, another is all Nasal files, and the last place (and often most useful!) is grepping (searching) through the C++ code. To determine how a property works and what it does often requires looking through any code that uses it. This is a part of FlightGear that we could certainly document better<br />
<br />
== Flight Dynamics Model (FDM) ==<br />
FlightGear uses a few [[Flight Dynamics Models]], such as<br />
* [[JSBSim]] <br />
* [[YASim]] <br />
These flight dynamics models present themselves differently in the tree, using different variables, in different places. That is what an aircraft can be designed around. Most FDMs use so called tied properties, which are directly mapped to memory in C++, so that they cannot be written to - so that you would need to disable the FDM using the null FDM instead.<br />
<br />
[[Category:Property Tree| ]]<br />
[[Category:Nasal]]<br />
[[Category:XML]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Telnet_usage&diff=73393Telnet usage2014-06-28T12:53:29Z<p>Bigstones: /* Telnet Server */ fixed link</p>
<hr />
<div>{{PropertyTree}}<br />
[[FlightGear]] comes with an internal command server. This so called '''"telnet" server''' provides a "remote shell" (like a command prompt) into the running FlightGear process that can be used to inspect and modify runtime state, but also to run commands.<br />
<br />
FlightGear can be configured to act like a telnet or even an http "server". It can watch a port for incoming connections and respond appropriately, these built-in daemons (servers) support multiple concurrent connections. <br />
<br />
FG has a low bandwidth "command" (aka telnet/props) interface where you can interactively (or automatically via an external program) examine and modify just about any internal variable in the sim. This gives you a great capability to do external scripting, external operater gui's, etc. For instance, if you have your own GUI for operating the sim and want to use it to set weather conditions, you can leverage the FG telnet interface to have your own program remotely configure the environmental settings in all your FG based visual channels.<br />
<br />
Many things (view parameters, weather, time of day, etc.) are configurable via the property system. For things like weather and view selection which don't change rapidly, you can send over new property values using the "telnet" interface. For things that could change rapidly (like view position/orientation) you probably want to blast over udp packets at 60hz or whatever your screen refresh rate.<br />
<br />
The telnet server can be activated with the <code>--telnet=port</code> [[Command Line Parameters|command line option]], where port is the number of the listening port that will be opened locally by the FlightGear fgfs process (note that the --props parameter is equivalent).<br />
<br />
The --telnet= option can be used to accept property configuration changes (things like weather effects and time of day.) You can use this interface to read/write individual properties. You could set up a separate gui configured to know the ip addresses of all the slaves so it could update them appropriately to make a change. For the time of day, this presupposes that all the computer clocks are pretty closely in sync ... then you can send the same time offset to them (in seconds) so they all can display the same time of day effects.<br />
<br />
A connection to the running server can be established using a conventional telnet client or by opening a simple TCP socket from a custom program. <br />
Using a telnet client (such as [http://www.chiark.greenend.org.uk/~sgtatham/putty/ Putty] for Windows) it is possible to connect to a running FlightGear process and issue commands that FlightGear then runs internally.<br />
The telnet client can be running on the same machine as FlightGear itself, or on other machines that are in some way connected to the same network (LAN, WAN/internet).<br />
<br />
This can for example be used to read and set values within the [[Property Tree]] structure, but it can also be used for running [[fgcommands]]. <br />
A list of available fgcommands is available in <tt>[[$FG_ROOT]]/Docs/README.commands</tt>.<br />
<br />
This makes it possible to "remote control" FlightGear by using the telnet protocol. This can for example be used to change environment settings (weather, time, visibility etc). But you can also remotely fail equipment: Use the telnet/http interface to unset the "serviceable" flags on the affected instruments and systems. All you need to write is a little script (perl,python, netcat) to do the 25-to-1 multiplex/demultiplex operation.<br />
<br />
Many internals are exposed through the property tree, which is accesible in many ways. There is a http and a telnet interface ready for use. A powerful thing is the interface with a freely configurable protocol to send and receive properties. This interface can talk via tcp or udp.<br />
<br />
So you need some kind of gui to trigger the failures, a layer that translates this to flightgear properties and a communication layer that communicates <br />
with the flightgear instances. This is an independent application, so you can write it in c, c++, c#, java, php or whatever you like, but you might keep <br />
cross platform usability in mind.<br />
<br />
Probably not every aircraft developer has implented every failure feature in his aircraft, since most of them are happy if the "normal procedures" work. <br />
Also, some systems are implemented, some are not. So for most GA aircraft for example, the landing gear has no model for the hydraulic system but a <br />
simple "if you operate the gear lever, the gear is extending" functionality.<br />
<br />
But a telnet connection can also be used for inserting scenery objects or [[Interactive traffic|AI aircraft]] models dynamically. It is also possible to trigger arbitrary [[Nasal]] code by writing to a property with a registered Nasal listener. In fact, it is even possible to insert and run Nasal code via telnet, by writing the code to a property and call()'ing it then [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00150.html][http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00965.html].<br />
<br />
Information on nearby multiplayer entities is provided in the property tree so you can access this information at least within flightgear. You could<br />
query this data via the property interface, or build some sort of nasal script. <br />
<br />
Multiple connections are possible at the same time. For an example in Java please refer to [http://gitorious.org/fg/flightgear/blobs/next/scripts/java/FGClient/src/FGFSDemo.java $FG_SRC/scripts/FGClient].<br />
<br />
For shell scripting purposes, [http://netcat.sf.net netcat] also works well.<br />
<br />
The routines already support network byte order, however there are cases (i.e. interfacing to an external perl script using pack/unpack, where network byte order is not desirable).<br />
<br />
In comparison to the binary native protocol, the props/telnet protocol is a lower bandwidth, high reliablity channel. You are guaranteed that every message gets to the receiver once (and only once.) This is great for setting up weather conditions, time of day, camera parameters, and anything else that might have an impact on the visuals. We have a convenient "telnet" interface to all the internal properties and built in commands. Anything you can set from the keyboard, or mouse, or gui, you can do from a remote program or script. It's much lower bandwidth, but very convenient.<br />
<br />
The telnet mechanism is not designed to be high bandwidth. I believe it runs at 5hz? and only processes one line/command per iteration. You could try upping the frequency via the command line, "--props=socket,bi,20,,5500,tcp" (we could change PropsChannel::foundTerminator() to handle several<br />
commands per line. Commands could be separated with semicolons. Or perhaps some commands could take more than one argument, eg "get /foo/bar /foo/baz"). For higher bandwidth needs, it would work better to send over an FGNetFDM structure (src/Network/net_fdm.hxx) via UDP or some other custom structure.<br />
<br />
A look at the sources shows that a fixed polling interval is used for telnet - default is 5Hz. So it cannot process more than 5 commands per <br />
second. That's why it's slow. There's better methods of implementing socket communication instead of polling, but I haven't looked into the <br />
module and don't know why this was chosen. The polling interval is configurable though - so you can speed it up. Use:<br />
<pre><br />
fgfs ..... --telnet=medium,direction,HZ,localhost,PORT,style<br />
</pre><br />
<br />
Use HZ to select the polling frequency (e.g. "100") and PORT for the telnet port (e.g. 9999). The other parameters are unused (it seems) when <br />
using the telnet protocol. Probably there for historic reasons (?). Maybe Curt knows. Remember you have to specify 6 parameters separated by <br />
a "," - otherwise you cannot configure the polling frequency. So call <br />
something like:<br />
<pre><br />
fgfs ..... --telnet=foo,bar,100,foo,9999,bar<br />
</pre><br />
<br />
TCP sockets are easier to implement for almost all applications, precicely because they are reliable. UDP will only look easier if you plan on skipping the code to recover from a lost packet. Some applications can do this, but the property tree can't -- property access is non-idempotent in the general case. Listeners can have side effects.<br />
<br />
== Telnet Server ==<br />
FlightGear has a telnet server that can be used to read and set values of the [[Property Tree]]. The telnet server is activated with the '''--telnet=port''' [[Command Line Parameters|command line option]], where port is the number of the listening port that will be opened.<br />
<br />
A connection to the server can be done using a [[Telnet usage|telnet client]] or opening a simple socket from any program. Multiple connections (more below) are possible at the same time. Too start FG and open the port 5401 as available telnet server use this command:<br />
fgfs --telnet=5401<br />
Using this server protocol is covered in detail on the [[Telnet usage]] page.<br />
<br />
== Starting FlightGear with Telnet Server ==<br />
(Note if you want to use an SSH client like putty, you'll need to disable the SSH mode, FG does NOT support SSH, it only supports the raw telnet mode!)<br />
<br />
Now, start up FlightGear with the following option: --telnet=5401 (or pick your favorite port number) Once FlightGear is up and running, go to an xterm/shell on the same machine running flightgear and type "telnet localhost 5401". You could do this from any machine on the net by substituting the appropriate machine name/ip-address. From the telnet session hit enter or type "help" to get a list of available commands. You can now remotely navigate through the property structure and examine and change values in the live running copy of FlightGear. This is very powerful (although low bandwidth) and allows you to set and change a huge range of values in FlightGear.<br />
<br />
Even better, it's pretty easy to automate a remote telnet session so you can write scripts or code that can remotely control FlightGear in various ways. I've written a commercial operator GUI that interfaces to FlightGear in this way. I've scripted (perl) out all the FAA Level 3 FTD certification tests in this way (setting up initial conditions, reseting the FDM, enabling/adjusting autopilot modes, and even remotely manipulating control surfaces when needed.)<br />
<br />
And you can use the same mechanism to adjust view parameters, configure weather settings, time of day, etc.<br />
<br />
The only draw back is that it's low bandwidth. It's good for setting a few parameters at a relatively low rate, it's good for interactive use, it's good for many remote scripting tasks, but you don't want to use it to try to blast a bunch of position/orientation data in real time. We have other interfaces better suited for that.<br />
<br />
I should also point out that we have an html version of the telnet interface "--httpd=5400" that allows you to connect up to a live copy of FlightGear from any web browser and interact with the sim. Just type in a url like this: "http://localhost:5401/";<br />
<br />
== Connect with Telnet Client ==<br />
Once connected to the server using a telnet client, you will be given a prompt such as if you where connected to a unix telnet server, example:<br />
<pre><br />
francesco@francesco-desktop:~$ telnet 127.0.0.1 5401<br />
Trying 127.0.0.1...<br />
Connected to 127.0.0.1.<br />
Escape character is '^]'.<br />
</pre><br />
Where 127.0.0.1 is the ip address (127.0.0.1=localhost) of the running FlightGear server and 5401 is the local server port (incoming) set when FlightGear started.<br />
<br />
If you are connecting on a Windows machine, you may find that you have to specify the hostname of the PC explicitly. For example on a PC which the Windows network identifies as "albatross":<br />
<pre><br />
C:\>telnet albatross 5401<br />
</pre><br />
This may be necessary for both the Windows command line client as well as when using other clients like [http://www.chiark.greenend.org.uk/~sgtatham/putty/ Putty]. The first time you connect, Windows will prompt you to allow the connection.<br />
<br />
Now that you are inside a telnet session, you can start issuing commands (see below) to FlightGear. Generally commands are used to get, change and navigate the values of the [[Property Tree|property tree]], similar to navigating with directories and files.<br />
<br />
=== Prompt ===<br />
Since we are ''simulating navigation'' through a file system, you will be given a prompt which consists of two parts:<br />
# current tree position<br />
# (the characters '''>(space)''')<br />
<br />
so you will typically see something like the following:<br />
/><br />
/autopilot[0]><br />
/autopilot[0]/settings[0]><br />
<br />
== Commands ==<br />
The following command are available:<br />
* '''[[Telnet usage#cd|cd]]''' - change directory<br />
* '''[[Telnet usage#data|data]]''' - switch to data mode<br />
* '''[[Telnet usage#dump|dump]]''' - dump to xml<br />
* '''[[Telnet usage#get|get]]''' - show a property value<br />
* '''[[Telnet usage#help|help]]''' - show available commands<br />
* '''[[Telnet usage#ls|ls]]''' - list directories and paramaters<br />
* '''[[Telnet usage#prompt|prompt]]''' - switch to interactive mode<br />
* '''[[Telnet usage#pwd|pwd]]''' - display current path<br />
* '''[[Telnet usage#quit|quit]]''' - terminate connection<br />
* '''[[Telnet usage#run|run]]''' - run a built in command<br />
* '''[[Telnet usage#set|set]]''' - set value of property<br />
* '''[[Telnet usage#subscribe and unsubscribe|subscribe and unsubscribe]]''' - subscribing to property changes<br />
* '''?''' - shortcut to help<br />
<br />
=== cd ===<br />
Change the current working directory; it needs a parameter which is the destination directory. Example session.<br />
<br />
/> cd gear<br />
/gear[0]><br />
/gear[0]> cd launchbar<br />
/gear[0]/launchbar[0]> cd ..<br />
/gear[0]> cd ..<br />
/> cd gear/launchbar<br />
/gear[0]/launchbar[0]> cd /<br />
/><br />
<br />
=== data ===<br />
Switch to data mode. This removes the '''prompt/>'''. This is mostly useful when communicating from code, eg a socket. <br />
<br />
To switch back on see prompt below.<br />
<br />
=== dump ===<br />
dumps the current state in [[PropertyList XML File|PropertyList-encoded]] XML. This requires at least a directory argument. (Note that there are some known issues/restrictions [http://forum.flightgear.org/viewtopic.php?f=36&t=19489]).<br />
<br />
/> dump postion/<br />
-ERR "node 'postion/' not found"<br />
<br />
/> dump /position <br />
<?xml version="1.0"?><br />
<PropertyList><br />
<longitude-deg type="double">-122.3577761</longitude-deg><br />
<latitude-deg type="double">37.61378776</latitude-deg><br />
<altitude-ft type="double">28.25613943</altitude-ft><br />
<ground-elev-m type="double">-0.131186098</ground-elev-m><br />
<ground-elev-ft type="double">-0.4304005839</ground-elev-ft><br />
</PropertyList><br />
<br />
=== get ===<br />
Shows the value of a given parameter, for example, to get the magnetos status inside the controls/engines/engine directory:<br />
<br />
/> cd controls/engines/engine<br />
/controls[0]/engines[0]/engine[0]> get magnetos<br />
magnetos = '3' (int)<br />
/controls[0]/engines[0]/engine[0]> <br />
or from the root simply:<br />
/> get controls/engines/engine/magnetos<br />
controls/engines/engine/magnetos = '3' (int)<br />
/><br />
<br />
Usually, you'd use "polling" to continuously update a property via "get" - however, as of FG 2.8 there are two new commands supported, see [[Telnet usage#subscribe and unsubscribe]].<br />
<br />
=== help ===<br />
Show all the available commands, same as just '''?'''<br />
<br />
=== ls ===<br />
List all the directories and properties within and under the current directory, for example:<br />
<br />
/> cd orientation<br />
/orientation[0]> ls<br />
heading-deg = '70.62909768' (double)<br />
alpha-deg = '-176.8560635' (double)<br />
pitch-rate-degps = '3.347789774e-07' (double)<br />
/orientation[0]> <br />
or with a directory argument<br />
/> ls /orientation<br />
heading-deg = '104.6032849' (double)<br />
alpha-deg = '-176.864208' (double)<br />
pitch-rate-degps = '-0.003761442232' (double)<br />
/><br />
<br />
=== prompt ===<br />
Switch on interactive mode '''prompt/>'''. One by default. See data above to switch off.<br />
<br />
=== pwd ===<br />
Display the current directory ie print working directory<br />
<br />
=== quit ===<br />
Terminate the client connection to server.<br />
<br />
=== run ===<br />
Run a built in command, the command name is required as an argument.<br />
<br />
=== set ===<br />
Sets the value of a given property, for example, to set the aileron position inside the /controls/flight directory:<br />
<pre><br />
/> cd controls/flight<br />
/controls[0]/flight[0]> set aileron 0.2<br />
aileron = '0.2' (double)<br />
/controls[0]/flight[0]> <br />
</pre><br />
or simply:<br />
<pre><br />
/> set /controls/flight/aileron -0.1<br />
/controls/flight/aileron = '-0.1' (double)<br />
/> <br />
</pre><br />
<br />
=== subscribe and unsubscribe===<br />
You'll find two new telnet commands in FG >= 2.8 that provide a very simple "subscription" mechanism, so that you can register listeners instead of using polling to get property updates. <br />
Obviously, that makes only sense for non-FDM (non-tied) properties and properties that are not updated at frame rate. <br />
But otherwise it can save you some bandwidth and prevent unnecessary polling:<br />
<br />
Just connect to fgfs via telnet and issue a "help" command for details:<br />
<br />
* subscribe <property><br />
* unsubscribe <property><br />
<br />
For each changed property, the notification response will be in the form of:<br />
'''/some/property=value (terminator)'''<br />
<br />
For example, to subscribe to all properties under '''/local-weather''', use '''subscribe /local-weather'''. To subscribe to all properties under '''/canvas''', use '''subscribe /canvas'''.<br />
<br />
Also see: https://gitorious.org/fg/flightgear/merge_requests/28<br />
<br />
Note that it probably makes sense to use the raw (data) mode.<br />
If you still want to support older FG versions, you should probably check the version property first, or simply copy the output from running "help" and checking if it contains the "subscribe" string or not - so that you can fall back to polling instead.<br />
<br />
== Interfacing with other programs ==<br />
Using the telnet interface, your own custom client software can request the value of any variable at any time. You can also update the value of any other variable at any time. The overall bandwidth of the telnet interface is not very high though so it's not appropriate for blasting all the flight dynamics data at 60hz for instance, but for your application it probably will work very well ... and I can imagine ways to cheat that would make it look like it was working even better than it actually was. (For instance, you might get some delay if you turn the knob, send the data to FG, and then read the new frequency back from FG, but if you know locally how far your knob turned, you can update your local display immediately, and then sync up with FG at a slower rate.)<br />
<br />
The cool thing is that you can easily write scripts to access the --telnet=<port#> interface.<br />
<syntaxhighlight language="python"><br />
//* psuedo code<br />
conn = telnet.connect(127.0.0.1, 5480)<br />
gear_down = conn.get("/gear/state")<br />
if gear_down:<br />
conn.set("/gear/state", "up")<br />
</syntaxhighlight><br />
Look under src/scripts and you'll find example code showing you how to do it in Python, Perl and C. The Python/Java ones includes a FlightGear module that makes the telnet part pretty transparent.<br />
<br />
There are a couple examples in the scripts section of the FG source code. There is a chunk of perl (telnet.pl) you can include to make access from a perl script mostly trivial. I think there is a java example and perhaps something for python.<br />
<br />
You should have a look at fgfsclient.cxx in the FG/script/exmaple subtree (on the cvs). The script/python subtree has also good examples<br />
of what can be done using the telnet protocol. The server side of the "telnet" protocol can be found in the src/Network/props.* files.<br />
Also FG must be lauched with --props=5501 to activate the server side.<br />
Now you juste have to find the properties that you need and the property browser is handy for that.<br />
<br />
Some links to source code examples in various flavours:<br />
* Perl - [http://gitorious.org/fg/flightgear/trees/next/scripts/perl/examples /source/scripts/perl/examples].<br />
* Python - [http://gitorious.org/fg/flightgear/trees/next/scripts/python /source/scripts/python/]<br />
* Java - [http://gitorious.org/fg/flightgear/trees/next/scripts/java source/scripts/java/]<br />
<br />
You could just as easily interact with a running FlightGear instance using perl, C, C++, java, python, probably even <ack> visual basic or anything else that can do TCP/IP network communication ... matlab? netcat? twisted?<br />
<br />
Also note that the downside to the telnet interface is that you can't blast a lot of data across it. It's fine if you want to monitor location and speed every second or 1/4 second and occasionally set some values; such as dump in a new weather configuration, reset the aircraft location, or read a set of values, etc.<br />
<br />
If you need to track 100 different variables at 60hz, this isn't the interface for you.<br />
For that you should consider using a native protocol, implemented in C++ (e.g. FGNetCtrl via UDP).<br />
<br />
You could take a look at FlightGear/scripts/example/fgfsclient.c for one example to query the values of a property from FlightGear. It should (in theory) be possible to use the net_fdm and net_ctrls code (which can be found in FlightGear/src/Network) also<br />
<br />
== Use Case: Instructor Station ==<br />
I have just added the raw beginnings of a Java client library and trivially-simple Swing GUI demo under scripts/java/demo/FGClient/.<br />
Here's the Java code to connect to a FlightGear process and increase the current altitude by 1000 feet:<br />
<br />
<syntaxhighlight language="java"><br />
FGConnection fgfs = new FGConnection("localhost", 9000);<br />
double altitude = fgfs.getDouble("/position/altitude-ft");<br />
fgfs.setDouble("/position/altitude-ft", altitude + 1000);<br />
fgfs.close();<br />
</Syntaxhighlight><br />
<br />
The demo application displays the current altitude, longitude, and<br />
latitude in a small GUI window, and uses a separate thread to update<br />
the values every second. To use it, try these commands:<br />
<br />
<pre><br />
fgfs --telnet=9000<br />
java FGFSDemo localhost 9000<br />
</pre><br />
<br />
I might develop this into a remote instructor's panel, a full configuration GUI, a remote-control module for weather and other<br />
environment parameters, or any combination of these. Contributions are welcome, of course.<br />
<br />
<pre><br />
set /sim/presets/latitude-deg -9999.0<br />
set /sim/presets/longitude-deg -9999.0<br />
set /sim/presets/altitude-ft -9999<br />
<br />
set /sim/presets/airport-id KANE<br />
<br />
set /sim/presets/ndb-freq ""<br />
set /sim/presets/vor-id ""<br />
set /sim/presets/airspeed-kt ""<br />
set /sim/presets/offset-distance ""<br />
set /sim/presets/offset-azimuth ""<br />
set /sim/presets/glideslope-deg ""<br />
set /sim/presets/runway ""<br />
set /sim/presets/fix ""<br />
set /sim/presets/ndb-id ""<br />
set /sim/presets/heading-deg ""<br />
set /sim/presets/vor-freq ""<br />
<br />
run presets-commit<br />
</pre><br />
<br />
To start on a 5 mile final to runway KBUR, runway 08 at 90 kts (3<br />
degree glide slope) you could do something like:<br />
<br />
<pre><br />
set /sim/presets/longitude-ft -9999.0<br />
set /sim/presets/latitude-deg -9999.0<br />
set /sim/presets/altitude-ft -9999<br />
<br />
set /sim/presets/airport-id KBUR<br />
set /sim/presets/runway 08<br />
set /sim/presets/offset-distance 5<br />
set /sim/presets/glideslope-deg 3<br />
set /sim/presets/airspeed-kt 90<br />
<br />
set /sim/presets/ndb-freq ""<br />
set /sim/presets/vor-id ""<br />
set /sim/presets/offset-azimuth ""<br />
set /sim/presets/fix ""<br />
set /sim/presets/ndb-id ""<br />
set /sim/presets/heading-deg ""<br />
set /sim/presets/vor-freq ""<br />
<br />
run presets-commit<br />
</pre><br />
<br />
To start over some fix (DAVID for instance) :-) at an alitude of 5000', airspeed of 90 kts, and heading of 45 degrees:<br />
<br />
<pre><br />
<br />
set /sim/presets/latitude-deg -9999.0<br />
set /sim/presets/longitude-deg -9999.0<br />
<br />
set /sim/presets/altitude-ft 5000<br />
set /sim/presets/airspeed-kt 90<br />
set /sim/presets/fix DAVID<br />
set /sim/presets/heading-deg 45<br />
set /sim/presets/offset-distance 0<br />
<br />
set /sim/presets/airport-id ""<br />
set /sim/presets/ndb-freq ""<br />
set /sim/presets/vor-id ""<br />
set /sim/presets/offset-azimuth ""<br />
set /sim/presets/glideslope-deg ""<br />
set /sim/presets/runway ""<br />
set /sim/presets/ndb-id ""<br />
set /sim/presets/vor-freq ""<br />
<br />
run presets-commit<br />
<br />
</pre><br />
<br />
== Use Case: Autopilot & Route Manager ==<br />
The autopilotss (there are several different implementations) are part of the models. (Rationale is that autopilot devices normally are mounted *in* the<br />
aircrafts in the real world =). If you are developing your own stand-alone autopilot and want it on another host, there are several ways to interface<br />
to the simulator to control the aircraft remotely.<br />
<br />
Everything you need to read and set to control an aircraft is in the aircraft's property tree. (This is how the aircraft is controlled internally too) This property tree can be read and modified (if the property is not a read-only one) across the network.<br />
<br />
The simplest way to /set/ a property is perhaps via the telnet interface. fgfs --telnet=<port> then do "telnet <host> <port>" and type "help" to see<br />
the syntax. You can read properties aswell, that way, but perhaps you rather prefer to get data synchronously. This can be achieved through the<br />
general i/o-interface.<br />
<br />
Regarding the autopilot, I believe you have to set the target speed value and then activate that particular autopilot mode, so you need to actually set two values. You should be able to look in the autopilot gui to see the exact property names (I don't have them here off the top of my head.) And watch out for spelling: that's one thing I've learned to check when things don't work as expected. With properties, the compiler can't spell check variable names at compile time so typos can creep in. When something doesn't behave as expected, it's worth looking in the property tree while the code is running to see if any new properties (with similar, but not quite exact spellings) have appeared. <br />
<br />
At a lower level, the FlightGear waypoint system (route manager) can handle any arbitrary latitude and longitude and altitude. However, something that might work better for you (?) would be to just set up a basic autopilot that can hold a commanded heading, altitude, speed, etc. and then monitor the flight location from the remote search algorithm and pass heading updates to the autopilot.<br />
<br />
The autopilot target values are all stored in the property system, so it's really straightforward to change them from a remote application using the<br />
"telnet" interface. And likewise you could monitor aircraft location through the same interface.<br />
<br />
There are commands available for clearing the list, removing entries, etc.<br />
<br />
<pre><br />
@clear ... clear route<br />
@pop ... remove first entry<br />
@delete3 ... delete 4th entry<br />
@insert2:k...@900 ... insert "k...@900" as 3rd entry<br />
k...@900 ... append "k...@900"<br />
</pre><br />
For example '''set /autopilot/route-manager/input @clear'''<br />
<br />
This works also from the property browser, or via Nasal etc. The route manager dialog uses the same interface.<br />
<br />
Of course, you have to use an autopilot which takes the waypoints from the route manager if you want your aircraft flown through all the points. The default AP does this.<br />
<br />
Everything that you can do in the "Route-Manager" dialog can be done via any way to write to properties. The dialog itself does exactly that. There's a command property /autopilot/route-manager/input. You can send commands to add/insert/remove/pop waypoints from the list, which you can see in the dialog. Here's the syntax description from $FG_ROOT/gui/dialogs/route-mgr.xml and src/Autopilot/route_mgr.cxx:<br />
<br />
command interface /autopilot/route-manager/input:<br />
<pre><br />
@clear ... clear route<br />
@pop ... remove first entry<br />
@delete3 ... delete 4th entry<br />
@insert2:[EMAIL PROTECTED] ... insert "[EMAIL PROTECTED]" as 3rd entry<br />
[EMAIL PROTECTED] ... append "[EMAIL PROTECTED]"<br />
<br />
</pre><br />
<br />
<br />
== Use Case: Radio Stack ==<br />
For the easiest start, I'd use a single fg instance, with the telnet server enabled, and write a little (eg. perl) script that reads the parallel port where you have your switch connected, and changes a property via the telnet interface when the switch gets opened/closed. If you'd like to build a hardware radio stack and interface it to FG. There are a couple of ways you could attack this.<br />
<br />
* Add a module (i.e. some code) inside FG that runs every frame. Your code would read all your hardware switches through whatever mechanism you have devised and update the FG internals. It would also send things like frequencies (probably cooked up in the best flavor for your hardware) so that the radio stack can display the frequencies.<br />
<br />
* You could go for total separation and create an external application that talks directly to your hardware. That application could then communicate with FG via the "telnet" interface to read the necessary FG property values to update your hardware display, and write the switch/knob values back to FG as input to it's radio models.<br />
<br />
There are probably a variety of other ways you could get this done, but these two approaches are the ones that jump to the front of my list. The first approach would require a bit more digging into the FG internals, the 2nd approach could have potentially sluggish performance. The "telnet" interface is the ultimate in flexibility, but is not anywhere close to high bandwidth.<br />
<br />
== Links ==<br />
* httpd source - [http://gitorious.org/fg/flightgear/blobs/next/src/Network/httpd.cxx source/src/Network/httpd.cxx]<br />
* telnet (props) source - [http://gitorious.org/fg/flightgear/blobs/next/src/Network/props.cxx source/src/Network/props.cxx]<br />
<br />
<br />
[[Category:Interfacing protocols]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_June_2014&diff=73327FlightGear Newsletter June 20142014-06-26T21:13:26Z<p>Bigstones: /* Scenery corner */ MSFS -> FG conversion of LIPY</p>
<hr />
<div><br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
{{Newsletter being written}}<br />
<br />
== Development news ==<br />
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].<br />
<br />
=== FlightGear 3.2 - Feature Freeze ===<br />
<br />
{{FGCquote<br />
|Hi all,<br/><br />
<br/><br />
this is just a short reminder that yesterday, we entered our scheduled <br/><br />
feature freeze state for the next release.<br/><br />
<br/><br />
Please use the next four weeks to improve the existing features, harden <br/><br />
and cleanup the code, edit the ChangeLog <br/><br />
(http://wiki.flightgear.org/Next_Changelog), improve the Manual, <br/><br />
document the undocumented etc. etc.<br/><br />
<br/><br />
I'll create the release branches on July 17th to have the release ready <br/><br />
by Aug. 17th.<br/><br />
<br/><br />
Torsten<br/><br />
<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32475295/<br />
|title=<nowiki>[Flightgear-devel] Feature Freeze for 3.2</nowiki><br />
|author=<nowiki>Torsten Dreyer</nowiki><br />
|date=<nowiki>2014-06-18</nowiki><br />
}}<br />
}}<br />
=== Canvas GUI: MessageBox Support ===<br />
Thanks to Tom's and James' recent work on the upcoming [[Aircraft Center]] for downloading and switching between aircraft without having to exit FlightGear, beginning with FlightGear 3.2, FlightGear's [[Canvas]]-based GUI will contain support for so called [[Canvas MessageBox|Message Boxes]]:<br />
{|<br />
|- style="vertical-align:top;"<br />
| [[File:Canvas-MessageBox-demo information.png|link=]] ||<br />
<syntaxhighlight lang="nasal"><br />
canvas.MessageBox.info("Success", "The operation has successfully completed.");<br />
</syntaxhighlight><br />
|- style="vertical-align:top;"<br />
| [[File:Canvas-MessageBox-demo question.png|link=]] ||<br />
<syntaxhighlight lang="nasal"><br />
canvas.MessageBox.question(<br />
"Do you want it?",<br />
"The question is: Do you want to get a real question?.",<br />
func(sel)<br />
{<br />
if( sel == canvas.MessageBox.Yes )<br />
print("I only know that the answer is 42.");<br />
else<br />
print("Ok, I will not give you a real question.");<br />
}<br />
);<br />
</syntaxhighlight><br />
|- style="vertical-align:top;"<br />
| [[File:Canvas-MessageBox-demo warning dont-show-again.png|link=]] ||<br />
<syntaxhighlight lang="nasal"><br />
canvas.MessageBox.warning(<br />
"Warning...",<br />
"Have you read this warning? If you want it will not be shown again.",<br />
func(sel)<br />
{<br />
if( sel != canvas.MessageBox.Ok )<br />
return;<br />
<br />
print("You have been warned. Let the games begin...");<br />
},<br />
canvas.MessageBox.Ok<br />
| canvas.MessageBox.Cancel<br />
| canvas.MessageBox.DontShowAgain<br />
);<br />
</syntaxhighlight><br />
|}<br />
<br />
=== Logo Proposal ===<br />
This is the new logo badge concept proposal for FlightGear designed by Michat.<br />
<br />
[[File:Fglogo1.png]]<br />
[[File:Fglogowiki.png]]<br />
[[File:Fglogoforum.png]]<br />
<br />
===MapStructure stress-testing ===<br />
<br />
[[File:Map-canvas-mapstructure-performance.png|thumb|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611] ]]<br />
<br />
{{cquote<br />
|<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki><br/><nowiki><br />
Here, I am using the ufo @ksfo circling in a shuttle climb at >= 2000 kts GS and getting roughly 30 fps and 40-60 ms.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611<br />
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Tue Jun 03</nowiki><br />
}}<br />
}}<br />
<br />
=== 777 EFB Prototype by I-NEMO ===<br />
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]<br />
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]<br />
<br />
I-NEMO has started porting his 777/EFB prototype to [[Canvas]]<br />
<br />
{{cquote<br />
|<nowiki>As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) to do something to compensate for the lacking of an EFB inside the Seattle.</nowiki><br/><nowiki><br />
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550<br />
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Mon Jun 02</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki> this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. </nowiki><br/><nowiki><br />
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550<br />
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Mon Jun 02</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550<br />
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Mon Jun 02</nowiki><br />
}}<br />
}}<br />
<br />
<br />
{{FGCquote<br />
|Current development ('modernisation' phase) of the '''Boeing 777 Seattle's EFB''' is going on nicely; the code is shorter, more readable and cleaner.<br/><br />
I have not finished it, yet (I'd say that it's almost 50% done).<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213104#p213104<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|At the moment I have a single Canvas group (i.e., ''EFB_group''), with 5 children: the text-matrix (16 left lines, 16 right lines), a Title line , an Helper line and the Display.<br/><br />
The ''Display'' element is then textured with all the various pages' textures, called by the page-handler (''see'' here below).<br/><br />
Currently, I'm using the .jpg textures which I had previously generated through Photoshop; in the future they might be replaced by .svg files, depending from actual interactive use of some graphical objects (a few EFB pages do need interaction with graphical parts). Besides - if i'm not wrong - I've read somewhere on the FGWiki that gradients are not handled by the SVG parser...and I do like to use some gradients effects (antialiasing and such) to achieve a sort of realism on the displays.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213104#p213104<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|that's the <u>current status</u> of the new 777 ''Seattle'''s EFB: it's still far from being perfect, but - as a newbie - I'm quite satisfied for the moment: I need to finish the first version fairly soon, because my to-do-list is long (I have to re-model all the aircraft fuselage [original model has wrong measures, ''sigh!''], produce better gears and flight-control surfaces model &amp; animations in Blender, and then to produce a new Paint-Kit in Photoshop; then all 3D models optimizations...and so forth; of course, we also have to take care of CDU, which will interface with the EFB. So, the job is still very, very long...<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213104#p213104<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|The current EFB code is heavily focused on rendering raster images, which can be retained obviously, but in FG, we have additional means to render airport information that is 100% in sync with the FG side of things (navdb). <br/><br />
<br/><br />
For instance, we are going to "port" the airport-selection dialog to move rendering of airports/runways/taxiways/parking spots into dedicated MapStructure layers that can be properly styled and customized: [[Canvas_MapStructure#Porting_the_airports.xml_dialog]] <br/><br />
<br/><br />
[[File:Airport-selection-dialog.png|250px]]<br/><br />
<br/><br />
As you can probably tell, these kinds of layers would be very useful for any kind of EFB related application.<br/><br />
<br/><br />
As long as the underlying design for a "page"-based MFD framework is sufficiently generic, we can easily replace/augment raster images and procedurally created charts - we could even use the built-in support for fetching via HTTP to download images on-line. In fact, we could then even extend Canvas to directly support rendering PDFs (OSG supports this out-of-the-box), this would make many steps unnecessary, because we could directly access [http://airnav.com http://airnav.com] without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213084#p213084<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
<br />
Learn more at [[Canvas EFB Framework]] ...<br />
<br />
=== Canvas Garmin GPSMap196 Updates ===<br />
<br />
[[File:Gpsmap196-canvas-panel-page.png|thumb|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]]]<br />
<br />
<br />
=== Avidyne Entegra R9 ===<br />
<br />
[[File:Extra500canvas.png|thumb|Work has begun to analyze, refactor and generalize useful parts of the [[Avidyne Entegra R9]] to help reuse some code in similar MFD efforts, like the [[Garmin GPSMap 196]] or [[Canvas EFB Framework]]]]<br />
<br />
=== Towards an Aircraft-agnostic MFD Framework ===<br />
<br />
[[File:Canvas-mfd-framework-prototyping.png|thumb|This is an adapted version of the [[Garmin GPSMap 196]] that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]].]]<br />
<br />
<br />
<br />
[[File:Canvas-mfd-framework-prototyping-with-mapstructure.png|400px|thumb|This demonstrates how a purely XML-based MFD framework can instantiate dynamic [[MapStructure]] layers - none of this involves any [[Nasal]] coding now, it's just an XML file - to learn more, see [[Canvas Glass Cockpit Efforts]].]]<br />
<br />
[[File:Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|400px|thumb|This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.]]<br />
<br />
=== Canvas System ===<br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>[[File:Map-canvas-chain-home-editor.png|250px]]<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>[[File:MapStructure-TFC-Troubleshooting.png|250px]]<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>[[File:Map-canvas-dialog-storms-overlay.png|250px]]<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure article.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
[[File:Aircraft-center-prototype.png|500px|thumb|Canvas dialog showing the prototype for an [[Aircraft Center]] for directly installing/managing aircraft from within FlightGear, an upcoming feature scheduled for FlightGear 3.2, currently being developed by TheTom and Zakalawe]]<br />
<br />
=== Missions & Adventures ===<br />
[[File:Missionb.png|thumb]]<br />
<br />
{{forum|79|Tutorials, Missions & Adventures}}<br />
<br />
<br />
=== High Level Architecture ===<br />
<br />
=== Usability Improvements ===<br />
<br />
== Release ChangeLog ==<br />
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
=== Damage and disintegration ===<br />
{{#ev:youtube|OpwNaoO3xMQ|240|right|Tomaskom's V-1 used in anger over London}}<br />
{{#ev:youtube|H4XDuLo35ks|240|right|Victor V2.0 damage script causing a catastrophic failure and fire}}<br />
{{#ev:youtube|uLojBI7ezdM|240|right|L-159 disintegration}}<br />
The development team at FGUK have been experimenting with modelling aircraft damage in a number of different ways. First of all, Tomaskom has used the particle system carefully to produce visually impressive fireballs and smoke columns with very little FPS impact. First seen in his V-1, we hope to adapt this to simulate realistic fireballs for ground impacts (where appropriate). For the moment, it explodes with the full force of a V-1's explosive payload. On the right is a video excerpt from the #FlightNight which Tom organised to debut the V-1, where we all had '''way''' too much fun bombing London. As you can see, the smoke is visible from quite a long way away from the impact, and despite two fires burning with huge smoke columns, and over ten multiplayer aircraft within model range, the frame rates are still more than acceptable. StuartC has already integrated the explosion and fireball into several development aircraft, and we expect eventually to combine it with the disintegration code and make the size of the explosion dependent on fuel load etc.<br />
<br />
In a separate development, Algernon's work on the Victor V2.0(YASim) now includes modelled damage, a collection of Nasal scripts, some modified from existing FlightGear staples, which detects irregularities such as component failures, birdstrikes and combat weapon damage and adversely affects system performance and reliability accordingly. Unserviceability often follows, using the existing FlightGear failures system, and compatibility will be maintained as the failures system is improved. The damage script also calculates probabilites for chain reaction damage - for instance, an explosion or serious fire in one Victor engine will usually have an effect on the other. In extreme circumstances, an explosion will trigger further explosions and destroy the aircraft. The second video on the right shows a serious induced explosion on the Victor's number one engine at night. Some fine-tuning of the Rembrandt light has been carried out since this video was shot, so apologies for the visible cut-off.<br />
<br />
Finally, and most spectacularly, Tomaskom has demonstrated the disintegration capabilities of his L-159, which is under development. Hopefully, he will explain all here before publication date.<br />
<br />
=== Scenesetter ===<br />
Scenesetter is a piece of code by Algernon, very early in development but already quite effective, which can effect changes to the time and weather from an AI scenario synchronously with other MP players. A crude proof of concept was used in the recent FGUK #FlightNight "British Weather", where pilots visited different airfields with various unpleasant flying conditions. Scenesetter pushes METAR strings to the FlightGear weather system based on the location of an associated Navaid, establishing a circular zone of a specified radius around it in which METAR will be changed. Start time can be specified too, either by providing a local start time or a local time offset (useful for Multiplayer use where players will not all start the AI scenario at precisely the same time).<br />
<br />
== In the hangar ==<br />
<br />
=== New aircraft ===<br />
<br />
=== Updated aircraft ===<br />
<br />
=== Saab JA-37 Viggen ===<br />
The Swedish fighter jet [[Saab JA-37 Viggen]] has been updated, since it was included in FlightGear 3.0. More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. HUD can now switch to imperial units and show MP and AI aircraft and closest airport. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.<br />
<br />
[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]<br />
<br />
==== Updated P-51D now in git ====<br />
The new 3D exterior model for the [[North American P-51D Mustang|North American P-51D Mustang]] is now in git and under active development. It is currently in gray primer waiting for the UV map to be finalized. It is now fully integrated into the existing FDM. Extensive new animation work has been done including animated trim tabs and a fully functional canopy. Here are some screen shots taken in sim for your enjoyment.<br />
<br />
<gallery mode=packed widths="250px" heights="250px"><br />
P-51D testing it's guns before a flight..jpg|P-51D testing it's guns before a flight.<br />
P-51D trim tab animation..jpg|P-51D trim tab animation.<br />
</gallery><br />
<br />
==== Balancing the Boeing 747-400 ====<br />
After he started developing the [[Boeing 747-400]] as a hobby project six years ago, Gijs finally managed to get the weight and balancing right. The center of gravity is now within 0.05% MAC (40 cm) of the published values.<br />
<br />
Make sure to use the new Fuel and Payload dialog to fill your fuel tanks. There is a slider and button that will nicely distribute a specified amount of fuel, while making sure the CoG stays within the operational limits. Before takeoff, check the Takeoff Reference page on the CDU to find the required stab trim units (your current setting is displayed to the left of the throttle quadrant). When you set your trim properly, you can almost relax your yoke to the neutral position after rotate. There's still some FDM work left to fine-tune this.<br />
<br />
The updated 747-400 is already available through Git and will be on the download page when FlightGear 3.2 is released.<br />
<br />
<br />
[[File:Extra500 flightgear1.png|thumb|200px|Extra500 flying in clouds]]<br />
==== Extra500 is updated to Production Status ====<br />
<br />
The Extra500 is updated and has reached "production status"! Just a short list of changes for release 1.1.0:<br />
* Interactive checklists<br />
* Interior model<br />
* Improved Moving Map etc.<br />
A more extensive list can be found in the "version" file.<br />
<br />
{{FGCquote<br />
|Here it is, the latest official version of the Extra500: release 1.1.0!<br/><br />
<br/><br />
The Model now has reached "production" status and a small list of changes you can find below:<br/><br />
* Engine+fuel: realistic flame-out, fuel flow to collector compartment, anti ice influence on TOT, improved oil press and temp model<br/><br />
* Aerodynamics: flap performance, elevator-30deg-flaps authority improvement<br/><br />
* User interface: interactive checklists<br/><br />
* Sounds: corrected sounds for test, CWS and AP disc<br/><br />
* Model: added interior, yokes<br/><br />
* Avionics: IFD moving map, automatic NAV tuning, automatic NAV switching, magnetic variation fixes<br/><br />
* Autopilot: added OBS and fly vectors mode, significant improvement of coupled ILS performance<br />
<br/><br />
This version does perform a bit better on my computer, but this has to do with improvements to FGFS, not of the aircraft model. So if your computer was struggling with the initial version, we recommend to use current FGFS git/nightly builds or wait until 3.2 comes out!<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213132#p213132<br />
|title=<nowiki>Re: New Aircraft: the Extra500</nowiki><br />
|author=<nowiki>D-EKEW</nowiki><br />
|date=<nowiki>Sun Jun 22</nowiki><br />
}}<br />
}}<br />
<br />
Please checkout the [[Extra EA-500|Extra500 wiki]] for download instructions and lots of more info.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
There is a project to add all the USA state capital buildings into FG. It is discussed in [http://forum.flightgear.org/viewtopic.php?f=5&t=22715&sid=ea847909bde2e1f8ffe5b94bcc673f4f this scenery forum thread]. There is also a wiki page: [[State Capitol Buildings in the United States]]. So far, Idaho, Louisiana & Nebraska have been completed. Hawaii and New York are currently in progress. Please feel free to join in with any other state that has not been done yet. Just let us know through the forum and we will add it to the in progress list.<br />
<br />
=== Airports ===<br />
==== LIPY, a scenery conversion from MSFS ====<br />
This month saw the [http://forum.flightgear.org/viewtopic.php?f=5&t=22623 second "preview" release] of the conversion of a scenery for MS Flight Simulator, [[Falconara Airport]] (ICAO code: LIPY), a small Italian international airport halfway down the Adriatic coast. The original author granted the permission to the conversion and even allowed for it to be included in the FlightGear official [[World Scenery]], at least the GPL compatible parts. This is not a huge limitation though, because most of the material was created from scratch, included pictures taken on purpose at the real airport, with the authorities' collaboration. Copyrighted aerial imagery only include the (unsuable) photoreal ground and some roofs.<br />
<br />
[[File:LIPY structures landscape.jpg|650px|right]]<br />
The conversion was made with [[ModelConverterX]], which makes the job partially easier than by [[Howto:Convert objects from X-Plane|the Blender method]], yet it's still needing fixes because of some misunderstandings with the coordinates axes. The author of the tool, though, seems not very concerned and anyway, it's so rare to have a freeware scenery author allow conversions, that the usefulness of this tool would be greatly reduced anyhow, especially if you plan to upload the models to the [[FlightGear Scenery Database]].<br />
<br />
The conversion itself, moreover, sure is not the matter of a button press. MSFS scenery are often packed and "compiled" in *.BGL files such that independent, far objects with the same materials and same LOD level (Level Of Detail) are bound together. This is clearly against FG's way, in which each new scenery generation could change the relative heights, and however MSFS airports are flat, while in FG they're all sloped. A similar thing happens with the texture maps. This basically means that you'll have to join all these objects and split them again based on the model they belong to (e.g. tower, terminal, hangars...)<br />
<br />
Another issue with textures is that in FG it's good practice - recommended if not mandatory - to have 2 separate texture maps for the same object, if some parts are translucent. This means that without rebuilding all the texture maps [http://forum.flightgear.org/viewtopic.php?f=5&t=22707 you'll likely get artifacts]. Then, you'd have to add the Rembrandt lights if you want, and also the lightmaps (MSFS uses night textures, but Gimp can easily convert them). This whole experience can be summed up in the following quote:<br />
<br />
{{cquote|I really wanted to have this scenery in FG because it's my home base, and seeing it ready and so well done just made me want it. However, even if still easier than making it from scratch (even if reusing the textures), I'd have to think well if I had to do this again.|bigstones, maintainer of the conversion}}<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
=== An updated Weather article ===<br />
The [[Weather]] wiki article went through a wide extension. Although Advanced Weather was released quite a while ago, its usage has never been explained in the wiki, and some thorough instructions were available only in a readme in the "docs" folder of the base package which is not commonly explored by users, while the wiki article [[Advanced weather]] is more about the project than the usage.<br />
<br />
AW's advanced configuration is known to be not easy. So, if you always only used the weather selection menu and want to know more, or want to understand what the options actually do and how you can combine them, the [[Weather]] article has now been updated with some hints and basic notions extracted from experience and the original documentation, and quality checked by the author of the AW weather engine.<br />
<br />
=== Translators required ===<br />
{|<br />
|[[File:en.gif]]<br />
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].<br />
|-<br />
|[[File:de.gif]]<br />
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
|[[File:nl.gif]]<br />
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
|[[File:es.gif]]<br />
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|}<br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
<br />
=== Call for volunteers ===<br />
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].<br />
<br />
=== Did you know ===<br />
<br />
[[Category:FlightGear Newsletter]]<br />
<!-- this needs to be changed after each release, so that newsletters show up in the proper category --><br />
<br />
[[Category:Changes after 3.00]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_June_2014&diff=73324FlightGear Newsletter June 20142014-06-26T20:15:49Z<p>Bigstones: /* Wiki updates */ the update to the Weather page. (is this the kind of news that should go here?)</p>
<hr />
<div><br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
{{Newsletter being written}}<br />
<br />
== Development news ==<br />
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].<br />
<br />
=== FlightGear 3.2 - Feature Freeze ===<br />
<br />
{{FGCquote<br />
|Hi all,<br/><br />
<br/><br />
this is just a short reminder that yesterday, we entered our scheduled <br/><br />
feature freeze state for the next release.<br/><br />
<br/><br />
Please use the next four weeks to improve the existing features, harden <br/><br />
and cleanup the code, edit the ChangeLog <br/><br />
(http://wiki.flightgear.org/Next_Changelog), improve the Manual, <br/><br />
document the undocumented etc. etc.<br/><br />
<br/><br />
I'll create the release branches on July 17th to have the release ready <br/><br />
by Aug. 17th.<br/><br />
<br/><br />
Torsten<br/><br />
<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32475295/<br />
|title=<nowiki>[Flightgear-devel] Feature Freeze for 3.2</nowiki><br />
|author=<nowiki>Torsten Dreyer</nowiki><br />
|date=<nowiki>2014-06-18</nowiki><br />
}}<br />
}}<br />
=== Canvas GUI: MessageBox Support ===<br />
Thanks to Tom's and James' recent work on the upcoming [[Aircraft Center]] for downloading and switching between aircraft without having to exit FlightGear, beginning with FlightGear 3.2, FlightGear's [[Canvas]]-based GUI will contain support for so called [[Canvas MessageBox|Message Boxes]]:<br />
{|<br />
|- style="vertical-align:top;"<br />
| [[File:Canvas-MessageBox-demo information.png|link=]] ||<br />
<syntaxhighlight lang="nasal"><br />
canvas.MessageBox.info("Success", "The operation has successfully completed.");<br />
</syntaxhighlight><br />
|- style="vertical-align:top;"<br />
| [[File:Canvas-MessageBox-demo question.png|link=]] ||<br />
<syntaxhighlight lang="nasal"><br />
canvas.MessageBox.question(<br />
"Do you want it?",<br />
"The question is: Do you want to get a real question?.",<br />
func(sel)<br />
{<br />
if( sel == canvas.MessageBox.Yes )<br />
print("I only know that the answer is 42.");<br />
else<br />
print("Ok, I will not give you a real question.");<br />
}<br />
);<br />
</syntaxhighlight><br />
|- style="vertical-align:top;"<br />
| [[File:Canvas-MessageBox-demo warning dont-show-again.png|link=]] ||<br />
<syntaxhighlight lang="nasal"><br />
canvas.MessageBox.warning(<br />
"Warning...",<br />
"Have you read this warning? If you want it will not be shown again.",<br />
func(sel)<br />
{<br />
if( sel != canvas.MessageBox.Ok )<br />
return;<br />
<br />
print("You have been warned. Let the games begin...");<br />
},<br />
canvas.MessageBox.Ok<br />
| canvas.MessageBox.Cancel<br />
| canvas.MessageBox.DontShowAgain<br />
);<br />
</syntaxhighlight><br />
|}<br />
<br />
=== Logo Proposal ===<br />
This is the new logo badge concept proposal for FlightGear designed by Michat.<br />
<br />
[[File:Fglogo1.png]]<br />
[[File:Fglogowiki.png]]<br />
[[File:Fglogoforum.png]]<br />
<br />
===MapStructure stress-testing ===<br />
<br />
[[File:Map-canvas-mapstructure-performance.png|thumb|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611] ]]<br />
<br />
{{cquote<br />
|<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki><br/><nowiki><br />
Here, I am using the ufo @ksfo circling in a shuttle climb at >= 2000 kts GS and getting roughly 30 fps and 40-60 ms.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611<br />
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Tue Jun 03</nowiki><br />
}}<br />
}}<br />
<br />
=== 777 EFB Prototype by I-NEMO ===<br />
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]<br />
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]<br />
<br />
I-NEMO has started porting his 777/EFB prototype to [[Canvas]]<br />
<br />
{{cquote<br />
|<nowiki>As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) to do something to compensate for the lacking of an EFB inside the Seattle.</nowiki><br/><nowiki><br />
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550<br />
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Mon Jun 02</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki> this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. </nowiki><br/><nowiki><br />
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550<br />
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Mon Jun 02</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550<br />
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Mon Jun 02</nowiki><br />
}}<br />
}}<br />
<br />
<br />
{{FGCquote<br />
|Current development ('modernisation' phase) of the '''Boeing 777 Seattle's EFB''' is going on nicely; the code is shorter, more readable and cleaner.<br/><br />
I have not finished it, yet (I'd say that it's almost 50% done).<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213104#p213104<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|At the moment I have a single Canvas group (i.e., ''EFB_group''), with 5 children: the text-matrix (16 left lines, 16 right lines), a Title line , an Helper line and the Display.<br/><br />
The ''Display'' element is then textured with all the various pages' textures, called by the page-handler (''see'' here below).<br/><br />
Currently, I'm using the .jpg textures which I had previously generated through Photoshop; in the future they might be replaced by .svg files, depending from actual interactive use of some graphical objects (a few EFB pages do need interaction with graphical parts). Besides - if i'm not wrong - I've read somewhere on the FGWiki that gradients are not handled by the SVG parser...and I do like to use some gradients effects (antialiasing and such) to achieve a sort of realism on the displays.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213104#p213104<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|that's the <u>current status</u> of the new 777 ''Seattle'''s EFB: it's still far from being perfect, but - as a newbie - I'm quite satisfied for the moment: I need to finish the first version fairly soon, because my to-do-list is long (I have to re-model all the aircraft fuselage [original model has wrong measures, ''sigh!''], produce better gears and flight-control surfaces model &amp; animations in Blender, and then to produce a new Paint-Kit in Photoshop; then all 3D models optimizations...and so forth; of course, we also have to take care of CDU, which will interface with the EFB. So, the job is still very, very long...<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213104#p213104<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>I-NEMO</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|The current EFB code is heavily focused on rendering raster images, which can be retained obviously, but in FG, we have additional means to render airport information that is 100% in sync with the FG side of things (navdb). <br/><br />
<br/><br />
For instance, we are going to "port" the airport-selection dialog to move rendering of airports/runways/taxiways/parking spots into dedicated MapStructure layers that can be properly styled and customized: [[Canvas_MapStructure#Porting_the_airports.xml_dialog]] <br/><br />
<br/><br />
[[File:Airport-selection-dialog.png|250px]]<br/><br />
<br/><br />
As you can probably tell, these kinds of layers would be very useful for any kind of EFB related application.<br/><br />
<br/><br />
As long as the underlying design for a "page"-based MFD framework is sufficiently generic, we can easily replace/augment raster images and procedurally created charts - we could even use the built-in support for fetching via HTTP to download images on-line. In fact, we could then even extend Canvas to directly support rendering PDFs (OSG supports this out-of-the-box), this would make many steps unnecessary, because we could directly access [http://airnav.com http://airnav.com] without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213084#p213084<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
<br />
Learn more at [[Canvas EFB Framework]] ...<br />
<br />
=== Canvas Garmin GPSMap196 Updates ===<br />
<br />
[[File:Gpsmap196-canvas-panel-page.png|thumb|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]]]<br />
<br />
<br />
=== Avidyne Entegra R9 ===<br />
<br />
[[File:Extra500canvas.png|thumb|Work has begun to analyze, refactor and generalize useful parts of the [[Avidyne Entegra R9]] to help reuse some code in similar MFD efforts, like the [[Garmin GPSMap 196]] or [[Canvas EFB Framework]]]]<br />
<br />
=== Towards an Aircraft-agnostic MFD Framework ===<br />
<br />
[[File:Canvas-mfd-framework-prototyping.png|thumb|This is an adapted version of the [[Garmin GPSMap 196]] that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]].]]<br />
<br />
<br />
<br />
[[File:Canvas-mfd-framework-prototyping-with-mapstructure.png|400px|thumb|This demonstrates how a purely XML-based MFD framework can instantiate dynamic [[MapStructure]] layers - none of this involves any [[Nasal]] coding now, it's just an XML file - to learn more, see [[Canvas Glass Cockpit Efforts]].]]<br />
<br />
[[File:Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|400px|thumb|This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.]]<br />
<br />
=== Canvas System ===<br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>[[File:Map-canvas-chain-home-editor.png|250px]]<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>[[File:MapStructure-TFC-Troubleshooting.png|250px]]<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>[[File:Map-canvas-dialog-storms-overlay.png|250px]]<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure article.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
[[File:Aircraft-center-prototype.png|500px|thumb|Canvas dialog showing the prototype for an [[Aircraft Center]] for directly installing/managing aircraft from within FlightGear, an upcoming feature scheduled for FlightGear 3.2, currently being developed by TheTom and Zakalawe]]<br />
<br />
=== Missions & Adventures ===<br />
[[File:Missionb.png|thumb]]<br />
<br />
{{forum|79|Tutorials, Missions & Adventures}}<br />
<br />
<br />
=== High Level Architecture ===<br />
<br />
=== Usability Improvements ===<br />
<br />
== Release ChangeLog ==<br />
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
=== Damage and disintegration ===<br />
{{#ev:youtube|OpwNaoO3xMQ|240|right|Tomaskom's V-1 used in anger over London}}<br />
{{#ev:youtube|H4XDuLo35ks|240|right|Victor V2.0 damage script causing a catastrophic failure and fire}}<br />
{{#ev:youtube|uLojBI7ezdM|240|right|L-159 disintegration}}<br />
The development team at FGUK have been experimenting with modelling aircraft damage in a number of different ways. First of all, Tomaskom has used the particle system carefully to produce visually impressive fireballs and smoke columns with very little FPS impact. First seen in his V-1, we hope to adapt this to simulate realistic fireballs for ground impacts (where appropriate). For the moment, it explodes with the full force of a V-1's explosive payload. On the right is a video excerpt from the #FlightNight which Tom organised to debut the V-1, where we all had '''way''' too much fun bombing London. As you can see, the smoke is visible from quite a long way away from the impact, and despite two fires burning with huge smoke columns, and over ten multiplayer aircraft within model range, the frame rates are still more than acceptable. StuartC has already integrated the explosion and fireball into several development aircraft, and we expect eventually to combine it with the disintegration code and make the size of the explosion dependent on fuel load etc.<br />
<br />
In a separate development, Algernon's work on the Victor V2.0(YASim) now includes modelled damage, a collection of Nasal scripts, some modified from existing FlightGear staples, which detects irregularities such as component failures, birdstrikes and combat weapon damage and adversely affects system performance and reliability accordingly. Unserviceability often follows, using the existing FlightGear failures system, and compatibility will be maintained as the failures system is improved. The damage script also calculates probabilites for chain reaction damage - for instance, an explosion or serious fire in one Victor engine will usually have an effect on the other. In extreme circumstances, an explosion will trigger further explosions and destroy the aircraft. The second video on the right shows a serious induced explosion on the Victor's number one engine at night. Some fine-tuning of the Rembrandt light has been carried out since this video was shot, so apologies for the visible cut-off.<br />
<br />
Finally, and most spectacularly, Tomaskom has demonstrated the disintegration capabilities of his L-159, which is under development. Hopefully, he will explain all here before publication date.<br />
<br />
=== Scenesetter ===<br />
Scenesetter is a piece of code by Algernon, very early in development but already quite effective, which can effect changes to the time and weather from an AI scenario synchronously with other MP players. A crude proof of concept was used in the recent FGUK #FlightNight "British Weather", where pilots visited different airfields with various unpleasant flying conditions. Scenesetter pushes METAR strings to the FlightGear weather system based on the location of an associated Navaid, establishing a circular zone of a specified radius around it in which METAR will be changed. Start time can be specified too, either by providing a local start time or a local time offset (useful for Multiplayer use where players will not all start the AI scenario at precisely the same time).<br />
<br />
== In the hangar ==<br />
<br />
=== New aircraft ===<br />
<br />
=== Updated aircraft ===<br />
<br />
=== Saab JA-37 Viggen ===<br />
The Swedish fighter jet [[Saab JA-37 Viggen]] has been updated, since it was included in FlightGear 3.0. More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. HUD can now switch to imperial units and show MP and AI aircraft and closest airport. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.<br />
<br />
[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]<br />
<br />
==== Updated P-51D now in git ====<br />
The new 3D exterior model for the [[North American P-51D Mustang|North American P-51D Mustang]] is now in git and under active development. It is currently in gray primer waiting for the UV map to be finalized. It is now fully integrated into the existing FDM. Extensive new animation work has been done including animated trim tabs and a fully functional canopy. Here are some screen shots taken in sim for your enjoyment.<br />
<br />
<gallery mode=packed widths="250px" heights="250px"><br />
P-51D testing it's guns before a flight..jpg|P-51D testing it's guns before a flight.<br />
P-51D trim tab animation..jpg|P-51D trim tab animation.<br />
</gallery><br />
<br />
==== Balancing the Boeing 747-400 ====<br />
After he started developing the [[Boeing 747-400]] as a hobby project six years ago, Gijs finally managed to get the weight and balancing right. The center of gravity is now within 0.05% MAC (40 cm) of the published values.<br />
<br />
Make sure to use the new Fuel and Payload dialog to fill your fuel tanks. There is a slider and button that will nicely distribute a specified amount of fuel, while making sure the CoG stays within the operational limits. Before takeoff, check the Takeoff Reference page on the CDU to find the required stab trim units (your current setting is displayed to the left of the throttle quadrant). When you set your trim properly, you can almost relax your yoke to the neutral position after rotate. There's still some FDM work left to fine-tune this.<br />
<br />
The updated 747-400 is already available through Git and will be on the download page when FlightGear 3.2 is released.<br />
<br />
<br />
[[File:Extra500 flightgear1.png|thumb|200px|Extra500 flying in clouds]]<br />
==== Extra500 is updated to Production Status ====<br />
<br />
The Extra500 is updated and has reached "production status"! Just a short list of changes for release 1.1.0:<br />
* Interactive checklists<br />
* Interior model<br />
* Improved Moving Map etc.<br />
A more extensive list can be found in the "version" file.<br />
<br />
{{FGCquote<br />
|Here it is, the latest official version of the Extra500: release 1.1.0!<br/><br />
<br/><br />
The Model now has reached "production" status and a small list of changes you can find below:<br/><br />
* Engine+fuel: realistic flame-out, fuel flow to collector compartment, anti ice influence on TOT, improved oil press and temp model<br/><br />
* Aerodynamics: flap performance, elevator-30deg-flaps authority improvement<br/><br />
* User interface: interactive checklists<br/><br />
* Sounds: corrected sounds for test, CWS and AP disc<br/><br />
* Model: added interior, yokes<br/><br />
* Avionics: IFD moving map, automatic NAV tuning, automatic NAV switching, magnetic variation fixes<br/><br />
* Autopilot: added OBS and fly vectors mode, significant improvement of coupled ILS performance<br />
<br/><br />
This version does perform a bit better on my computer, but this has to do with improvements to FGFS, not of the aircraft model. So if your computer was struggling with the initial version, we recommend to use current FGFS git/nightly builds or wait until 3.2 comes out!<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213132#p213132<br />
|title=<nowiki>Re: New Aircraft: the Extra500</nowiki><br />
|author=<nowiki>D-EKEW</nowiki><br />
|date=<nowiki>Sun Jun 22</nowiki><br />
}}<br />
}}<br />
<br />
Please checkout the [[Extra EA-500|Extra500 wiki]] for download instructions and lots of more info.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
There is a project to add all the USA state capital buildings into FG. A scenery forum thread talks about it here http://forum.flightgear.org/viewtopic.php?f=5&t=22715&sid=ea847909bde2e1f8ffe5b94bcc673f4f There is also a wiki page here [[State_Capitol_Buildings_in_the_United_States]]. So far, Idaho, Louisiana & Nebraska have been completed. Hawaii and New York are currently in progress. Please feel free to join in with any other state that has not been done yet. Just let us know through the forum and we will add it to the in progress list.<br />
<br />
=== Airports ===<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
=== An updated Weather article ===<br />
The [[Weather]] wiki article went through a wide extension. Although Advanced Weather was released quite a while ago, its usage has never been explained in the wiki, and some thorough instructions were available only in a readme in the "docs" folder of the base package which is not commonly explored by users, while the wiki article [[Advanced weather]] is more about the project than the usage.<br />
<br />
AW's advanced configuration is known to be not easy. So, if you always only used the weather selection menu and want to know more, or want to understand what the options actually do and how you can combine them, the [[Weather]] article has now been updated with some hints and basic notions extracted from experience and the original documentation, and quality checked by the author of the AW weather engine.<br />
<br />
=== Translators required ===<br />
{|<br />
|[[File:en.gif]]<br />
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].<br />
|-<br />
|[[File:de.gif]]<br />
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
|[[File:nl.gif]]<br />
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
|[[File:es.gif]]<br />
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|}<br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
<br />
=== Call for volunteers ===<br />
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].<br />
<br />
=== Did you know ===<br />
<br />
[[Category:FlightGear Newsletter]]<br />
<!-- this needs to be changed after each release, so that newsletters show up in the proper category --><br />
<br />
[[Category:Changes after 3.00]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=73060FlightGear wiki:Instant-Refs2014-06-22T13:41:00Z<p>Bigstones: fixed conversion of resized wiki images</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br/><br />
<br/><br />
This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br/><br />
<br/><br />
For more info, I suggest to check out:<br/><br />
<br/><br />
[[MapStructure#Porting_the_map_dialog]]<br/><br />
[[File:MapStructureDialog.png|250px]] <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case {{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
* gitorious links converted to wiki markup could/should probably use the "Git link" template, e.g. see the quote at [http://wiki.flightgear.org/Canvas_ND_Framework#Design]<br />
<br />
== The Script ==<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
phpBB_smilies2text(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
// automatic links to the wiki (we don't use the displayed text)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>https?:\/\/wiki.flightgear.org.*?<\/a>/g, "[[$1]]");<br />
// links to the wiki with custom text (we preserve it)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
html = html.replace(/<a[^(?:href)]*href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
return html;<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/(?:[0-9]+px-)?([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
bbhtml = bbhtml.replace(/<span class="posthilit">(.*?)<\/span>/g, "$1");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// converts smilies images from phpBB.<br />
// Must be used BEFORE img2link(), because it makes a broken link of them<br />
function phpBB_smilies2text() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<img.*?src="\.\/images\/smilies\/icon_.*?\.gif".*?alt="(.*?)".*?>/g,"$1");<br />
}<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=73058FlightGear wiki talk:Instant-Refs2014-06-22T13:39:44Z<p>Bigstones: /* Postings that break our script for some reason */ done</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
:::: {{done}}, however it looks fine only with single words (it's not converting the underscores to spaces).--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:02, 18 June 2014 (UTC)<br />
<br />
=== too greedy non-greedy regexes ===<br />
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can still be incorrect: say I have<br />
<nowiki><a someprop="href" href="http://www.link.org" ... ></nowiki><br />
If I want to mach anything between a and href, I use <tt><nowiki>[^(?:href)]*</nowiki></tt>, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].<br />
<br />
So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using ''only'' xpaths *sobs*.<br />
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
=== Postings that break our script for some reason ===<br />
* http://forum.flightgear.org/viewtopic.php?f=19&t=23365<br />
<br />
{{FGCquote<br />
|t should be possible to procedurally render charts like these using Canvas and some custom styling:<br/><br />
[[Airport_Diagram_Generator]]<br/><br />
[[File:423px-Adg-KSFO-0.png]] [[File:423px-Adg-KSFO-1.png]]<br/><br />
<br/><br />
(the main advantage would be that these would be 100% in sync with actual FG nav data!)<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213110#p213110<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
: {{done}}, I didn't consider resized images, now that should be ok. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 13:39, 22 June 2014 (UTC)<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: {{done}}. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}} --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)<br />
<br />
=== Chopped strings and stripped \n's: we need an alternative output ===<br />
At first, the limitation of the alert dialog was only on the length of the text. Now radi reports that Firefox strips the newlines (as in \n) making the string hardly readable, and I can confirm this on Iceweasel (Debian's re-branded Firefox). It seems that the most flexible way out of this is a superimposed div. I made some experiments and a basic style for such a div, simply appended inside <body> is:<br />
<br />
position: fixed;<br />
width: 80%;<br />
height: 57%;<br />
z-index: 1000;<br />
margin: 10%;<br />
padding: 1%;<br />
background: white;<br />
border: solid black;<br />
word-wrap: break-word;<br />
overflow: auto;<br />
<br />
However it seems that all of this could be handled easier through some library like jQuery. I think I don't even know how to include a library inside a JS script. To escape the html code to show it in the html body (like br's and others) a nice and easy solution is [http://stackoverflow.com/a/12034334 here].</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=73057FlightGear wiki talk:Instant-Refs2014-06-22T13:30:33Z<p>Bigstones: /* Misc notes */ we need an alternative output + removed outdated observations</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
:::: {{done}}, however it looks fine only with single words (it's not converting the underscores to spaces).--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:02, 18 June 2014 (UTC)<br />
<br />
=== too greedy non-greedy regexes ===<br />
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can still be incorrect: say I have<br />
<nowiki><a someprop="href" href="http://www.link.org" ... ></nowiki><br />
If I want to mach anything between a and href, I use <tt><nowiki>[^(?:href)]*</nowiki></tt>, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].<br />
<br />
So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using ''only'' xpaths *sobs*.<br />
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
=== Postings that break our script for some reason ===<br />
* http://forum.flightgear.org/viewtopic.php?f=19&t=23365<br />
<br />
{{FGCquote<br />
|t should be possible to procedurally render charts like these using Canvas and some custom styling:<br/><br />
[[Airport_Diagram_Generator]]<br/><br />
[[File:423px-Adg-KSFO-0.png]] [[File:423px-Adg-KSFO-1.png]]<br/><br />
<br/><br />
(the main advantage would be that these would be 100% in sync with actual FG nav data!)<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213110#p213110<br />
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 21</nowiki><br />
}}<br />
}}<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: {{done}}. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}} --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)<br />
<br />
=== Chopped strings and stripped \n's: we need an alternative output ===<br />
At first, the limitation of the alert dialog was only on the length of the text. Now radi reports that Firefox strips the newlines (as in \n) making the string hardly readable, and I can confirm this on Iceweasel (Debian's re-branded Firefox). It seems that the most flexible way out of this is a superimposed div. I made some experiments and a basic style for such a div, simply appended inside <body> is:<br />
<br />
position: fixed;<br />
width: 80%;<br />
height: 57%;<br />
z-index: 1000;<br />
margin: 10%;<br />
padding: 1%;<br />
background: white;<br />
border: solid black;<br />
word-wrap: break-word;<br />
overflow: auto;<br />
<br />
However it seems that all of this could be handled easier through some library like jQuery. I think I don't even know how to include a library inside a JS script. To escape the html code to show it in the html body (like br's and others) a nice and easy solution is [http://stackoverflow.com/a/12034334 here].</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Falconara_Airport&diff=73024Falconara Airport2014-06-21T18:30:43Z<p>Bigstones: /* Scenery project */ progress update (release of 6/2014 preview)</p>
<hr />
<div>{{infobox Airport<br />
|name = Aeroporto di Ancona-Falconara<br/> Aeroporto delle Marche "Raffaello Sanzio"<br />
|image = LIPY structures landscape.jpg<br />
|alt =<br />
|iata = AOI<br />
|icao = LIPY<br />
|type = public<br />
|owner = Aerdorica S.p.A.<br />
|city = Falconara (AN), Italy<br />
|website = http://www.aeroportomarche.it<br />
<br />
|runway = 04/22<br />
|length = 2965m<br />
|material = asphalt, concrete heads<br />
<br />
|scenerytile = e013n43<br />
|terrasync = no<br />
|download = <br />
}}<br />
<br />
'''Falconara Airport''' is a small international airport located half way down the east coast of Italy, 18 km west of Ancona.<br />
<br />
== The airport ==<br />
LIPY is the only international airport of le Marche region. In 2013 it had a traffic of ~500 000 passengers and ~6 600 tons of goods. It has two separate terminals for arrival/departure of passengers and another cargo terminal area. The control tower is powered by a photovoltaic system. It has an unused military area and hosts 5º Nucleo Elicotteri of the Carabinieri, with an Agusta [[A109]] helicopter.<br />
<br />
In 1981 the airport was visited by a [[Concorde]]. During the various operations in the Balcans area, for its obvious favourable position, it has been used by military forces with Apaches, UH-60, tankers, A-10, Harriers, and heavy cargos like C-17, C-5, An-124.<br />
<br />
A peculiarity of this airport is that 1 km north of it, right on the coast, there is a refinery that can't be overflown.<br />
<br />
=== Structure ===<br />
The only runway, 04/22, is almost 3 km long, 45 m wide, and it's used also for taxiing, as the taxiway parallel to the runway is off duty. It's used in both directions but only 22 is served by ILS. It has a 0.2% slope towards north-east.<br />
<br />
The main apron is located towards the southwest end of the runway. It has 14 parking places, four of which for smaller planes, and the main taxiways are R1 and R2. R3 connects the middle of the runway to the aeroclub and private hangars.<br />
<br />
No operations area is present for civil helicopters, that need to take off and land on the runway.<br />
<br />
=== ATC and navigational aids ===<br />
LIPY is in a class D airspace up to FL115, class G outside CTR zone "1" below 2000 ft. There are APP, TWR and ATIS frequencies.<br />
<br />
Navigational aids include VOR-DME and NDB in Ancona, and in Falconara TACAN, DME, locator and ILS.<br />
<br />
=== Aeroclub ===<br />
Falconara Airport is base of Aeroclub Ancona,<ref><br />
[http://www.aeroclubancona.com/ Aeroclub Ancona]<br />
</ref><br />
which is a {{wikipedia|Flight Training Organization}} and owns one [[C172]] SP with [[Garmin G1000]], one [[C152]], one [[PA28]]RT-201 Turbo Arrow IV (with retractable gear) and one [[P92]]-JS.<br />
<br />
== Scenery project ==<br />
Since April 2014 user bigstones<ref name="thread"><br />
{{forumref<br />
|title=LIPY airport<br />
|t=22623<br />
|f=5<br />
}}</ref><br />
has been interested in improving the airport. Models would be provided by a generous MSFS user who made a wonderful scenery no more than few months earlier, with bigstones trying to convert this very detailed scenery while keeping it usable on not-so-powerful machines. The tool used for conversion is [[ModelConverterX]].<br />
<br />
Latest update: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:30, 21 June 2014 (UTC)<br />
<br />
=== Download and testing ===<br />
A scenery preview is available, as an overlay. In this phase, it still contains parts that are not GPL compatible, hence '''it is still under its original, NON-GPL license'''. For more information on this please see the README inside the ZIP file. ''Note that right now this package includes two other airports, layout only: LIPR, LIDF''.<br />
<br />
'''Download here''':<br />
<s>[http://www.mediafire.com/download/by5wkp35b1qsaqc/LIPY_2014-04-29.zip LIPY_2014-04-29.zip]</s><br />
[http://www.mediafire.com/download/9dx9x4u9vlg8i3d/LIPY_2014-06-21.zip LIPY_2014-06-21.zip]<br />
<br />
See [[Howto:Install scenery]] for installing instructions.<br />
<br />
==== Testing objectives ====<br />
Please report your experiences/ideas/anything, particularly focusing on the following points:<br />
* '''Modelers''': please open a couple of models and tell me if/how you can fix their axes??<br />
<br />
The preferred channel for communication is the forum thread on LIPY<ref name="thread"/>.<br />
<br />
=== Project status ===<br />
* The 850 airport layout has already been sent to Robin from X-Plane. It's not perfect, but is enough.<br />
* Static objects have all been converted and placed.<br />
* LOD adjustment: instead of using an expensive range animation, the "detailed" setting of the LOD dialog is checked and some less important but heavy objects are hidden accordingly:<br />
** <1500m is low detail<br />
** 1500m is medium detail (and default FG setting)<br />
** >1501m is high detail<br />
* The glass made terminal buildings were customized to show the inside.<br />
* Lightmaps and Rembrandt lights make the airport comfortable at night too. Three levels of lights are supported, based on the shader setting:<br />
** no lights<br />
** only apron main light poles<br />
** apron light poles and other apron spotlights<br />
** streetlights<br />
* Parking positions were fixed (?)<br />
* Custom ground signs were placed<br />
<br />
=== Agenda ===<br />
This is a to-do list of things that are not yet in the downloadable preview.<br />
* [[Interactive traffic|Groundnet, traffic]] and other XMLs<br />
* substitute non GPLable textures (and fix "thank's")<br />
* rebuild all the texture maps to comply FG scenery db (...)<br />
* [[Howto:Animate models|Animated]] PAPI and [[Nasal|programmable]] IBN<br />
* Real taxi and runway lights (that would need an n-th layout version without default lighting...)<br />
* '''Some better looking oil refinery buildings would really be welcome'''<br />
<br />
=== Preview gallery ===<br />
<gallery><br />
File:LIPY landscape with API.jpg| LIPY landscape with API<br />
File:LIPY landscape with Mount San Vicino.jpg| LIPY landscape with Mount San Vicino<br />
File:LIPY apron landscape.jpg| LIPY apron landscape<br />
File:LIPY terminals.jpg| LIPY terminals<br />
File:LIPY cargo area.jpg| LIPY cargo area<br />
File:LIPY fire station.jpg| LIPY fire station<br />
File:LIPY tower and solar plant.jpg| LIPY tower and solar plant<br />
File:LIPY aeroclub.jpg| LIPY aeroclub<br />
File:LIPY military tower.jpg| LIPY military tower<br />
File:LIPY structures landscape.jpg| LIPY structures landscape<br />
File:LIPY Falconara API refinery.jpg| LIPY Falconara API refinery<br />
File:LIPY at night 1.jpg|LIPY at night<br />
File:LIPY at night 2.jpg|LIPY at night<br />
</gallery><br />
<br />
=== Models credits ===<br />
The team to which the creator of the original models belongs is called '''Phoenix Team'''<ref><br />
[http://www.gianlucag78.altervista.org/index.htm Phoenix Team site]<br />
</ref><br />
and is focused on improving italian military traffic and scenery for MSFS. If you're interested in seeing what '''a year's worth''' of volunteer work can lead to, you'd better check out the original scenery<ref><br />
[http://www.gianlucag78.altervista.org/Scenari.htm Phoenix Team Sceneries download]<br />
</ref> if you have Flight Simulator, or just check out some screenshots from a forum thread that followed his development<ref><br />
[http://www.flightportal.it/forum/viewtopic.php?f=255&t=57811 Ancona Falconara LIPY - Flightportal.it]<br />
</ref>. In fact the original one uses a photoreal ground improved by Gianluca's painstaking hand and includes a very good looking refinery (contribution from a team mate). Other people deserve credits for the scenery<ref>see the readme from the original scenery package, where you'll also find info on how to donate to the team if you like its work.</ref>, but we'd specially like to remember Bruno, who provided Gianluca with the pictures of buildings and vehicles that, wisely adapted, are texturing the airport objects.<br />
<br />
A "thank you" goes also to the creator and maintainer of MCX, Arno (that might want to fix his program support for AC files).<ref><br />
[http://www.scenerydesign.org/modelconverterx/ ModelConverterX official site]<br />
</ref><br />
<br />
== Notes ==<br />
<references/><br />
<br />
[[Category:Airports in Italy]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=File:LIPY_at_night_2.jpg&diff=73023File:LIPY at night 2.jpg2014-06-21T18:14:37Z<p>Bigstones: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=LIPY at night}}<br />
|date=2014-06-21 20:12:41<br />
|source={{own}}<br />
|author=[[User:Bigstones|Bigstones]]<br />
|permission=<br />
|other_versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-zero}}<br />
<br />
<br />
[[Category:Screenshots of scenery]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=File:LIPY_at_night_1.jpg&diff=73022File:LIPY at night 1.jpg2014-06-21T18:14:26Z<p>Bigstones: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=LIPY at night}}<br />
|date=2014-06-21 20:12:40<br />
|source={{own}}<br />
|author=[[User:Bigstones|Bigstones]]<br />
|permission=<br />
|other_versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-zero}}<br />
<br />
<br />
[[Category:Screenshots of scenery]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Falconara_Airport&diff=73019Falconara Airport2014-06-21T17:31:41Z<p>Bigstones: /* Aeroclub */ +wikipedia template</p>
<hr />
<div>{{infobox Airport<br />
|name = Aeroporto di Ancona-Falconara<br/> Aeroporto delle Marche "Raffaello Sanzio"<br />
|image = LIPY structures landscape.jpg<br />
|alt =<br />
|iata = AOI<br />
|icao = LIPY<br />
|type = public<br />
|owner = Aerdorica S.p.A.<br />
|city = Falconara (AN), Italy<br />
|website = http://www.aeroportomarche.it<br />
<br />
|runway = 04/22<br />
|length = 2965m<br />
|material = asphalt, concrete heads<br />
<br />
|scenerytile = e013n43<br />
|terrasync = no<br />
|download = <br />
}}<br />
<br />
'''Falconara Airport''' is a small international airport located half way down the east coast of Italy, 18 km west of Ancona.<br />
<br />
== The airport ==<br />
LIPY is the only international airport of le Marche region. In 2013 it had a traffic of ~500 000 passengers and ~6 600 tons of goods. It has two separate terminals for arrival/departure of passengers and another cargo terminal area. The control tower is powered by a photovoltaic system. It has an unused military area and hosts 5º Nucleo Elicotteri of the Carabinieri, with an Agusta [[A109]] helicopter.<br />
<br />
In 1981 the airport was visited by a [[Concorde]]. During the various operations in the Balcans area, for its obvious favourable position, it has been used by military forces with Apaches, UH-60, tankers, A-10, Harriers, and heavy cargos like C-17, C-5, An-124.<br />
<br />
A peculiarity of this airport is that 1 km north of it, right on the coast, there is a refinery that can't be overflown.<br />
<br />
=== Structure ===<br />
The only runway, 04/22, is almost 3 km long, 45 m wide, and it's used also for taxiing, as the taxiway parallel to the runway is off duty. It's used in both directions but only 22 is served by ILS. It has a 0.2% slope towards north-east.<br />
<br />
The main apron is located towards the southwest end of the runway. It has 14 parking places, four of which for smaller planes, and the main taxiways are R1 and R2. R3 connects the middle of the runway to the aeroclub and private hangars.<br />
<br />
No operations area is present for civil helicopters, that need to take off and land on the runway.<br />
<br />
=== ATC and navigational aids ===<br />
LIPY is in a class D airspace up to FL115, class G outside CTR zone "1" below 2000 ft. There are APP, TWR and ATIS frequencies.<br />
<br />
Navigational aids include VOR-DME and NDB in Ancona, and in Falconara TACAN, DME, locator and ILS.<br />
<br />
=== Aeroclub ===<br />
Falconara Airport is base of Aeroclub Ancona,<ref><br />
[http://www.aeroclubancona.com/ Aeroclub Ancona]<br />
</ref><br />
which is a {{wikipedia|Flight Training Organization}} and owns one [[C172]] SP with [[Garmin G1000]], one [[C152]], one [[PA28]]RT-201 Turbo Arrow IV (with retractable gear) and one [[P92]]-JS.<br />
<br />
== Scenery project ==<br />
Since April 2014 user bigstones<ref name="thread"><br />
{{forumref<br />
|title=LIPY airport<br />
|t=22623<br />
|f=5<br />
}}</ref><br />
has been interested in improving the airport. Models would be provided by a generous MSFS user who made a wonderful scenery no more than few months earlier, with bigstones trying to convert this very detailed scenery while keeping it usable on not-so-powerful machines. The tool used for conversion is [[ModelConverterX]].<br />
<br />
Latest update: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 10:52, 20 June 2014 (UTC)<br />
<br />
=== Download and testing ===<br />
A scenery preview is available, as an overlay. In this phase, it still contains parts that are not GPL compatible, hence '''it is still under its original, NON-GPL license'''. For more information on this please see the README inside the ZIP file. ''Note that right now this package includes two other airports, layout only: LIPR, LIDF''.<br />
<br />
'''Download here''': [http://www.mediafire.com/download/by5wkp35b1qsaqc/LIPY_2014-04-29.zip LIPY_2014-04-29.zip]<br />
<br />
See [[Howto:Install scenery]] for installing instructions.<br />
<br />
==== Testing objectives ====<br />
Please report your experiences/ideas/anything, particularly focusing on the following points:<br />
* '''Modelers''': please open a couple of models and tell me if/how you can fix their axes??<br />
<br />
The preferred channel for communication is the forum thread on LIPY<ref name="thread"/>.<br />
<br />
=== Project status ===<br />
* The 850 airport layout is ready and has already been sent to Robin from X-Plane. However it went through some polish and will be resent [...a third time. I hope he won't get upset.]<br />
* Static objects have all been converted and placed but might need some optimization. Some still have no "bottoms" and have incorrect shadows with [[Project Rembrandt|Rembrandt]].<br />
* LOD adjustment is active but seems to have no impact on framerate -- needs community feedback<br />
* Some alpha textures need the alpha color to be fixed, to prevent the "black edges" effect.<br />
<br />
=== Agenda ===<br />
This is a to-do list of things that are not yet in the downloadable preview.<br />
* <s>Publish an alpha version, get some feedback and decide on optimizations</s><br />
* <s>Fix those alpha texture colors</s><br />
* <s>Try and make terminals glass transparent in [[Project Rembrandt#Registering all translucent surfaces|Rembrandt]]</s><br />
* <s>[[Howto:Lightmap|Lightmaps]]</s><br />
* <s>Primary Rembrandt lights (apron)</s><br />
* <s>Build the inside of the now transparent terminals</s><br />
* <s>Add buildings "bottoms" to fix their shadows</s> (didn't work out great)<br />
* <s>Secondary [[Project Rembrandt#Adding lights to a model|Rembrandt lights]] (street ligths, cargo area)</s><br />
* Fix "thank's"<br />
* [[Interactive traffic|Groundnet, traffic]] and other XMLs (<s>+fix parking spots</s>)<br />
* substitute non GPLable textures<br />
* rebuild all the texture maps to comply FG scenery db (...)<br />
* [[Howto:Animate models|Animated]] PAPI and [[Nasal|programmable]] IBN<br />
* Real taxi and runway lights (that would need an n-th layout version without default lighting...)<br />
* '''Some better looking oil refinery buildings would really be welcome'''<br />
<br />
=== Preview gallery ===<br />
<gallery><br />
File:LIPY landscape with API.jpg| LIPY landscape with API<br />
File:LIPY landscape with Mount San Vicino.jpg| LIPY landscape with Mount San Vicino<br />
File:LIPY apron landscape.jpg| LIPY apron landscape<br />
File:LIPY terminals.jpg| LIPY terminals<br />
File:LIPY cargo area.jpg| LIPY cargo area<br />
File:LIPY fire station.jpg| LIPY fire station<br />
File:LIPY tower and solar plant.jpg| LIPY tower and solar plant<br />
File:LIPY aeroclub.jpg| LIPY aeroclub<br />
File:LIPY military tower.jpg| LIPY military tower<br />
File:LIPY structures landscape.jpg| LIPY structures landscape<br />
File:LIPY Falconara API refinery.jpg| LIPY Falconara API refinery<br />
</gallery><br />
<br />
=== Models credits ===<br />
The team to which the creator of the original models belongs is called '''Phoenix Team'''<ref><br />
[http://www.gianlucag78.altervista.org/index.htm Phoenix Team site]<br />
</ref><br />
and is focused on improving italian military traffic and scenery for MSFS. If you're interested in seeing what '''a year's worth''' of volunteer work can lead to, you'd better check out the original scenery<ref><br />
[http://www.gianlucag78.altervista.org/Scenari.htm Phoenix Team Sceneries download]<br />
</ref> if you have Flight Simulator, or just check out some screenshots from a forum thread that followed his development<ref><br />
[http://www.flightportal.it/forum/viewtopic.php?f=255&t=57811 Ancona Falconara LIPY - Flightportal.it]<br />
</ref>. In fact the original one uses a photoreal ground improved by Gianluca's painstaking hand and includes a very good looking refinery (contribution from a team mate). Other people deserve credits for the scenery<ref>see the readme from the original scenery package, where you'll also find info on how to donate to the team if you like its work.</ref>, but we'd specially like to remember Bruno, who provided Gianluca with the pictures of buildings and vehicles that, wisely adapted, are texturing the airport objects.<br />
<br />
A "thank you" goes also to the creator and maintainer of MCX, Arno (that might want to fix his program support for AC files).<ref><br />
[http://www.scenerydesign.org/modelconverterx/ ModelConverterX official site]<br />
</ref><br />
<br />
== Notes ==<br />
<references/><br />
<br />
[[Category:Airports in Italy]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Taxiway_signs&diff=72993Taxiway signs2014-06-21T12:28:21Z<p>Bigstones: /* Related content */ + link</p>
<hr />
<div>Taxiway signs add a great deal of realism and information to an airport. FlightGear supports the apt.dat 850 signs specification.<br />
<br />
Users interested in helping to improve the scenery are extremely welcome to read the [[#Placing_signs|Placing signs]] section of this article. [[FGSignMaker]], a tool to generate taxiway sign codes, is a tool that can make placing taxiway signs easier.<br />
<br />
== Explanation of signs ==<br />
There are many types of signs on airfields. The following table explains the used syntax.<br />
<br />
=== Taxiway Signs ===<br />
{| style="background: white; text-align: left; border: 1px silver solid; border-collapse: collapse; margin-left:1em;" cellpadding="3" border="1"<br />
||[[File:Sign_27-33.jpg|x32px]]<br />
|'''Black lettering on a yellow background: direction sign:''' Gives directions to other installations: "Runways 27 and 33 are to your right".<br />
|<tt>OBJECT_SIGN {@Y}27-33{^r}</tt><br />
|-<br />
|[[File:Sign_A.jpg|x32px]]<br />
|'''Yellow lettering on a black background: location sign:''' Indicates the taxiway you are on.<br />
|style="width:200px"|<tt>OBJECT_SIGN {@L}A</tt><br />
|- <br />
||[[File:Sign_15-33.jpg|x32px]]<br />
|'''Holding position sign:''' Hold here. From your position on the taxiway at midfield, the threshold for Runway 15 is to your left and the threshold for Runway 33 is to your right. This sign is located next to the yellow holding position markings painted on the taxiway pavement.<br />
|<tt>OBJECT_SIGN {@R}15-33</tt><br />
|-<br />
||[[File:Sign_ILS.jpg|x32px]]<br />
|'''ILS holding position sign:''' ATC may hold you at this sign when the instrument landing system is being used at the airport. Aircraft taxiing beyond this point may interfere with the ILS signal to approaching aircraft.<br />
|<tt>OBJECT_SIGN {@R}ILS</tt><br />
|-<br />
||[[File:Sign_15-APCH.jpg|x32px]]<br />
|'''Holding position sign for approach areas:''' Hold here unless cleared to cross. Taxiing past this sign may interfere with arriving or departing aircraft to Runway 15.<br />
|<tt>OBJECT_SIGN {@R}15-APCH</tt><br />
|-<br />
||[[File:Sign safety.png|x32px]]<br />
|'''Runway boundary sign:''' This sign faces the runway and is visible to pilots exiting the runway. Taxi past this sign (dash past the dashed lines) to be sure you are clear of the runway.<br />
|<tt>OBJECT_SIGN {safety}</tt><br />
|-<br />
||[[File:Sign critical.png|x32px]]<br />
|'''ILS critical area boundary sign:''' Seen when exiting the runway, this sign marks the boundary of the ILS critical area. When ILS approaches are in use, be sure your aircraft has passed beyond this sign before stopping on the taxiway.<br />
|<tt>OBJECT_SIGN {critical}</tt><br />
|-<br />
||[[File:Sign hazard.png|x32px]]<br />
|'''End of taxiway:''' Seen when a taxiway ends and a left/right turn has to be performed instead.<br />
|<tt>OBJECT_SIGN {hazard}</tt><br />
|- <br />
|[[File:Sign_no-entry.jpg|x32px]]<br />
|'''No entry sign:''' Do not enter this area. Aircraft are prohibited. This sign would be found at the entrance to a one-way taxiway or at the intersection of a road intended for vehicles. <br />
<del>'''Note that this sign needs the red color (@R) prefix in FlightGear!'''</del><br />
|<tt>OBJECT_SIGN {no-entry}</tt><br />
|}<br />
<br />
== Placing signs ==<br />
Signs can be placed by obtaining the lat/lon coordinates from a [[GNU GPL]] licensed source. <br />
<br />
You can also [[Howto: Place 3D objects with the UFO|use the UFO]] for easier positioning. Load (by pressing the l-key) the <tt>[[$FG ROOT]]/Aircraft/UFO/Models/sign.ac</tt> model to find the correct headings. After dumping the data, replace OBJECT_SHARED by OBJECT_SIGN and add the sign codes instead of <tt>Aircraft/UFO/Models/sign.ac</tt>.<br />
<br />
=== Sign types ===<br />
These instructions specify sign types. They refer to the sign names in the FAA specification:<br />
<br />
{| class="prettytable" border="0" cellspacing="2"<br />
! style="background:#efefef; text-align: center" | Name<br />
! style="background:#efefef; text-align: center" | Instructions<br />
! style="background:#efefef; text-align: center" | Description<br />
|-<br />
|L858-Y<br />
| style="text-align: center" |<tt>@Y</tt><br />
|"Direction, Destination, Boundary" sign (black on yellow)<br /><br />
|- <br />
|L858-R<br />
| style="text-align: center" |<tt>@R</tt><br />
|"Mandatory Instruction" sign (white on red with black outline)<br />
|-<br />
|L858-L<br />
| style="text-align: center" |<tt>@L</tt><br />
|"Location" sign (yellow text and frame on black)<br />
|-<br />
|L858-B<br />
| style="text-align: center" |<tt>@B</tt><br />
|"Runway Distance Remaining" sign (white on black)<br />
|}<br />
<br />
These sign type specifiers are used to request FAA signs L858-Y, L858-R, L858-L and L858-B of unspecified size. It is up to the implementation to choose a default size. If the size is known, then a size digit is appended, which also refers to the FAA standard:<br />
<br />
{| class="prettytable" border="0" cellspacing="2" style="text-align: center;"<br />
! style="background:#efefef; text-align: center" |<br />
! style="background:#efefef; text-align: center" |Size 1<br />0.460 m<br />
! style="background:#efefef; text-align: center" |Size 2<br />0.610 m<br />
! style="background:#efefef; text-align: center" |Size 3<br />0.760 m<br />
! style="background:#efefef; text-align: center" |Size 4<br />1.220 m<br />
! style="background:#efefef; text-align: center" |Size 5<br />0.760 m<br />
|-<br />
! style="background:#efefef; text-align: center" |L858-Y<br />
|<tt>@Y1</tt><br />
|<tt>@Y2</tt><br />
|<tt>@Y3</tt><br />
|<br />
|<br />
|-<br />
! style="background:#efefef; text-align: center" |L858-R<br />
|<tt>@R1</tt><br />
|<tt>@R2</tt><br />
|<tt>@R3</tt><br />
|<br />
|<br />
|-<br />
! style="background:#efefef; text-align: center" |L858-L<br />
|<tt>@L1</tt><br />
|<tt>@L2</tt><br />
|<tt>@L3</tt><br />
|<br />
|<br />
|-<br />
! style="background:#efefef; text-align: center" |L858-B<br />
|<br />
|<br />
|<br />
|<tt>@B4</tt><br />
|<tt>@B5</tt><br />
|}<br />
<br />
=== Multi-Letter Glyph Names ===<br />
{| border=1 cellspacing=0 cellpadding=5<br />
|<tt>^u</tt><br />
|up arrow<br />
|-<br />
|<tt>^d</tt><br />
|down arrow<br />
|-<br />
|<tt>^l</tt><br />
|left arrow<br />
|-<br />
|<tt>^r</tt><br />
|right arrow<br />
|-<br />
|<tt>^lu</tt><br />
|left-up arrow<br />
|-<br />
|<tt>^ru</tt><br />
|right-up arrow<br />
|-<br />
|<tt>^ld</tt><br />
|left-down arrow<br />
|-<br />
|<tt>^rd</tt><br />
|right-down arrow<br />
|-<br />
|<tt>r1</tt><br />
|roman numeral I<br />
|-<br />
|<tt>r2</tt><br />
|roman numeral II<br />
|-<br />
|<tt>r3</tt><br />
|roman numeral III<br />
|-<br />
|<tt>no-entry</tt><br />
|no-entry sign (white circle with horizontal bar on red background)<br />
|}<br />
<br />
Note that diagonal arrows always have the right/left letter first, as is common in Cartesian coordinate systems. So it's <tt>ru</tt> (right up), not <tt>ur</tt>.<br />
<br />
=== Examples ===<br />
* <tt>OBJECT_SIGN {@Y,@l}S7{@L}B{@Y}S8{@ru} -22.592 63.985 46 72</tt><br />
* <tt>OBJECT_SIGN {@Y}MAX_SPAN_52M -22.592 63.985 46 72</tt><br />
* <tt>OBJECT_SIGN {@R,no-entry} -22.592 63.985 46 72</tt><br />
* <tt>OBJECT_SIGN {@L}V2{@R}06-24 -22.592 63.985 46 72</tt><br />
<br />
== Related content ==<br />
* [[FGSignMaker]]<br />
* [[Sign Specification Proposal]]<br />
* [[Howto:Modeling Ground Signs with Blender]]<br />
<br />
== External links ==<br />
* [http://www.aopa.org/asf/publications/taxi/taxi_signage.html AOPA Airport and Taxiway Signage]<br />
<br />
[[Category:Scenery enhancement]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=User_talk:DuaneBarry&diff=72906User talk:DuaneBarry2014-06-20T14:15:10Z<p>Bigstones: /* Two versions of the Italian FlightGear page? */ new section</p>
<hr />
<div>== Two versions of the Italian FlightGear page? ==<br />
<br />
Hi, thanks for the translation work! Just to be sure, are you aware that there are currently two Italian versions of the [[FlightGear]] page? [[IT/FlightGear]] and [[It/FlightGear]]. Not sure if that's intended, so that's why I'm asking. The "other languages" link points to the [[It/FlightGear]] page, but [[Translation requests]] links to the other one.<br />
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:15, 20 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Falconara_Airport&diff=72884Falconara Airport2014-06-20T10:52:33Z<p>Bigstones: /* Scenery project */ progress update</p>
<hr />
<div>{{infobox Airport<br />
|name = Aeroporto di Ancona-Falconara<br/> Aeroporto delle Marche "Raffaello Sanzio"<br />
|image = LIPY structures landscape.jpg<br />
|alt =<br />
|iata = AOI<br />
|icao = LIPY<br />
|type = public<br />
|owner = Aerdorica S.p.A.<br />
|city = Falconara (AN), Italy<br />
|website = http://www.aeroportomarche.it<br />
<br />
|runway = 04/22<br />
|length = 2965m<br />
|material = asphalt, concrete heads<br />
<br />
|scenerytile = e013n43<br />
|terrasync = no<br />
|download = <br />
}}<br />
<br />
'''Falconara Airport''' is a small international airport located half way down the east coast of Italy, 18 km west of Ancona.<br />
<br />
== The airport ==<br />
LIPY is the only international airport of le Marche region. In 2013 it had a traffic of ~500 000 passengers and ~6 600 tons of goods. It has two separate terminals for arrival/departure of passengers and another cargo terminal area. The control tower is powered by a photovoltaic system. It has an unused military area and hosts 5º Nucleo Elicotteri of the Carabinieri, with an Agusta [[A109]] helicopter.<br />
<br />
In 1981 the airport was visited by a [[Concorde]]. During the various operations in the Balcans area, for its obvious favourable position, it has been used by military forces with Apaches, UH-60, tankers, A-10, Harriers, and heavy cargos like C-17, C-5, An-124.<br />
<br />
A peculiarity of this airport is that 1 km north of it, right on the coast, there is a refinery that can't be overflown.<br />
<br />
=== Structure ===<br />
The only runway, 04/22, is almost 3 km long, 45 m wide, and it's used also for taxiing, as the taxiway parallel to the runway is off duty. It's used in both directions but only 22 is served by ILS. It has a 0.2% slope towards north-east.<br />
<br />
The main apron is located towards the southwest end of the runway. It has 14 parking places, four of which for smaller planes, and the main taxiways are R1 and R2. R3 connects the middle of the runway to the aeroclub and private hangars.<br />
<br />
No operations area is present for civil helicopters, that need to take off and land on the runway.<br />
<br />
=== ATC and navigational aids ===<br />
LIPY is in a class D airspace up to FL115, class G outside CTR zone "1" below 2000 ft. There are APP, TWR and ATIS frequencies.<br />
<br />
Navigational aids include VOR-DME and NDB in Ancona, and in Falconara TACAN, DME, locator and ILS.<br />
<br />
=== Aeroclub ===<br />
Falconara Airport is base of Aeroclub Ancona,<ref><br />
[http://www.aeroclubancona.com/ Aeroclub Ancona]<br />
</ref><br />
which is a [[wikipedia:Flight Training Organization|Flight Training Organization]] and owns one [[C172]] SP with [[Garmin G1000]], one [[C152]], one [[PA28]]RT-201 Turbo Arrow IV (with retractable gear) and one [[P92]]-JS.<br />
<br />
== Scenery project ==<br />
Since April 2014 user bigstones<ref name="thread"><br />
{{forumref<br />
|title=LIPY airport<br />
|t=22623<br />
|f=5<br />
}}</ref><br />
has been interested in improving the airport. Models would be provided by a generous MSFS user who made a wonderful scenery no more than few months earlier, with bigstones trying to convert this very detailed scenery while keeping it usable on not-so-powerful machines. The tool used for conversion is [[ModelConverterX]].<br />
<br />
Latest update: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 10:52, 20 June 2014 (UTC)<br />
<br />
=== Download and testing ===<br />
A scenery preview is available, as an overlay. In this phase, it still contains parts that are not GPL compatible, hence '''it is still under its original, NON-GPL license'''. For more information on this please see the README inside the ZIP file. ''Note that right now this package includes two other airports, layout only: LIPR, LIDF''.<br />
<br />
'''Download here''': [http://www.mediafire.com/download/by5wkp35b1qsaqc/LIPY_2014-04-29.zip LIPY_2014-04-29.zip]<br />
<br />
See [[Howto:Install scenery]] for installing instructions.<br />
<br />
==== Testing objectives ====<br />
Please report your experiences/ideas/anything, particularly focusing on the following points:<br />
* '''Modelers''': please open a couple of models and tell me if/how you can fix their axes??<br />
<br />
The preferred channel for communication is the forum thread on LIPY<ref name="thread"/>.<br />
<br />
=== Project status ===<br />
* The 850 airport layout is ready and has already been sent to Robin from X-Plane. However it went through some polish and will be resent [...a third time. I hope he won't get upset.]<br />
* Static objects have all been converted and placed but might need some optimization. Some still have no "bottoms" and have incorrect shadows with [[Project Rembrandt|Rembrandt]].<br />
* LOD adjustment is active but seems to have no impact on framerate -- needs community feedback<br />
* Some alpha textures need the alpha color to be fixed, to prevent the "black edges" effect.<br />
<br />
=== Agenda ===<br />
This is a to-do list of things that are not yet in the downloadable preview.<br />
* <s>Publish an alpha version, get some feedback and decide on optimizations</s><br />
* <s>Fix those alpha texture colors</s><br />
* <s>Try and make terminals glass transparent in [[Project Rembrandt#Registering all translucent surfaces|Rembrandt]]</s><br />
* <s>[[Howto:Lightmap|Lightmaps]]</s><br />
* <s>Primary Rembrandt lights (apron)</s><br />
* <s>Build the inside of the now transparent terminals</s><br />
* <s>Add buildings "bottoms" to fix their shadows</s> (didn't work out great)<br />
* <s>Secondary [[Project Rembrandt#Adding lights to a model|Rembrandt lights]] (street ligths, cargo area)</s><br />
* Fix "thank's"<br />
* [[Interactive traffic|Groundnet, traffic]] and other XMLs (<s>+fix parking spots</s>)<br />
* substitute non GPLable textures<br />
* rebuild all the texture maps to comply FG scenery db (...)<br />
* [[Howto:Animate models|Animated]] PAPI and [[Nasal|programmable]] IBN<br />
* Real taxi and runway lights (that would need an n-th layout version without default lighting...)<br />
* '''Some better looking oil refinery buildings would really be welcome'''<br />
<br />
=== Preview gallery ===<br />
<gallery><br />
File:LIPY landscape with API.jpg| LIPY landscape with API<br />
File:LIPY landscape with Mount San Vicino.jpg| LIPY landscape with Mount San Vicino<br />
File:LIPY apron landscape.jpg| LIPY apron landscape<br />
File:LIPY terminals.jpg| LIPY terminals<br />
File:LIPY cargo area.jpg| LIPY cargo area<br />
File:LIPY fire station.jpg| LIPY fire station<br />
File:LIPY tower and solar plant.jpg| LIPY tower and solar plant<br />
File:LIPY aeroclub.jpg| LIPY aeroclub<br />
File:LIPY military tower.jpg| LIPY military tower<br />
File:LIPY structures landscape.jpg| LIPY structures landscape<br />
File:LIPY Falconara API refinery.jpg| LIPY Falconara API refinery<br />
</gallery><br />
<br />
=== Models credits ===<br />
The team to which the creator of the original models belongs is called '''Phoenix Team'''<ref><br />
[http://www.gianlucag78.altervista.org/index.htm Phoenix Team site]<br />
</ref><br />
and is focused on improving italian military traffic and scenery for MSFS. If you're interested in seeing what '''a year's worth''' of volunteer work can lead to, you'd better check out the original scenery<ref><br />
[http://www.gianlucag78.altervista.org/Scenari.htm Phoenix Team Sceneries download]<br />
</ref> if you have Flight Simulator, or just check out some screenshots from a forum thread that followed his development<ref><br />
[http://www.flightportal.it/forum/viewtopic.php?f=255&t=57811 Ancona Falconara LIPY - Flightportal.it]<br />
</ref>. In fact the original one uses a photoreal ground improved by Gianluca's painstaking hand and includes a very good looking refinery (contribution from a team mate). Other people deserve credits for the scenery<ref>see the readme from the original scenery package, where you'll also find info on how to donate to the team if you like its work.</ref>, but we'd specially like to remember Bruno, who provided Gianluca with the pictures of buildings and vehicles that, wisely adapted, are texturing the airport objects.<br />
<br />
A "thank you" goes also to the creator and maintainer of MCX, Arno (that might want to fix his program support for AC files).<ref><br />
[http://www.scenerydesign.org/modelconverterx/ ModelConverterX official site]<br />
</ref><br />
<br />
== Notes ==<br />
<references/><br />
<br />
[[Category:Airports in Italy]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Falconara_Airport&diff=72879Falconara Airport2014-06-19T21:44:40Z<p>Bigstones: /* Scenery project */ progress update</p>
<hr />
<div>{{infobox Airport<br />
|name = Aeroporto di Ancona-Falconara<br/> Aeroporto delle Marche "Raffaello Sanzio"<br />
|image = LIPY structures landscape.jpg<br />
|alt =<br />
|iata = AOI<br />
|icao = LIPY<br />
|type = public<br />
|owner = Aerdorica S.p.A.<br />
|city = Falconara (AN), Italy<br />
|website = http://www.aeroportomarche.it<br />
<br />
|runway = 04/22<br />
|length = 2965m<br />
|material = asphalt, concrete heads<br />
<br />
|scenerytile = e013n43<br />
|terrasync = no<br />
|download = <br />
}}<br />
<br />
'''Falconara Airport''' is a small international airport located half way down the east coast of Italy, 18 km west of Ancona.<br />
<br />
== The airport ==<br />
LIPY is the only international airport of le Marche region. In 2013 it had a traffic of ~500 000 passengers and ~6 600 tons of goods. It has two separate terminals for arrival/departure of passengers and another cargo terminal area. The control tower is powered by a photovoltaic system. It has an unused military area and hosts 5º Nucleo Elicotteri of the Carabinieri, with an Agusta [[A109]] helicopter.<br />
<br />
In 1981 the airport was visited by a [[Concorde]]. During the various operations in the Balcans area, for its obvious favourable position, it has been used by military forces with Apaches, UH-60, tankers, A-10, Harriers, and heavy cargos like C-17, C-5, An-124.<br />
<br />
A peculiarity of this airport is that 1 km north of it, right on the coast, there is a refinery that can't be overflown.<br />
<br />
=== Structure ===<br />
The only runway, 04/22, is almost 3 km long, 45 m wide, and it's used also for taxiing, as the taxiway parallel to the runway is off duty. It's used in both directions but only 22 is served by ILS. It has a 0.2% slope towards north-east.<br />
<br />
The main apron is located towards the southwest end of the runway. It has 14 parking places, four of which for smaller planes, and the main taxiways are R1 and R2. R3 connects the middle of the runway to the aeroclub and private hangars.<br />
<br />
No operations area is present for civil helicopters, that need to take off and land on the runway.<br />
<br />
=== ATC and navigational aids ===<br />
LIPY is in a class D airspace up to FL115, class G outside CTR zone "1" below 2000 ft. There are APP, TWR and ATIS frequencies.<br />
<br />
Navigational aids include VOR-DME and NDB in Ancona, and in Falconara TACAN, DME, locator and ILS.<br />
<br />
=== Aeroclub ===<br />
Falconara Airport is base of Aeroclub Ancona,<ref><br />
[http://www.aeroclubancona.com/ Aeroclub Ancona]<br />
</ref><br />
which is a [[wikipedia:Flight Training Organization|Flight Training Organization]] and owns one [[C172]] SP with [[Garmin G1000]], one [[C152]], one [[PA28]]RT-201 Turbo Arrow IV (with retractable gear) and one [[P92]]-JS.<br />
<br />
== Scenery project ==<br />
Since April 2014 user bigstones<ref name="thread"><br />
{{forumref<br />
|title=LIPY airport<br />
|t=22623<br />
|f=5<br />
}}</ref><br />
has been interested in improving the airport. Models would be provided by a generous MSFS user who made a wonderful scenery no more than few months earlier, with bigstones trying to convert this very detailed scenery while keeping it usable on not-so-powerful machines. The tool used for conversion is [[ModelConverterX]].<br />
<br />
Latest update: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:44, 19 June 2014 (UTC)<br />
<br />
=== Download and testing ===<br />
A scenery preview is available, as an overlay. In this phase, it still contains parts that are not GPL compatible, hence '''it is still under its original, NON-GPL license'''. For more information on this please see the README inside the ZIP file. ''Note that right now this package includes two other airports, layout only: LIPR, LIDF''.<br />
<br />
'''Download here''': [http://www.mediafire.com/download/by5wkp35b1qsaqc/LIPY_2014-04-29.zip LIPY_2014-04-29.zip]<br />
<br />
See [[Howto:Install scenery]] for installing instructions.<br />
<br />
==== Testing objectives ====<br />
Please report your experiences/ideas/anything, particularly focusing on the following points:<br />
* '''Modelers''': please open a couple of models and tell me if/how you can fix their axes??<br />
<br />
The preferred channel for communication is the forum thread on LIPY<ref name="thread"/>.<br />
<br />
=== Project status ===<br />
* The 850 airport layout is ready and has already been sent to Robin from X-Plane. However it went through some polish and will be resent [...a third time. I hope he won't get upset.]<br />
* Static objects have all been converted and placed but might need some optimization. Some still have no "bottoms" and have incorrect shadows with [[Project Rembrandt|Rembrandt]].<br />
* LOD adjustment is active but seems to have no impact on framerate -- needs community feedback<br />
* Some alpha textures need the alpha color to be fixed, to prevent the "black edges" effect.<br />
<br />
=== Agenda ===<br />
This is a to-do list of things that are not yet in the downloadable preview.<br />
* <s>Publish an alpha version, get some feedback and decide on optimizations</s><br />
* <s>Fix those alpha texture colors</s><br />
* <s>Try and make terminals glass transparent in [[Project Rembrandt#Registering all translucent surfaces|Rembrandt]]</s><br />
* <s>[[Howto:Lightmap|Lightmaps]]</s><br />
* <s>Primary Rembrandt lights (apron)</s><br />
* <s>Build the inside of the now transparent terminals</s><br />
* <s>Add buildings "bottoms" to fix their shadows</s> (didn't work out great)<br />
* Secondary [[Project Rembrandt#Adding lights to a model|Rembrandt lights]] (<s>street ligths</s>, cargo area)<br />
* Fix "thank's"<br />
* [[Interactive traffic|Groundnet, traffic]] and other XMLs (<s>+fix parking spots</s>)<br />
* substitute non GPLable textures<br />
* rebuild all the texture maps to comply FG scenery db (...)<br />
* [[Howto:Animate models|Animated]] PAPI and [[Nasal|programmable]] IBN<br />
* Real taxi and runway lights (that would need an n-th layout version without default lighting...)<br />
* '''Some better looking oil refinery buildings would really be welcome'''<br />
<br />
=== Preview gallery ===<br />
<gallery><br />
File:LIPY landscape with API.jpg| LIPY landscape with API<br />
File:LIPY landscape with Mount San Vicino.jpg| LIPY landscape with Mount San Vicino<br />
File:LIPY apron landscape.jpg| LIPY apron landscape<br />
File:LIPY terminals.jpg| LIPY terminals<br />
File:LIPY cargo area.jpg| LIPY cargo area<br />
File:LIPY fire station.jpg| LIPY fire station<br />
File:LIPY tower and solar plant.jpg| LIPY tower and solar plant<br />
File:LIPY aeroclub.jpg| LIPY aeroclub<br />
File:LIPY military tower.jpg| LIPY military tower<br />
File:LIPY structures landscape.jpg| LIPY structures landscape<br />
File:LIPY Falconara API refinery.jpg| LIPY Falconara API refinery<br />
</gallery><br />
<br />
=== Models credits ===<br />
The team to which the creator of the original models belongs is called '''Phoenix Team'''<ref><br />
[http://www.gianlucag78.altervista.org/index.htm Phoenix Team site]<br />
</ref><br />
and is focused on improving italian military traffic and scenery for MSFS. If you're interested in seeing what '''a year's worth''' of volunteer work can lead to, you'd better check out the original scenery<ref><br />
[http://www.gianlucag78.altervista.org/Scenari.htm Phoenix Team Sceneries download]<br />
</ref> if you have Flight Simulator, or just check out some screenshots from a forum thread that followed his development<ref><br />
[http://www.flightportal.it/forum/viewtopic.php?f=255&t=57811 Ancona Falconara LIPY - Flightportal.it]<br />
</ref>. In fact the original one uses a photoreal ground improved by Gianluca's painstaking hand and includes a very good looking refinery (contribution from a team mate). Other people deserve credits for the scenery<ref>see the readme from the original scenery package, where you'll also find info on how to donate to the team if you like its work.</ref>, but we'd specially like to remember Bruno, who provided Gianluca with the pictures of buildings and vehicles that, wisely adapted, are texturing the airport objects.<br />
<br />
A "thank you" goes also to the creator and maintainer of MCX, Arno (that might want to fix his program support for AC files).<ref><br />
[http://www.scenerydesign.org/modelconverterx/ ModelConverterX official site]<br />
</ref><br />
<br />
== Notes ==<br />
<references/><br />
<br />
[[Category:Airports in Italy]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Howto:Make_an_airport&diff=72863Howto:Make an airport2014-06-19T14:13:18Z<p>Bigstones: /* A note about the formats */ +wikipedia template</p>
<hr />
<div>This article will guide you through the process of '''creating an airport''' and link you to related articles.<br />
<br />
== A note about licenses ==<br />
Official FlightGear scenery is, as the rest of the program and data, licensed under the [[GNU General Public License]] v2. In order to have your work included in the official scenery, it must comply with this license.<br />
<br />
In short this means that you can only use images that:<br />
* you created yourself, entirely from scratch. This is the case when you draw something, or take a photograph of a building.<br />
* you received permission for to release under the GNU GPL v2.<br />
* are licensed under a [http://upload.wikimedia.org/wikipedia/commons/d/dc/Quick-guide-gplv3-compatibility.svg GNU GPL v2 compatible license] (eg. Public Domain).<br />
<br />
Google Earth imagery is per definition '''not''' compatible. For the USA you can download the High Resolution Orthoimagery jpeg from http://earthexplorer.usgs.gov/ and use that to trace airports or buildings. For other countries, you might use OpenStreetMap data if available. Note that OpenStreetMap has been granted the right to trace over Yahoo and Bing aerial images, so it can get quite accurate. Consider learning how to [http://wiki.openstreetmap.org/wiki/Aeroways map airports in OSM].<br />
<br />
Alternatively you can estimate the lengths and widths of the buildings by looking at pictures.<br />
<br />
== Runways, taxiways and aprons ==<br />
=== What you need ===<br />
* [[WorldEditor]] - to "draw" the layout of the airport (taxiways, runways, aprons)<br />
** Runway layout data - either from the USA Airport & Scenery Database or from other free imagery<br />
** Other data (approach lighting systems, frequencies etc.) about the airport you want to make<br />
* [[TerraGear]] - to turn the layout into useable scenery<br />
** Shapefiles for the area around your airport - http://mapserver.flightgear.org/download.psp<br />
** Heightmaps - http://dds.cr.usgs.gov/srtm/version2_1/<br />
<br />
Ubuntu users, can use the script in [[Ubuntu fg tools]].<br />
<br />
=== Airport layout ===<br />
The very first step before creating a new airport layout is to check if the airport already exists in the airport database. Latest data is available at http://data.x-plane.com/get_data.html<br />
If we find our airport there, we can improve it, if not, we start a new layout. This is all done in [[WorldEditor]].<br />
<br />
So if we have done the airport in WED, we save it as "ICAO.dat" (replacing ICAO with the ICAO code of your airport). That's the X-Plane fileformat, which is used by FlightGear too.<br />
<br />
==== A note about the formats ====<br />
FlightGear once used the 810 version of the [[File formats#apt.dat file|apt.dat file format]], while now 850 is on duty. The difference between them is mainly that 850 allows laying down taxiways/taxilines indipendently, and making them bend smoothly (with {{wikipedia|Bezier curve|Bezier curves}}), while in 810 there were only rectangles of taxiways with a yellow line in the middle. You can tell an old airport by the fact that crossings and bends are rounded by overlaying a number of rectangular patches. If you meet one, consider converting it, and as you're already there try to gather information to make it better!<br />
<br />
=== Turning the airport into FlightGear scenery ===<br />
There are three possibilities, the later two require [[TerraGear]], but have the advantage that you can view the result immediately:<br />
* Send your layout (.dat file) to robin peel, as explained at [[#Share your layout with the world!]] and wait for the next FlightGear scenery build to include your airport.<br />
* [[Howto: Test your airport layout: quick and easy]], for a quick look at your airport. This will place your airport in the middle of an ocean.<br />
* [[Using TerraGear]], you can create an entire scenery, including the surrounding terrain.<br />
<br />
=== Share your layout with the world! ===<br />
Don't forget to send your new "airport.dat" [http://data.x-plane.com/contact.html to Robin], so we all will benefit from, with the next scenery release!<br />
<br />
== Terminals, towers and hangars ==<br />
=== What you need ===<br />
* 3D modeling software, like [[Blender]] or [[SketchUp]], as long as it can export to the .ac file type.<br />
* Lots of pictures of the buildings at the airport.<br />
<br />
=== Making a 3D model ===<br />
One meter in FlightGear is one meter in the real world. If you use aerial or satellite imagery to measure out the buildings you'll be fine.<br />
<br />
=== Placing objects ===<br />
{{Main article|Howto:Add details to your airport}}<br />
<br />
You can either place the model manually using the [[UFO]], or if you are developing an actual building, it's usually good to get the co-ordinates of one of the corners of the building so you can place it extremely accurately. You also need the elevation and the rotation of the model, but those are easy to estimate.<br />
<br />
=== Share your models with the world! ===<br />
after finishing a building, send your model to the [http://scenemodels.flightgear.org/ scenery database], as that is the best way for them to be distributed. Everyone who downloads the airport from then on will be able to see your building! <br />
<br />
== Related content ==<br />
* [[Howto:Make a helipad]]<br />
<br />
[[Category:Howto]]<br />
[[Category:Scenery enhancement]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72844FlightGear wiki talk:Instant-Refs2014-06-18T20:02:46Z<p>Bigstones: /* recognizing wiki images */ update on pretty wiki links</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
:::: {{done}}, however it looks fine only with single words (it's not converting the underscores to spaces).--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:02, 18 June 2014 (UTC)<br />
<br />
=== too greedy non-greedy regexes ===<br />
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can still be incorrect: say I have<br />
<nowiki><a someprop="href" href="http://www.link.org" ... ></nowiki><br />
If I want to mach anything between a and href, I use <tt><nowiki>[^(?:href)]*</nowiki></tt>, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].<br />
<br />
So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using ''only'' xpaths *sobs*.<br />
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: {{done}}. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}}. However, before resorting to simply using the alt text, I tried by matching on the image name, so I had a series of replace() and tested it [http://forum.flightgear.org/viewtopic.php?f=14&t=23020&p=209367&hilit=syntax+highlighting#p209367 here]. It worked, but if I selected a larger extent of text, again one of the regexes would go crazy and eat up half the message. That's clearly the same that's happening [[#recognizing wiki images|above]], I'd really love to understand what's happening there. I tried using a new variable instead of reassigning to the same, but it changed nothing (I expected that.)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72843FlightGear wiki:Instant-Refs2014-06-18T19:59:12Z<p>Bigstones: a2wikilinks: don't display the text from automatic forum links (http://blabla...bla)</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case {{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
<br />
<br />
== The Script ==<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
phpBB_smilies2text(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
// automatic links to the wiki (we don't use the displayed text)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>https?:\/\/wiki.flightgear.org.*?<\/a>/g, "[[$1]]");<br />
// links to the wiki with custom text (we preserve it)<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
html = html.replace(/<a[^(?:href)]*href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
return html;<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
bbhtml = bbhtml.replace(/<span class="posthilit">(.*?)<\/span>/g, "$1");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// converts smilies images from phpBB.<br />
// Must be used BEFORE img2link(), because it makes a broken link of them<br />
function phpBB_smilies2text() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<img.*?src="\.\/images\/smilies\/icon_.*?\.gif".*?alt="(.*?)".*?>/g,"$1");<br />
}<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72841FlightGear wiki talk:Instant-Refs2014-06-17T17:04:39Z<p>Bigstones: /* too greedy non-greedy regexes */ made it clearer</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
<br />
=== too greedy non-greedy regexes ===<br />
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can still be incorrect: say I have<br />
<nowiki><a someprop="href" href="http://www.link.org" ... ></nowiki><br />
If I want to mach anything between a and href, I use <tt><nowiki>[^(?:href)]*</nowiki></tt>, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].<br />
<br />
So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using ''only'' xpaths *sobs*.<br />
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: {{done}}. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}}. However, before resorting to simply using the alt text, I tried by matching on the image name, so I had a series of replace() and tested it [http://forum.flightgear.org/viewtopic.php?f=14&t=23020&p=209367&hilit=syntax+highlighting#p209367 here]. It worked, but if I selected a larger extent of text, again one of the regexes would go crazy and eat up half the message. That's clearly the same that's happening [[#recognizing wiki images|above]], I'd really love to understand what's happening there. I tried using a new variable instead of reassigning to the same, but it changed nothing (I expected that.)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72840FlightGear wiki talk:Instant-Refs2014-06-17T16:49:02Z<p>Bigstones: /* Issues */ regarding messages chopped by regexes - found what's wrong, no easy fix</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
<br />
=== too greedy non-greedy regexes ===<br />
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can't be straightforwardly done everywhere: for example, say you have <tt><nowiki><a href="http://www.link.org" ... someprop="a > c" ... ></nowiki></tt>. If I want to mach anything after the href up to the closing &gt;, I'd have to use <tt><nowiki>[^>]*</nowiki></tt>, but that would match only up to a greather than b, so I'd have to check that it's not inside parenthesis... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].<br />
<br />
So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground.<br />
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: {{done}}. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}}. However, before resorting to simply using the alt text, I tried by matching on the image name, so I had a series of replace() and tested it [http://forum.flightgear.org/viewtopic.php?f=14&t=23020&p=209367&hilit=syntax+highlighting#p209367 here]. It worked, but if I selected a larger extent of text, again one of the regexes would go crazy and eat up half the message. That's clearly the same that's happening [[#recognizing wiki images|above]], I'd really love to understand what's happening there. I tried using a new variable instead of reassigning to the same, but it changed nothing (I expected that.)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72839FlightGear wiki:Instant-Refs2014-06-17T16:48:07Z<p>Bigstones: kind of fixed a too greedy regex. see FlightGear wiki talk:Instant-Cquotes#too greedy non-greedy regexes</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case {{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
<br />
<br />
== The Script ==<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
phpBB_smilies2text(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
html = html.replace(/<a[^(?:href)]*href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
html = html.replace(/<a[^(?:href)]*href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
return html;<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
bbhtml = bbhtml.replace(/<span class="posthilit">(.*?)<\/span>/g, "$1");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// converts smilies images from phpBB.<br />
// Must be used BEFORE img2link(), because it makes a broken link of them<br />
function phpBB_smilies2text() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<img.*?src="\.\/images\/smilies\/icon_.*?\.gif".*?alt="(.*?)".*?>/g,"$1");<br />
}<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72838FlightGear wiki talk:Instant-Refs2014-06-17T15:14:34Z<p>Bigstones: /* Paragraphs / br (trailing slash) */ +done</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: {{done}}. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}}. However, before resorting to simply using the alt text, I tried by matching on the image name, so I had a series of replace() and tested it [http://forum.flightgear.org/viewtopic.php?f=14&t=23020&p=209367&hilit=syntax+highlighting#p209367 here]. It worked, but if I selected a larger extent of text, again one of the regexes would go crazy and eat up half the message. That's clearly the same that's happening [[#recognizing wiki images|above]], I'd really love to understand what's happening there. I tried using a new variable instead of reassigning to the same, but it changed nothing (I expected that.)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72837FlightGear wiki talk:Instant-Refs2014-06-17T15:13:38Z<p>Bigstones: /* support/ignore highlighted keywords/smilies */ done</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples<br />
: {{done}}. However, before resorting to simply using the alt text, I tried by matching on the image name, so I had a series of replace() and tested it [http://forum.flightgear.org/viewtopic.php?f=14&t=23020&p=209367&hilit=syntax+highlighting#p209367 here]. It worked, but if I selected a larger extent of text, again one of the regexes would go crazy and eat up half the message. That's clearly the same that's happening [[#recognizing wiki images|above]], I'd really love to understand what's happening there. I tried using a new variable instead of reassigning to the same, but it changed nothing (I expected that.)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72836FlightGear wiki:Instant-Refs2014-06-17T14:56:36Z<p>Bigstones: phpBB smilies support</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case {{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
<br />
<br />
== The Script ==<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
phpBB_smilies2text(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
return html.replace(/<a.*?href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
bbhtml = bbhtml.replace(/<span class="posthilit">(.*?)<\/span>/g, "$1");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// converts smilies images from phpBB.<br />
// Must be used BEFORE img2link(), because it makes a broken link of them<br />
function phpBB_smilies2text() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<img.*?src="\.\/images\/smilies\/icon_.*?\.gif".*?alt="(.*?)".*?>/g,"$1");<br />
}<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72835FlightGear wiki:Instant-Refs2014-06-17T14:23:16Z<p>Bigstones: "support" for highlighted words from phpBB search</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case {{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
<br />
<br />
== The Script ==<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
return html.replace(/<a.*?href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
bbhtml = bbhtml.replace(/<span class="posthilit">(.*?)<\/span>/g, "$1");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72834FlightGear wiki talk:Instant-Refs2014-06-17T14:03:52Z<p>Bigstones: removing old stuff + about fix of br and trailing slash</p>
<hr />
<div>== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)<br />
<br />
:: Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:58, 14 June 2014 (UTC)<br />
<br />
<br />
::: Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just <nowiki>[[FOO]]</nowiki> would make more make sense than having something http://wiki.flightgear.org/FOO ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:32, 15 June 2014 (UTC)<br />
<br />
=== regex vectors ===<br />
<br />
When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
: Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:46, 16 June 2014 (UTC)<br />
<br />
=== Syntaxhighlighting ===<br />
Need to investigate what needs to be updated to support quoting code sections, as per [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&p=212585#p212581] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:33, 14 June 2014 (UTC)<br />
<br />
== Misc notes ==<br />
<br />
=== Detecting failed XPaths === <br />
you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. <br />
<br />
=== Paragraphs / br (trailing slash) ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote<br />
: That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:03, 17 June 2014 (UTC)<br />
<br />
<br />
=== support/ignore highlighted keywords/smilies ===<br />
see [[Understanding Forward Compatibility]] for examples</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72833FlightGear wiki:Instant-Refs2014-06-17T13:22:09Z<p>Bigstones: (back to work!) fixed the issue with newlines, wiki source should be way more readable now</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this (as well as allowing people to easily reuse forum/devel list announcements in wiki articles, e.g. to update the changelog, newsletter or "release plan/lessons learnt" section) - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.<br />
Use this article's discussion page to get in touch (e.g. if there are any bugs/problems or features requests).}}<br />
<br />
== Example Output ==<br />
The output may look like this (click the link to see the original forum posting): <br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Background & Installation ==<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script (on firefox, save the script as instant_cquotes.user.js, then drag'n'drop it into firefox).<br />
== Usage ==<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message, such as: http://forum.flightgear.org/viewtopic.php?f=71&t=23299#p212558<br />
* copy/mark some relevant portion of text (the script converts links, images and even youtube videos - wiki images are properly converted, too and it will try to retain basic formatting)<br />
* and directly get a full cquote paragraph (including author, date, thread and URL) that you can add to the wiki here using CTRL+C & CTRL-V<br />
<br />
== Known Limitations ==<br />
* <s>newline2br</s> addNewline() should also insert CR/LF for separating paragraphs in the cquote (also, the trailing slash is not added) {{done}}<br />
* quoting code doesn't yet work properly {{Not done}}<br />
* our regexes may fail once the HTML DOM of the source changes (e.g. phpBB/theme update), so we should better show a warning when that's the case {{Not done}}<br />
* it may make sense to provide multiple regexes that are tried in order {{Not done}}<br />
* The script uses a conventional JavaScript alert() box for providing the output, these dialogs are typically restricted to a max size of ~10kb-we may need to explore other/extended options {{Not done}}<br />
* The script has already seen several iterations and created dozens of cquotes we're using in various places, but it might be possible to use the script to update previously created cquotes/FGCquotes automatically, instead of using the getSelection() helper, we could register a '''match''' for wiki.flightgear.org with the '''action=edit''' set, so that we can directly process all text of an edited page (using AJAX calls to open the URL in the background would make sense) {{Not done}}<br />
<br />
== Feature Requests & Ideas ==<br />
<br />
<br />
== The Script ==<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals(),<br />
addNewlines()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
return html.replace(/<a.*?href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// puts newlines where it makes for more readable wiki "source"<br />
function addNewlines() {<br />
return function(html) {<br />
html = html.replace(/<br\/?>/g,"<br/>\n");<br />
html = html.replace(/(<\/?[uo]l>)/g,"$1\n");<br />
return html.replace(/<\/li>/g,"</li>\n");<br />
}<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Weather&diff=72812Weather2014-06-16T10:10:35Z<p>Bigstones: /* Quirks */ a bit better explanation + note about setting the time</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 10SM, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 3000ft, wind 300° at 10 kt<br />
* Aloft layer, 6000ft, wind 310° at 20 kt<br />
* Aloft layer, 9000ft, wind 320° at 30 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/preferences.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button.<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind''. It has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects. <br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
<br />
[[Category:Weather| ]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72782FlightGear wiki talk:Instant-Refs2014-06-14T21:51:01Z<p>Bigstones: /* recognizing wiki images */ problem found, not the fix though...</p>
<hr />
<div>== regex / sourceforge {{Done}} ==<br />
<br />
You're right - I just checked out the sourceforge archives, there's just a single <small></small> tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using '''From:''', '''<''' and '''-''' as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the '''CONFIG''' hash, maybe in addition to XPath expressions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:12, 31 May 2014 (UTC)<br />
<br />
== RX suffix {{Done}} ==<br />
<br />
That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:<br />
<br />
<syntaxhighlight language="javascript"><br />
<br />
var CONFIG = {<br />
"sourceforge.net": { <br />
author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },<br />
title: { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },<br />
date: { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },<br />
url: { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }<br />
},<br />
};<br />
</syntaxhighlight><br />
<br />
basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! <br />
Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:23, 31 May 2014 (UTC)<br />
: Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.<br />
: EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:27, 31 May 2014 (UTC)<br />
:: Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:47, 31 May 2014 (UTC)<br />
<br />
== extractInfo loop {{Done}}==<br />
<br />
I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:22, 31 May 2014 (UTC)<br />
<br />
<br />
== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Post-Processing ==<br />
=== the prepend field {{Done}} ===<br />
<br />
I would rename this to '''transform''' and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:24, 31 May 2014 (UTC)<br />
<br />
: I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:47, 31 May 2014 (UTC)<br />
<br />
=== CR/LF - br handling {{Done}} ===<br />
<br />
The whole '''transform'''/post-process idea may not be that far-fetched, I just added quite a few cquotes to the [[Canvas EFB Framework]] article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links (<nowiki>[[FOO]]</nowiki>) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <nowiki><br/></nowiki>) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 1 June 2014 (UTC)<br />
: I'll take a look at these, paragraphs are easy indeed {{Done}}.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
:: For starters, just looking for CR/LF and turning it into <nowiki><br/></nowiki> should suffice --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:30, 2 June 2014 (UTC)<br />
<br />
::: Newlines are now <nowiki><br/></nowiki>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:52, 2 June 2014 (UTC)<br />
<br />
:::: The examples below (in essence [http://wiki.flightgear.org/index.php?title=Talk:Fixing_up_articles_with_wrong_quotes&diff=72282&oldid=72281 this edit]) look like there is one line break more than usual inserted. I would think that both <tt>&lt;br/&gt;</tt> tags and the new line between the <tt>&lt;/nowiki&gt;</tt> and <tt>&lt;nowiki&gt;</tt> tags are treated as line breaks, though I am not 100% sure.<br />
:::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 04:53, 3 June 2014 (UTC)<br />
<br />
::::: I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <nowiki><p></p></nowiki> tag. Possibly it's not that hard... even a regex could probably do: <tt><nowiki>/([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s</nowiki></tt><br />
::::: (note that I don't know if the above works: what with "fake" bullet list newlines? what if only one newline is used to separate text? when should it be applied wrt other transformations?)<br />
::::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:30, 3 June 2014 (UTC)<br />
<br />
:: this looks fairly good to me, once we can also '''transform()''' the actual text selection, and maybe process the underlying HTML code to transform /some/ formatting, I'd consider the whole thing feature-complete. Functionality-wise there really isn't much that could/should be added then. And additional sources are straightforward to add anyway. Overall, this could really help to easily organize efforts that are typically spread across several months/years, because community/contributor support for certain ideas & proposals can be much better evaluated this way, even by new contributors. In fact, we could now even post-process user names, e.g. to link to their forum profile for people wanting to send a PM. So I think this will be a great tool and a huge time-saver. Thanks for all your work on this, really appreciated! BTW: I also don't really "know" JavaScript, but it looks similar enough to Nasal - and it seems you are also getting along, which also means that you may want to check out Nasal at some point :-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:49, 3 June 2014 (UTC)<br />
<br />
=== retained formatting {{Done}} ===<br />
<br />
: I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?<br />
:--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
<br />
:: <del>I don't think</del> we need to copy the HTML content[http://blog.ssokolow.com/archives/2008/12/03/getting-the-selected-text-as-html-using-javascript/comment-page-1/] - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [http://stackoverflow.com/questions/5643635/how-to-get-selected-html-text-with-javascript][http://stackoverflow.com/questions/6251937/how-to-get-selecteduser-highlighted-text-in-contenteditable-element-and-replac][http://stackoverflow.com/a/5670825], e.g. <nowiki><a href=""></a></nowiki> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as '''postlink''' (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <nowiki><ul> <li>...</li> </ul></nowiki>. Looking for images doesn't make too much sense unless those are wiki-hosted, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into <nowiki>{{#ev:youtube|VIDEO_ID}}</nowiki> markup - either through youtube.com URLs. Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:18, 2 June 2014 (UTC)<br />
<br />
::: Ok, I made some support for HTML. I copied a function to get the selected HTML from stackoverflow, then used it on the forum and made up some transform operators. A couple need some attention (especially the syntaxhighlight one). Some have a funny behaviour: try to cquote [http://forum.flightgear.org/viewtopic.php?p=211670#p211670 this post], and you'll see that the image will correctly become a link, while the link will be fully shown as an image. That's because it gets converted to an internal link, and the wiki knows that's an image. Then, I'm not sure if nested quotes are actually a smart thing, and I didn't make the list converter because I couldn't find an example.<br />
::: Not much else to say. Have fun :)<br />
::: EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:16, 8 June 2014 (UTC)<br />
<br />
:: This is pretty cool, and impressive how this has evolved so quickly - I agree that nested quotes are probably too tricky. I think conversion of URLs and youtube links should be a good start. Converting lists should be fairly straightforward now, BTW: here's a posting containing a list[http://forum.flightgear.org/viewtopic.php?f=71&t=23241#p212029]. Thanks again for your work on this !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:43, 8 June 2014 (UTC)<br />
<br />
::: Hi Hooray, I saw your latest cquotes, didn't you "upgrade" to the last version of the script? It's working already, with links, formatting, and nested quotes if one will. Actually, even lists work, because now it copies the HTML and they work even without converting them to the wiki formatting.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:26, 11 June 2014 (UTC)<br />
<br />
: oops, good spotting: using a different computer and browser at the moment, need to upgrade obviously. Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
=== selection processing {{Done}} ===<br />
I think we really only need to add another "content" key that is mapped to GetSelectedText() and then use a '''transform()''' field that can post-process the selection, that is then also where newline replacement, and other content processing would take place. That way we can even replace common acronyms using their wiki equivalents, e.g. [[$FG ROOT]], [[Nasal]] so that quotes would become a bit more self-explanatory --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:55, 3 June 2014 (UTC)<br />
: Two+1 observations on [http://wiki.flightgear.org/index.php?title=Fixing_up_articles_with_wrong_quotes&diff=prev&oldid=72316 latest changes]: 1) I considered GetSelectedText() the "main()" of the script, why would I want to configure that? 2) I see transform() happening in both extractInfo() and GetSelectedText(), is that in preparation to have extractInfo() extract also the content? 3) I didn't think of the transform option that way, it's way cleaner than I thought, we could even make a "pipe()" to serialize different make_xxx() operators! At this point, also the regex could be one of such operators.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:51, 3 June 2014 (UTC)<br />
<br />
:: Those are indeed all very good points, and I was actually aware of them. I really just wanted to "establish the separation" here. It is true that there are now some workarounds in place that are not exactly "a good design". It just seemed simple enough for me, and I was going to volunteer to clean it up once the key functionality is in place. GetSelectedText() is indeed the main work-horse, I just prepared it to become customizable wearing my "Architecture Astronaut" hat :-) And like you say, generalizing extractInfo() seemed like a good idea to me at the time, which is why the workhorse is now specified via the CONFIG hash (despite probably not having to be there). It is probably over-engineering things, but I just wanted to establish the infrastructure to turn everything into a chain of steps that can be mostly configured through just the CONFIG hash. It is awesome that you can see the potential of that, because I fully realized that it may seem "odd" at first glance and maybe too involved. But my goal really is to move all those processing steps into the CONFIG hash, so that we can trivially add other functionality, without having to touch those other functions. I like the whole pipe/cascade analogy very much, it could be just a vector of different transformations applied in order! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:05, 3 June 2014 (UTC)<br />
<br />
::: work in progress... towards 0.8<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:58, 5 June 2014 (UTC)<br />
::: Done. Huge refactoring (I hope you like the style, overall the fact that I use to put "inner" functions after they're used, trusting in a hopefully meaningful name) and "transform" works properly for fields and contents (formally, "content" is one of the fields of "info" now).<br />
::: For the format of the contents, I made it so that you can get either text or (later) html, but that way one can't rely on using the structure of html (xpaths), right now. I know that [http://stackoverflow.com/a/1732454 parsing html with regexes is bad] (btw, I didn't know that Architecture Astronaut thing :) ), but hopefully for a short piece of text it will do?<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:25, 5 June 2014 (UTC)<br />
<br />
:: Looking good here. Regarding your comments/FIXMEs, I agree that the non-conditional nowiki-escaping is a hack, but to do it the proper way would require parsing the blob for nowiki tags, and keeping track of how many open tags there (i.e. using a stack). Stuff like newline2br could probably also be turned into a transformation callback now, thanks to your changes. Changing the order of functions to make them appear sequentially makes sense, I just didn't do it because JS also works without doing it, but I agree that it's now more readable. Regarding reliance on xpath expressions, that's true - but we only use those "ONCE" for each quote. And created quotes won't break - but you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. We'll see how this evolves over time. At least URLs and youtube URLs/videos can be easily processed and could be turned into wiki markup, so that we can easily reuse forum & devel list postings to help populate the newsletter and other wiki articles. Again, thanks for your work on this, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:51, 5 June 2014 (UTC)<br />
<br />
=== HTML handling and Escaping {{Done}} ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote - I think there are also some issues related to the lack of nowiki-escaping now, i.e. see the "Issues" section below. But like I said elsewhere, to do this properly, we'd need to maintain a stack of nowiki tags, so that we know how deeply those are nested and unescape properly.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:11, 12 June 2014 (UTC)<br />
: Bug reports, exciting :) newline2br is not used anymore in the forum, because the br's are already there in the copied html, and phpBB seems to be printing br without slash (does it? I can't verify now, but I can't figure what would remove them in the script.)<br />
: I played a bit with the broken quote ("Issues") and I really can't understand what's wrong. I added back the slashes in the br's, put a newline after them, no change... and there are no strange characters apparently (could it be some non printable character? might be worth to paste that stuff into a hex editor? Philosopher found something like that recently, can't remember where) Obviously nowiki-escaping all the quote works, but I really don't see what should be escaped there.<br />
: It's funny also that it puts the author in place of the quote (if you look well, the position and font is that of the quote) so it must be the template that gets confused somehow. But one thing's sure: it looks very similar to what happens when enabling the conversion of code blocks, so they might be related.<br />
: I'll be busy in the next days, very busy until monday at least... so it'll take me some time to get back to this.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:49, 12 June 2014 (UTC)<br />
<br />
:: Now that you mention it: I saw that being the case with other templates containing certain URLs, including the stub/note templates. So I just tried it myself and it is indeed the embedded youtube URL causing this here. I guess the <nowiki>#</nowiki> character or URL-encoding could be contributing to this --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:56, 12 June 2014 (UTC)<br />
<br />
::: confirmed: it's the equal sign (=) confusing the template parser, probably because it is trying to do argument assignment or something like that. We could probably introduce a new URL template to handle such things, or simply use the youtube embedding code instead in this case. Also see [http://en.wikipedia.org/wiki/Help:Template#Usage_hints_and_workarounds] and [http://en.wikipedia.org/wiki/Template:URL] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:01, 12 June 2014 (UTC)<br />
<br />
:::: That was fast, thanks! This seem to fix also the problem with code snippets, which was a pity to miss. I'll add an operator for those special characters too, and using the URL template is straightforward and should be safer for all the external links. I hope this saves us from the nowiki escape thing (at least for a while.)<br />
:::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:55, 12 June 2014 (UTC)<br />
<br />
:::: Working on this... will commit something before going to bed. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:55, 13 June 2014 (UTC)<br />
<br />
:::: Uhm, kind of done but I'm not satisfied with the code snippet quoting. It's not nice to have escaped stuff and unreadable "wiki source"... anyway, youtube links work fine. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
== example ==<br />
{{cquote<br />
|<nowiki>This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the prope... do. I don't consider this to be coding but others may not agree.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>YIKES !!!Hey guys, I love flying the A330-223 BUT as soon as I wanna intercept the LOC my plane starts to shake like crazy. I was following the youtube Tutorial step by step but I CANT land with ILS. No Autoland nothing.. </nowiki><br/><nowiki><br />
Does anyone know why, On the Flightgear Wiki there are 4 Videos of the custom flight from EDDF (Frankfurt) to EDDM (Munich). But in Germany we CANT watch Video No. 4 (Approach and Autoland) .. because of the music in the video. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=188233#p188233<br />
|title=<nowiki>ILS-Problem on Airbus A330-223</nowiki><br />
|author=<nowiki>henrysean84</nowiki><br />
|date=<nowiki>Mon Aug 05</nowiki><br />
}}<br />
}}<br />
<br />
== testing CR/LF conversion ==<br />
<br />
{{cquote<br />
|<nowiki>I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211086#p211086<br />
|title=<nowiki>Re: Aircraft Rating System</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I think we have usually not deleted textures when introducing a new variant, because good GPL-compatible terrain textures are hard to come by and hence a useful resource. In particular, I remember 'reviving' some nominally obsolete textures as overlays, or in some particular regional context - for regional texturing projects, having lots of varieties is actually invaluable. I would even go as far as trying to commit good textures without an immediate use.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So I guess the bottomline is that we wouldn't necessarily want to ship these textures with the base package, but we would like to have them on a devel repository.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32405025/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>What a muddle...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
There's a whole bunch of different cases in there.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) Duplicate 'winter'-textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Apparently, when creating the winter scheme, all summer textures were copied over and the ones where adding snow makes sense got snow - the rest were just kept. For instance, Terrain.winter/tidal.png is just a copy of Terrain/tidal.png, Terrain.winter/rocks-desert.png is just a copy of Terrain./rocks-desert.png and so on. I think in these cases the duplicate can simply go. Since they're as a rule tiny textures, we don't necessarily gain much.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2) dds-converted unused textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
It would seem (perhaps one of the people involved can confirm that) that in the first version of the dds texturing schemes all existing textures were automatically converted...extures for effects which have since been changed to png for compatibility reasons possibly belong into the same category, Water/bowwave_normal.dds would be an example for this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3) Unused unique png textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
As argued previously, these we should store, possibly in 'unused'. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
4) Unique dds textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Things like Terrain/limestone2.dds are somewhat annoying, as they might be perfectly good texture templates which can't easily be edited or put to use as a png version of the same texture could be, and in addition they aren''t actually used inside the dds scheme. </nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32406658/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-02</nowiki><br />
}}<br />
}}<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Testing 0.9 ==<br />
<br />
{{FGCquote<br />
|Also, we must take into account the different dynamic range and color temperature of the human vision, cameras and computer monitors. "Closer to reality" means completely different if "reality" is "the actual physical properties of the light", "what our eyes capture/brain interprets giving the current lighting conditions" or "what our monitor can really represent". Punkepanda can find an introduction to this extremely complex issue in this link: [http://www.cambridgeincolour.com/tutorials/dynamic-range.htm http://www.cambridgeincolour.com/tutori ... -range.htm]<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212412#p212412<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>ludomotico</nowiki><br />
|date=<nowiki>Thu Jun 12</nowiki><br />
}}<br />
}}<br />
<br />
== Testing 0.10 ==<br />
{{FGCquote<br />
|The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. <br><br>This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.<br><br>For more info, I suggest to check out:<br><br>[[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>[[File:MapStructureDialog.png|250px]] <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>[[File:Map-canvas-chain-home-editor.png|250px]]<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>[[File:MapStructure-TFC-Troubleshooting.png|250px]]<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>[[File:Map-canvas-dialog-storms-overlay.png|250px]]<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure article.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)<br />
<br />
: Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:51, 14 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72780FlightGear wiki talk:Instant-Refs2014-06-14T21:35:31Z<p>Bigstones: /* recognizing wiki images */ changelog (0.10.1 ?)</p>
<hr />
<div>== regex / sourceforge {{Done}} ==<br />
<br />
You're right - I just checked out the sourceforge archives, there's just a single <small></small> tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using '''From:''', '''<''' and '''-''' as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the '''CONFIG''' hash, maybe in addition to XPath expressions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:12, 31 May 2014 (UTC)<br />
<br />
== RX suffix {{Done}} ==<br />
<br />
That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:<br />
<br />
<syntaxhighlight language="javascript"><br />
<br />
var CONFIG = {<br />
"sourceforge.net": { <br />
author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },<br />
title: { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },<br />
date: { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },<br />
url: { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }<br />
},<br />
};<br />
</syntaxhighlight><br />
<br />
basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! <br />
Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:23, 31 May 2014 (UTC)<br />
: Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.<br />
: EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:27, 31 May 2014 (UTC)<br />
:: Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:47, 31 May 2014 (UTC)<br />
<br />
== extractInfo loop {{Done}}==<br />
<br />
I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:22, 31 May 2014 (UTC)<br />
<br />
<br />
== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Post-Processing ==<br />
=== the prepend field {{Done}} ===<br />
<br />
I would rename this to '''transform''' and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:24, 31 May 2014 (UTC)<br />
<br />
: I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:47, 31 May 2014 (UTC)<br />
<br />
=== CR/LF - br handling {{Done}} ===<br />
<br />
The whole '''transform'''/post-process idea may not be that far-fetched, I just added quite a few cquotes to the [[Canvas EFB Framework]] article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links (<nowiki>[[FOO]]</nowiki>) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <nowiki><br/></nowiki>) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 1 June 2014 (UTC)<br />
: I'll take a look at these, paragraphs are easy indeed {{Done}}.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
:: For starters, just looking for CR/LF and turning it into <nowiki><br/></nowiki> should suffice --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:30, 2 June 2014 (UTC)<br />
<br />
::: Newlines are now <nowiki><br/></nowiki>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:52, 2 June 2014 (UTC)<br />
<br />
:::: The examples below (in essence [http://wiki.flightgear.org/index.php?title=Talk:Fixing_up_articles_with_wrong_quotes&diff=72282&oldid=72281 this edit]) look like there is one line break more than usual inserted. I would think that both <tt>&lt;br/&gt;</tt> tags and the new line between the <tt>&lt;/nowiki&gt;</tt> and <tt>&lt;nowiki&gt;</tt> tags are treated as line breaks, though I am not 100% sure.<br />
:::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 04:53, 3 June 2014 (UTC)<br />
<br />
::::: I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <nowiki><p></p></nowiki> tag. Possibly it's not that hard... even a regex could probably do: <tt><nowiki>/([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s</nowiki></tt><br />
::::: (note that I don't know if the above works: what with "fake" bullet list newlines? what if only one newline is used to separate text? when should it be applied wrt other transformations?)<br />
::::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:30, 3 June 2014 (UTC)<br />
<br />
:: this looks fairly good to me, once we can also '''transform()''' the actual text selection, and maybe process the underlying HTML code to transform /some/ formatting, I'd consider the whole thing feature-complete. Functionality-wise there really isn't much that could/should be added then. And additional sources are straightforward to add anyway. Overall, this could really help to easily organize efforts that are typically spread across several months/years, because community/contributor support for certain ideas & proposals can be much better evaluated this way, even by new contributors. In fact, we could now even post-process user names, e.g. to link to their forum profile for people wanting to send a PM. So I think this will be a great tool and a huge time-saver. Thanks for all your work on this, really appreciated! BTW: I also don't really "know" JavaScript, but it looks similar enough to Nasal - and it seems you are also getting along, which also means that you may want to check out Nasal at some point :-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:49, 3 June 2014 (UTC)<br />
<br />
=== retained formatting {{Done}} ===<br />
<br />
: I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?<br />
:--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
<br />
:: <del>I don't think</del> we need to copy the HTML content[http://blog.ssokolow.com/archives/2008/12/03/getting-the-selected-text-as-html-using-javascript/comment-page-1/] - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [http://stackoverflow.com/questions/5643635/how-to-get-selected-html-text-with-javascript][http://stackoverflow.com/questions/6251937/how-to-get-selecteduser-highlighted-text-in-contenteditable-element-and-replac][http://stackoverflow.com/a/5670825], e.g. <nowiki><a href=""></a></nowiki> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as '''postlink''' (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <nowiki><ul> <li>...</li> </ul></nowiki>. Looking for images doesn't make too much sense unless those are wiki-hosted, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into <nowiki>{{#ev:youtube|VIDEO_ID}}</nowiki> markup - either through youtube.com URLs. Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:18, 2 June 2014 (UTC)<br />
<br />
::: Ok, I made some support for HTML. I copied a function to get the selected HTML from stackoverflow, then used it on the forum and made up some transform operators. A couple need some attention (especially the syntaxhighlight one). Some have a funny behaviour: try to cquote [http://forum.flightgear.org/viewtopic.php?p=211670#p211670 this post], and you'll see that the image will correctly become a link, while the link will be fully shown as an image. That's because it gets converted to an internal link, and the wiki knows that's an image. Then, I'm not sure if nested quotes are actually a smart thing, and I didn't make the list converter because I couldn't find an example.<br />
::: Not much else to say. Have fun :)<br />
::: EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:16, 8 June 2014 (UTC)<br />
<br />
:: This is pretty cool, and impressive how this has evolved so quickly - I agree that nested quotes are probably too tricky. I think conversion of URLs and youtube links should be a good start. Converting lists should be fairly straightforward now, BTW: here's a posting containing a list[http://forum.flightgear.org/viewtopic.php?f=71&t=23241#p212029]. Thanks again for your work on this !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:43, 8 June 2014 (UTC)<br />
<br />
::: Hi Hooray, I saw your latest cquotes, didn't you "upgrade" to the last version of the script? It's working already, with links, formatting, and nested quotes if one will. Actually, even lists work, because now it copies the HTML and they work even without converting them to the wiki formatting.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:26, 11 June 2014 (UTC)<br />
<br />
: oops, good spotting: using a different computer and browser at the moment, need to upgrade obviously. Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
=== selection processing {{Done}} ===<br />
I think we really only need to add another "content" key that is mapped to GetSelectedText() and then use a '''transform()''' field that can post-process the selection, that is then also where newline replacement, and other content processing would take place. That way we can even replace common acronyms using their wiki equivalents, e.g. [[$FG ROOT]], [[Nasal]] so that quotes would become a bit more self-explanatory --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:55, 3 June 2014 (UTC)<br />
: Two+1 observations on [http://wiki.flightgear.org/index.php?title=Fixing_up_articles_with_wrong_quotes&diff=prev&oldid=72316 latest changes]: 1) I considered GetSelectedText() the "main()" of the script, why would I want to configure that? 2) I see transform() happening in both extractInfo() and GetSelectedText(), is that in preparation to have extractInfo() extract also the content? 3) I didn't think of the transform option that way, it's way cleaner than I thought, we could even make a "pipe()" to serialize different make_xxx() operators! At this point, also the regex could be one of such operators.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:51, 3 June 2014 (UTC)<br />
<br />
:: Those are indeed all very good points, and I was actually aware of them. I really just wanted to "establish the separation" here. It is true that there are now some workarounds in place that are not exactly "a good design". It just seemed simple enough for me, and I was going to volunteer to clean it up once the key functionality is in place. GetSelectedText() is indeed the main work-horse, I just prepared it to become customizable wearing my "Architecture Astronaut" hat :-) And like you say, generalizing extractInfo() seemed like a good idea to me at the time, which is why the workhorse is now specified via the CONFIG hash (despite probably not having to be there). It is probably over-engineering things, but I just wanted to establish the infrastructure to turn everything into a chain of steps that can be mostly configured through just the CONFIG hash. It is awesome that you can see the potential of that, because I fully realized that it may seem "odd" at first glance and maybe too involved. But my goal really is to move all those processing steps into the CONFIG hash, so that we can trivially add other functionality, without having to touch those other functions. I like the whole pipe/cascade analogy very much, it could be just a vector of different transformations applied in order! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:05, 3 June 2014 (UTC)<br />
<br />
::: work in progress... towards 0.8<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:58, 5 June 2014 (UTC)<br />
::: Done. Huge refactoring (I hope you like the style, overall the fact that I use to put "inner" functions after they're used, trusting in a hopefully meaningful name) and "transform" works properly for fields and contents (formally, "content" is one of the fields of "info" now).<br />
::: For the format of the contents, I made it so that you can get either text or (later) html, but that way one can't rely on using the structure of html (xpaths), right now. I know that [http://stackoverflow.com/a/1732454 parsing html with regexes is bad] (btw, I didn't know that Architecture Astronaut thing :) ), but hopefully for a short piece of text it will do?<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:25, 5 June 2014 (UTC)<br />
<br />
:: Looking good here. Regarding your comments/FIXMEs, I agree that the non-conditional nowiki-escaping is a hack, but to do it the proper way would require parsing the blob for nowiki tags, and keeping track of how many open tags there (i.e. using a stack). Stuff like newline2br could probably also be turned into a transformation callback now, thanks to your changes. Changing the order of functions to make them appear sequentially makes sense, I just didn't do it because JS also works without doing it, but I agree that it's now more readable. Regarding reliance on xpath expressions, that's true - but we only use those "ONCE" for each quote. And created quotes won't break - but you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. We'll see how this evolves over time. At least URLs and youtube URLs/videos can be easily processed and could be turned into wiki markup, so that we can easily reuse forum & devel list postings to help populate the newsletter and other wiki articles. Again, thanks for your work on this, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:51, 5 June 2014 (UTC)<br />
<br />
=== HTML handling and Escaping {{Done}} ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote - I think there are also some issues related to the lack of nowiki-escaping now, i.e. see the "Issues" section below. But like I said elsewhere, to do this properly, we'd need to maintain a stack of nowiki tags, so that we know how deeply those are nested and unescape properly.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:11, 12 June 2014 (UTC)<br />
: Bug reports, exciting :) newline2br is not used anymore in the forum, because the br's are already there in the copied html, and phpBB seems to be printing br without slash (does it? I can't verify now, but I can't figure what would remove them in the script.)<br />
: I played a bit with the broken quote ("Issues") and I really can't understand what's wrong. I added back the slashes in the br's, put a newline after them, no change... and there are no strange characters apparently (could it be some non printable character? might be worth to paste that stuff into a hex editor? Philosopher found something like that recently, can't remember where) Obviously nowiki-escaping all the quote works, but I really don't see what should be escaped there.<br />
: It's funny also that it puts the author in place of the quote (if you look well, the position and font is that of the quote) so it must be the template that gets confused somehow. But one thing's sure: it looks very similar to what happens when enabling the conversion of code blocks, so they might be related.<br />
: I'll be busy in the next days, very busy until monday at least... so it'll take me some time to get back to this.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:49, 12 June 2014 (UTC)<br />
<br />
:: Now that you mention it: I saw that being the case with other templates containing certain URLs, including the stub/note templates. So I just tried it myself and it is indeed the embedded youtube URL causing this here. I guess the <nowiki>#</nowiki> character or URL-encoding could be contributing to this --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:56, 12 June 2014 (UTC)<br />
<br />
::: confirmed: it's the equal sign (=) confusing the template parser, probably because it is trying to do argument assignment or something like that. We could probably introduce a new URL template to handle such things, or simply use the youtube embedding code instead in this case. Also see [http://en.wikipedia.org/wiki/Help:Template#Usage_hints_and_workarounds] and [http://en.wikipedia.org/wiki/Template:URL] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:01, 12 June 2014 (UTC)<br />
<br />
:::: That was fast, thanks! This seem to fix also the problem with code snippets, which was a pity to miss. I'll add an operator for those special characters too, and using the URL template is straightforward and should be safer for all the external links. I hope this saves us from the nowiki escape thing (at least for a while.)<br />
:::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:55, 12 June 2014 (UTC)<br />
<br />
:::: Working on this... will commit something before going to bed. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:55, 13 June 2014 (UTC)<br />
<br />
:::: Uhm, kind of done but I'm not satisfied with the code snippet quoting. It's not nice to have escaped stuff and unreadable "wiki source"... anyway, youtube links work fine. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
== example ==<br />
{{cquote<br />
|<nowiki>This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the prope... do. I don't consider this to be coding but others may not agree.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>YIKES !!!Hey guys, I love flying the A330-223 BUT as soon as I wanna intercept the LOC my plane starts to shake like crazy. I was following the youtube Tutorial step by step but I CANT land with ILS. No Autoland nothing.. </nowiki><br/><nowiki><br />
Does anyone know why, On the Flightgear Wiki there are 4 Videos of the custom flight from EDDF (Frankfurt) to EDDM (Munich). But in Germany we CANT watch Video No. 4 (Approach and Autoland) .. because of the music in the video. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=188233#p188233<br />
|title=<nowiki>ILS-Problem on Airbus A330-223</nowiki><br />
|author=<nowiki>henrysean84</nowiki><br />
|date=<nowiki>Mon Aug 05</nowiki><br />
}}<br />
}}<br />
<br />
== testing CR/LF conversion ==<br />
<br />
{{cquote<br />
|<nowiki>I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211086#p211086<br />
|title=<nowiki>Re: Aircraft Rating System</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I think we have usually not deleted textures when introducing a new variant, because good GPL-compatible terrain textures are hard to come by and hence a useful resource. In particular, I remember 'reviving' some nominally obsolete textures as overlays, or in some particular regional context - for regional texturing projects, having lots of varieties is actually invaluable. I would even go as far as trying to commit good textures without an immediate use.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So I guess the bottomline is that we wouldn't necessarily want to ship these textures with the base package, but we would like to have them on a devel repository.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32405025/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>What a muddle...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
There's a whole bunch of different cases in there.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) Duplicate 'winter'-textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Apparently, when creating the winter scheme, all summer textures were copied over and the ones where adding snow makes sense got snow - the rest were just kept. For instance, Terrain.winter/tidal.png is just a copy of Terrain/tidal.png, Terrain.winter/rocks-desert.png is just a copy of Terrain./rocks-desert.png and so on. I think in these cases the duplicate can simply go. Since they're as a rule tiny textures, we don't necessarily gain much.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2) dds-converted unused textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
It would seem (perhaps one of the people involved can confirm that) that in the first version of the dds texturing schemes all existing textures were automatically converted...extures for effects which have since been changed to png for compatibility reasons possibly belong into the same category, Water/bowwave_normal.dds would be an example for this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3) Unused unique png textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
As argued previously, these we should store, possibly in 'unused'. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
4) Unique dds textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Things like Terrain/limestone2.dds are somewhat annoying, as they might be perfectly good texture templates which can't easily be edited or put to use as a png version of the same texture could be, and in addition they aren''t actually used inside the dds scheme. </nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32406658/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-02</nowiki><br />
}}<br />
}}<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Testing 0.9 ==<br />
<br />
{{FGCquote<br />
|Also, we must take into account the different dynamic range and color temperature of the human vision, cameras and computer monitors. "Closer to reality" means completely different if "reality" is "the actual physical properties of the light", "what our eyes capture/brain interprets giving the current lighting conditions" or "what our monitor can really represent". Punkepanda can find an introduction to this extremely complex issue in this link: [http://www.cambridgeincolour.com/tutorials/dynamic-range.htm http://www.cambridgeincolour.com/tutori ... -range.htm]<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212412#p212412<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>ludomotico</nowiki><br />
|date=<nowiki>Thu Jun 12</nowiki><br />
}}<br />
}}<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)<br />
<br />
: I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work ''unless'' I include in the selection also the first link. That seems to break the regex.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:35, 14 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72779FlightGear wiki:Instant-Refs2014-06-14T21:32:21Z<p>Bigstones: separating pipes and equals escapes (need to be applied at different times)</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.}}<br />
<br />
<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message<br />
* copy/mark some relevant portion of text<br />
* and directly get a full cquote paragraph that you can add to the wiki here<br />
<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
escapePipes(),<br />
a2wikilink(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapeEquals()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
return html.replace(/<a.*?href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// escapes pipe characters that can be problematic inside a template.<br />
// Must be used BEFORE html tags were converted, or they get messed up.<br />
function escapePipes() {<br />
return function(text) {<br />
text = text.replace(/\|\|/g,"{{!!}}");<br />
text = text.replace(/\|\-/g,"{{!-}}");<br />
return text.replace(/\|/g,"{{!}}");<br />
}<br />
}<br />
<br />
// escapes the equal sign that can be problematic inside a template.<br />
// Must be used AFTER html tags were converted, or they get messed up.<br />
function escapeEquals() {<br />
return function(text) {<br />
return text.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72778FlightGear wiki:Instant-Refs2014-06-14T21:22:28Z<p>Bigstones: changed image linking/showing handling + quoting phpBB takes into account the <cite> tag</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.}}<br />
<br />
<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message<br />
* copy/mark some relevant portion of text<br />
* and directly get a full cquote paragraph that you can add to the wiki here<br />
<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
a2wikilink(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapePipeAndEquals()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links, firstmost links to images (File:xxx), because<br />
// they need special treatment, or they get displayed<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(File:.*?)".*?>(.*?)<\/a>/g, "[[:$1|$2]]");<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
return html.replace(/<a.*?href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
};<br />
}<br />
<br />
// converts embedded html images to external links,<br />
// but shows them as little images if they're from the wiki<br />
function img2link() {<br />
return function(html) {<br />
html = html.replace(/<img.*?src="https?:\/\/wiki.flightgear.org\/images\/.*?\/([^\/]*?)".*?>/g, "[[File:$1|250px]]");<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(?:<cite>.*?<\/cite>)?(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// escapes characters that can be problematic inside a template. Must be used after html tags were converted, or they get messed up.<br />
function escapePipeAndEquals() {<br />
return function(html) {<br />
html = html.replace(/\|\|/g,"{{!!}}");<br />
html = html.replace(/\|\-/g,"{{!-}}");<br />
html = html.replace(/\|/g,"{{!}}");<br />
return html.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72777FlightGear wiki talk:Instant-Refs2014-06-14T17:37:58Z<p>Bigstones: /* recognizing wiki images */ oops. agreed on wiki images + notice regarding a fix for a2wikilink()</p>
<hr />
<div>== regex / sourceforge {{Done}} ==<br />
<br />
You're right - I just checked out the sourceforge archives, there's just a single <small></small> tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using '''From:''', '''<''' and '''-''' as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the '''CONFIG''' hash, maybe in addition to XPath expressions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:12, 31 May 2014 (UTC)<br />
<br />
== RX suffix {{Done}} ==<br />
<br />
That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:<br />
<br />
<syntaxhighlight language="javascript"><br />
<br />
var CONFIG = {<br />
"sourceforge.net": { <br />
author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },<br />
title: { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },<br />
date: { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },<br />
url: { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }<br />
},<br />
};<br />
</syntaxhighlight><br />
<br />
basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! <br />
Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:23, 31 May 2014 (UTC)<br />
: Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.<br />
: EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:27, 31 May 2014 (UTC)<br />
:: Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:47, 31 May 2014 (UTC)<br />
<br />
== extractInfo loop {{Done}}==<br />
<br />
I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:22, 31 May 2014 (UTC)<br />
<br />
<br />
== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Post-Processing ==<br />
=== the prepend field {{Done}} ===<br />
<br />
I would rename this to '''transform''' and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:24, 31 May 2014 (UTC)<br />
<br />
: I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:47, 31 May 2014 (UTC)<br />
<br />
=== CR/LF - br handling {{Done}} ===<br />
<br />
The whole '''transform'''/post-process idea may not be that far-fetched, I just added quite a few cquotes to the [[Canvas EFB Framework]] article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links (<nowiki>[[FOO]]</nowiki>) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <nowiki><br/></nowiki>) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 1 June 2014 (UTC)<br />
: I'll take a look at these, paragraphs are easy indeed {{Done}}.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
:: For starters, just looking for CR/LF and turning it into <nowiki><br/></nowiki> should suffice --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:30, 2 June 2014 (UTC)<br />
<br />
::: Newlines are now <nowiki><br/></nowiki>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:52, 2 June 2014 (UTC)<br />
<br />
:::: The examples below (in essence [http://wiki.flightgear.org/index.php?title=Talk:Fixing_up_articles_with_wrong_quotes&diff=72282&oldid=72281 this edit]) look like there is one line break more than usual inserted. I would think that both <tt>&lt;br/&gt;</tt> tags and the new line between the <tt>&lt;/nowiki&gt;</tt> and <tt>&lt;nowiki&gt;</tt> tags are treated as line breaks, though I am not 100% sure.<br />
:::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 04:53, 3 June 2014 (UTC)<br />
<br />
::::: I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <nowiki><p></p></nowiki> tag. Possibly it's not that hard... even a regex could probably do: <tt><nowiki>/([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s</nowiki></tt><br />
::::: (note that I don't know if the above works: what with "fake" bullet list newlines? what if only one newline is used to separate text? when should it be applied wrt other transformations?)<br />
::::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:30, 3 June 2014 (UTC)<br />
<br />
:: this looks fairly good to me, once we can also '''transform()''' the actual text selection, and maybe process the underlying HTML code to transform /some/ formatting, I'd consider the whole thing feature-complete. Functionality-wise there really isn't much that could/should be added then. And additional sources are straightforward to add anyway. Overall, this could really help to easily organize efforts that are typically spread across several months/years, because community/contributor support for certain ideas & proposals can be much better evaluated this way, even by new contributors. In fact, we could now even post-process user names, e.g. to link to their forum profile for people wanting to send a PM. So I think this will be a great tool and a huge time-saver. Thanks for all your work on this, really appreciated! BTW: I also don't really "know" JavaScript, but it looks similar enough to Nasal - and it seems you are also getting along, which also means that you may want to check out Nasal at some point :-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:49, 3 June 2014 (UTC)<br />
<br />
=== retained formatting {{Done}} ===<br />
<br />
: I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?<br />
:--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
<br />
:: <del>I don't think</del> we need to copy the HTML content[http://blog.ssokolow.com/archives/2008/12/03/getting-the-selected-text-as-html-using-javascript/comment-page-1/] - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [http://stackoverflow.com/questions/5643635/how-to-get-selected-html-text-with-javascript][http://stackoverflow.com/questions/6251937/how-to-get-selecteduser-highlighted-text-in-contenteditable-element-and-replac][http://stackoverflow.com/a/5670825], e.g. <nowiki><a href=""></a></nowiki> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as '''postlink''' (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <nowiki><ul> <li>...</li> </ul></nowiki>. Looking for images doesn't make too much sense unless those are wiki-hosted, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into <nowiki>{{#ev:youtube|VIDEO_ID}}</nowiki> markup - either through youtube.com URLs. Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:18, 2 June 2014 (UTC)<br />
<br />
::: Ok, I made some support for HTML. I copied a function to get the selected HTML from stackoverflow, then used it on the forum and made up some transform operators. A couple need some attention (especially the syntaxhighlight one). Some have a funny behaviour: try to cquote [http://forum.flightgear.org/viewtopic.php?p=211670#p211670 this post], and you'll see that the image will correctly become a link, while the link will be fully shown as an image. That's because it gets converted to an internal link, and the wiki knows that's an image. Then, I'm not sure if nested quotes are actually a smart thing, and I didn't make the list converter because I couldn't find an example.<br />
::: Not much else to say. Have fun :)<br />
::: EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:16, 8 June 2014 (UTC)<br />
<br />
:: This is pretty cool, and impressive how this has evolved so quickly - I agree that nested quotes are probably too tricky. I think conversion of URLs and youtube links should be a good start. Converting lists should be fairly straightforward now, BTW: here's a posting containing a list[http://forum.flightgear.org/viewtopic.php?f=71&t=23241#p212029]. Thanks again for your work on this !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:43, 8 June 2014 (UTC)<br />
<br />
::: Hi Hooray, I saw your latest cquotes, didn't you "upgrade" to the last version of the script? It's working already, with links, formatting, and nested quotes if one will. Actually, even lists work, because now it copies the HTML and they work even without converting them to the wiki formatting.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:26, 11 June 2014 (UTC)<br />
<br />
: oops, good spotting: using a different computer and browser at the moment, need to upgrade obviously. Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
=== selection processing {{Done}} ===<br />
I think we really only need to add another "content" key that is mapped to GetSelectedText() and then use a '''transform()''' field that can post-process the selection, that is then also where newline replacement, and other content processing would take place. That way we can even replace common acronyms using their wiki equivalents, e.g. [[$FG ROOT]], [[Nasal]] so that quotes would become a bit more self-explanatory --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:55, 3 June 2014 (UTC)<br />
: Two+1 observations on [http://wiki.flightgear.org/index.php?title=Fixing_up_articles_with_wrong_quotes&diff=prev&oldid=72316 latest changes]: 1) I considered GetSelectedText() the "main()" of the script, why would I want to configure that? 2) I see transform() happening in both extractInfo() and GetSelectedText(), is that in preparation to have extractInfo() extract also the content? 3) I didn't think of the transform option that way, it's way cleaner than I thought, we could even make a "pipe()" to serialize different make_xxx() operators! At this point, also the regex could be one of such operators.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:51, 3 June 2014 (UTC)<br />
<br />
:: Those are indeed all very good points, and I was actually aware of them. I really just wanted to "establish the separation" here. It is true that there are now some workarounds in place that are not exactly "a good design". It just seemed simple enough for me, and I was going to volunteer to clean it up once the key functionality is in place. GetSelectedText() is indeed the main work-horse, I just prepared it to become customizable wearing my "Architecture Astronaut" hat :-) And like you say, generalizing extractInfo() seemed like a good idea to me at the time, which is why the workhorse is now specified via the CONFIG hash (despite probably not having to be there). It is probably over-engineering things, but I just wanted to establish the infrastructure to turn everything into a chain of steps that can be mostly configured through just the CONFIG hash. It is awesome that you can see the potential of that, because I fully realized that it may seem "odd" at first glance and maybe too involved. But my goal really is to move all those processing steps into the CONFIG hash, so that we can trivially add other functionality, without having to touch those other functions. I like the whole pipe/cascade analogy very much, it could be just a vector of different transformations applied in order! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:05, 3 June 2014 (UTC)<br />
<br />
::: work in progress... towards 0.8<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:58, 5 June 2014 (UTC)<br />
::: Done. Huge refactoring (I hope you like the style, overall the fact that I use to put "inner" functions after they're used, trusting in a hopefully meaningful name) and "transform" works properly for fields and contents (formally, "content" is one of the fields of "info" now).<br />
::: For the format of the contents, I made it so that you can get either text or (later) html, but that way one can't rely on using the structure of html (xpaths), right now. I know that [http://stackoverflow.com/a/1732454 parsing html with regexes is bad] (btw, I didn't know that Architecture Astronaut thing :) ), but hopefully for a short piece of text it will do?<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:25, 5 June 2014 (UTC)<br />
<br />
:: Looking good here. Regarding your comments/FIXMEs, I agree that the non-conditional nowiki-escaping is a hack, but to do it the proper way would require parsing the blob for nowiki tags, and keeping track of how many open tags there (i.e. using a stack). Stuff like newline2br could probably also be turned into a transformation callback now, thanks to your changes. Changing the order of functions to make them appear sequentially makes sense, I just didn't do it because JS also works without doing it, but I agree that it's now more readable. Regarding reliance on xpath expressions, that's true - but we only use those "ONCE" for each quote. And created quotes won't break - but you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. We'll see how this evolves over time. At least URLs and youtube URLs/videos can be easily processed and could be turned into wiki markup, so that we can easily reuse forum & devel list postings to help populate the newsletter and other wiki articles. Again, thanks for your work on this, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:51, 5 June 2014 (UTC)<br />
<br />
=== HTML handling and Escaping {{Done}} ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote - I think there are also some issues related to the lack of nowiki-escaping now, i.e. see the "Issues" section below. But like I said elsewhere, to do this properly, we'd need to maintain a stack of nowiki tags, so that we know how deeply those are nested and unescape properly.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:11, 12 June 2014 (UTC)<br />
: Bug reports, exciting :) newline2br is not used anymore in the forum, because the br's are already there in the copied html, and phpBB seems to be printing br without slash (does it? I can't verify now, but I can't figure what would remove them in the script.)<br />
: I played a bit with the broken quote ("Issues") and I really can't understand what's wrong. I added back the slashes in the br's, put a newline after them, no change... and there are no strange characters apparently (could it be some non printable character? might be worth to paste that stuff into a hex editor? Philosopher found something like that recently, can't remember where) Obviously nowiki-escaping all the quote works, but I really don't see what should be escaped there.<br />
: It's funny also that it puts the author in place of the quote (if you look well, the position and font is that of the quote) so it must be the template that gets confused somehow. But one thing's sure: it looks very similar to what happens when enabling the conversion of code blocks, so they might be related.<br />
: I'll be busy in the next days, very busy until monday at least... so it'll take me some time to get back to this.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:49, 12 June 2014 (UTC)<br />
<br />
:: Now that you mention it: I saw that being the case with other templates containing certain URLs, including the stub/note templates. So I just tried it myself and it is indeed the embedded youtube URL causing this here. I guess the <nowiki>#</nowiki> character or URL-encoding could be contributing to this --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:56, 12 June 2014 (UTC)<br />
<br />
::: confirmed: it's the equal sign (=) confusing the template parser, probably because it is trying to do argument assignment or something like that. We could probably introduce a new URL template to handle such things, or simply use the youtube embedding code instead in this case. Also see [http://en.wikipedia.org/wiki/Help:Template#Usage_hints_and_workarounds] and [http://en.wikipedia.org/wiki/Template:URL] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:01, 12 June 2014 (UTC)<br />
<br />
:::: That was fast, thanks! This seem to fix also the problem with code snippets, which was a pity to miss. I'll add an operator for those special characters too, and using the URL template is straightforward and should be safer for all the external links. I hope this saves us from the nowiki escape thing (at least for a while.)<br />
:::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:55, 12 June 2014 (UTC)<br />
<br />
:::: Working on this... will commit something before going to bed. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:55, 13 June 2014 (UTC)<br />
<br />
:::: Uhm, kind of done but I'm not satisfied with the code snippet quoting. It's not nice to have escaped stuff and unreadable "wiki source"... anyway, youtube links work fine. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
== example ==<br />
{{cquote<br />
|<nowiki>This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the prope... do. I don't consider this to be coding but others may not agree.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>YIKES !!!Hey guys, I love flying the A330-223 BUT as soon as I wanna intercept the LOC my plane starts to shake like crazy. I was following the youtube Tutorial step by step but I CANT land with ILS. No Autoland nothing.. </nowiki><br/><nowiki><br />
Does anyone know why, On the Flightgear Wiki there are 4 Videos of the custom flight from EDDF (Frankfurt) to EDDM (Munich). But in Germany we CANT watch Video No. 4 (Approach and Autoland) .. because of the music in the video. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=188233#p188233<br />
|title=<nowiki>ILS-Problem on Airbus A330-223</nowiki><br />
|author=<nowiki>henrysean84</nowiki><br />
|date=<nowiki>Mon Aug 05</nowiki><br />
}}<br />
}}<br />
<br />
== testing CR/LF conversion ==<br />
<br />
{{cquote<br />
|<nowiki>I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211086#p211086<br />
|title=<nowiki>Re: Aircraft Rating System</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I think we have usually not deleted textures when introducing a new variant, because good GPL-compatible terrain textures are hard to come by and hence a useful resource. In particular, I remember 'reviving' some nominally obsolete textures as overlays, or in some particular regional context - for regional texturing projects, having lots of varieties is actually invaluable. I would even go as far as trying to commit good textures without an immediate use.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So I guess the bottomline is that we wouldn't necessarily want to ship these textures with the base package, but we would like to have them on a devel repository.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32405025/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>What a muddle...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
There's a whole bunch of different cases in there.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) Duplicate 'winter'-textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Apparently, when creating the winter scheme, all summer textures were copied over and the ones where adding snow makes sense got snow - the rest were just kept. For instance, Terrain.winter/tidal.png is just a copy of Terrain/tidal.png, Terrain.winter/rocks-desert.png is just a copy of Terrain./rocks-desert.png and so on. I think in these cases the duplicate can simply go. Since they're as a rule tiny textures, we don't necessarily gain much.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2) dds-converted unused textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
It would seem (perhaps one of the people involved can confirm that) that in the first version of the dds texturing schemes all existing textures were automatically converted...extures for effects which have since been changed to png for compatibility reasons possibly belong into the same category, Water/bowwave_normal.dds would be an example for this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3) Unused unique png textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
As argued previously, these we should store, possibly in 'unused'. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
4) Unique dds textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Things like Terrain/limestone2.dds are somewhat annoying, as they might be perfectly good texture templates which can't easily be edited or put to use as a png version of the same texture could be, and in addition they aren''t actually used inside the dds scheme. </nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32406658/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-02</nowiki><br />
}}<br />
}}<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
:: right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 13 June 2014 (UTC)<br />
<br />
== Testing 0.9 ==<br />
<br />
{{FGCquote<br />
|Also, we must take into account the different dynamic range and color temperature of the human vision, cameras and computer monitors. "Closer to reality" means completely different if "reality" is "the actual physical properties of the light", "what our eyes capture/brain interprets giving the current lighting conditions" or "what our monitor can really represent". Punkepanda can find an introduction to this extremely complex issue in this link: [http://www.cambridgeincolour.com/tutorials/dynamic-range.htm http://www.cambridgeincolour.com/tutori ... -range.htm]<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212412#p212412<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>ludomotico</nowiki><br />
|date=<nowiki>Thu Jun 12</nowiki><br />
}}<br />
}}<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}<br />
<br />
=== recognizing wiki images ===<br />
<br />
I just tested the script using one of my recent forum postings:<br />
{{cquote<br />
|<blockquote><div><cite>RevHardt wrote in [[MapStructure#Porting_the_map_dialog|http://wiki.flightgear.org/MapStructure ... map_dialog]]<br>(see the [http://wiki.flightgear.org/images/5/5f/MapStructureDialog.png linked image]) <br><br>You can basically create arbitrary layers, even for custom objects/positions:<br>(see the [http://wiki.flightgear.org/images/d/d7/Map-canvas-chain-home-editor.png linked image])<br><br>The same method can be used for creating a "live" radar display:<br>[[Canvas_Radar|http://wiki.flightgear.org/Canvas_Radar]]<br>(see the [http://wiki.flightgear.org/images/b/bf/MapStructure-TFC-Troubleshooting.png linked image])<br><br>But maps and layers can be fairly sophisticated, too - all 100% scripted:<br>[[FlightGear_Newsletter_May_2014#A_Canvas-based_Map_dialog|http://wiki.flightgear.org/FlightGear_N ... Map_dialog]]<br>(see the [http://wiki.flightgear.org/images/7/78/Map-canvas-dialog-storms-overlay.png linked image])<br><br>As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure <br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212558#p212558<br />
|title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sat Jun 14</nowiki><br />
}}<br />
}}<br />
<br />
I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:45, 14 June 2014 (UTC)<br />
<br />
: Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <nowiki><cite>RevHardt...</nowiki> part.)<br />
: Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image ''pages'' (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.<br />
: One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.<br />
: (Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:37, 14 June 2014 (UTC)</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72730FlightGear wiki talk:Instant-Refs2014-06-13T22:30:58Z<p>Bigstones: /* selection/clipboard buffer or alert() limits ? */ no, you can't edit the clipboard</p>
<hr />
<div>== regex / sourceforge {{Done}} ==<br />
<br />
You're right - I just checked out the sourceforge archives, there's just a single <small></small> tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using '''From:''', '''<''' and '''-''' as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the '''CONFIG''' hash, maybe in addition to XPath expressions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:12, 31 May 2014 (UTC)<br />
<br />
== RX suffix {{Done}} ==<br />
<br />
That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:<br />
<br />
<syntaxhighlight language="javascript"><br />
<br />
var CONFIG = {<br />
"sourceforge.net": { <br />
author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },<br />
title: { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },<br />
date: { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },<br />
url: { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }<br />
},<br />
};<br />
</syntaxhighlight><br />
<br />
basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! <br />
Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:23, 31 May 2014 (UTC)<br />
: Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.<br />
: EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:27, 31 May 2014 (UTC)<br />
:: Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:47, 31 May 2014 (UTC)<br />
<br />
== extractInfo loop {{Done}}==<br />
<br />
I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:22, 31 May 2014 (UTC)<br />
<br />
<br />
== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Post-Processing ==<br />
=== the prepend field {{Done}} ===<br />
<br />
I would rename this to '''transform''' and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:24, 31 May 2014 (UTC)<br />
<br />
: I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:47, 31 May 2014 (UTC)<br />
<br />
=== CR/LF - br handling {{Done}} ===<br />
<br />
The whole '''transform'''/post-process idea may not be that far-fetched, I just added quite a few cquotes to the [[Canvas EFB Framework]] article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links (<nowiki>[[FOO]]</nowiki>) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <nowiki><br/></nowiki>) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 1 June 2014 (UTC)<br />
: I'll take a look at these, paragraphs are easy indeed {{Done}}.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
:: For starters, just looking for CR/LF and turning it into <nowiki><br/></nowiki> should suffice --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:30, 2 June 2014 (UTC)<br />
<br />
::: Newlines are now <nowiki><br/></nowiki>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:52, 2 June 2014 (UTC)<br />
<br />
:::: The examples below (in essence [http://wiki.flightgear.org/index.php?title=Talk:Fixing_up_articles_with_wrong_quotes&diff=72282&oldid=72281 this edit]) look like there is one line break more than usual inserted. I would think that both <tt>&lt;br/&gt;</tt> tags and the new line between the <tt>&lt;/nowiki&gt;</tt> and <tt>&lt;nowiki&gt;</tt> tags are treated as line breaks, though I am not 100% sure.<br />
:::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 04:53, 3 June 2014 (UTC)<br />
<br />
::::: I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <nowiki><p></p></nowiki> tag. Possibly it's not that hard... even a regex could probably do: <tt><nowiki>/([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s</nowiki></tt><br />
::::: (note that I don't know if the above works: what with "fake" bullet list newlines? what if only one newline is used to separate text? when should it be applied wrt other transformations?)<br />
::::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:30, 3 June 2014 (UTC)<br />
<br />
:: this looks fairly good to me, once we can also '''transform()''' the actual text selection, and maybe process the underlying HTML code to transform /some/ formatting, I'd consider the whole thing feature-complete. Functionality-wise there really isn't much that could/should be added then. And additional sources are straightforward to add anyway. Overall, this could really help to easily organize efforts that are typically spread across several months/years, because community/contributor support for certain ideas & proposals can be much better evaluated this way, even by new contributors. In fact, we could now even post-process user names, e.g. to link to their forum profile for people wanting to send a PM. So I think this will be a great tool and a huge time-saver. Thanks for all your work on this, really appreciated! BTW: I also don't really "know" JavaScript, but it looks similar enough to Nasal - and it seems you are also getting along, which also means that you may want to check out Nasal at some point :-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:49, 3 June 2014 (UTC)<br />
<br />
=== retained formatting {{Done}} ===<br />
<br />
: I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?<br />
:--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
<br />
:: <del>I don't think</del> we need to copy the HTML content[http://blog.ssokolow.com/archives/2008/12/03/getting-the-selected-text-as-html-using-javascript/comment-page-1/] - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [http://stackoverflow.com/questions/5643635/how-to-get-selected-html-text-with-javascript][http://stackoverflow.com/questions/6251937/how-to-get-selecteduser-highlighted-text-in-contenteditable-element-and-replac][http://stackoverflow.com/a/5670825], e.g. <nowiki><a href=""></a></nowiki> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as '''postlink''' (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <nowiki><ul> <li>...</li> </ul></nowiki>. Looking for images doesn't make too much sense unless those are wiki-hosted, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into <nowiki>{{#ev:youtube|VIDEO_ID}}</nowiki> markup - either through youtube.com URLs. Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:18, 2 June 2014 (UTC)<br />
<br />
::: Ok, I made some support for HTML. I copied a function to get the selected HTML from stackoverflow, then used it on the forum and made up some transform operators. A couple need some attention (especially the syntaxhighlight one). Some have a funny behaviour: try to cquote [http://forum.flightgear.org/viewtopic.php?p=211670#p211670 this post], and you'll see that the image will correctly become a link, while the link will be fully shown as an image. That's because it gets converted to an internal link, and the wiki knows that's an image. Then, I'm not sure if nested quotes are actually a smart thing, and I didn't make the list converter because I couldn't find an example.<br />
::: Not much else to say. Have fun :)<br />
::: EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:16, 8 June 2014 (UTC)<br />
<br />
:: This is pretty cool, and impressive how this has evolved so quickly - I agree that nested quotes are probably too tricky. I think conversion of URLs and youtube links should be a good start. Converting lists should be fairly straightforward now, BTW: here's a posting containing a list[http://forum.flightgear.org/viewtopic.php?f=71&t=23241#p212029]. Thanks again for your work on this !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:43, 8 June 2014 (UTC)<br />
<br />
::: Hi Hooray, I saw your latest cquotes, didn't you "upgrade" to the last version of the script? It's working already, with links, formatting, and nested quotes if one will. Actually, even lists work, because now it copies the HTML and they work even without converting them to the wiki formatting.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:26, 11 June 2014 (UTC)<br />
<br />
: oops, good spotting: using a different computer and browser at the moment, need to upgrade obviously. Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
=== selection processing {{Done}} ===<br />
I think we really only need to add another "content" key that is mapped to GetSelectedText() and then use a '''transform()''' field that can post-process the selection, that is then also where newline replacement, and other content processing would take place. That way we can even replace common acronyms using their wiki equivalents, e.g. [[$FG ROOT]], [[Nasal]] so that quotes would become a bit more self-explanatory --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:55, 3 June 2014 (UTC)<br />
: Two+1 observations on [http://wiki.flightgear.org/index.php?title=Fixing_up_articles_with_wrong_quotes&diff=prev&oldid=72316 latest changes]: 1) I considered GetSelectedText() the "main()" of the script, why would I want to configure that? 2) I see transform() happening in both extractInfo() and GetSelectedText(), is that in preparation to have extractInfo() extract also the content? 3) I didn't think of the transform option that way, it's way cleaner than I thought, we could even make a "pipe()" to serialize different make_xxx() operators! At this point, also the regex could be one of such operators.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:51, 3 June 2014 (UTC)<br />
<br />
:: Those are indeed all very good points, and I was actually aware of them. I really just wanted to "establish the separation" here. It is true that there are now some workarounds in place that are not exactly "a good design". It just seemed simple enough for me, and I was going to volunteer to clean it up once the key functionality is in place. GetSelectedText() is indeed the main work-horse, I just prepared it to become customizable wearing my "Architecture Astronaut" hat :-) And like you say, generalizing extractInfo() seemed like a good idea to me at the time, which is why the workhorse is now specified via the CONFIG hash (despite probably not having to be there). It is probably over-engineering things, but I just wanted to establish the infrastructure to turn everything into a chain of steps that can be mostly configured through just the CONFIG hash. It is awesome that you can see the potential of that, because I fully realized that it may seem "odd" at first glance and maybe too involved. But my goal really is to move all those processing steps into the CONFIG hash, so that we can trivially add other functionality, without having to touch those other functions. I like the whole pipe/cascade analogy very much, it could be just a vector of different transformations applied in order! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:05, 3 June 2014 (UTC)<br />
<br />
::: work in progress... towards 0.8<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:58, 5 June 2014 (UTC)<br />
::: Done. Huge refactoring (I hope you like the style, overall the fact that I use to put "inner" functions after they're used, trusting in a hopefully meaningful name) and "transform" works properly for fields and contents (formally, "content" is one of the fields of "info" now).<br />
::: For the format of the contents, I made it so that you can get either text or (later) html, but that way one can't rely on using the structure of html (xpaths), right now. I know that [http://stackoverflow.com/a/1732454 parsing html with regexes is bad] (btw, I didn't know that Architecture Astronaut thing :) ), but hopefully for a short piece of text it will do?<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:25, 5 June 2014 (UTC)<br />
<br />
:: Looking good here. Regarding your comments/FIXMEs, I agree that the non-conditional nowiki-escaping is a hack, but to do it the proper way would require parsing the blob for nowiki tags, and keeping track of how many open tags there (i.e. using a stack). Stuff like newline2br could probably also be turned into a transformation callback now, thanks to your changes. Changing the order of functions to make them appear sequentially makes sense, I just didn't do it because JS also works without doing it, but I agree that it's now more readable. Regarding reliance on xpath expressions, that's true - but we only use those "ONCE" for each quote. And created quotes won't break - but you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. We'll see how this evolves over time. At least URLs and youtube URLs/videos can be easily processed and could be turned into wiki markup, so that we can easily reuse forum & devel list postings to help populate the newsletter and other wiki articles. Again, thanks for your work on this, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:51, 5 June 2014 (UTC)<br />
<br />
=== HTML handling and Escaping {{Done}} ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote - I think there are also some issues related to the lack of nowiki-escaping now, i.e. see the "Issues" section below. But like I said elsewhere, to do this properly, we'd need to maintain a stack of nowiki tags, so that we know how deeply those are nested and unescape properly.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:11, 12 June 2014 (UTC)<br />
: Bug reports, exciting :) newline2br is not used anymore in the forum, because the br's are already there in the copied html, and phpBB seems to be printing br without slash (does it? I can't verify now, but I can't figure what would remove them in the script.)<br />
: I played a bit with the broken quote ("Issues") and I really can't understand what's wrong. I added back the slashes in the br's, put a newline after them, no change... and there are no strange characters apparently (could it be some non printable character? might be worth to paste that stuff into a hex editor? Philosopher found something like that recently, can't remember where) Obviously nowiki-escaping all the quote works, but I really don't see what should be escaped there.<br />
: It's funny also that it puts the author in place of the quote (if you look well, the position and font is that of the quote) so it must be the template that gets confused somehow. But one thing's sure: it looks very similar to what happens when enabling the conversion of code blocks, so they might be related.<br />
: I'll be busy in the next days, very busy until monday at least... so it'll take me some time to get back to this.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:49, 12 June 2014 (UTC)<br />
<br />
:: Now that you mention it: I saw that being the case with other templates containing certain URLs, including the stub/note templates. So I just tried it myself and it is indeed the embedded youtube URL causing this here. I guess the <nowiki>#</nowiki> character or URL-encoding could be contributing to this --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:56, 12 June 2014 (UTC)<br />
<br />
::: confirmed: it's the equal sign (=) confusing the template parser, probably because it is trying to do argument assignment or something like that. We could probably introduce a new URL template to handle such things, or simply use the youtube embedding code instead in this case. Also see [http://en.wikipedia.org/wiki/Help:Template#Usage_hints_and_workarounds] and [http://en.wikipedia.org/wiki/Template:URL] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:01, 12 June 2014 (UTC)<br />
<br />
:::: That was fast, thanks! This seem to fix also the problem with code snippets, which was a pity to miss. I'll add an operator for those special characters too, and using the URL template is straightforward and should be safer for all the external links. I hope this saves us from the nowiki escape thing (at least for a while.)<br />
:::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:55, 12 June 2014 (UTC)<br />
<br />
:::: Working on this... will commit something before going to bed. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:55, 13 June 2014 (UTC)<br />
<br />
:::: Uhm, kind of done but I'm not satisfied with the code snippet quoting. It's not nice to have escaped stuff and unreadable "wiki source"... anyway, youtube links work fine. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
== example ==<br />
{{cquote<br />
|<nowiki>This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the prope... do. I don't consider this to be coding but others may not agree.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>YIKES !!!Hey guys, I love flying the A330-223 BUT as soon as I wanna intercept the LOC my plane starts to shake like crazy. I was following the youtube Tutorial step by step but I CANT land with ILS. No Autoland nothing.. </nowiki><br/><nowiki><br />
Does anyone know why, On the Flightgear Wiki there are 4 Videos of the custom flight from EDDF (Frankfurt) to EDDM (Munich). But in Germany we CANT watch Video No. 4 (Approach and Autoland) .. because of the music in the video. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=188233#p188233<br />
|title=<nowiki>ILS-Problem on Airbus A330-223</nowiki><br />
|author=<nowiki>henrysean84</nowiki><br />
|date=<nowiki>Mon Aug 05</nowiki><br />
}}<br />
}}<br />
<br />
== testing CR/LF conversion ==<br />
<br />
{{cquote<br />
|<nowiki>I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211086#p211086<br />
|title=<nowiki>Re: Aircraft Rating System</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I think we have usually not deleted textures when introducing a new variant, because good GPL-compatible terrain textures are hard to come by and hence a useful resource. In particular, I remember 'reviving' some nominally obsolete textures as overlays, or in some particular regional context - for regional texturing projects, having lots of varieties is actually invaluable. I would even go as far as trying to commit good textures without an immediate use.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So I guess the bottomline is that we wouldn't necessarily want to ship these textures with the base package, but we would like to have them on a devel repository.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32405025/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>What a muddle...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
There's a whole bunch of different cases in there.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) Duplicate 'winter'-textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Apparently, when creating the winter scheme, all summer textures were copied over and the ones where adding snow makes sense got snow - the rest were just kept. For instance, Terrain.winter/tidal.png is just a copy of Terrain/tidal.png, Terrain.winter/rocks-desert.png is just a copy of Terrain./rocks-desert.png and so on. I think in these cases the duplicate can simply go. Since they're as a rule tiny textures, we don't necessarily gain much.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2) dds-converted unused textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
It would seem (perhaps one of the people involved can confirm that) that in the first version of the dds texturing schemes all existing textures were automatically converted...extures for effects which have since been changed to png for compatibility reasons possibly belong into the same category, Water/bowwave_normal.dds would be an example for this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3) Unused unique png textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
As argued previously, these we should store, possibly in 'unused'. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
4) Unique dds textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Things like Terrain/limestone2.dds are somewhat annoying, as they might be perfectly good texture templates which can't easily be edited or put to use as a png version of the same texture could be, and in addition they aren''t actually used inside the dds scheme. </nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32406658/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-02</nowiki><br />
}}<br />
}}<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a [http://stackoverflow.com/a/6055620 security issue]. <br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
== Testing 0.9 ==<br />
<br />
{{FGCquote<br />
|Also, we must take into account the different dynamic range and color temperature of the human vision, cameras and computer monitors. "Closer to reality" means completely different if "reality" is "the actual physical properties of the light", "what our eyes capture/brain interprets giving the current lighting conditions" or "what our monitor can really represent". Punkepanda can find an introduction to this extremely complex issue in this link: [http://www.cambridgeincolour.com/tutorials/dynamic-range.htm http://www.cambridgeincolour.com/tutori ... -range.htm]<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212412#p212412<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>ludomotico</nowiki><br />
|date=<nowiki>Thu Jun 12</nowiki><br />
}}<br />
}}<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72728FlightGear wiki:Instant-Refs2014-06-13T22:07:02Z<p>Bigstones: fixed FGCquote in the code</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.}}<br />
<br />
<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message<br />
* copy/mark some relevant portion of text<br />
* and directly get a full cquote paragraph that you can add to the wiki here<br />
<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
a2wikilink(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapePipeAndEquals()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links<br />
// -- WARNING: if it's a link to a wiki file (wiki.fg.org/File:xxx), it will become a shown image<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
return html.replace(/<a.*?href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
};<br />
}<br />
<br />
// converts embedded html images to external links<br />
function img2link() {<br />
return function(html) {<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// escapes characters that can be problematic inside a template. Must be used after html tags were converted, or they get messed up.<br />
function escapePipeAndEquals() {<br />
return function(html) {<br />
html = html.replace(/\|\|/g,"{{!!}}");<br />
html = html.replace(/\|\-/g,"{{!-}}");<br />
html = html.replace(/\|/g,"{{!}}");<br />
return html.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{FGCquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72727FlightGear wiki talk:Instant-Refs2014-06-13T22:02:51Z<p>Bigstones: a bit of cleanup, updates and answers</p>
<hr />
<div>== regex / sourceforge {{Done}} ==<br />
<br />
You're right - I just checked out the sourceforge archives, there's just a single <small></small> tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using '''From:''', '''<''' and '''-''' as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the '''CONFIG''' hash, maybe in addition to XPath expressions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:12, 31 May 2014 (UTC)<br />
<br />
== RX suffix {{Done}} ==<br />
<br />
That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:<br />
<br />
<syntaxhighlight language="javascript"><br />
<br />
var CONFIG = {<br />
"sourceforge.net": { <br />
author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },<br />
title: { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },<br />
date: { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },<br />
url: { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }<br />
},<br />
};<br />
</syntaxhighlight><br />
<br />
basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! <br />
Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:23, 31 May 2014 (UTC)<br />
: Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.<br />
: EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:27, 31 May 2014 (UTC)<br />
:: Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:47, 31 May 2014 (UTC)<br />
<br />
== extractInfo loop {{Done}}==<br />
<br />
I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:22, 31 May 2014 (UTC)<br />
<br />
<br />
== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Post-Processing ==<br />
=== the prepend field {{Done}} ===<br />
<br />
I would rename this to '''transform''' and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:24, 31 May 2014 (UTC)<br />
<br />
: I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:47, 31 May 2014 (UTC)<br />
<br />
=== CR/LF - br handling {{Done}} ===<br />
<br />
The whole '''transform'''/post-process idea may not be that far-fetched, I just added quite a few cquotes to the [[Canvas EFB Framework]] article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links (<nowiki>[[FOO]]</nowiki>) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <nowiki><br/></nowiki>) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 1 June 2014 (UTC)<br />
: I'll take a look at these, paragraphs are easy indeed {{Done}}.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
:: For starters, just looking for CR/LF and turning it into <nowiki><br/></nowiki> should suffice --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:30, 2 June 2014 (UTC)<br />
<br />
::: Newlines are now <nowiki><br/></nowiki>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:52, 2 June 2014 (UTC)<br />
<br />
:::: The examples below (in essence [http://wiki.flightgear.org/index.php?title=Talk:Fixing_up_articles_with_wrong_quotes&diff=72282&oldid=72281 this edit]) look like there is one line break more than usual inserted. I would think that both <tt>&lt;br/&gt;</tt> tags and the new line between the <tt>&lt;/nowiki&gt;</tt> and <tt>&lt;nowiki&gt;</tt> tags are treated as line breaks, though I am not 100% sure.<br />
:::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 04:53, 3 June 2014 (UTC)<br />
<br />
::::: I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <nowiki><p></p></nowiki> tag. Possibly it's not that hard... even a regex could probably do: <tt><nowiki>/([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s</nowiki></tt><br />
::::: (note that I don't know if the above works: what with "fake" bullet list newlines? what if only one newline is used to separate text? when should it be applied wrt other transformations?)<br />
::::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:30, 3 June 2014 (UTC)<br />
<br />
:: this looks fairly good to me, once we can also '''transform()''' the actual text selection, and maybe process the underlying HTML code to transform /some/ formatting, I'd consider the whole thing feature-complete. Functionality-wise there really isn't much that could/should be added then. And additional sources are straightforward to add anyway. Overall, this could really help to easily organize efforts that are typically spread across several months/years, because community/contributor support for certain ideas & proposals can be much better evaluated this way, even by new contributors. In fact, we could now even post-process user names, e.g. to link to their forum profile for people wanting to send a PM. So I think this will be a great tool and a huge time-saver. Thanks for all your work on this, really appreciated! BTW: I also don't really "know" JavaScript, but it looks similar enough to Nasal - and it seems you are also getting along, which also means that you may want to check out Nasal at some point :-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:49, 3 June 2014 (UTC)<br />
<br />
=== retained formatting {{Done}} ===<br />
<br />
: I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?<br />
:--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
<br />
:: <del>I don't think</del> we need to copy the HTML content[http://blog.ssokolow.com/archives/2008/12/03/getting-the-selected-text-as-html-using-javascript/comment-page-1/] - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [http://stackoverflow.com/questions/5643635/how-to-get-selected-html-text-with-javascript][http://stackoverflow.com/questions/6251937/how-to-get-selecteduser-highlighted-text-in-contenteditable-element-and-replac][http://stackoverflow.com/a/5670825], e.g. <nowiki><a href=""></a></nowiki> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as '''postlink''' (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <nowiki><ul> <li>...</li> </ul></nowiki>. Looking for images doesn't make too much sense unless those are wiki-hosted, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into <nowiki>{{#ev:youtube|VIDEO_ID}}</nowiki> markup - either through youtube.com URLs. Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:18, 2 June 2014 (UTC)<br />
<br />
::: Ok, I made some support for HTML. I copied a function to get the selected HTML from stackoverflow, then used it on the forum and made up some transform operators. A couple need some attention (especially the syntaxhighlight one). Some have a funny behaviour: try to cquote [http://forum.flightgear.org/viewtopic.php?p=211670#p211670 this post], and you'll see that the image will correctly become a link, while the link will be fully shown as an image. That's because it gets converted to an internal link, and the wiki knows that's an image. Then, I'm not sure if nested quotes are actually a smart thing, and I didn't make the list converter because I couldn't find an example.<br />
::: Not much else to say. Have fun :)<br />
::: EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:16, 8 June 2014 (UTC)<br />
<br />
:: This is pretty cool, and impressive how this has evolved so quickly - I agree that nested quotes are probably too tricky. I think conversion of URLs and youtube links should be a good start. Converting lists should be fairly straightforward now, BTW: here's a posting containing a list[http://forum.flightgear.org/viewtopic.php?f=71&t=23241#p212029]. Thanks again for your work on this !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:43, 8 June 2014 (UTC)<br />
<br />
::: Hi Hooray, I saw your latest cquotes, didn't you "upgrade" to the last version of the script? It's working already, with links, formatting, and nested quotes if one will. Actually, even lists work, because now it copies the HTML and they work even without converting them to the wiki formatting.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:26, 11 June 2014 (UTC)<br />
<br />
: oops, good spotting: using a different computer and browser at the moment, need to upgrade obviously. Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
=== selection processing {{Done}} ===<br />
I think we really only need to add another "content" key that is mapped to GetSelectedText() and then use a '''transform()''' field that can post-process the selection, that is then also where newline replacement, and other content processing would take place. That way we can even replace common acronyms using their wiki equivalents, e.g. [[$FG ROOT]], [[Nasal]] so that quotes would become a bit more self-explanatory --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:55, 3 June 2014 (UTC)<br />
: Two+1 observations on [http://wiki.flightgear.org/index.php?title=Fixing_up_articles_with_wrong_quotes&diff=prev&oldid=72316 latest changes]: 1) I considered GetSelectedText() the "main()" of the script, why would I want to configure that? 2) I see transform() happening in both extractInfo() and GetSelectedText(), is that in preparation to have extractInfo() extract also the content? 3) I didn't think of the transform option that way, it's way cleaner than I thought, we could even make a "pipe()" to serialize different make_xxx() operators! At this point, also the regex could be one of such operators.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:51, 3 June 2014 (UTC)<br />
<br />
:: Those are indeed all very good points, and I was actually aware of them. I really just wanted to "establish the separation" here. It is true that there are now some workarounds in place that are not exactly "a good design". It just seemed simple enough for me, and I was going to volunteer to clean it up once the key functionality is in place. GetSelectedText() is indeed the main work-horse, I just prepared it to become customizable wearing my "Architecture Astronaut" hat :-) And like you say, generalizing extractInfo() seemed like a good idea to me at the time, which is why the workhorse is now specified via the CONFIG hash (despite probably not having to be there). It is probably over-engineering things, but I just wanted to establish the infrastructure to turn everything into a chain of steps that can be mostly configured through just the CONFIG hash. It is awesome that you can see the potential of that, because I fully realized that it may seem "odd" at first glance and maybe too involved. But my goal really is to move all those processing steps into the CONFIG hash, so that we can trivially add other functionality, without having to touch those other functions. I like the whole pipe/cascade analogy very much, it could be just a vector of different transformations applied in order! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:05, 3 June 2014 (UTC)<br />
<br />
::: work in progress... towards 0.8<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:58, 5 June 2014 (UTC)<br />
::: Done. Huge refactoring (I hope you like the style, overall the fact that I use to put "inner" functions after they're used, trusting in a hopefully meaningful name) and "transform" works properly for fields and contents (formally, "content" is one of the fields of "info" now).<br />
::: For the format of the contents, I made it so that you can get either text or (later) html, but that way one can't rely on using the structure of html (xpaths), right now. I know that [http://stackoverflow.com/a/1732454 parsing html with regexes is bad] (btw, I didn't know that Architecture Astronaut thing :) ), but hopefully for a short piece of text it will do?<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:25, 5 June 2014 (UTC)<br />
<br />
:: Looking good here. Regarding your comments/FIXMEs, I agree that the non-conditional nowiki-escaping is a hack, but to do it the proper way would require parsing the blob for nowiki tags, and keeping track of how many open tags there (i.e. using a stack). Stuff like newline2br could probably also be turned into a transformation callback now, thanks to your changes. Changing the order of functions to make them appear sequentially makes sense, I just didn't do it because JS also works without doing it, but I agree that it's now more readable. Regarding reliance on xpath expressions, that's true - but we only use those "ONCE" for each quote. And created quotes won't break - but you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. We'll see how this evolves over time. At least URLs and youtube URLs/videos can be easily processed and could be turned into wiki markup, so that we can easily reuse forum & devel list postings to help populate the newsletter and other wiki articles. Again, thanks for your work on this, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:51, 5 June 2014 (UTC)<br />
<br />
=== HTML handling and Escaping {{Done}} ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote - I think there are also some issues related to the lack of nowiki-escaping now, i.e. see the "Issues" section below. But like I said elsewhere, to do this properly, we'd need to maintain a stack of nowiki tags, so that we know how deeply those are nested and unescape properly.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:11, 12 June 2014 (UTC)<br />
: Bug reports, exciting :) newline2br is not used anymore in the forum, because the br's are already there in the copied html, and phpBB seems to be printing br without slash (does it? I can't verify now, but I can't figure what would remove them in the script.)<br />
: I played a bit with the broken quote ("Issues") and I really can't understand what's wrong. I added back the slashes in the br's, put a newline after them, no change... and there are no strange characters apparently (could it be some non printable character? might be worth to paste that stuff into a hex editor? Philosopher found something like that recently, can't remember where) Obviously nowiki-escaping all the quote works, but I really don't see what should be escaped there.<br />
: It's funny also that it puts the author in place of the quote (if you look well, the position and font is that of the quote) so it must be the template that gets confused somehow. But one thing's sure: it looks very similar to what happens when enabling the conversion of code blocks, so they might be related.<br />
: I'll be busy in the next days, very busy until monday at least... so it'll take me some time to get back to this.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:49, 12 June 2014 (UTC)<br />
<br />
:: Now that you mention it: I saw that being the case with other templates containing certain URLs, including the stub/note templates. So I just tried it myself and it is indeed the embedded youtube URL causing this here. I guess the <nowiki>#</nowiki> character or URL-encoding could be contributing to this --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:56, 12 June 2014 (UTC)<br />
<br />
::: confirmed: it's the equal sign (=) confusing the template parser, probably because it is trying to do argument assignment or something like that. We could probably introduce a new URL template to handle such things, or simply use the youtube embedding code instead in this case. Also see [http://en.wikipedia.org/wiki/Help:Template#Usage_hints_and_workarounds] and [http://en.wikipedia.org/wiki/Template:URL] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:01, 12 June 2014 (UTC)<br />
<br />
:::: That was fast, thanks! This seem to fix also the problem with code snippets, which was a pity to miss. I'll add an operator for those special characters too, and using the URL template is straightforward and should be safer for all the external links. I hope this saves us from the nowiki escape thing (at least for a while.)<br />
:::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:55, 12 June 2014 (UTC)<br />
<br />
:::: Working on this... will commit something before going to bed. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:55, 13 June 2014 (UTC)<br />
<br />
:::: Uhm, kind of done but I'm not satisfied with the code snippet quoting. It's not nice to have escaped stuff and unreadable "wiki source"... anyway, youtube links work fine. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
== example ==<br />
{{cquote<br />
|<nowiki>This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the prope... do. I don't consider this to be coding but others may not agree.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>YIKES !!!Hey guys, I love flying the A330-223 BUT as soon as I wanna intercept the LOC my plane starts to shake like crazy. I was following the youtube Tutorial step by step but I CANT land with ILS. No Autoland nothing.. </nowiki><br/><nowiki><br />
Does anyone know why, On the Flightgear Wiki there are 4 Videos of the custom flight from EDDF (Frankfurt) to EDDM (Munich). But in Germany we CANT watch Video No. 4 (Approach and Autoland) .. because of the music in the video. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=188233#p188233<br />
|title=<nowiki>ILS-Problem on Airbus A330-223</nowiki><br />
|author=<nowiki>henrysean84</nowiki><br />
|date=<nowiki>Mon Aug 05</nowiki><br />
}}<br />
}}<br />
<br />
== testing CR/LF conversion ==<br />
<br />
{{cquote<br />
|<nowiki>I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211086#p211086<br />
|title=<nowiki>Re: Aircraft Rating System</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I think we have usually not deleted textures when introducing a new variant, because good GPL-compatible terrain textures are hard to come by and hence a useful resource. In particular, I remember 'reviving' some nominally obsolete textures as overlays, or in some particular regional context - for regional texturing projects, having lots of varieties is actually invaluable. I would even go as far as trying to commit good textures without an immediate use.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So I guess the bottomline is that we wouldn't necessarily want to ship these textures with the base package, but we would like to have them on a devel repository.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32405025/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>What a muddle...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
There's a whole bunch of different cases in there.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) Duplicate 'winter'-textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Apparently, when creating the winter scheme, all summer textures were copied over and the ones where adding snow makes sense got snow - the rest were just kept. For instance, Terrain.winter/tidal.png is just a copy of Terrain/tidal.png, Terrain.winter/rocks-desert.png is just a copy of Terrain./rocks-desert.png and so on. I think in these cases the duplicate can simply go. Since they're as a rule tiny textures, we don't necessarily gain much.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2) dds-converted unused textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
It would seem (perhaps one of the people involved can confirm that) that in the first version of the dds texturing schemes all existing textures were automatically converted...extures for effects which have since been changed to png for compatibility reasons possibly belong into the same category, Water/bowwave_normal.dds would be an example for this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3) Unused unique png textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
As argued previously, these we should store, possibly in 'unused'. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
4) Unique dds textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Things like Terrain/limestone2.dds are somewhat annoying, as they might be perfectly good texture templates which can't easily be edited or put to use as a png version of the same texture could be, and in addition they aren''t actually used inside the dds scheme. </nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32406658/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-02</nowiki><br />
}}<br />
}}<br />
<br />
== Automatic update of script and old quotes ==<br />
Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
: I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard?<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:02, 13 June 2014 (UTC)<br />
<br />
== Testing 0.9 ==<br />
<br />
{{FGCquote<br />
|Also, we must take into account the different dynamic range and color temperature of the human vision, cameras and computer monitors. "Closer to reality" means completely different if "reality" is "the actual physical properties of the light", "what our eyes capture/brain interprets giving the current lighting conditions" or "what our monitor can really represent". Punkepanda can find an introduction to this extremely complex issue in this link: [http://www.cambridgeincolour.com/tutorials/dynamic-range.htm http://www.cambridgeincolour.com/tutori ... -range.htm]<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212412#p212412<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>ludomotico</nowiki><br />
|date=<nowiki>Thu Jun 12</nowiki><br />
}}<br />
}}<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{FGCquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><br />
<syntaxhighlight><br />
<periodic><br />
<min>-180</min><br />
<max>180</max><br />
</periodic><br />
</syntaxhighlight><br />
will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Instant-Refs&diff=72724FlightGear wiki:Instant-Refs2014-06-13T21:50:31Z<p>Bigstones: 0.10: escaping pipes and equals, made a workaround for code quoting</p>
<hr />
<div>{{Note|FlightGear development is not centrally coordinated in any way - at the very best, FlightGear development is "self-coordinated" - i.e. contributors discuss ideas and make proposals to contribute in a certain fashion and then team up to implement certain features and building blocks temporarily. <br />
<br />
Obviously, ideas and feature requests made by end-users are also appreciated. But at the end of the day, people who do the actual work have obviously more say about future development than those who merely make suggestions. And contributors tend to prioritize work on items that are prioritized/suggested by other contributors, especially those offering to get involved and help in some way, and of those having some kind of track record in the form of past contributions.<br />
<br />
But given the lack of development manpower, many good ideas tend to have a fairly long shelf life unfortunately. So that good ideas may be forgotten over time.<br />
<br />
This is also why it is important for other developers/contributors to know who came up with a certain idea and who originally supported/supports it, possibly months (or even years) after a discussion took place - which is why good ideas should not just be preserved, but accompanied by corresponding quotes, linking back to the original discussion, so that potential contributors can make up their own minds to determine if/how they want to get involved in some effort or not. The script that you can find below is intended to help with this - it allows people to easily copy&paste important discussions over to the wiki, without having to rewrite any text, and without having to put together proper cquotes manually. In fact, it's a matter of just a few seconds.}}<br />
<br />
<br />
* A simple userscript extension implemented in JavaScript<br />
* Supported by FireFox, Chrome, Chromium, probably Opera and others<br />
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension<br />
* install the script<br />
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727<br />
: or to any forum message<br />
* copy/mark some relevant portion of text<br />
* and directly get a full cquote paragraph that you can add to the wiki here<br />
<br />
<syntaxhighlight lang="javascript">// ==UserScript==<br />
// @name instant-cquotes<br />
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections<br />
// @namespace http://wiki.flightgear.org/<br />
// @version 0.10<br />
// @icon http://wiki.flightgear.org/skins/common/images/icons-fg-135.png<br />
// @match http://sourceforge.net/p/flightgear/mailman/* <br />
// @match http://forum.flightgear.org/*<br />
// @copyright 2013+, FlightGear.org (bigstones, Philosopher & Hooray)<br />
// ==/UserScript==<br />
<br />
var debug = 0; <br />
<br />
/* content:<br />
* - 'selection' supports only getSelectedText, will support getSelectedHtml<br />
* - 'transform' takes a "tranform operator", or an ordered array of operators<br />
* author, title, date, url:<br />
* - 'xpath' takes the path to the field, relative to the html parent of the selected text<br />
* - 'transform' takes a "transform operator", or an ordered array of operators<br />
*/<br />
var CONFIG = {<br />
"sourceforge.net": {<br />
content: {<br />
selection: getSelectedText,<br />
transform: newline2br()<br />
}, <br />
author: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/^From: (.*) <.*@.*>/)<br />
},<br />
title: {<br />
xpath: "../../../tr/td/div/div/b/a/text()"<br />
},<br />
date: {<br />
xpath: "../../../tr/td/div/small/text()",<br />
transform: extract(/ - (.*-.*-.*) /)<br />
},<br />
url: {<br />
xpath: "../../../tr/td/div/div/b/a/@href",<br />
transform: prepend("http://sourceforge.net")<br />
}<br />
},<br />
"forum.flightgear.org": {<br />
content: {<br />
selection: getSelectedHtml,<br />
transform: [removeComments(),<br />
a2wikilink(),<br />
img2link(),<br />
phpBB_fontstyle2wikistyle(),<br />
phpBB_code2syntaxhighlight(), // FIXME: could be much better, see below<br />
phpBB_quote2cquote(),<br />
escapePipeAndEquals()]<br />
},<br />
author: {<br />
xpath: "../p/strong/a/text()"<br />
},<br />
title: {<br />
xpath: "../h3/a/text()"<br />
},<br />
date: {<br />
xpath: "../p/text()[2]",<br />
transform: extract(/ » (.*),/)<br />
},<br />
url: {<br />
xpath: "../p/a/@href",<br />
transform: [extract(/\.(.*)/),<br />
prepend("http://forum.flightgear.org")]<br />
}<br />
} <br />
};<br />
<br />
var OUTPUT = {<br />
// shows a message box <br />
msgbox: function(msg) {<br />
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", msg) !== null)<br />
window.getSelection().removeAllRanges(); // deselect all text<br />
}<br />
};<br />
<br />
//////////////////////<br />
// TRANSFORM OPERATORS<br />
<br />
// prepend 'prefix'<br />
function prepend(prefix) {<br />
return function(text) {<br />
return prefix+text;<br />
};<br />
}<br />
<br />
// extract the first capture group in the regex (i.e. '(xxx)') <br />
function extract(regex) {<br />
return function(text) {<br />
return text.match(regex)[1];<br />
};<br />
}<br />
<br />
// replaces newlines with "unescaped" <br/>'s<br />
function newline2br() {<br />
return function(text) {<br />
return text.replace(/\n/g,"<br/>\n");<br />
};<br />
}<br />
<br />
// remove html comments (e.g. '<!-- this is a comment -->')<br />
function removeComments() {<br />
return function(html) {<br />
return html.replace(/<!--.*?-->/g,"");<br />
};<br />
}<br />
<br />
// converts html <a>...</a>'s to wiki links, internal if possible<br />
function a2wikilink() {<br />
return function(html) {<br />
// first tries internal links<br />
// -- WARNING: if it's a link to a wiki file (wiki.fg.org/File:xxx), it will become a shown image<br />
html = html.replace(/<a.*?href="https?:\/\/wiki.flightgear.org\/(.*?)".*?>(.*?)<\/a>/g, "[[$1|$2]]");<br />
<br />
// then the others<br />
return html.replace(/<a.*?href="(.*?)".*?>(.*?)<\/a>/g, "[$1 $2]");<br />
};<br />
}<br />
<br />
// converts embedded html images to external links<br />
function img2link() {<br />
return function(html) {<br />
return html.replace(/<img.*?src="(.*?)".*?>/g, "(see the [$1 linked image])");<br />
};<br />
}<br />
<br />
// converts phpBB way of doing font style to the wiki way<br />
function phpBB_fontstyle2wikistyle() {<br />
return function(bbhtml) {<br />
bbhtml = bbhtml.replace(/<span style="font-weight: bold">(.*?)<\/span>/g, "'''$1'''");<br />
bbhtml = bbhtml.replace(/<span style="text-decoration: underline">(.*?)<\/span>/g, "<u>$1</u>");<br />
bbhtml = bbhtml.replace(/<span style="font-style: italic">(.*?)<\/span>/g, "''$1''");<br />
return bbhtml;<br />
};<br />
}<br />
<br />
// converts (html) phpBB code blocks to wiki <syntaxhighlight><br />
// FIXME: not actually using the above tag, because the copied html has<br />
// unconverted html entities and br's are not interpreted.<br />
// Solution would be to extract the code, fix it and use the proper tag...<br />
function phpBB_code2syntaxhighlight() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<dl.*?><dt>.*?<\/dt><dd><code>(.*?)<\/code><\/dd><\/dl>/g, "<tt>\n$1\n</tt>");<br />
};<br />
}<br />
<br />
// converts (html) phpBB quotes to simple wiki cquotes (author not cited, it'd get messy anyway)<br />
function phpBB_quote2cquote() {<br />
return function(bbhtml) {<br />
return bbhtml.replace(/<blockquote.*?><div>(.*?)<\/div><\/blockquote>/g, "{{cquote|$1}}");<br />
};<br />
}<br />
<br />
// escapes characters that can be problematic inside a template. Must be used after html tags were converted, or they get messed up.<br />
function escapePipeAndEquals() {<br />
return function(html) {<br />
html = html.replace(/\|\|/g,"{{!!}}");<br />
html = html.replace(/\|\-/g,"{{!-}}");<br />
html = html.replace(/\|/g,"{{!}}");<br />
return html.replace(/=/g,"{{=}}");<br />
}<br />
}<br />
<br />
<br />
///////////////////<br />
// SCRIPT MAIN BODY<br />
<br />
window.addEventListener('load', register);<br />
<br />
function register() {<br />
// check if we have a matching domain in the CONFIG hash<br />
if (CONFIG.hasOwnProperty(window.location.hostname)) {<br />
document.onmouseup = instantCquote; // register the callback for "mouse button up" event<br />
}<br />
}<br />
<br />
// main function<br />
function instantCquote() {<br />
if(getSelectedText() === "") return;<br />
<br />
var profile = CONFIG[window.location.hostname];<br />
var parent = getSelectionParent();<br />
<br />
var info = parent ? extractInfo(profile, parent) : extractInfoFallback();<br />
<br />
if (info) {<br />
var cquote = createCquote(info);<br />
OUTPUT.msgbox(cquote);<br />
} else {<br />
alert("info == null");<br />
}<br />
}<br />
<br />
function extractInfoFallback() { // XXX untested<br />
var info = {};<br />
info.content = getSelectedText();<br />
info.url = document.URL;<br />
info.title = "from " + window.location.hostname;<br />
info.author = "";<br />
info.date = "";<br />
return info;<br />
}<br />
<br />
function extractInfo(profile, parent) {<br />
var info = {};<br />
<br />
for (var field in profile) {<br />
if (!profile.hasOwnProperty(field)) continue; <br />
<br />
// this part gets the data, both for field and content (i.e. text, html)<br />
var fieldInfo = extractFieldInfo(profile, parent, field);<br />
<br />
if (debug) alert("pre trans:\n" + field + " = " + fieldInfo);<br />
<br />
var transform = profile[field].transform;<br />
if(transform) fieldInfo = applyTransformations(fieldInfo, transform);<br />
<br />
if (debug) alert("post trans:\n" + field + " = " + fieldInfo);<br />
<br />
info[field] = fieldInfo;<br />
<br />
}<br />
<br />
return info;<br />
}<br />
<br />
function extractFieldInfo(profile, parent, field) {<br />
if (field != "content") {<br />
var xpath = profile[field].xpath;<br />
var parentXPath = getXPathTo(parent);<br />
var fullPath = parentXPath + "/" + xpath;<br />
return document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null).stringValue;<br />
} else {<br />
return profile[field].selection(); // here we extract the contents of the selection<br />
}<br />
}<br />
<br />
function applyTransformations(fieldInfo, trans) {<br />
if(typeof trans === "function") {<br />
return trans(fieldInfo);<br />
} else if (Array.isArray(trans)) {<br />
for (var i = 0; i < trans.length; i++) {<br />
if (debug) alert("pre trans in array:\n = " + fieldInfo);<br />
fieldInfo = trans[i](fieldInfo);<br />
if (debug) alert("post trans in array:\n = " + fieldInfo);<br />
}<br />
return fieldInfo;<br />
}<br />
}<br />
<br />
function createCquote(info) {<br />
//TODO: add template string to profile<br />
var template = "{{cquote" + "\n" +<br />
" |" + info.content + "\n" +<br />
" |{{cite web |url=" + info.url + "\n" +<br />
" |title=" + nowiki(info.title) + "\n" +<br />
" |author=" + nowiki(info.author) + "\n" +<br />
" |date=" + nowiki(info.date) + "\n" +<br />
" }}" + "\n" +<br />
"}}";<br />
return template;<br />
}<br />
<br />
function createForumQuote(info) {<br />
//TODO: add template string to profile<br />
// nowiki(info.date)<br />
var template = "[url='"+info.url+"']"+info.title+"("+nowiki(info.date)+")[/url][quote='"+nowiki(info.author)+"']" + nowiki(info.content) + "\n" +<br />
"[/quote]";<br />
return template;<br />
}<br />
<br />
<br />
function nowiki(text) {<br />
return "<nowiki>" + text + "</nowiki>";<br />
}<br />
<br />
////////////////////<br />
// UTILITY FUNCTIONS<br />
<br />
// IE8 compat. function<br />
function getSelectionParent() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
// anchorNode is the textnode, parentNode is the parent html element<br />
return document.getSelection().anchorNode.parentNode;<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().parentElement();<br />
}<br />
}<br />
<br />
// IE8 compat. function<br />
function getSelectedText() {<br />
if(document.getSelection) { // for modern, standard compliant browsers<br />
return document.getSelection().toString();<br />
<br />
} else if (document.selection) { // for IE <= v8 - XXX: not tested!<br />
return document.selection.createRange().text;<br />
}<br />
}<br />
<br />
// IE8 compat. function (copied from http://stackoverflow.com/a/6668159 )<br />
function getSelectedHtml() {<br />
var html = "";<br />
if (typeof window.getSelection != "undefined") {<br />
var sel = window.getSelection();<br />
if (sel.rangeCount) {<br />
var container = document.createElement("div");<br />
for (var i = 0, len = sel.rangeCount; i < len; ++i) {<br />
container.appendChild(sel.getRangeAt(i).cloneContents());<br />
}<br />
html = container.innerHTML;<br />
}<br />
} else if (typeof document.selection != "undefined") {<br />
if (document.selection.type == "Text") {<br />
html = document.selection.createRange().htmlText;<br />
}<br />
}<br />
return html;<br />
}<br />
<br />
// copied from http://stackoverflow.com/a/2631931<br />
function getXPathTo(element) {<br />
if (element.id !== '')<br />
return 'id("' + element.id + '")';<br />
if (element === document.body)<br />
return element.tagName;<br />
<br />
var ix= 0;<br />
var siblings = element.parentNode.childNodes;<br />
for (var i= 0; i<siblings.length; i++) {<br />
var sibling = siblings[i];<br />
if (sibling === element)<br />
return getXPathTo(element.parentNode) + '/' + element.tagName + '[' + (ix+1) + ']';<br />
if (sibling.nodeType === 1 && sibling.tagName === element.tagName)<br />
ix++;<br />
}<br />
}</syntaxhighlight><br />
<br />
[[Category:Wiki maintenance]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72723FlightGear wiki talk:Instant-Refs2014-06-13T21:48:29Z<p>Bigstones: /* Issues */ removed old ones, added one new</p>
<hr />
<div>== regex / sourceforge ==<br />
<br />
You're right - I just checked out the sourceforge archives, there's just a single <small></small> tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using '''From:''', '''<''' and '''-''' as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the '''CONFIG''' hash, maybe in addition to XPath expressions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:12, 31 May 2014 (UTC)<br />
<br />
== RX suffix ==<br />
<br />
That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:<br />
<br />
<syntaxhighlight language="javascript"><br />
<br />
var CONFIG = {<br />
"sourceforge.net": { <br />
author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },<br />
title: { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },<br />
date: { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },<br />
url: { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }<br />
},<br />
};<br />
</syntaxhighlight><br />
<br />
basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! <br />
Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:23, 31 May 2014 (UTC)<br />
: Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.<br />
: EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:27, 31 May 2014 (UTC)<br />
:: Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:47, 31 May 2014 (UTC)<br />
<br />
== extractInfo loop ==<br />
<br />
I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:22, 31 May 2014 (UTC)<br />
<br />
<br />
== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Post-Processing ==<br />
=== the prepend field ===<br />
<br />
I would rename this to '''transform''' and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:24, 31 May 2014 (UTC)<br />
<br />
: I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:47, 31 May 2014 (UTC)<br />
<br />
=== CR/LF - br handling ===<br />
<br />
The whole '''transform'''/post-process idea may not be that far-fetched, I just added quite a few cquotes to the [[Canvas EFB Framework]] article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links (<nowiki>[[FOO]]</nowiki>) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <nowiki><br/></nowiki>) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 1 June 2014 (UTC)<br />
: I'll take a look at these, paragraphs are easy indeed {{Done}}.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
:: For starters, just looking for CR/LF and turning it into <nowiki><br/></nowiki> should suffice --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:30, 2 June 2014 (UTC)<br />
<br />
::: Newlines are now <nowiki><br/></nowiki>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:52, 2 June 2014 (UTC)<br />
<br />
:::: The examples below (in essence [http://wiki.flightgear.org/index.php?title=Talk:Fixing_up_articles_with_wrong_quotes&diff=72282&oldid=72281 this edit]) look like there is one line break more than usual inserted. I would think that both <tt>&lt;br/&gt;</tt> tags and the new line between the <tt>&lt;/nowiki&gt;</tt> and <tt>&lt;nowiki&gt;</tt> tags are treated as line breaks, though I am not 100% sure.<br />
:::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 04:53, 3 June 2014 (UTC)<br />
<br />
::::: I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <nowiki><p></p></nowiki> tag. Possibly it's not that hard... even a regex could probably do: <tt><nowiki>/([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s</nowiki></tt><br />
::::: (note that I don't know if the above works: what with "fake" bullet list newlines? what if only one newline is used to separate text? when should it be applied wrt other transformations?)<br />
::::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:30, 3 June 2014 (UTC)<br />
<br />
:: this looks fairly good to me, once we can also '''transform()''' the actual text selection, and maybe process the underlying HTML code to transform /some/ formatting, I'd consider the whole thing feature-complete. Functionality-wise there really isn't much that could/should be added then. And additional sources are straightforward to add anyway. Overall, this could really help to easily organize efforts that are typically spread across several months/years, because community/contributor support for certain ideas & proposals can be much better evaluated this way, even by new contributors. In fact, we could now even post-process user names, e.g. to link to their forum profile for people wanting to send a PM. So I think this will be a great tool and a huge time-saver. Thanks for all your work on this, really appreciated! BTW: I also don't really "know" JavaScript, but it looks similar enough to Nasal - and it seems you are also getting along, which also means that you may want to check out Nasal at some point :-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:49, 3 June 2014 (UTC)<br />
<br />
=== retained formatting ===<br />
<br />
: I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?<br />
:--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
<br />
:: <del>I don't think</del> we need to copy the HTML content[http://blog.ssokolow.com/archives/2008/12/03/getting-the-selected-text-as-html-using-javascript/comment-page-1/] - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [http://stackoverflow.com/questions/5643635/how-to-get-selected-html-text-with-javascript][http://stackoverflow.com/questions/6251937/how-to-get-selecteduser-highlighted-text-in-contenteditable-element-and-replac][http://stackoverflow.com/a/5670825], e.g. <nowiki><a href=""></a></nowiki> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as '''postlink''' (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <nowiki><ul> <li>...</li> </ul></nowiki>. Looking for images doesn't make too much sense unless those are wiki-hosted, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into <nowiki>{{#ev:youtube|VIDEO_ID}}</nowiki> markup - either through youtube.com URLs. Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:18, 2 June 2014 (UTC)<br />
<br />
::: Ok, I made some support for HTML. I copied a function to get the selected HTML from stackoverflow, then used it on the forum and made up some transform operators. A couple need some attention (especially the syntaxhighlight one). Some have a funny behaviour: try to cquote [http://forum.flightgear.org/viewtopic.php?p=211670#p211670 this post], and you'll see that the image will correctly become a link, while the link will be fully shown as an image. That's because it gets converted to an internal link, and the wiki knows that's an image. Then, I'm not sure if nested quotes are actually a smart thing, and I didn't make the list converter because I couldn't find an example.<br />
::: Not much else to say. Have fun :)<br />
::: EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:16, 8 June 2014 (UTC)<br />
<br />
:: This is pretty cool, and impressive how this has evolved so quickly - I agree that nested quotes are probably too tricky. I think conversion of URLs and youtube links should be a good start. Converting lists should be fairly straightforward now, BTW: here's a posting containing a list[http://forum.flightgear.org/viewtopic.php?f=71&t=23241#p212029]. Thanks again for your work on this !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:43, 8 June 2014 (UTC)<br />
<br />
::: Hi Hooray, I saw your latest cquotes, didn't you "upgrade" to the last version of the script? It's working already, with links, formatting, and nested quotes if one will. Actually, even lists work, because now it copies the HTML and they work even without converting them to the wiki formatting.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:26, 11 June 2014 (UTC)<br />
<br />
: oops, good spotting: using a different computer and browser at the moment, need to upgrade obviously. Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
=== selection processing ===<br />
I think we really only need to add another "content" key that is mapped to GetSelectedText() and then use a '''transform()''' field that can post-process the selection, that is then also where newline replacement, and other content processing would take place. That way we can even replace common acronyms using their wiki equivalents, e.g. [[$FG ROOT]], [[Nasal]] so that quotes would become a bit more self-explanatory --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:55, 3 June 2014 (UTC)<br />
: Two+1 observations on [http://wiki.flightgear.org/index.php?title=Fixing_up_articles_with_wrong_quotes&diff=prev&oldid=72316 latest changes]: 1) I considered GetSelectedText() the "main()" of the script, why would I want to configure that? 2) I see transform() happening in both extractInfo() and GetSelectedText(), is that in preparation to have extractInfo() extract also the content? 3) I didn't think of the transform option that way, it's way cleaner than I thought, we could even make a "pipe()" to serialize different make_xxx() operators! At this point, also the regex could be one of such operators.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:51, 3 June 2014 (UTC)<br />
<br />
:: Those are indeed all very good points, and I was actually aware of them. I really just wanted to "establish the separation" here. It is true that there are now some workarounds in place that are not exactly "a good design". It just seemed simple enough for me, and I was going to volunteer to clean it up once the key functionality is in place. GetSelectedText() is indeed the main work-horse, I just prepared it to become customizable wearing my "Architecture Astronaut" hat :-) And like you say, generalizing extractInfo() seemed like a good idea to me at the time, which is why the workhorse is now specified via the CONFIG hash (despite probably not having to be there). It is probably over-engineering things, but I just wanted to establish the infrastructure to turn everything into a chain of steps that can be mostly configured through just the CONFIG hash. It is awesome that you can see the potential of that, because I fully realized that it may seem "odd" at first glance and maybe too involved. But my goal really is to move all those processing steps into the CONFIG hash, so that we can trivially add other functionality, without having to touch those other functions. I like the whole pipe/cascade analogy very much, it could be just a vector of different transformations applied in order! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:05, 3 June 2014 (UTC)<br />
<br />
::: work in progress... towards 0.8<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:58, 5 June 2014 (UTC)<br />
::: Done. Huge refactoring (I hope you like the style, overall the fact that I use to put "inner" functions after they're used, trusting in a hopefully meaningful name) and "transform" works properly for fields and contents (formally, "content" is one of the fields of "info" now).<br />
::: For the format of the contents, I made it so that you can get either text or (later) html, but that way one can't rely on using the structure of html (xpaths), right now. I know that [http://stackoverflow.com/a/1732454 parsing html with regexes is bad] (btw, I didn't know that Architecture Astronaut thing :) ), but hopefully for a short piece of text it will do?<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:25, 5 June 2014 (UTC)<br />
<br />
:: Looking good here. Regarding your comments/FIXMEs, I agree that the non-conditional nowiki-escaping is a hack, but to do it the proper way would require parsing the blob for nowiki tags, and keeping track of how many open tags there (i.e. using a stack). Stuff like newline2br could probably also be turned into a transformation callback now, thanks to your changes. Changing the order of functions to make them appear sequentially makes sense, I just didn't do it because JS also works without doing it, but I agree that it's now more readable. Regarding reliance on xpath expressions, that's true - but we only use those "ONCE" for each quote. And created quotes won't break - but you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. We'll see how this evolves over time. At least URLs and youtube URLs/videos can be easily processed and could be turned into wiki markup, so that we can easily reuse forum & devel list postings to help populate the newsletter and other wiki articles. Again, thanks for your work on this, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:51, 5 June 2014 (UTC)<br />
<br />
=== HTML handling and Escaping ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote - I think there are also some issues related to the lack of nowiki-escaping now, i.e. see the "Issues" section below. But like I said elsewhere, to do this properly, we'd need to maintain a stack of nowiki tags, so that we know how deeply those are nested and unescape properly.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:11, 12 June 2014 (UTC)<br />
: Bug reports, exciting :) newline2br is not used anymore in the forum, because the br's are already there in the copied html, and phpBB seems to be printing br without slash (does it? I can't verify now, but I can't figure what would remove them in the script.)<br />
: I played a bit with the broken quote ("Issues") and I really can't understand what's wrong. I added back the slashes in the br's, put a newline after them, no change... and there are no strange characters apparently (could it be some non printable character? might be worth to paste that stuff into a hex editor? Philosopher found something like that recently, can't remember where) Obviously nowiki-escaping all the quote works, but I really don't see what should be escaped there.<br />
: It's funny also that it puts the author in place of the quote (if you look well, the position and font is that of the quote) so it must be the template that gets confused somehow. But one thing's sure: it looks very similar to what happens when enabling the conversion of code blocks, so they might be related.<br />
: I'll be busy in the next days, very busy until monday at least... so it'll take me some time to get back to this.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:49, 12 June 2014 (UTC)<br />
<br />
:: Now that you mention it: I saw that being the case with other templates containing certain URLs, including the stub/note templates. So I just tried it myself and it is indeed the embedded youtube URL causing this here. I guess the <nowiki>#</nowiki> character or URL-encoding could be contributing to this --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:56, 12 June 2014 (UTC)<br />
<br />
::: confirmed: it's the equal sign (=) confusing the template parser, probably because it is trying to do argument assignment or something like that. We could probably introduce a new URL template to handle such things, or simply use the youtube embedding code instead in this case. Also see [http://en.wikipedia.org/wiki/Help:Template#Usage_hints_and_workarounds] and [http://en.wikipedia.org/wiki/Template:URL] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:01, 12 June 2014 (UTC)<br />
<br />
:::: That was fast, thanks! This seem to fix also the problem with code snippets, which was a pity to miss. I'll add an operator for those special characters too, and using the URL template is straightforward and should be safer for all the external links. I hope this saves us from the nowiki escape thing (at least for a while.)<br />
:::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:55, 12 June 2014 (UTC)<br />
<br />
:::: Working on this... will commit something before going to bed. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:55, 13 June 2014 (UTC)<br />
<br />
== example ==<br />
{{cquote<br />
|<nowiki>This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the prope... do. I don't consider this to be coding but others may not agree.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>YIKES !!!Hey guys, I love flying the A330-223 BUT as soon as I wanna intercept the LOC my plane starts to shake like crazy. I was following the youtube Tutorial step by step but I CANT land with ILS. No Autoland nothing.. </nowiki><br/><nowiki><br />
Does anyone know why, On the Flightgear Wiki there are 4 Videos of the custom flight from EDDF (Frankfurt) to EDDM (Munich). But in Germany we CANT watch Video No. 4 (Approach and Autoland) .. because of the music in the video. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=188233#p188233<br />
|title=<nowiki>ILS-Problem on Airbus A330-223</nowiki><br />
|author=<nowiki>henrysean84</nowiki><br />
|date=<nowiki>Mon Aug 05</nowiki><br />
}}<br />
}}<br />
<br />
== testing CR/LF conversion ==<br />
<br />
{{cquote<br />
|<nowiki>I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211086#p211086<br />
|title=<nowiki>Re: Aircraft Rating System</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I think we have usually not deleted textures when introducing a new variant, because good GPL-compatible terrain textures are hard to come by and hence a useful resource. In particular, I remember 'reviving' some nominally obsolete textures as overlays, or in some particular regional context - for regional texturing projects, having lots of varieties is actually invaluable. I would even go as far as trying to commit good textures without an immediate use.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So I guess the bottomline is that we wouldn't necessarily want to ship these textures with the base package, but we would like to have them on a devel repository.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32405025/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>What a muddle...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
There's a whole bunch of different cases in there.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) Duplicate 'winter'-textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Apparently, when creating the winter scheme, all summer textures were copied over and the ones where adding snow makes sense got snow - the rest were just kept. For instance, Terrain.winter/tidal.png is just a copy of Terrain/tidal.png, Terrain.winter/rocks-desert.png is just a copy of Terrain./rocks-desert.png and so on. I think in these cases the duplicate can simply go. Since they're as a rule tiny textures, we don't necessarily gain much.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2) dds-converted unused textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
It would seem (perhaps one of the people involved can confirm that) that in the first version of the dds texturing schemes all existing textures were automatically converted...extures for effects which have since been changed to png for compatibility reasons possibly belong into the same category, Water/bowwave_normal.dds would be an example for this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3) Unused unique png textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
As argued previously, these we should store, possibly in 'unused'. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
4) Unique dds textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Things like Terrain/limestone2.dds are somewhat annoying, as they might be perfectly good texture templates which can't easily be edited or put to use as a png version of the same texture could be, and in addition they aren''t actually used inside the dds scheme. </nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32406658/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-02</nowiki><br />
}}<br />
}}<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
<br />
== Testing 0.9 ==<br />
<br />
{{FGCquote<br />
|Also, we must take into account the different dynamic range and color temperature of the human vision, cameras and computer monitors. "Closer to reality" means completely different if "reality" is "the actual physical properties of the light", "what our eyes capture/brain interprets giving the current lighting conditions" or "what our monitor can really represent". Punkepanda can find an introduction to this extremely complex issue in this link: [http://www.cambridgeincolour.com/tutorials/dynamic-range.htm http://www.cambridgeincolour.com/tutori ... -range.htm]<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212412#p212412<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>ludomotico</nowiki><br />
|date=<nowiki>Thu Jun 12</nowiki><br />
}}<br />
}}<br />
<br />
== Issues ==<br />
=== phpBB code snippets not displayed using syntaxhighlight ===<br />
{{cquote<br />
|What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:<br><tt><br />
&nbsp; &lt;periodic&gt;<br>&nbsp; &nbsp; &nbsp;&lt;min&gt;-180&lt;/min&gt;<br>&nbsp; &nbsp; &nbsp;&lt;max&gt;180&lt;/max&gt;<br>&nbsp; &lt;/periodic&gt;<br><br />
</tt><br>will transform a value of -190 to +170 for example. But that's probably not what you asked for.<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=150087#p150087<br />
|title=<nowiki>Re: Calculating pitch angle for V/S - <atan> explresion</nowiki><br />
|author=<nowiki>Torsten</nowiki><br />
|date=<nowiki>10 Feb 2012</nowiki><br />
}}<br />
}}</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki_talk:Instant-Refs&diff=72722FlightGear wiki talk:Instant-Refs2014-06-13T20:55:39Z<p>Bigstones: /* HTML handling and Escaping */ WIP</p>
<hr />
<div>== regex / sourceforge ==<br />
<br />
You're right - I just checked out the sourceforge archives, there's just a single <small></small> tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using '''From:''', '''<''' and '''-''' as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the '''CONFIG''' hash, maybe in addition to XPath expressions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:12, 31 May 2014 (UTC)<br />
<br />
== RX suffix ==<br />
<br />
That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:<br />
<br />
<syntaxhighlight language="javascript"><br />
<br />
var CONFIG = {<br />
"sourceforge.net": { <br />
author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },<br />
title: { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },<br />
date: { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },<br />
url: { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }<br />
},<br />
};<br />
</syntaxhighlight><br />
<br />
basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! <br />
Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:23, 31 May 2014 (UTC)<br />
: Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.<br />
: EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 18:27, 31 May 2014 (UTC)<br />
:: Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:47, 31 May 2014 (UTC)<br />
<br />
== extractInfo loop ==<br />
<br />
I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:22, 31 May 2014 (UTC)<br />
<br />
<br />
== more sources ==<br />
<br />
at some point, we may also want to add support for other sources, such as:<br />
* the issue tracker: http://code.google.com/p/flightgear-bugs/<br />
* gitorious commit logs http://gitorious.org/fg/<br />
* http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)<br />
<br />
that should cover all important sources. And it would allow us to also use the same script to help populate [[FlightGear Newsletter]] & [[Changelog 3.2|changelogs]], but also [[Release plan/Lessons learned]]. So this could be a real time-saver. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:40, 1 June 2014 (UTC)<br />
<br />
== Post-Processing ==<br />
=== the prepend field ===<br />
<br />
I would rename this to '''transform''' and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:24, 31 May 2014 (UTC)<br />
<br />
: I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:47, 31 May 2014 (UTC)<br />
<br />
=== CR/LF - br handling ===<br />
<br />
The whole '''transform'''/post-process idea may not be that far-fetched, I just added quite a few cquotes to the [[Canvas EFB Framework]] article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links (<nowiki>[[FOO]]</nowiki>) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <nowiki><br/></nowiki>) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 1 June 2014 (UTC)<br />
: I'll take a look at these, paragraphs are easy indeed {{Done}}.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
:: For starters, just looking for CR/LF and turning it into <nowiki><br/></nowiki> should suffice --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:30, 2 June 2014 (UTC)<br />
<br />
::: Newlines are now <nowiki><br/></nowiki>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:52, 2 June 2014 (UTC)<br />
<br />
:::: The examples below (in essence [http://wiki.flightgear.org/index.php?title=Talk:Fixing_up_articles_with_wrong_quotes&diff=72282&oldid=72281 this edit]) look like there is one line break more than usual inserted. I would think that both <tt>&lt;br/&gt;</tt> tags and the new line between the <tt>&lt;/nowiki&gt;</tt> and <tt>&lt;nowiki&gt;</tt> tags are treated as line breaks, though I am not 100% sure.<br />
:::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 04:53, 3 June 2014 (UTC)<br />
<br />
::::: I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <nowiki><p></p></nowiki> tag. Possibly it's not that hard... even a regex could probably do: <tt><nowiki>/([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s</nowiki></tt><br />
::::: (note that I don't know if the above works: what with "fake" bullet list newlines? what if only one newline is used to separate text? when should it be applied wrt other transformations?)<br />
::::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:30, 3 June 2014 (UTC)<br />
<br />
:: this looks fairly good to me, once we can also '''transform()''' the actual text selection, and maybe process the underlying HTML code to transform /some/ formatting, I'd consider the whole thing feature-complete. Functionality-wise there really isn't much that could/should be added then. And additional sources are straightforward to add anyway. Overall, this could really help to easily organize efforts that are typically spread across several months/years, because community/contributor support for certain ideas & proposals can be much better evaluated this way, even by new contributors. In fact, we could now even post-process user names, e.g. to link to their forum profile for people wanting to send a PM. So I think this will be a great tool and a huge time-saver. Thanks for all your work on this, really appreciated! BTW: I also don't really "know" JavaScript, but it looks similar enough to Nasal - and it seems you are also getting along, which also means that you may want to check out Nasal at some point :-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:49, 3 June 2014 (UTC)<br />
<br />
=== retained formatting ===<br />
<br />
: I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?<br />
:--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:53, 2 June 2014 (UTC)<br />
<br />
:: <del>I don't think</del> we need to copy the HTML content[http://blog.ssokolow.com/archives/2008/12/03/getting-the-selected-text-as-html-using-javascript/comment-page-1/] - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [http://stackoverflow.com/questions/5643635/how-to-get-selected-html-text-with-javascript][http://stackoverflow.com/questions/6251937/how-to-get-selecteduser-highlighted-text-in-contenteditable-element-and-replac][http://stackoverflow.com/a/5670825], e.g. <nowiki><a href=""></a></nowiki> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as '''postlink''' (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <nowiki><ul> <li>...</li> </ul></nowiki>. Looking for images doesn't make too much sense unless those are wiki-hosted, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into <nowiki>{{#ev:youtube|VIDEO_ID}}</nowiki> markup - either through youtube.com URLs. Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:18, 2 June 2014 (UTC)<br />
<br />
::: Ok, I made some support for HTML. I copied a function to get the selected HTML from stackoverflow, then used it on the forum and made up some transform operators. A couple need some attention (especially the syntaxhighlight one). Some have a funny behaviour: try to cquote [http://forum.flightgear.org/viewtopic.php?p=211670#p211670 this post], and you'll see that the image will correctly become a link, while the link will be fully shown as an image. That's because it gets converted to an internal link, and the wiki knows that's an image. Then, I'm not sure if nested quotes are actually a smart thing, and I didn't make the list converter because I couldn't find an example.<br />
::: Not much else to say. Have fun :)<br />
::: EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:16, 8 June 2014 (UTC)<br />
<br />
:: This is pretty cool, and impressive how this has evolved so quickly - I agree that nested quotes are probably too tricky. I think conversion of URLs and youtube links should be a good start. Converting lists should be fairly straightforward now, BTW: here's a posting containing a list[http://forum.flightgear.org/viewtopic.php?f=71&t=23241#p212029]. Thanks again for your work on this !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:43, 8 June 2014 (UTC)<br />
<br />
::: Hi Hooray, I saw your latest cquotes, didn't you "upgrade" to the last version of the script? It's working already, with links, formatting, and nested quotes if one will. Actually, even lists work, because now it copies the HTML and they work even without converting them to the wiki formatting.<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:26, 11 June 2014 (UTC)<br />
<br />
: oops, good spotting: using a different computer and browser at the moment, need to upgrade obviously. Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the '''downloadURL''' attribute[http://stackoverflow.com/questions/15095055/why-isnt-my-greasemonkey-script-updating] so that scripts can auto-update --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:51, 11 June 2014 (UTC)<br />
<br />
=== selection processing ===<br />
I think we really only need to add another "content" key that is mapped to GetSelectedText() and then use a '''transform()''' field that can post-process the selection, that is then also where newline replacement, and other content processing would take place. That way we can even replace common acronyms using their wiki equivalents, e.g. [[$FG ROOT]], [[Nasal]] so that quotes would become a bit more self-explanatory --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:55, 3 June 2014 (UTC)<br />
: Two+1 observations on [http://wiki.flightgear.org/index.php?title=Fixing_up_articles_with_wrong_quotes&diff=prev&oldid=72316 latest changes]: 1) I considered GetSelectedText() the "main()" of the script, why would I want to configure that? 2) I see transform() happening in both extractInfo() and GetSelectedText(), is that in preparation to have extractInfo() extract also the content? 3) I didn't think of the transform option that way, it's way cleaner than I thought, we could even make a "pipe()" to serialize different make_xxx() operators! At this point, also the regex could be one of such operators.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 12:51, 3 June 2014 (UTC)<br />
<br />
:: Those are indeed all very good points, and I was actually aware of them. I really just wanted to "establish the separation" here. It is true that there are now some workarounds in place that are not exactly "a good design". It just seemed simple enough for me, and I was going to volunteer to clean it up once the key functionality is in place. GetSelectedText() is indeed the main work-horse, I just prepared it to become customizable wearing my "Architecture Astronaut" hat :-) And like you say, generalizing extractInfo() seemed like a good idea to me at the time, which is why the workhorse is now specified via the CONFIG hash (despite probably not having to be there). It is probably over-engineering things, but I just wanted to establish the infrastructure to turn everything into a chain of steps that can be mostly configured through just the CONFIG hash. It is awesome that you can see the potential of that, because I fully realized that it may seem "odd" at first glance and maybe too involved. But my goal really is to move all those processing steps into the CONFIG hash, so that we can trivially add other functionality, without having to touch those other functions. I like the whole pipe/cascade analogy very much, it could be just a vector of different transformations applied in order! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:05, 3 June 2014 (UTC)<br />
<br />
::: work in progress... towards 0.8<br />
:::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:58, 5 June 2014 (UTC)<br />
::: Done. Huge refactoring (I hope you like the style, overall the fact that I use to put "inner" functions after they're used, trusting in a hopefully meaningful name) and "transform" works properly for fields and contents (formally, "content" is one of the fields of "info" now).<br />
::: For the format of the contents, I made it so that you can get either text or (later) html, but that way one can't rely on using the structure of html (xpaths), right now. I know that [http://stackoverflow.com/a/1732454 parsing html with regexes is bad] (btw, I didn't know that Architecture Astronaut thing :) ), but hopefully for a short piece of text it will do?<br />
::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:25, 5 June 2014 (UTC)<br />
<br />
:: Looking good here. Regarding your comments/FIXMEs, I agree that the non-conditional nowiki-escaping is a hack, but to do it the proper way would require parsing the blob for nowiki tags, and keeping track of how many open tags there (i.e. using a stack). Stuff like newline2br could probably also be turned into a transformation callback now, thanks to your changes. Changing the order of functions to make them appear sequentially makes sense, I just didn't do it because JS also works without doing it, but I agree that it's now more readable. Regarding reliance on xpath expressions, that's true - but we only use those "ONCE" for each quote. And created quotes won't break - but you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed. We'll see how this evolves over time. At least URLs and youtube URLs/videos can be easily processed and could be turned into wiki markup, so that we can easily reuse forum & devel list postings to help populate the newsletter and other wiki articles. Again, thanks for your work on this, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:51, 5 June 2014 (UTC)<br />
<br />
=== HTML handling and Escaping ===<br />
There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote - I think there are also some issues related to the lack of nowiki-escaping now, i.e. see the "Issues" section below. But like I said elsewhere, to do this properly, we'd need to maintain a stack of nowiki tags, so that we know how deeply those are nested and unescape properly.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:11, 12 June 2014 (UTC)<br />
: Bug reports, exciting :) newline2br is not used anymore in the forum, because the br's are already there in the copied html, and phpBB seems to be printing br without slash (does it? I can't verify now, but I can't figure what would remove them in the script.)<br />
: I played a bit with the broken quote ("Issues") and I really can't understand what's wrong. I added back the slashes in the br's, put a newline after them, no change... and there are no strange characters apparently (could it be some non printable character? might be worth to paste that stuff into a hex editor? Philosopher found something like that recently, can't remember where) Obviously nowiki-escaping all the quote works, but I really don't see what should be escaped there.<br />
: It's funny also that it puts the author in place of the quote (if you look well, the position and font is that of the quote) so it must be the template that gets confused somehow. But one thing's sure: it looks very similar to what happens when enabling the conversion of code blocks, so they might be related.<br />
: I'll be busy in the next days, very busy until monday at least... so it'll take me some time to get back to this.<br />
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:49, 12 June 2014 (UTC)<br />
<br />
:: Now that you mention it: I saw that being the case with other templates containing certain URLs, including the stub/note templates. So I just tried it myself and it is indeed the embedded youtube URL causing this here. I guess the <nowiki>#</nowiki> character or URL-encoding could be contributing to this --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:56, 12 June 2014 (UTC)<br />
<br />
::: confirmed: it's the equal sign (=) confusing the template parser, probably because it is trying to do argument assignment or something like that. We could probably introduce a new URL template to handle such things, or simply use the youtube embedding code instead in this case. Also see [http://en.wikipedia.org/wiki/Help:Template#Usage_hints_and_workarounds] and [http://en.wikipedia.org/wiki/Template:URL] --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:01, 12 June 2014 (UTC)<br />
<br />
:::: That was fast, thanks! This seem to fix also the problem with code snippets, which was a pity to miss. I'll add an operator for those special characters too, and using the URL template is straightforward and should be safer for all the external links. I hope this saves us from the nowiki escape thing (at least for a while.)<br />
:::: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 19:55, 12 June 2014 (UTC)<br />
<br />
:::: Working on this... will commit something before going to bed. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:55, 13 June 2014 (UTC)<br />
<br />
== example ==<br />
{{cquote<br />
|<nowiki>This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the prope... do. I don't consider this to be coding but others may not agree.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211175#p211175<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>YIKES !!!Hey guys, I love flying the A330-223 BUT as soon as I wanna intercept the LOC my plane starts to shake like crazy. I was following the youtube Tutorial step by step but I CANT land with ILS. No Autoland nothing.. </nowiki><br/><nowiki><br />
Does anyone know why, On the Flightgear Wiki there are 4 Videos of the custom flight from EDDF (Frankfurt) to EDDM (Munich). But in Germany we CANT watch Video No. 4 (Approach and Autoland) .. because of the music in the video. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=188233#p188233<br />
|title=<nowiki>ILS-Problem on Airbus A330-223</nowiki><br />
|author=<nowiki>henrysean84</nowiki><br />
|date=<nowiki>Mon Aug 05</nowiki><br />
}}<br />
}}<br />
<br />
== testing CR/LF conversion ==<br />
<br />
{{cquote<br />
|<nowiki>I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211086#p211086<br />
|title=<nowiki>Re: Aircraft Rating System</nowiki><br />
|author=<nowiki>hvengel</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I think we have usually not deleted textures when introducing a new variant, because good GPL-compatible terrain textures are hard to come by and hence a useful resource. In particular, I remember 'reviving' some nominally obsolete textures as overlays, or in some particular regional context - for regional texturing projects, having lots of varieties is actually invaluable. I would even go as far as trying to commit good textures without an immediate use.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So I guess the bottomline is that we wouldn't necessarily want to ship these textures with the base package, but we would like to have them on a devel repository.</nowiki><br/><nowiki><br />
</nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32405025/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>What a muddle...</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
There's a whole bunch of different cases in there.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
1) Duplicate 'winter'-textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Apparently, when creating the winter scheme, all summer textures were copied over and the ones where adding snow makes sense got snow - the rest were just kept. For instance, Terrain.winter/tidal.png is just a copy of Terrain/tidal.png, Terrain.winter/rocks-desert.png is just a copy of Terrain./rocks-desert.png and so on. I think in these cases the duplicate can simply go. Since they're as a rule tiny textures, we don't necessarily gain much.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
2) dds-converted unused textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
It would seem (perhaps one of the people involved can confirm that) that in the first version of the dds texturing schemes all existing textures were automatically converted...extures for effects which have since been changed to png for compatibility reasons possibly belong into the same category, Water/bowwave_normal.dds would be an example for this.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
3) Unused unique png textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
As argued previously, these we should store, possibly in 'unused'. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
4) Unique dds textures:</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
Things like Terrain/limestone2.dds are somewhat annoying, as they might be perfectly good texture templates which can't easily be edited or put to use as a png version of the same texture could be, and in addition they aren''t actually used inside the dds scheme. </nowiki><br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32406658/<br />
|title=<nowiki>Re: [Flightgear-devel] Unused textures?</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-06-02</nowiki><br />
}}<br />
}}<br />
<br />
== selection/clipboard buffer or alert() limits ? ==<br />
<br />
There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:11, 12 June 2014 (UTC)<br />
<br />
== Testing 0.9 ==<br />
<br />
{{FGCquote<br />
|Also, we must take into account the different dynamic range and color temperature of the human vision, cameras and computer monitors. "Closer to reality" means completely different if "reality" is "the actual physical properties of the light", "what our eyes capture/brain interprets giving the current lighting conditions" or "what our monitor can really represent". Punkepanda can find an introduction to this extremely complex issue in this link: [http://www.cambridgeincolour.com/tutorials/dynamic-range.htm http://www.cambridgeincolour.com/tutori ... -range.htm]<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212412#p212412<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>ludomotico</nowiki><br />
|date=<nowiki>Thu Jun 12</nowiki><br />
}}<br />
}}<br />
<br />
== Issues ==<br />
<br />
{{FGCquote<br />
|Using an AI scenario distributed to the pilots so we all seen the same(ish) weather at the same time and place.<br>Well the AI weather script certainly threw some nasty stuff at us for sure.<br>Well done to all those who endured it and survived.<br><br>Full video available here ( flying starts at 13 min ) :-<br><br><br />
<br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212081#p212081<br />
|title=<nowiki>British Weather. Group flight pics and video.</nowiki><br />
|author=<nowiki>StuartC</nowiki><br />
|date=<nowiki>Sun Jun 08</nowiki><br />
}}<br />
}}</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Category:Working_together&diff=72720Category:Working together2014-06-13T20:42:51Z<p>Bigstones: unifying description style</p>
<hr />
<div>Category for articles about "navigating" the projects in FlightGear, without causing too much irritation, and without being overly frustrated. It's more about understanding how things "happen to work" by convention, not by conscious consensus (see [[Talk:Entitlement]].)<br />
<br />
[[Category:Community]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Howto:Understand_the_FlightGear_development_process&diff=72717Howto:Understand the FlightGear development process2014-06-13T20:07:59Z<p>Bigstones: +nav template</p>
<hr />
<div>{{stub}}<br />
{{Working together}}<br />
<br />
The '''FlightGear development process''' is described below, with an accessible language and lots of links to Wikipedia for terms you might not know. To learn more, see [[Release Plan]].<br />
<br />
== Understanding code development ==<br />
=== Code development for the unaware ===<br />
Usually, the process of ''compiling a program'' refers to taking its [[wikipedia:source code|source code]] (written in some [[wikipedia:programming language|programming language]] and running it through a so called [[wikipedia:compiler|compiler]], which compiles, assembles and links the human readable source code to come up with the resulting binary and [[wikipedia:executable|executable]] files, which contain the [[wikipedia:machine code|machine code]] that can be run by your computer (CPU).<br />
<br />
When you simply download a pre-compiled FlightGear release, you do not have to do this yourself, because other people have already done this for you. These are so called [[wikipedia:release management|release managers]], who often also happen to be software developers themselves.<br />
<br />
This is because the process of compiling a piece of software such as FlightGear requires a so called [[wikipedia:build environment|build environment]] which consists of a number of tools (such as a compiler), and custom project configuration settings to turn human readable source code into the machine code that is required for actually running a program.<br />
<br />
Programs are usually written in a plain text editor. However, there are very complex "word processors" specifically designed to deal with source code in various programming languages. They are called [[wikipedia:Integrated development environment|Integrated development environment]]s or IDEs, because they usually also provide comprehensive integration with the build environment, including its various tools. For example, an '''IDE''' may provide integrated support for syntax highlighting, as well as support for running certain commands, i.e. to recompile/rebuild parts of the program (or all of it). In addition, IDEs typically provide support for source code management to access a corresponding respository.<br />
<br />
==== The repository ====<br />
The human-readable source code is stored on a shared place. It's called generally [[wikipedia:Repository (version control)|repository]], and FlightGear specifically uses [[FlightGear Git|Git]] (once, CVS). Repositories do not only store code, but allow concurrent contributions without stepping on each other's toes. In very simple terms, all changes to a single piece of code are tracked, so that people can easily look up who made a certain change, or if there were any changes made in a certain time frame (e.g. to prevent conflicts between people working with the same files). Imagine it like a revision history on wikipedia or the FlightGear wiki: for any changes there's someone who's responsible for it, and if several people made conflicting changes, the software will show the difference to merge things easily.<br />
<br />
This repository does not store only the FlightGear core project, but also other sister ones, like [[TerraGear]], [[SimGear]] and the [[#Understanding the base package|base package]], as well as several related tools.<br />
<br />
=== Normal and core developers ===<br />
People who build FlightGear from source code and make modifications to this source code, are usually called [[wikipedia:programmer|programmer]]s or more generally [[wikipedia:software developer|developers]]. People who have commit rights to the master [[FlightGear Git]] repository, are called ''core developers'' -- because they are the ones who develop the FlightGear "core".<br />
<br />
Other programmers/developers may provide patches to the source code, which need to be reviewed, improved and committed by those core developers.<br />
<br />
== Understanding the base package ==<br />
The base package contains the data: scenery, aircraft, sounds, images/textures, configuration files, scripts. It has its own section in the main repository. <br />
<br />
Most data kept in the base package does not involve any coding/programming, the only exceptions are [[Nasal]] scripts and GLSL [[Shaders]]. However, none of these require a dedicated build environment, people able to run FlightGear, will automatically have an environment suitable to develop and test Nasal and shaders. <br />
<br />
You can contribute to the base package without being a hardcore programmer. See [[Volunteer]].<br />
<br />
=== Configuration files ===<br />
A [[wikipedia:configuration file|configuration file]] provides a convenient interface to customize a program's behavior without having to be a programmer or developer. Similarly, [[wikipedia:command line argument|command line argument]]s are another way for customizing program behavior without having to change a program's source code.<br />
<br />
Imagine it like the difference between a carpenter and someone who merely takes a pre-fabricated piece of furniture (like a chair or table) and customizes it by changing its color, or adding/removing some features. Similarly, just because you are able to refuel your car or change your tyres you would not necessarily be referred to as a "car mechanic".<br />
<br />
So, unless you start modifying the source code (logics) of the program (FlightGear) in order to change existing behavior, your changes would normally not qualify as ''developing'', even changing XML files does not fall under ''development'', because [[wikipedia:Xml|XML]] is a markup (i.e. description) language and not a ''programming'' language. To see what's XML used for in FligthGear, visit [[XML|this article]].<br />
<br />
{{Note|To be absolutely fair, some FlightGear XML files do support programming related constructs, especially condition handling via SGCondition, but also the state machine stuff, as well as the autopilot system, the latter providing various building blocks to come up with configurable autopilot components like PID controllers and filters.In addition, FDM development itself is often done via XML files and can be an extremely complex topic, despite not necessarily involving programming in the conventional sense.}}<br />
<br />
=== Non programming developers ===<br />
People who do development largely within the confines of the base package (i.e. by creating or modifying aircraft/instruments and/or scenery or other base package resources) are usually also called ''developers'', specifying their area of interest. Terms you'll mostly see here are for example ''aircraft developer'' or ''scenery developer'', both of which imply that their work takes usually place in the base package. Some people may refer to them as ''base package developers'' or as ''[[wikipedia:middlware|middlware]] developers''.<br />
<br />
This distinction is largely due to the different set of skills required for producing these resources. While programming and software development in general requires dealing with source code of programs in different programming languages, aircraft or scenery development is no longer primarily about programming. These people don't ''program'' aircraft or scenery, but usually they ''design'' things primarily (i.e. [[wikipedia:3d modeling|3D models, textures]]) and may then add various other resources (such as for example sounds, animations, flight models).<br />
<br />
Programming in this context usually refers to tiny scripted programs that are stored in and loaded from the base package, reusable components often provided by others.<br />
Programs written in such [[wikipedia:scripting language|scripting language]]s are usually not separately compiled, and can be easily created by people new to programming or software development in general.<br />
<br />
== Modding, an exception ==<br />
Of course, you can also literally ''compile'' parts (like certain scenery or aircraft) of FlightGear to create a custom version of it. So, someone who simply takes FlightGear, and who creates a custom version of it by downstripping the base package, omitting certain resources and adding new ones or creating custom configurations, would probably not normally be referred to as a "developer" here. The most appropriate term would be [[wikipedia:Modding|modder]] in that case, because you are "modding" FlightGear to come up with a special version for a specific purpose, without doing any actual "development" like for example C++ coding, Nasal scripting or more generally aircraft/scenery development.<br />
<br />
Normally, "developing" something implies changing functionality and logics, in the sense of "programming" and "creating" things, features and code. Someone who customizes a piece of software by editing configuration files and by adding or removing such files would usually not be called a developer.<br />
<br />
== Developing... documentation ==<br />
If you were now to start documenting your experiences modding FlightGear, you would become a "contributor" and a "documentation writer" ;-)<br />
<br />
[[Category:Howto]]<br />
[[Category:Working together]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Implementing_new_features_for_FlightGear&diff=72716Implementing new features for FlightGear2014-06-13T20:07:31Z<p>Bigstones: +nav template</p>
<hr />
<div>{{Working together}}<br />
<!--<br />
{{WIP}}<br />
--><br />
<br />
We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding, hardware support, backward compatibility etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback. <br />
<br />
Now, we do appreciate any community involvement obviously, even just people making constructive suggestions, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless, too. Indeed, as contributors, we would also appreciate it if it would suffice to just make a suggestion and provide feedback. But that's not how things work unfortunately. Still, most of us went through this whole process at least once, so we do know pretty well what it felt like, including all the frustration surrounding it, i.e. of having some great idea or vision, and seeing it not recognized as/dealt with as such. <br />
<br />
We've had some extremely heated discussions over the years, some debating really interesting ideas and features - and many ending up being dozens of pages in size, containing hundreds of postings. <br />
Nobody in their sane mind is going to dig out such old discussions and spend hours to find the valuable stuff. But often, even such heated discussions may still contain lots of good ideas and suggestions, but sooner or later these debates become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. And even those among us who usually remain levelheaded, may find their valuable postings remain unnoticed in such threads.<br />
<br />
In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form. Basically, some of us have literally wasted dozens of hours trying to contribute to such discussions in order to provide some direction, to no avail however.<br />
<br />
We are now trying to document how "bootstrapping" a feature or project works ''conceptually'' from having an idea to turning it into a feature, i.e. implementing new features for Flightgear from a high-level standpoint to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own, and without necessarily having been a part of the community for years (or even decades). It's been shown that this particular model also seems to work for newcomers.<br />
<br />
Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which nobody really came up with, but which is just a convention that happens to "just work" for all contributors, which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens", so any form of coordination, networking and collaboration must be self-directed, too.<br />
<br />
Currently, this article is mostly based on a write-up that Thorsten contributed based on having worked on a variety of novel, and unprecedented, FlightGear features over the years which initially also didn't receive much support at all, and which also caused lengthy discussions (or even flame wars) on the forum and the devel list, including features like [[Advanced weather]], [[Atmospheric light scattering]], [[Procedural Texturing]] and most recently the [[FlightGear Newsletter April 2014|EarthView]] orbital rendering engine. None of these were implemented through so called core development, which would typically mean that people change/write C++ code and have to recompile the FlightGear source code. In fact, one could see that all of these changes could be qualified as so called "mods", even though all of them have meanwhile become an official part of the main FlightGear distribution.<br />
<br />
These are just a few examples to put some context around the advice given here. Also note that the people who contributed to this particular write-up are not FlightGear core developers per se, we are also primarily middleware/base package contributors, i.e. contribute to those part of FlightGear that are typically considered very "accessible", as you don't need to be a programmer to make a meaningful contribution. This means that making changes to these parts of FlightGear typically involves editing text files (XML, scripts, effects, shaders) or textures (images), sounds or 3D models.<br />
<br />
And when we started out a few years ago (and several thousand forum postings back), we were also highly critical about [[How the FlightGear project works|the way the project works]], and all its obvious shortcomings. And now, we're often the ones being "yelled" at on the forums when dealing with newcomers, even though that's exactly how we started out. <br />
<br />
Yet, fast forward 5+ years later, we are still trying to contribute in meaningful ways to the project, despite some (or even many) of these problems still persisting even today. So this is an attempt to provide a '''lessons learnt''' intro based on newcomers becoming contributors, turning their ideas into features that actually end up in FlightGear, without having to be expert programmers necessarily, or even programmers at all, and without having to be familiar with FlightGear.<br />
<br />
== What is this about? ==<br />
<br />
Like many FG users, you probably reach a point when you think 'Wouldn't it be nice if we had feature XY?' From this point, there are various options available:<br />
<br />
* You mention it in the forum: <br/> A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there. Some may point you to past discussions to provide a few pointers.<br />
* You make a formal feature request on the issue tracker: <br/> The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen.<br />
* You make it your own project to get feature XY implemented: <br/> This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on.<br />
<br />
== Some (unpleasant) truths up front ==<br />
First, to avoid disappointments, it is important to understand how FG as an OpenSource all-volunteer project works - if you start with your project without understanding these essentials, it is bound to fail.<br />
<br />
# Flightgear relies on having a contributor base, but not on a user base: <br/> Unlike a commercial project which needs customers to survive, FG does not. A commercial project is sustained by paying customers, so that the company can pay its workers. In FlightGear, "workers" are generally not paid. And a self-sustaining project depends very much on contributors. As a result, FG development is not focused on the end user. Developers, and other contributors, tend to work on ideas and features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting. And this is something that is generally true in the wider context of the FlightGear history: technology-enablers improving accessibility and usablity that ended up getting more people involved, generally helped the simulator and community to grow over time.<br />
# Developers are free to do what they want: <br/> This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily (this is for example how this article came into existence, without the person suggesting it, being originally involved in creating it).<br />
# Flightgear development tends to be inclusive: <br/> There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers).<br />
# FlightGear being not focused on end-users, it may often not be as accessible/usable as a more polished/commercial piece of software. This has several reasons, which are explained below.<br />
<br />
Obviously, we would all like to have a flight simulator that provides for an experience that doesn't involve a steep learning curve. <br />
<br />
Often, people tend to compare usability (or lack thereof) to some great GUI tools available in proprietary simulators. Historically, however, we've learned that implementing such extremely high level end user features doesn't scale all that well. We've seen several years of time spent developing high-level features in C++ space that got quickly re-implemented, or even replaced, once middleware developers had sufficient tools at their disposal to customize the simulator through XML and scripting (for example, the existing weather system is more feature-rich than any previous weather system developed by core developers). Besides, it generally works better for the community to reuse existing tools whenever possible - no matter if it's Blender for 3D modeling, Inkscape for vector graphics, GIMP for texturing, or even just a conventional text editor for XML/script editing. Coming up with such tools from scratch, as is common in commercial software projects, would be a huge effort - obviously, having to use generic tools, also means that usability may lack at times. A couple of examples are given in [http://forum.flightgear.org/viewtopic.php?p=211165#p211165 this forum post] and the following one, dealing with this very issue by telling about what happened when it was attempted to make development easier with terrain texturing and the Canvas system.<br />
<br />
What this means is that developing high-level end-user features through core development often doesn't scale as well as using existing tools, customize those or just exposing the infrastructure required to allow middleware developers to implement certain features directly through existing FlightGear extension mechanisms. <br />
<br />
Which is a win/win for both sides, because core developers get to do core development, freeing them from having to develop end-user features, while middleware developers get to evaluate end-user requests and implement popular requests.<br />
<br />
== Test the waters ==<br />
<br />
If you want your idea to be part of Flightgear in the end and not a fork or an addon, test the waters early on. Working for a year on some project which won't be committed in the end is frustrating for both sides. Use the forum or the mailing list to talk to people, get a feeling for how the response is, just don't leave it there. And make sure that you're aware of who you're talking to, there's often a ton of end-user feedback, but little development from other contributors, which is however the only thing that matters to get your work accepted and included. <br />
<br />
It is always a good idea to announce your project on the forum, you can also use the [[Newsletter]] to make announcements. If your project/idea is in any way about software or the base package, another good idea is becoming familiar with using git and gitorious and using it to conduct development in the open, so that others can track your work and provide feedback. This in and of itself demonstrates to long-term developers that you are to be taken seriously, because your development process is transparent and can be easily tracked.<br />
<br />
Some events that have occurred in the past, and what to learn from them:<br />
<br />
* Beautiful airport scenery (and certain aircraft/cockpits) could not be committed, because it was textured using material from a source that has free textures with a no commercial use clause. This however is incompatible with FGs GPL license which permits also commercial use. Lesson: If you use any material other than your own work, check the license early!<br />
<br />
* A large collection of Swiss airport scenery could not be committed because it was structured in the wrong way - scenery data has to be submitted in a certain format to the scenery database, other data to the FGData repository. Lesson: Study the structure of FG - don't expect that the whole structure of the project will change for you, it is what it is for good reasons, even if you don't know them, others do. <br />
<br />
* The bombable addon providing support for air combat could not be committed because the devel community feels strongly that FG should remain a civilian aviation simulator. Lesson: Test the waters, see what the response to an idea from developers who can commit are. They will decide, regardless of what users say.<br />
<br />
* Huge patches for novel features were announced shortly before a release, providing little time to thoroughly test and integrate the patches in time for the release, while also creating a huge workload for other developers who were not aware of the effort, and may have made conflicting changes in the meantime - something like this can be prevented by using gitorious regularly, and by getting touch with other developers to make them aware of your plans, but also your implementation strategies - ideally, asking for feedback on how to proceed best in order to avoid coding conflicts.<br />
<br />
== Gather information ==<br />
<br />
Regardless if you want to proceed on your own, or if you want to find people to help you - you need information. If you want to see a new visual effect implemented, at minimum you need to find out who inside the FG project can help you, even better is to have an idea what options FG provides, how the effect framework works, how effects are configured etc. The Wiki is your friend, but usually if you show some interest, people in the forum will post helpful links. If you want to be taken seriously later, work through the information and make sure you know what you're talking about. It is also a good idea to look up who's previously done related work, or who's recently been working on similar ideas and projects, so that you know who to get in touch with. Usually, other community members will be glad to provide pointers to related projects and their contributors.<br />
<br />
<br />
== Make a proposal ==<br />
<br />
Now it's time to approach the people who can help you. Remember - they're volunteers. So you need to get them interested. <br />
<br />
Do...<br />
<br />
* ... point out how your idea will make FG a better simulation.<br />
* ... make a point out of what you would be willing to do if only XY were available.<br />
* ... be as concrete as possible, point out what precisely you would like to see changed.<br />
* ... demonstrate that you have looked at the relevant information and know what you're talking about<br />
* ... provide a summary of your main ideas using the wiki, in case the discussion leads nowhere, people can still pick up the whole thing at a later time<br />
<br />
Don't...<br />
<br />
* ... demand anything from anyone.<br />
* ... be rude or angry if people are critical - it's part of the process.<br />
* ... point out how bad FG is going to be or how it will fail if your idea is not implemented<br />
* ... say that you're going to abandon the project or switch to a commercial product <br />
* ... say you can't do anything, because you don't understand C++, coding or XML - the human mind can learn<br />
<br />
Compare 'Wouldn't it be cool if we had better-looking cities like X-Plane?' with 'Would it be possible to make the random building shader configurable such that it loads a pre-defined set of 3d models and assembles them in naturally looking groups by a placement mask of this and that format? I would then take care of the buildings and textures, but I'd need some help with the code. Here's a picture of how FG could look like.' - which of the two proposals would you support?<br />
<br />
<br />
Even good proposals have a fair chance of failing to get any support. The reason is that experience has shown that the majority of people who say that they would do X if only feature XY is implemented do in fact not do X afterwards. Which is to say, before starting to join a project, developers want to be reasonably sure that their work will not be in vain because you lose interest and walk away. The magic words here are 'track record' and 'proof of concept', you can help improve you signal/noise ratio significantly by ensuring that you follow up on your commitments and do the necessary behind-the-scenes networking to implement a new feature or project. <br />
<br />
It is this combination of having a track record, or "credit", and a good signal/noise ratio that will ultimately give you certain ''leverage'' when interacting with other contributors.<br />
Overall, time spent contributing to the project really '''is''' our "currency-it shows dedication and discipline and it demonstrates to potential collaboratos that you are serious about your commitments, and that teaming up with you is not a waste of their time. If properly done, such networking can be a great multiplier/lever.<br />
<br />
If you already have a history of bringing projects to a conclusion, people are far, far more likely to support you. If you have not, because you're just starting out, the best thing you can do is a proof of concept. Perhaps something should really be in C++ for performance reasons - but you can make a simple proof of concept in Nasal scripting space. Once people see that you're actually investing time and work rather than talk, and once they can see what you want to do, you're again more likely to get support.<br />
<br />
Finally, proposals failing may still happen for other reasons, such as bad timing, lack of man power, people being busy with other aspects of FG or RL etc.<br />
This happens even to long-term contributors regularly, including core developers. <br />
<br />
== Getting People involved ==<br />
One of the most common show-stoppers preventing people from succeeding with their ideas, feature requests or projects is the lack of networking, and the unwillingness to compromise and make sacrifices. <br />
<br />
The common pattern we get to see is that people want '''their''' particular idea to be implemented immediately, expecting others to drop pretty much anything else and provide first-class support to them. <br />
Obviously, this is not how things work - just imagine for a second, somebody were to ask you to drop your own ideas and projects in favor of some random new idea, in a volunteer project.<br />
<br />
{{cquote<br />
|<nowiki>the main problem seems to be "tunnel vision", things have to be done in a certain way or they're considered inferior inevitably, which also isn't helping - but technically, we have more building blocks in FG to create a dogfighting WW2 environment than we have building blocks for any modern airliner simulation. If you don't believe me look up any well-developed airliner, and check those todo lists - the majority is about FG issues, i.e. things that cannot be worked around easily. </nowiki><br/><nowiki><br />
In fact, in the pre-Canvas days we had clever guys like omega95 who used massively complicated XML animations to come up with a navigation display, despite lacking a 2D drawing API. But that was basically a dead-end. </nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
And even in the Canvas days, there's a ton of stuff that isn't currently supported easily. A WW2 simulation would not encounter many real showstoppers, there's a ton of stuff that can be accomplished even without any explicit support, as can be seen in flug's bombable addon - he never got any support from core developers to pull all that off, it's all his own work, representing probably hundreds of hours of testing, designing and coding.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207692#p207692<br />
|title=<nowiki>Re: Trouble at EDDF-Triangle</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Thu May 01</nowiki><br />
}}<br />
}}<br />
<br />
However, there '''is''' a way to have your cake and still it eat, by going more slowly, and by sharing.<br />
<br />
To get people involved, you need to get them interested, and you need to motivate them. <br />
<br />
People are not just motivated by '''ideas''' but by actions that materialize, and short of that, by saving their own time.<br />
Sometimes, it may be helpful to not just introduce the final outcome, but also the pathway to make it happen.<br />
<br />
Usually, most contributors have different ideas about FlightGear, and very different priorities, skills and expertise. <br />
<br />
So the point really is compromising. Finding overlapping areas of interest, i.e. common goals. Very often, that means that people may not directly work towards the original goal/project (such as for example an improved multiplayer system, a weather system or even combat support), but rather some interim milestones, as part of some longer-term '''roadmap''' or bigger picture.<br />
<br />
That way, contributing becomes pretty much a '''journey''', where you may meet people willing to accompany you for a certain time, task and project, until their own goals have been reached, or until they join some other effort (or even project). Sometimes this journey make take a few months or even years, but often it's really just a few weeks or even just days that someone finds some of your project overlapping with his own goals and interests, such as for example programming shaders/effects or doing Nasal scripting or helping with [[Canvas]] related projects.<br />
<br />
This may seem frustrating at first, but you should cherish such opportunities, no matter how short-lived they may be, for they provide an excellent networking opportunity, getting more people involved in your project, but also to become better known to fellow contributors.<br />
<br />
In retrospective, this is exactly how some of the most popular base package projects took shape recently, despite a lack of momentum initially: People were willing to compromise their original goals by talking to others who had somewhat overlapping, or at least sufficiently similar, goals and found a way to collaborate to a certain degree, even though every contributor would still keep his own long-term goals and priorities in mind. Sometimes, this requires a significant shift in thinking and creative or very unconventional ways to explore a new solution space. <br />
<br />
In general, it is unlikely that you'll be able to directly form a team of people who fully share your motivation, goals and roadmap - and even then, you may find yourself missing other components that are required for a successful project, such as expertise in certain areas (3D modeling, texturing, programming, scripting, effects or shaders etc). <br />
<br />
This is why you'll typically have to reach out to other contributors and ask them to get involved. And this is also exactly where most people fail right from the beginning: because they're more focused on their own goals and projects, than demonstrating to fellow contributors, how they can help improve others lives, i.e. by learning more about other projects and efforts, and potentially overlapping areas there, to contribute to similar projects first, before asking others to contribute to theirs.<br />
<br />
Typically, this means that you must be willing to adjust your own priorities - while it may seem of utmost important to you to work on feature X, some other contributor may be more interested to work on something that you don't consider extremely important, or maybe even making concessions that you don't consider acceptable (such as e.g. supporting mouse-control in a combat sim, or using scripted code to implement a space rendering framework) - this is where most people fail big time, discussions start becoming enormous, vocabulary harsh - and at some point, there's no collaboration feasible anymore. Potential contributors with a track record often start losign interest quickly, so that the whole project gets killed quickly, or is left with zero manpower - just with people having ideas and "visions", but nobody able to actually implement them.<br />
<br />
But this is one of the most important aspects of successfully "bootstrapping" a new project: finding overlapping areas, contributors who can help with related efforts, and making compromises, i.e. accepting that you have to walk before you run. <br />
<br />
Conceptually, this boils down to thinking in terms of components, i.e. "building blocks", that need to be established in order to accomplish something. It is very likely that a dozen unrelated projects may benefit from very similar building blocks, depending on the viewpoint - typically, there's at least a handful of needs that projects may have in common. Sometimes, you may need to extend your own plans beyond what seems reasonable to you, while limiting your original goals to a subset of the original idea, just to get something started. <br />
<br />
Note that this doesn't have to do anything with programming, '''building blocks''' can just as well be non-coding items, like textures, sounds, instruments, 3D models etc.<br />
<br />
Successful contributors realize that such overlapping areas are an excellent opportunity to get others involved, but also to get involved in other projects, that may not be directly related to their own area of interest - i.e. to learn a new skill, or even just introduce yourself to a contributor with a known track record and certain skills, to pave the way for future collaboration.<br />
<br />
For instance, some of our most active contributors have very little time to provide support to end-users or even just to maintain their documentation, this could be a great opportunity to introduce yourself to a contributor - you're demonstrating that you're interested in contributing, while also saving them some time, so that they can work on other projects, so that you inevitably show up on their "radar". <br />
<br />
There are some contributors who have never contributed to the software itself directly, still they managed to shape the project through lots of feedback, simply because they have become important in other aspects of the project, which are also important - no matter if it's the forum, the wiki or other aspects of the infrastructure surrounding the project.<br />
<br />
Still, there may be areas with little, if any, momentum and where networking doesn't seem feasible, this is where you may have to make an upfront investment to get other contributors involved, i.e. reach out to re-implement/replace features or infrastructure with parts of your own work. This is basically a pretty safe way to get more eyeballs involved.<br />
<br />
== Be persistent ==<br />
If you fail to get help you need, think about why-and don't take it personally. There may be fair reasons for it - your priority may not be everyone else's priority, or some criticism may not be mean but actually valid, or your contribution isn't apparent enough - go back and try to revise the proposal. If you can't get help in some area, perhaps there's a workaround which is less perfect? Nasal scripting often is a viable alternative to C++, and subsystems can always be converted later. Trying to get things perfect up-front is likely to get you nowhere, because making things perfect is very hard - starting with something 'good enough' and improving it is more likely to succeed. If your project is truly good, it will get support on the way. Investigate your idea critically, but if you truly believe in your idea, stay with it and make it work in some form, i.e. to build momentum over time. Seriously, the perfect is the enemy of the good here - we've seen countless of good proposals that simply failed because people were not willing to make concessions, people would see problems with any workaround and imperfect solution suggested by others - so what they ultimately got in return was a "perfect" design, discussed across hundreds of postings, usually wasting dozens of manpower hours of in the process.<br />
<br />
As an example, in the beginning the idea of using Nasal to implement a full weather system was not taken seriously by anyone in the development community. Once written in a very inefficient but working way, the system however did get lots of help from developers on the C++ side and is now known as Advanced Weather, one of the most sophisticated weather systems which exist in a flight simulation.<br />
<br />
Likewise, one of the most-heated discussions in the history of the FlightGear forum involved bringing space flight or combat support to FlightGear - these discussions took place over many years, brought up by various individuals - but most people would only see the limitations in the suggested approaches, so that the system they envisioned was never implemented - and in retrospective, it would have taken them a tiny fraction of the time spent debating with others to come up with a very basic working prototype, which is a great momentum builder.<br />
<br />
== Honor your commitments ==<br />
<br />
This should go without saying but: Keep your end of the bargain. Seriously. If you got someone to do a month of work for you because you proposed it would enable you to do XY and you in fact don't do XY later, that's pretty much it - no one will ever lift a finger for you from that point. This may never be publicly discussed, but people will notice it and will refrain from collaborating with you once they have witnessed something like this. If you cannot make some deadline, it's better to be candid about it and announce it early-on, ideally offering to catch up ASAP or offer to volunteer somewhere else instead.<br />
<br />
== Release early, document your efforts ==<br />
<br />
Use the forum and/or the wiki as a platform to show people what you are doing and how you are progressing. People need to be aware of things before they can help you, and you may get useful pointers just at the expense of posting your current vexing problem in the forum. It is also always a good idea to do a forum/devel list search to check the archives for related discussions that took place in the past, this should give you a good idea on discussed approaches, but also people involved in these discussions (and if they're still around or not).<br />
<br />
While the forum and the devel mailing list are great places for discussions, there are sometimes topics that have been discussed at great lengths, this includes topics like multiplayer improvements or even combat support for example. <br />
<br />
For such popular discussions, there are often 5-10 threads per year on the list/forum with typically dozens of responses. Another popular debate is better multi-threading support, but also scenery improvements, providing better end-user support and accessibility, improving hardware support for lower-end hardware, funding/crowd-funding/sponsporship schemes and even setting up a non-profit to help FlightGear.<br />
<br />
Accordingly, given the popularity of these topics, there are typically hundreds (or even thousands!) of postings and statements that have been made over the years. <br />
<br />
Often, with little -if anything- materializing from such debates directly, no matter how good the discussed ideas were. Postings may contain good suggestions, useful feedback, but also lots of controversial arguments. <br />
And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved.<br />
<br />
Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of actual features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time. <br />
<br />
'''Time''' really being the keyword here - some topics are not about a single isolated feature that can simply be implemented by some random developer, those are often large-scale architectural changes, or even proposals to change parts of the project's philosophy (see [[Release Plan]]) or some of its infrastructure (e.g. the [[FlightGear Build Server]]). Thus, these topics are often not about people disagreeing that something needs to be done, but the suggestion really is a long-term item, that needs to be tackled over time - typically many months, often several years and also by different people.<br />
<br />
Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time, while providing an entry point for people interested in a certain topic. For instance, some of the aforementioned flamewars ended up having ~4000 views in over 2 years, compare that to wiki articles covering the same topic, getting 12k views in just a few months. Go ask yourself, how would you prefer to be introduced to some novel idea that you may want to work on at some point ? <br />
<br />
We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA and reset/re-init efforts are other ongoing examples for this. Typically, complex ideas may very well have a shelf life of several months - often even, 12-18 months. The [[Canvas]] system only took shape 18 months after it had been introduced on the FlightGear wiki for example.<br />
<br />
Thus, sometimes good ideas may take time to materialize, for momentum to build up - and whenever timing doesn't seem to work in your favor, it's a good idea to let time work for you instead, by creating a corresponding wiki article to document something, and maintaining it over time, e.g. by adding links, quotes or references to related discussions. To provide another example: We've had various discussions on coming up with a scenery build server, and this is something that is slowly starting to materialize now - largely thanks to having a dedicated wiki article presenting an overview about past discussions and ideas, and all this took really just a few months - but those were spread across almost 3 years now. But the wiki article allowed us to still build on existing ideas and discussions, without requiring people to spend hours in the archives.<br />
<br />
Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release.<br />
<br />
If you made it to this point, you may perhaps appreciate much better why the devel community is how it is!<br />
<br />
== Collaboration and Consistency ==<br />
<br />
{{cquote<br />
|<nowiki>people won't change a single thing by just debating - even if they should be completely right. And being ignorant about how the project works behind the scenes, will not help much either. This is not to say that we all "like" the way the project works, but the way things are working is not by conscious decision, but due to people caring about their own stuff, with little to zero interest for getting involved in other projects. Simple as that. It is the few cases where people manage to work around such issues and actually collaborate that FlightGear is shaped in major ways. Nasal, Canvas, NavDisplay and MapStructure are testimony to this working extremely well - but it's tedious and not exactly "fun" to work like this - just ask TheTom, Gijs, Philosopher or myself: It is much more fun to focus on our own little projects than keeping the big picture in mind and coordinating things behind the scenes. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211164#p211164<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>the thing is that consistency is a b*tch to get "right" <br />
<br />
There are obvious areas like backward compatibility where consistency would help us a great deal.<br />
<br />
But being consistent takes a great deal of work, not just in your own working areas, but especially in other areas that you have never touched.<br />
Being consistent takes a lot of time, dedication, discipline and skill and a ton of networking. And it really isn't fun at all <br />
<br />
We have an infinite number of examples for this being the case in FlightGear. It's not just our lack of standardized XML processing.<br />
The whole MP/MMO debate is basically about the same thing - competing/conflicting features that never got updated and integrated, so that they end up crippling each other.<br />
And we end up having a dozen way to "skin a cat" semi-properly <br />
<br />
Being consistent means that "coding" (or even 3D modeling or developing FDMs) is suddenly no longer "just" about your own work, but looking at all the other places and potential use-cases in FlightGear that may benefit from it, including stuff that you never used, and never intend to use yourself.<br />
</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>To see for yourself, just ask yourself if any of your recent work (textures, 3D models, livery packs, FDMs, FDM components, autopilots, scripts, instruments or aircraft) can be easily used outside the context/scope that you designed them for originally ?<br />
For instance, how easily can your aircraft:<br />
support being used by the AI traffic system ?<br />
support different liveries, liveries over MP ?<br />
dual-pilot use across multiplayer ?<br />
the weight& balance dialog ?<br />
the replay/flight recorder subsystem ?<br />
checklists ?<br />
autopilot dialog ?<br />
the bombable addon ?<br />
...<br />
<br />
These are all features in existence today that could be supported by aircraft developers - but most contributors only really scratch their own itch understandably <br />
And that's really just the non-coding side of things - for programmers, pulling off consistent designs is often even more difficult.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>As a coder, you permanently need to re-evaluate your own design and look at other/similar features, and see how those affect each other potentially - and be willing to modernize and re-implement certain stuff.<br />
<br />
There's stuff like our networking stack, and the I/O system, along with its generic protocol system - and a httpd/telnet system, and of course the multiplayer system. All of this came into existence at different times - so are hardly integrated, even though they're sharing almost identical requirements, and could be re-implemented on top of 3-5 building blocks probably.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>The thing about consistency is that it needs to be future-proof, too - i.e. in case someone leaves the project for a while, or even completely abandons a project.<br />
<br />
And that's when becoming a "visionary" is almost as important as being a "designer" of some new project or feature.<br />
Which also means that solutions must not be "lock-in" solutions, but need to be sufficiently well-understood and documented to either allow others to review/maintain them over time, or let them completely revamp/replace them if needed.<br />
<br />
We always tend to see the problems in solutions that others come up with, but refer to our own contributions as "hacks", "workarounds", or more eloquently, "prototypes", even though they typically have the same issues and effects on projects and features developed by others<br />
<br />
Yet, those very "prototypes" often end up being around for several years until someone comes up with something better or some major improvement.<br />
At the end of the day, we're all just that: lazy human beings - and volunteers at that, too - i.e. we are really only motivated by stuff that's not a chore, but it must be fun.<br />
<br />
So you end up with a huge herd of cats that don't want to be organized at all ...</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Then again, there are a few people doing the unpopular "grunt" work here, i.e. constantly refactoring things, and permanently looking at the bigger picture to generalize stuff over time.<br />
However, their work is usually not at all "visible" or even compelling to non-developers, often not even to developers.<br />
<br />
We're really here to scratch our own itch and not contribute to some "global cause" that we may never benefit from at all.<br />
<br />
Asking for better and more consistency is however exactly doing that: asking people to drop the "interesting & fun" stuff in favor of improving things for the long-term, without them necessarily benefiting from such work (or without it being obvious to them). Understandably, that's kinda frustrating - not just for the people asked to do the work, but also for those asking for it </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>magine for a second you had spent 18 months working on a new project/aircraft/feature, and everybody is proud of your product, but suddenly someone comes around and says something along the lines of this is all great, but it's not future-proof, what you should really be doing is neuter the whole thing, split it up into a dozen modules, generalize each component to make it accessible to other users, and please don't complain about regressions - there certainly will be many, and we won't have much time to help you, but it's basically the right thing to do, and it needs to be done ASAP<br />
<br />
This is pretty much what's happening to many developers who come up with useful, but non-generic, stuff - especially in a healthy software development environment, where people are constantly reviewing their own code. We've had many such discussions here in the past, i.e. when the random buildings system got first introduced, Thorsten and I were the ones discussing potential scripting hooks to make it less random and expose it to scripting space, so that placement heuristics could be based on other data (i.e. OSM). Back then, that was not a popular thing to ask for, the response was "this only has theoretical merits..." - 3+ years later, this is what people are looking into now <br />
<br />
So being consistent really is a painful thing unfortunately, because it means more work, less time for interesting stuff, much more networking - and the outcome may still be uncertain, and it may cause frustration among contributors, too.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>For instance, when one aircraft developer came up with the new NavDisplay code, we had been talking with Zakalawe about doing kinda that as part of the map dialog - and I was pretty frustrated seeing code that was more complete than mine, but on the other hand much less generic (not as re-usable), i.e. it being aircraft-specific, single instance, single style, too slow etc <br />
<br />
And raising my concerns, the 747 developer was the one saying "not a high priority for me" and next: "but, ok be my guest" (which is very common around here!).<br />
<br />
So that's how the whole shebang got split up into ~20 different modules, introducing a plethora of regressions/bugs (that he gratefully ignored!), slowing down his progress and overall development by at least 6 months in the process, and introducing a degree of complexity, so that the original developer no longer felt responsible for the modified code, or even refused to work with it afterwards <br />
<br />
As you can imagine, this sort of thing ...case.<br />
<br />
So, all the while we'd been trying to be more consistent, and then that - and looking at the extra500 commit history, we're apparently having a hard time inviting them to be more consistent by adopting our framework now.<br />
<br />
And that's what kinda everybody is going through here - Thorsten also mentioned various times that it would be so much easier to just code his own stuff than having to maintain compatibility with other/similar or even conflicting features (e.g. basic weather/rembrandt).<br />
<br />
It really is hard to understand why we should accept such issues without being also paid for all the frustration resulting from all this<br />
<br />
Honestly, consider this a freakin' petri-dish in which software evolution simply takes place and you'll have a much better time</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209490#p209490<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>The Canvas/MapStructure work is another example for this: for over a decade, we've had various hard-coded instruments, a hard-coded GUI library, and certain 2D rendering code that could only be used within a fixed context, like 1) cockpit, 2) GUI, 3) scenery. It's only recently -thanks to canvas- that this is being unified and re-implemented, to hopefully get rid of a plethora of legacy features and modernize them through canvas and scripting space wrappers.<br />
<br />
Previously, people could not render an instrument/HUD in a dialog, or vice versa - yet, this is a key feature, because supporting recursion means that even features like interactive map editors can share the same back-end code. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term.<br />
<br />
This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code.<br />
<br />
But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209465#p209465<br />
|title=<nowiki>Re: scaling instruments in xml</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed May 14</nowiki><br />
}}<br />
}}<br />
<br />
== Some context on different perceptions ==<br />
<br />
<br />
Assume you have this interesting feature in mind which is not in FG. Chances are, you assume that just nobody thought about having it before. Chances are however that this assumption is wrong (a rough estimate would be that perhaps 5% of the suggestions are of that type). People working e.g. with shader effects have spent thousands of hours working with rendering code and usually have a habit of comparing nature and FG to see how to improve things. They also know what other games do and have read books and tutorials on GLSL shaders. So what's the case most of the time is that if a feature is not there, it failed a cost-benefit analysis - either it's not interesting enough so that it's low on a to-do list, or it would cost too much framerate to implement it, or too much coding time. If it'd be interesting and easy to do over the weekend, someone would have done it already. As a result, the reaction to simply suggesting the feature will be along 'Oh yeah, thought about this a while ago, not so interesting...' So if you want to change this, you have to understand and change the cost-benefit analysis.<br />
<br />
=== Case study - about empowering the masses ===<br />
<br />
{{cquote<br />
|<nowiki>If the coders here at FG spent their time (1000 hrs) making the aps / tools that take all the coding out of making stuff, then the modders those with little coding knowledge would spend the 3000 hrs doing the rest.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211072#p211072<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>Bomber</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Basically, that's what's been happening over the last few years in various areas, especially canvas - however, rather than focusing on "tools" or "apps", developers tend to focus on infrastructure and building blocks - often using existing standards and established technologies, so that existing tools can be used, without those having to be coded from scratch (XML=>XML editors, Blender/AC3D, textures: GIMP, sound editing, GRASS/QGIS etc)</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211075#p211075<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Thu May 29</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Here's my personal experiment with this: Making terrain texturing look better. After a few years of coding and nagging others to code, we now have</nowiki><br />
<br />
* xml-configured regional texture definitions<br />
* general-purpose xml-configurable effects for the terrain<br />
* and the best - all controlled from the same file!<br />
* and the whole thing documented in the wiki<br />
* and my personal help for people who want to do it in the forum<br />
<br />
<nowiki>It's the classical grunt task - most of the actual work is gathering aerial imagery of an area, finding or making the textures you need and lots of trial and error with different texture schemes - almost zero coding requirement, the necessary xml you can pick up in an afternoon if you don't do cut and paste. And it makes a hell of a difference for the visuals of a region, more than any amount of CORINE data or static models can do.<br />
<br />
The net effect is that I still do 90% of the regional te...s me is a few days.<br />
<br />
Some folks use it for custom scenery, and every once in a while someone makes a definition that can actually go to GIT, but it's really the opposite of what you claim to be true - there's lots of time invested in an easy-to-use tool which enables people to make 'their' region much better - and what happens is that nobody uses it.<br />
<br />
It's simply not true that the grunts would appear and start working if only they had the proper tools / the documentation / the whatnot. The fact of the matter is that I've almost never seen it happen, so by now my prevalent philosophy (born from that experience) is that I want to see very solid evidence that someone will actually use any tool requested from me before I consider coding it.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211165#p211165<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>Thorsten</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>We've actually tried that with the MapStructure framework, which is rather extensively documented now, and which even provides kind of a "plugin" or "module" system, where people can easily add their own map layers for custom stuff. While the documentation is obviously very popular (14k views within just 6 months), we still have to see someone else step up and actually adopt the system. Admittedly, FlightGear 3.2 is going to be the first release that will provide most of the building blocks required here, but currently it doesn't seem likely that there will be dozens of modules provided by others, despite us having taken the time to work out a system, and document it rather well. Still, I don't regret having spent that time, because the contribution is at least "future-proof" that way - i.e. it doesn't matter if we're around or not, because people can look up all the required info and actually understand the code sufficiently well to improve/maintain the system, or...d of seeing someone contributing something back is exponentially higher once certain criteria are met, i.e. either a corresponding track record, absent that, a strong willingness to follow advice, or at least acquire knowledge and follow pointers. <br />
<br />
Ultimately, the question still boils down to motivation - we've seen some very experienced contributors/core developers who agreed that certain features would be "good to have", but who still didn't care enough to actually work on those - at least, they stated so upfront <br />
<br />
Seriously, the same people asking for GUI tools like an aircraft, scenery, texture or mission editor are usually the same ones who refuse to use existing tools like Blender, GIMP, QGIS/GRASS or even just a good XML editor.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211169#p211169<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
=== Case study - when is rendering simple? ===<br />
<br />
A fairly recurrent question is why, with all the rendering effects we have on models, we don't have something simple as a reflection in water. After all, the math to determine the varying colors of a cloud at sunrise dependent on whether the light shines through them or not is university level, one needs to solve two nested integrals for the correct answer, whereas everyone knows how to compute a reflection.<br />
<br />
The problem is that real-time rendering is not simple when the math is simple, but when it can be parallelized. Graphics cards are built to solve a particular problem very fast - when a ray from the eye (E) hits a surface (S) and then is tracked to the light (L). If at the pixel location the surface normal is known, all relevant vectors are knows without having to know anything else about the scene, the computation is purely local and can be parallelized. So whenever an effect uses an ESL situation, it is simple to implement.<br />
<br />
Water reflection however needs to compute at minimum ESSL (follow the light from the eye to the water, then to whatever is reflected in the water, then to the light). Raytracing codes solve these problems just fine, they track a large number of test rays from the first surface hit to everywhere else in the scene to see where the reflected light comes from. However, that doesn't run real time - if you use 10.000 test rays, the computational effort goes a factor 10.000 up and the framerate down by the same factor. What's perfectly okay if you can take a minute to render a picture is not if you need 60 per second.<br />
<br />
There are ways around this, for instance shadows are also ESSL problems, and they can (approximately) be solved by techniques like a shadow camera pass in deferred rendering (Rembrandt in FG) - then the scene needs to be rendered just two times, which is a more acceptable value. But then this needs lots of additional resources and cleverness.<br />
<br />
Lesson here: Many things which look (and even are mathematically) simple to do are not implemented because they are not as far as real-time rendering works because they are not ESL, and hence their cost-benefit analysis is judged poor. Clouds reflecting in a pool of still water are a cool effect but - would you work half a year for coding it and have your framerate reduced by half - would that still be cool?<br />
<br />
(Side note: Plenty of first person shooters and racing games can run very fancy 3d effects. However, they can also run very agressive optimization because your movement is very restricted to 'levels' - so the fact that game XY can do something doesn't mean that FG where we need to render scenes from the ground into orbit can do the same thing.)<br />
<br />
<br />
<!--<br />
== Advice for Developers ==<br />
=== Aircraft ===<br />
=== Scenery ===<br />
=== Effects / Shaders ===<br />
=== Nasal ===<br />
=== C++ ===<br />
--><br />
<br />
[[Category:Development]]<br />
[[Category:Working together]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=How_the_FlightGear_project_works&diff=72715How the FlightGear project works2014-06-13T20:07:10Z<p>Bigstones: +nav template</p>
<hr />
<div>{{Working together}}<br />
As FlightGear is becoming increasingly popular each year, we've been seeing a number of controversial discussions regarding the inner workings of the FlightGear project recently. Meanwhile, it is a well-known fact among long-time contributors that the FlightGear development model may seem irritating at first and it is known to cause some confusions or even frustration among new contributors who may already have experience contributing in other flight sim communities or even other OSS software. <br />
So here's a collection of responses intended to clarify why things are set up this way. People interested in getting involved in the FlightGear community and contributing in one way or another, are encouraged to read this and understand how FlightGear has been able to be successful despite the fact that it does not have any commercial backing or a really structured development model.<br />
<br />
A more succinct version of this article can be found at: http://forum.flightgear.org/viewtopic.php?f=42&t=15267 (which serves as a really good introduction, people interested in more details, may still want to look at the text below).<br />
<br />
== Background ==<br />
As FlightGear is getting increasingly popular, we get to see new users coming to our forums and the mailing list every week. Many of them quite obviously very much interested in contributing to FlightGear in one way or another and getting involved in our community.<br />
<br />
This is something that all of us appreciate, because this is important to keep the project alive and kicking, so we do truly appreciate and welcome new community members, because this is an important part of enabling FlightGear to grow even more popular. <br />
<br />
There's such a huge range of ways to get involved in FlightGear, so that we truly appreciate everybody's skills. <br />
<br />
Please don't think that you cannot contribute to the project, because you cannot program or because you cannot design 3D models. Creating a flight simulator is a huge undertaking and there are many tasks which may seem less obvious to outsiders, such as helping maintain the wiki, moderating the forum, reporting spam, triaging the bug tracker, reviewing bug reports, helping fellow users and so on.<br />
<br />
== Irritations ==<br />
However, sometimes we get to see some irritations among new community members and more seasoned members, because people may have certain expectations and assumptions on contributing to FlightGear. This has frequently caused some heated discussions, sometimes even flame wars on both, the devel mailing list and the forums.<br />
<br />
Apparently, this occurs frequently when dealing with people who already have experience developing software or contributing to open source software, be it professionally or as a hobby.<br />
<br />
Over the last couple of years, such discussions have taken place increasingly and they are obviously eating up considerable resources, given that spare time is our most precious resource to contribute to the project.<br />
<br />
It seems, some people are trying to apply their own experiences and assumptions to FlightGear as a software development project, which is sometimes causing grief and anger because FlightGear seems so different from anything they may know already.<br />
<br />
The best approach when encountering such problems is to take a step back, evaluate the goals and the means available, and come back with solutions or valid proposals. Several developers have taken long breaks, then returned to contribute again many features.<br />
<br />
== Passion ==<br />
Honestly, we are all part of this community because we appreciate some things about this open source flight sim named FlightGear. So we are always sorry whenever our tone becomes inappropriate or even harsh.<br />
We sincerely believe that you can contribute in more meaningful ways than you may currently perceive, without just voicing criticism. Obviously, it really is important to get along with people, regardless of differences in opinions.<br />
<br />
== Welcome to the club ==<br />
To tell the truth: Most of us have been in that situation at some point. To most of us, the way FlightGear works as a project has been somewhat irritating and confusing in the beginning. So, we may actually share your initial confusion, because most of us went through the same process at some point.<br />
<br />
Honestly, you could search the forum and mailing list archives and probably find heated responses posted by even the most seasoned contributors. Some of us may have a track record of thousands of postings now and may seem like fairly knowledgeable contributors , but this is just a result of having been part of the community for a number of years, despite the deficiencies that we may have perceived initially. Frequently, some of our very first posts were also just voicing criticism.<br />
<br />
It isn't even unlikely that new community members are bringing up long-term issues that have been annoying most of us for quite a while already. We are probably more aware of these issues and their implications than you are. But just saying that something is "broken" is simply not the way to affect the situation for the better. Some of us have tried and failed doing exactly that. To no avail.<br />
<br />
Like you can see now, we've changed our strategy: We are trying to act like we want others to act, we are trying to be the change we'd like to see.<br />
<br />
Really, your situation may not be any different than ours: We've all been there. You need to be patient and absorb what we're telling you. We have no doubt that you'll get along with most of us, especially if you can demonstrate that you are actually listening and absorbing the advice we are handing out and applying your new knowledge.<br />
<br />
So this is an attempt at explaining things in a non-heated fashion, so that we can point aspiring contributors to this article explaining some things which may not be directly obvious, but which we feel are important to understand why some things are done the way they are.<br />
<br />
At the time of writing (2012), this is largely copied together from various flame wars that have taken place in the last 12 months, so the format still needs some work, and things may seem pretty inconsistent and roundabout in some places.<br />
<br />
== Proposing changes ==<br />
This is not to say that things are set in stone, but the current development model is the result of a certain evolution, and it's exactly this what has enabled FlightGear to survive and grow for over a decade already, without relying on commercial backing, funding organizations or formal project management. <br />
<br />
So, we would like to ask you to keep these factors in mind when proposing changes and when voicing recommendations, and when discussing such issues with fellow community members, publicly or privately.<br />
<br />
It requires patience to work together and to get something useful out. Sometimes you just have to live with a problem, work around it, and talk to people for a long time. It takes time, but I've experienced that you can convince core developers that your particular project is important enough to warrant attention and support. Everyone's time is limited, and it's all volunteer work. For example: If you complain that shadows are absent, it will change nothing. What you need to do is convince people that shadows would make a huge difference - possibly even with a proof of concept code.<br />
<br />
== Ideas getting ignored or rejected ==<br />
Let's be honest: Not every suggestion made in the forum or on the devel list is good. While no one deserves to be belittled, a fair share of suggestions deserve to be ignored (unless you feel you are entitled to 30 minutes time from, say, a 3d rendering specialist who explains to you in detail why your idea really doesn't work in non-technical terms). <br />
<br />
There are many questions asked where the answer can be found in the Wiki with a short search. There are suggestions being made which even on first glance are impossible in practice. It's not the developer's job to deal with these things - it's your job as a forum user to do so. And not every rejection needs to be taken as personal grievance carried around for the next years - sometimes one just has to allow for the possibility that one has been wrong.<br />
<br />
Often, it does require a certain amount of background knowledge to truly understand why a certain idea or feature cannot be implemented. New users, and even new developers are likely to lack this knowledge. You need to be somewhat familiar with the code bases involved in order to understand some things.<br />
<br />
Since I work on FlightGear, I have suggested a lot of things - about 10% of which have been reacted on. To give you a current example: I've noticed that models from Nasal load way slower than needed, and I've asked that someone looks into it. I have not expected that somebody immediately jumps on it and spends 10 hours of his time tracking what is going on and delivers a detailed report in non-technical terms later. It has taken a few months and posting several examples to convince people that what I see is real. Then somebody looked at it and traced it to the (non)-existence of the osg texture cache. Now, people are debating the pros and cons of activating the texture cache by default, because it might affect stability and memory usage in an unwanted way - and I don't know if it will eventually be there.<br />
<br />
I have no problem with that - neither with convincing people that my suggestion is worth looking into, nor with the fact that other issues I have not thought of need to be taken into account. But it seems a lot of people in the forum expect that because they suggest something, someone will take it very seriously and act quickly and are then disappointed when this isn't actually the case.<br />
<br />
Coming from the other side, having worked on a problem I often know that a particular thing suggested cannot be done easily. If I have the time, I can take 20 minutes to explain why. Sometimes I don't have the time, then I just write a small sentence indicating why it doesn't work. Probably then somebody feels ignored. Can't help it - if I'd try to take the time, my 3 year old daughter would feel ignored, and she needs my attention more.<br />
<br />
I just lack any sign from the user community that they're willing to accept that a suggestion or feedback can in fact be dismissed, and that a developer's time to explain why a suggestion cannot be followed is also not unlimited. I have no problem with the users providing 50% of an opinion where the project should go - as long as they don't expect that that opinion necessarily translates into a decision.<br />
<br />
Sometimes rejecting new ideas can be painful to contributors who had spent a considerable amount of time researching and implementing features. Some new ideas have been the seeds of a similar implementation by the more seasoned coders. In any case, it is always best to evaluate the pain/gain benefit, and to keep older solutions to problems rather than having a half-way semi-realistic solution. Ideas tend to get the proper recognition in time, if they are beneficial, or are quickly forgotten if they are not worthy. Keep in mind to do this for fun, and always attack the idea, not the person, to keep things calm.<br />
<br />
== Lack of feedback ==<br />
Lack of feedback - same thing. Go out into the forum, download interesting addons, talk to the people who provide them, let them know what you think. If you want feedback for your own work, start by giving feedback to the work of others. That's how it works. And yes, lack of recognition is sometimes a problem. Basically, you have to do things because you want to, and you have to be enthusiastic enough to pull others along so that they can see and appreciate your vision of how things could be. Again, requires a lot of patience. I wish that many things here would be different. I wish people would collaborate on projects more often, instead of everyone developing his own pet project and half of them dying for lack of interest. But I've come to realize that it's not going to happen because I wish it to happen - things are only happening my way if I slowly work towards it, talk to people an unholy amount of time and try to convince them that I am serious and have a case. <br />
<br />
<br />
And to people who have stated (rightly or wrongly) that they don't feel the core developers are active enough in the forums:<br />
<br />
When asking on the devel list why people keep the mailing list separate from the forum, the response I got was along the lines of 'We like to exchange information, and in the Forum we get to hear only noise - petty complaints, lazy questions and so on - so we stay where the information relevant for development flows'.<br />
<br />
So, it goes two ways (I have been saying this before, haven't I?) - the probability that people will listen to what you have to say increases if you can convince people that they take you seriously.<br />
<br />
When I started to write that I want to rewrite an integrated weather system, pretty much no one took me seriously because it's a large chunk of work and you need to know what you're doing, and, face it, there's a lot of noise being made about what people will do who drop it later after a week. After I had written a working demonstration, people started to believe that I know what I'm talking about. Sometimes that's what it takes.<br />
<br />
From the other perspective, I would do the same. If somebody tells me he's going to implement volume rendering for clouds, I'd simply say 'Go ahead, I don't think it can be done.' Once he demonstrates to me that it can be done, I'd be willing to work with him. That makes a lot of sense, because the amount of ideas that can be realized and have a person behind them who is willing to see it through is a tiny fraction of the amount of ideas being presented - so it pays to focus on those who have a shot at success.<br />
<br />
So, I'd like to see some appreciation for the fact that there is no a priori right to be taken seriously, no matter what you say, but that this is something you need to work on. I also think that if the forum would offer a lot of high-quality development related discussions then you'd see much more active core developers here.<br />
<br />
Sometimes, there is a rift between new people and older members, simply because the latter expect all things to go through the proper channels and procedures. Unfortunately, since these are hardly policy, some prior research on the best communication channels and the best people to talk to in person can be valuable and time saving.<br />
<br />
== Users vs. contributors ==<br />
We have here two groups of persons (with blurry boundaries): The first group takes something for free, which is a flight sim which you download from servers for which someone probably pays real money. The second group gives something, which is their time to create the simulation.<br />
<br />
You'd expect in the real world that if I give you something for free, that this earns me your gratitude. But this is the internet - so instead of gratitude, you somehow assume that in addition to giving you something, I am also expected to care about what you want, and it disturbs you that I don't really care for people who take for free and ask for more, but that I care for those who take and are prepared to give in return.<br />
<br />
On the other hand, a 'user' in your concept of course is supposed to be entitled to not only acquire FlightGear, but also get support in the forum and should also have a voice ( in what is done for the project (by others), and for this he's expected to do what in return? Nothing.<br />
<br />
If it disturbs you that I don't share this sentiment, then so be it, but let me be very clear: I have every sympathy for people who come here and offer to return some (whatever small) contribution back for getting FlightGear. I get angry when I see their contributions rejected for opaque reasons, when I see disparaging comments made that this is 'merely modelling' or 'just Nasal', when I see someone being discouraged from honestly trying to contribute. I have also sympathy for people who take FlightGear, enjoy using it but don't want to contribute and still ask politely for some help in the Forum.<br />
<br />
I just have no sympathy for people who take, are not prepared to do any work, but feel entitled to say how others should do their job and issue demands for features, aircraft, documentation, whatever. You may call that elitism, I call that my sense of fairness.<br />
<br />
== Lack of Support and Backwards Compatibility ==<br />
FlightGear is a volunteer effort and no one is paying several thousand dollars a year for software and related support each year. Since legacy support is expensive (IE. time/effort) one of the ways a project like FlightGear deals with this is to limit legacy support. If this were not the case then time/effort would be expended on legacy support that could be used for new features and bug fixes. Like most things there are trade offs involved. Which do you want - more advanced FlightGear and aircraft or better support for older versions? This is a common issue for open source software and most prefer to look forward rather than looking back.<br />
<br />
For JSBSim there been has incremental changes in almost every version of FlightGear. These changes did things like add features or change the way a specific feature acted. For example around FG 2.4 there where changes to the engine cooling code (to allow modelling of cooling systems with things like cowl flaps) and also to the nose/tail wheel steering code (to allow toggling between locked and swivelling steering wheels). Many aircraft are unaffected by these changes because they don't make use of the enhancements but some aircraft do use these enhancements. For example the JSBSim P-51D uses both of these features and it probably will not work correctly (IE. it will over heat/run cold or not have correct ground handling) if used with FG versions before 2.4. There is also the possibility that it will throw all kinds of error messages when used with an older version of FG but none of this has been tested at least by me. So it may be OK with a few missing features on 1.9.1 or it may fail totally. We simply do not know. If someone complains about the JSBSim P-51D not running correctly on FG 1.9.1 my reply is too bad you need to upgrade to 2.4 or later and get back to me if things aren't working after the upgrade. There may be other more recent features that other aircraft use/leverage that don't affect the P-51D so I think this is a significant issue.<br />
<br />
In addition, FlightGear itself has been a moving target with a constant stream of new features and enhancements some of which require changes to at least some aircraft.<br />
<br />
== Priorities in bug fixing ==<br />
{{cquote|I stopped filing bug reports after too many instances of our omniscient developers denying a problem exists, or telling me to fix it myself (yeah, right). Bug reports are a waste of time. You'll have a hard time convincing me that anyone cares about fixing bugs that don't bother them personally. I'm really glad some folks are writing free software for me, but you gotta admit, most of them are pretty arrogant about it.}}<br />
<br />
Let's start this with the obvious - how much of your free time do you invest into things which don't bother you personally? Do you volunteer for 3 hours per week to make the world a better place? Because preciously few do, whereas the average FG developer does.<br />
<br />
For a bug to be fixed it takes the coincidence of a few factors:<br />
<br />
# Attention - someone who has the ability to fix it must know about it<br />
# Relevance - that person must judge it worth his time<br />
# Information - that person must either be able to reproduce it or be given enough information<br />
# Access - someone needs to commit the fix to the repository<br />
<br />
If you tell me that you find that you get a shader compilation error of someshader.frag in line 401, you have covered 1) (told the right person), and 2) (we shouldn't have shader compilation errors) and 3) (I have all I need to fix it, a line number is as good as it gets) and since I have 4) covered myself, you'll see a fix overnight.<br />
<br />
Sadly, that's not how bugs are usually reported. They're told to the wrong person with insufficient information given, follow-up requests for more information are ignored, and as a result nothing happens. Because I'm not going to spend hours guessing what people might be doing such that a problem becomes visible if I can't reproduce it, and neither is anyone else I know. Arrogance is to expect users have the right to such a chunk of developer's time and hence feel they shouldn't need to be asked for more info and to do checks.<br />
<br />
Relevance stalls another bunch. The time of core-developers like Stuart or James (who do a hell lot of unpleasant bug-fixing) is precious - if they work on fixing something for 5 hours, I'd rather have them fix something important. Relevant things get priorized. If I judge a problem relevant which I can't fix, I gather enough information to make it easy to find the cause and then ask someone to look at it. TACAN got fixed within a day, lack of solidity of the carrier within a week. These are flight-critical, spawning on the carrier upon reset is not, it's a luxury - the sim can be operated just fine without the ability to reset and we could simply disable it.<br />
<br />
Access stalls a fix really rarely - only if there is concern that the patch might have unwanted side-effects.<br />
<br />
Also, in a fair share of situations, the problem is with the user or his system. A number of 'FG doesn't run' reports have to do with users messing up paths on their system during re-installing something. Many 'AP is broken' reports really are improper usage of correctly modeled systems (I'm guilty of that one myself in two instances). If FG has a problem only on your computer, it's unlikely to be a problem of FG. And so on. Of course, all users 'know' that the problem can't possibly be on their side...<br />
<br />
== Number of aircraft vs. quality of aircraft ==<br />
{{cleanup}}<br />
<br />
One thing to consider when comparing real-world handling qualities versus simulated handling is the control devices. I use a Logitech Gamepad which is not ideal by any means, it serves my purposes and gives me acceptable handling capability. The biggest problem with it is the small throw of the sticks which makes them very touchy. Even if you have a full size control column, you lose a lot of fidelity due to the lack of control feedback as well as lack of "seat of your pants" feedback. Both the control throw and the feedback issues result in a great loss of fidelity which makes it impossible to control an aircraft in simulation anywhere near as well as the real thing. <br />
<br />
Taking the P-51 issue as an example; even if the FDM did closely emulate the real thing, the reaction time to correct for any divergent yaw on takeoff will be much slower than it would be in real life with more sensory cues. Once you do react, you can't react with the same accuracy as real life due to the lack of control feedback, so your inputs will tend to over correct the situation which in turn you will be slower to react to.<br />
<br />
This can obviously be corrected by making the FDMs less touchy than the real-world aircraft, but this then compromises reality. So it takes a bit of a balance.<br />
First, let me say that there are HUGE fluctuations in the quality of FG flight dynamics models, and that I don't like all of them. This is why I specifically wrote which planes I use and asked which plane you've been flying. Some FDMs are pretty bad, but others (the Seneca-II for instance) are made by people who fly the real thing, yet others (the P-51D, the F-16) are done using a huge pile of available test data and have been tweaked literally for hundreds of hours to agree with the real performance and capabilities. It's these FDMs which I like and which I'm defending here.<br />
<br />
So, you ask why some posters are so enamoured with the FG FDMs. For once, because I know physics. When I do certain things, I know how the aerodynamics works out, and I expect to find that in the simulation. <br />
<br />
For two, I've been flying gliders for a while. I distinctly remember the feeling of making tiny not really conscious movements with the stick all the time to fly the thing. I want to have that experience reproduced by a flight sim, it's part of the feeling of immersion - and the top-end JSBSim models do that for me. Also, I want to _do_ something while flying, not just get my plane on rails and watch the scenery.<br />
<br />
Third, because I find it educational. I for instance happen to know that the F-104 Starfighter was pretty accident prone. Just 10 minutes flying around with the thing told me why - when the plane becomes unstable, what manoeuvres you can and can't do (I think the Starfighter is also one of these FDMs with plenty of real life experience used by the creator...). I find it interesting to explore how the SR-71 reaches Mach-3 and why it needs to do the funny 'dipsy' manoeuvre. I find it instructive to understand why one has to fly the Concorde by the book and how fuel consumption figures change if I don't. I want to understand how thrust vectoring can be used and how stable it is. I want to learn what's different about a helicopter. For all this, I need the real physics of flight simulated as faithfully as possible.<br />
<br />
<br />
As the creator of several aircraft made for FlightGear including a heavily researched Velocity XL and an Edgley Optica, I can say the above observation is nonsense. Fly one of my planes and the controls won't do diddly under 30 knots unless a pilot's handbook or a pilot's report indicates they should. Even the worst flight models in the FlightGear world don't have fully effective controls while sitting still. As for inherent stability, my own efforts are easily trimmed at cruise speeds for relatively benign, hands-off flight to match the flight manual or pilot reports.<br />
<br />
Why are some so enamoured of FG flight models? I'll state what Thorsten wrote in another way. I'm not a licensed pilot, though I do have stick-time in several light planes. But I'll never fly in an Optica, and I'm very unlikely to ever fly in a Velocity or a Grumman Goose, and no sane airline is going to let me into the flight deck of an MD-80. By building these models, I can gain an understanding, an insight, and an experience with these aircraft that would otherwise be closed to me. I can know them in some ways that even a pilot might not know them. The closer the simulation matches the real aircraft, the closer my experience comes to that aircraft. I can't experience these planes unless they are correct in every detail that matters, and pursuing that correctness is a long journey, perhaps one without an end.<br />
<br />
Maybe I misunderstand the notion of options to make a plane harder or easier to fly. For me, the point is to simulate the aircraft. If the aircraft had functions or gadgets that facilitated making it harder or easier to fly, then fine, that's part of the simulation goal. But it's not the same as a game, where I can select EASY, NORMAL, HARD, or HURT ME PLENTY. There are many planes where someone like me has no business trying even the simulated version. And no real C172 or MD-80 has difficulty modes or configuration files.<br />
<br />
Are there "crappy" flight models in the FlightGear world? Sure. Plenty of them. Maybe most of them. But there are some darn nice ones, some made by pilots with hands-on experience, some with the feedback of pilots, and some by non-pilots using meticulous research. Many are simply nice modelling efforts, waiting for someone to come along and create a good flight model, or add systems simulation, or cockpit instruments, or some other contribution.<br />
<br />
In the MSFS world, the typical model is a commercial product, released as a complete and well-rounded package. In the FG world, few models are finished, complete efforts. Developers work on what they know and what interests them, and most are open to contribution from others. Few works are above improvement. The neat thing about the FlightGear environment isn't that it's free. It's that if you don't like some aspect, you're welcome to help refine it. You can learn to improve it yourself, or you can help by suggesting well-conceived, objective changes to the authors. Most will listen. And you just might learn something along the way that will surprise or enlighten you.<br />
<br />
<br />
By saying that users can easily tweak the FDM in FlightGear, I am not implying that the the flight models or the FG architecture are inherently defective. There are many FG aircraft with great FDMs, other are not so good. Those that aren't so good are usually because they are not completed as indicated by their production status. As with any software product in beta release, the users are free to provide feedback directly to the developer. As this is an open source project, that feedback is often in the from of contributing code/FDM enhancements directly to the author for incorporation into the model. With commercial flight sims, you are always seeing the polished product because they would not get away with selling an unpolished product. With FG we are not burdened by the need to make a profit or satisfy our customers. We ARE our customers so we only need to make ourselves happy 8) So with FG you get to see a preview in the form of a pre-production or alpha release. This gives the users an opportunity to provide feedback directly to the developers, and often this feedback can be incorporated into an updated version of the aircraft in a few days or less. This is not a remote possibility for a commercial sim. I think this is why those who use FG like it so much. We are not content to use something out of the box, we are far too picky!<br />
<br />
== Fictional Aircraft ==<br />
FlightGear is developed by a community of volunteers from all over the world, we contribute in whatever way we see fit, if you disagree with the way FlightGear development is going, your best chance to affect it, is by starting contributing yourself. FlightGear could only progress so far without any commercial backing for over a decade, because of FlightGear contributors and their very passion for turning their own ideas into FlightGear features.<br />
<br />
FlightGear isn't only developed with a single role or purpose in mind, FlightGear is to be understood as a framework for developing new aviation related features, including fictional features. We have hundreds of "aircraft" and "vehicles" available in FlightGear, only a fraction of those are fictional, and most of the fictional ones are not even well-developed, you will surely be able to find other aircraft that you are interested in, see: http://www.flightgear.org/download/airc ... ilterable/<br />
<br />
So until you roll up your own sleeves, let's just appreciate the variety of aircraft and other features to be found in FlightGear, including the X-wing star fighter from Star Wars, Star Trek space shuttles and lots of other passionately developed 3D models, like the BlueBird for example<br />
<br />
FlightGear doesn't necessarily have a real "fictional side" - it's just that we all needed to get started somehow. Contributing a completely new aircraft is obviously difficult. Contributing to existing aircraft is useful, but it doesn't teach you all of the skills required to create an aircraft from scratch. So people who want to do a full aircraft, need to start with something simple and "fun".<br />
<br />
So what new contributors often do, is creating "fun" vehicles to learn how FlightGear works.<br />
<br />
Aircraft like the ufo, ogeL, bluebird etc were usually created by people in their initial phase of becoming familiar with FG - for example, the ogeL was made by the same guy who ended up modelling the Seneca, one of our most-developed (and maintained!) GA aircraft in FlightGear: http://wiki.flightgear.org/Seneca<br />
<br />
s you can tell from looking at the wiki, the ogeL aircraft developer has not only become the developer and maintainer of the Seneca aircraft in FlightGear, but he also has become a FlightGear core developer writing C++ code and maintaining the autopilot system for example, and he also happens to be a CPL-IFR/ME rated pilot in real life, who owns the Seneca he modelled for FlightGear.<br />
<br />
Obviously, contributing to all these areas in FG takes time, a steep learning curve is an unfortunate but important part of it - rarely, do we see people who immediately start out with complex and well-developed aircraft, it's a process - and we all needed to get started at some point. Just because we contribute "playful" things to FG, doesn't necessarily mean that we are not interested in "realistic aviation" as you can see.<br />
<br />
You will notice that many long-term contributors actually have an aviation-related professional background, be it flying (commercial, private, ATPL), software development, maths, physics, GIS or whatever. Among the long-term contributors are people with PhDs, Masters, commercial pilot rating, PPL or retired military pilots, and even one test pilot...<br />
Still, 3D modelling is a completely new skills, and needs to be learned from scratch - which applies especially to people who "only" have a real background in aviation, but not in computers and/or games.<br />
<br />
Creating the ogeL was obviously simple and fun, creating aircraft like the Seneca requires tons of skills, experience and expertise that you don't end up having "automatically". And it requires tons of dedication and discipline.<br />
<br />
I hope that puts things a little into perspective.<br />
<br />
== You need development guidelines ==<br />
You might have made general statements like 'There should be clear development guidelines', 'the project should not depend on a single person being around' or 'the developers should pay more attention to the users'. In theory, all these are beautiful - and who would object that these are all good things?<br />
<br />
The problem is that the reason that these things do not exist already have to do with how things are in practice. <br />
<br />
The consequence of developers paying more attention to what users want, rather than what they are interested in, and not being free to ignore suggestions is that a developer potentially is asked to work on something he personally dislikes, just because enough users want it. <br />
<br />
Who gets to decide what a relevant suggestion for the benefit of the project is and what a petty suggestion for the benefit of a single user is?<br />
<br />
Who gets to determine the guidelines and how - and what happens with people who don't want to follow? What happens if a developer doesn't want to code a feature even if 500 users signed a petition? What happens to a developer who belittles a contribution, and who enforces that and how? Once you start thinking these questions through, the moral high ground of the theoretical principles becomes a mud field of messiness and compromises.<br />
<br />
I've learned in the past year or so that FlightGear development is a messy place. It simply isn't structured in the clean and neat way I have in mind. Unfortunately, I've also come to realize that I am part of the mess - the way I work simply doesn't fit in with the equally clean and neat way others have in mind.<br />
<br />
== Telling volunteers what to do ==<br />
Posted by MAKG:<br />
<br />
; Rule #1<br />
: You can't tell volunteers to do anything. You can ask, but you have to motivate it if you want good and timely work, or any work at all.<br />
<br />
; Rule #2<br />
: Volunteers may or may not be inexperienced -- it has to be evaluated and management is different for the two cases. Allow a lot of time for inexperienced developers.<br />
<br />
; Rule #3<br />
: Let the volunteers learn something. You can tell them the right way to do something, and they may or may not listen. They are volunteers; let them do what they want even if it means redoing the work at a later time (example -- I had an undergrad student code an early telescope trajectory algorithm -- he wanted to numerically integrate rates because it was a whole lot simpler to derive; I explained that numerical stability would be much better with analytic positions. He coded rates, it was unstable, and he redid it as positions later. This was an extremely valuable lesson). Keep in mind that sometimes the volunteers are right...be prepared to learn something from them (the same student insisted on making a simulated sky, over my objections that it was unnecessary for the task at hand and time consuming -- and it turned out to be the single most valuable feature we have).<br />
<br />
; Rule #3A<br />
: Volunteers may want to exceed their abilities. Let them unless it's far beyond their abilities and you can't tolerate a delay (if you're in that zone, reconsider whether a volunteer effort is really appropriate). They may need a lot of help, or their work may need to be redone, or they may not finish the work. This is part of the cost of a volunteer effort.<br />
<br />
; Rule #4<br />
: BE GENTLE. These are volunteers. They won't do work you want/need if it's painful. Coax as needed, but nicely. Steer, don't push.<br />
<br />
; Rule #5<br />
: Though management is necessarily loose with volunteers, it cannot be completely absent. There has to be a coherent vision coordinating the effort, or it will be unfocused and will not serve the needs at hand.<br />
<br />
Whether this is open source or not is irrelevant. It's a volunteer effort; there are many of those that don't have to do with software. Think Habitat for Humanity, for instance.<br />
<br />
=== Some comments on elitism ===<br />
Every once in a while, people complain that they feel elitism is a major problem in the FlightGear project.<br />
<br />
The notion you may have in mind when you talk about 'elitism' is that everyone should be equal - applied to FlightGear, that everyone's opinion of how things should be heard and should matter about equally. In real life, that's how democracy works - everyone gets a say how to run a state. But there are many situations which do not work like this. Consider a shareholder's meeting - here influence is proportional to the investment. If I meet with 100 other shareholders, but I own 60% of the stock of a company, I alone get to decide what will happen. Or consider a scientific conference - here your influence is proportional to your expertise. You may have your favourite theory why Darwin was wrong, or why climate change is a fluke, but without some scientific merits, you won't be even admitted to the room, and it takes quite a bit more of reputation to get a talk.<br />
<br />
All these cases have nothing to do with elitism. In the first case (shareholder), the argument is fairness - if I take 10% of the risk of an enterprise and you take 1%, it is hardly fair that we should have the same voting rights. In the second case (science conference), the argument is efficiency - the amount of potential information is so huge that a careful filtering needs to be done in order to ensure that people spend their time processing relevant information - the scientific filter eliminates time-wasters up front (well, not all of them, as I can state from experience). You couldn't run either a shareholder's meeting or a science conference based on 'everyone is equal' - because while everyone is indeed equal in value as a human being, not everyone is equal in ability, expertise, or is equally involved in risk, work, ...- that's a fact, and to pretend otherwise doesn't help.<br />
<br />
You may call that elitism if you like, but my definition of elitism would be that a transfer takes place, i.e. that someone who owns 60% of the shares of a company starts to believe that he should not only get to say how the company is run, but also should get more influence in other areas outside his field of expertise, in other words, he starts to feel that his value as a human being is enhanced.<br />
<br />
Experience shows that it makes a lot of sense not to uphold the pretence that everyone is equal with respect to some property when this is in fact not the case. I've been observing internet language communities over the last 10 years where you have basically two classes of users - those who know the language in question, and those who ask questions as they are trying to learn. Almost without exception, communities which treated everyone equal did not work - the experienced users were annoyed at being interrupted in technical discussions, were told that everyone has the same right to enter a discussion, decided that they'd rather discuss in a place without interruptions, thus the communities were left with the users who bring only questions with no experts left to answer them, being unable to get answers they also left and the communities died. The communities which respected expertise worked - it's better to start as low-influence user in a forum and get your questions answered than to start as equal-influence user in a forum and not get your question answered.<br />
<br />
Perceived elitism is not a problem only for the Flightgear project, and the best way to avoid misjudging people is to make contact in a polite but ferm manner, expose yourself in a very matter-of-fact way, and keep it technical as much as possible. Always remember that with great power comes great responsibility, and if you get one day to be in a elite position, you might regret the old happy careless days.<br />
<br />
== FlightGear is a meritocracy ==<br />
FlightGear, as best as we have managed to understand the somewhat opaque workings in core development, is a meritocracy - your influence is proportional to the amount of work you do for the project. It's not closed, i.e. you can, if you invest a lot of work into the project, work yourself into a position where you have a lot of influence even starting today from zero.<br />
<br />
In general, that makes a lot of sense, basically because you can't vote what work volunteers should do later - or rather, you can, but it's not going to be done if the people volunteering for work don't like to do it, they'll just leave. <br />
<br />
In theory, I can spend 5 weeks of my spare time coding something I don't like, but why should I do that? Do you expect me to sit down and do something I dislike just because you (or other users) asked me to do it? Am I supposed to get satisfaction out of doing something for others, even if I don't like it? I don't know if there are people like that, if so, I've yet to meet them. My idea of the deal is: If somebody wants a feature I don't want to code, he can get my help to do it, he can get advice and a well-defined interface, he can get documentation - but that's about it.<br />
<br />
Question: Are you personally ready to work for FlightGear on something you dislike if enough users ask you for it? If you answer with yes, then the best way to proceed is that you poll users what they think you should do (within the limit of your abilities), and then do whatever is requested. <br />
<br />
There is a continuous transition - people who 'just ask questions' have less influence than people who write frequent feedback and maintain the wiki, then come possibly 3d modellers, Nasal coders, Terrain specialists and finally core developers. So, rather than seeing elitism, I see the chance that every user can in fact start with a small contribution and grow into the project - and that's what I'd like to see improved.<br />
<br />
They are different areas of expertise, to be a good 3d modeller and graphics expert is quite possibly as demanding as to be a good C++ programmer, Nasal coding isn't per see inferior, ... so why are they not equal?<br />
<br />
<br />
The reason is, simply the dependency structure: FlightGear can run, live and be developed without detailed 3d models, but it can not run without C++ code. If tomorrow all C++ developers quit, that's quite possibly the end of FlightGear, if tomorrow all 3d modellers quit, that's the end of eye candy in FlightGear.<br />
<br />
<br />
It's not particularly fair that this translates into the existing project structure, and in fact if you go through my posts here and on the devel list, you'll see that I continue to make the same point. As I said, can't all be fixed in a day... I don't have a particularly large influence either, all I can do is talk to people and ask for patience. You can read up what I wrote in the case of the Bo-105... Good work tends to be recognized eventually - be it modelling or coding. But there's no guarantee, sometimes you have to accept being frustrated, get up and try again. Or you walk because things are not perfect as they are, which is a pity.<br />
<br />
<br />
Another thing I don't like is that I feel that the power which comes with having a lot of merits for the projects gets sometimes abused by people who behave in a way that would never be accepted from newcomers.<br />
<br />
<br />
And yet - it's a fine line between idealism and realism here - so suppose for a moment I had the power to do as I want with the project - what would I do? I feel that all users and contributors should be treated with some basic level of politeness. Assume someone violates that rule, but happens to be a core contributor. Idealism tells me that I need to enforce the rule, because everyone is equal in value as human being and deserves to be treated with respect - so quite likely the developer feels pissed off and leaves, creating a huge gap in the project (and, no kidding, there are people who are really important...) - in the end, no one benefits if the project collapses. So realism tells me to let things pass - it's better to mistreat one user than to kill the project and to make all users unhappy in the process. <br />
<br />
<br />
I don't think there's a simple answer to such problems - philosophy has been struggling with them for thousands of years, there hasn't so far emerged a clear preference between an ethics of means and an ethics of ends.<br />
<br />
So, perhaps a few folks can step back and see the bigger picture - and maybe share a vision: How would it be if contributing to FlightGear were as easy as contributing to Wikipedia - just what would, e.g. our scenery look like?<br />
<br />
And just how can we get there?<br />
<br />
<br />
There will probably always be irreconcilable differences between those that _create_ a program, and those that _use_ a program. The extremely successful programs/environments are the ones where those that create can understand those that use, and those that use can understand those that create. Everyone here, in the long run, is really here for their own benefit, and until we all understand that, not much will change. Open source has it's downfalls. It doesn't have to please the majority, it doesn't need sales, it only has to please the person that created it. This doesn't mean that people are greedy or selfish. They have no problem sharing, but they don't need to _do_anything_for_you_, if they aren't interested in it.<br />
<br />
== You guys need some serious changes ==<br />
You know, if I wanted to change the structure of a project for better, but would not have any real power (control over servers, commit rights, admin rights in the forum, ...), I'd do the following:<br />
<br />
First, I'd try to make sure I understand the situation as it is - not as it appears from my perspective, but also how it appears to others, of what nature the obstacles to change are and so on. Then I'd try to get to talk to some of the people who have the power to change things, and convince them that changing something would not just be better for me, but also be better for them - in fact be better for anyone around. In order to do so, I'd go as far as I can to meet them - talk their language, start describing things from their perspective, value their efforts - and then talk about that one can also see things from a different perspective. I'd do that because I want something - I want them to listen to me, so I want to make that as easy as possible. I'd also prepare a compelling and persuasive case - I'd try up front to sort genuine structural problems from things which are just one-time mistakes which can happen because people are not perfect, I'd sort important things from unimportant things and focus on the important things. Above all, I'd think about what I personally did wrong and what part of the problem I can fix - and how I should do it. And then I'd see if I can't convince anyone that there is merit in my perspective. In the process, I'd also try to find like-minded people who might help me achieve my goals.<br />
<br />
== FlightGear is inconsistent and overly complicated ==<br />
: the fact that it's overly complicated, lacks a single design or even feature set, defies any semblance of cohesion, daunts and confuses would-be contributors with equal severity, and thus produces a wide range of results quality from "embarrassing" to "ready-for-commercial-release" [http://forum.flightgear.org/viewtopic.php?f=14&t=20413#p186983]<br />
<br />
I don't see there's anything wrong with FG providing options - many of the features/options we have came into existence at different times, with different needs and requirements in mind. It is often only by accident that they start overlapping, sort of like various FDMs, scripting solutions, interfacing options or weather simulations.<br />
<br />
Admittedly, it's far from cohesive, but there's really nothing that we can do about it: It would require a coordinated effort, not just people telling others what to do, but others willing to listen.<br />
The T4T/combat support situation isn't any different: we have flug's bombable addon as the most sophisticated option available in FG, and then we have various more or less "competitive" approaches, including T4T - yet most folks are not actively seeking collaboration, and doing very little to unify different concepts and approaches. Instead, the focus is often on differences rather than shared needs and common goals.<br />
<br />
Which is part of the reason why we have so many "unfinished" aircraft in comparison to other simulators. But like I said, there's really nothing that we, as a project, can do about it - short of adopting a commercial development model and a corresponding hierarchy.<br />
<br />
Absent that, we'll have to continue embracing the "Darwinian's development philosophy", where everybody is free to contribute in whatever form they see fit, and it will be up to time to decide which features are going to stay, and which are going to be ripped out eventually.<br />
<br />
All of us have real life obligations, and very few of us are willing to accept additional duties/deadlines, no matter if it's aircraft development, core development, texturing, scenery work, wiki administration, forum administration or other "duties" - still, all this needs to be done by someone. <br />
<br />
Thus, it's those who roll up their own sleeves and spend their time contributing who get to influence the way FG development is heading, no matter if others agree or not - the only "hard currency" that counts in this project is time, i.e. the amount of time you have to contribute to the project<br />
<br />
Which is also the reason why we are seeing some really skilled and experienced contributors (with very little time on their hands...) being increasingly fed up with the way FG development is going recently, simply because there are quite a number of guys who may not be as experienced or skilled (i.e. not holding multiple CS degrees), but who may be able to spend more time contributing to the project in a different form, which -at least in part- also explains the sheer rate of growth of Nasal scripting in FlightGear, especially in comparison to relatively little new C++ code being committed to the core repository (the canvas system being the obvious exception here, but ironically the Canvas system additionally fosters scripting adoption even further, because base package developers can suddenly contribute in areas that were previously reserved for C++ developers only, such as the GUI, avionics and other fancy stuff).<br />
<br />
Honestly, we do have various accomplished core developers who do not particularly like the way Nasal is increasingly used, or the way the Canvas system is becoming a viable alternative over some hardcoded solutions - likewise, the weather system being 95% scripted is another annoyance to some - but at the end of the day, it's really just software evolution taking place: We have a decreasing number of experienced C++ developers, more and more becoming increasingly inactive - which is why the base package has been seeing so much development in comparison, and under these circumstances it is only natural for some core developers to recognize these issues and focus on providing building blocks and infrastructure to empower base package developers.<br />
<br />
It's not that your assessment is totally off, but we cannot really deal with it, unless we are telling people what to do - and as you may have witnessed before, that doesn't work out too well usually (remember the various T4T discussions). Thus, we need to accept what's brought to the table, no matter how inconsistent it is, and "absorb" it until something better comes along - even though that may mean that we'll end up with various different approaches in the meantime.<br />
<br />
Overall, the current situation isn't as bad as it used to be once<br />
<br />
== Is this program just for scientists and engineers? ==<br />
No, but at least historically, the FlightGear project tends to attract certain types of people, many of them having some sort of academic background and some involvement or interest in aviation, i.e. in engineering, maths, physics, IT/computing or just real life pilots (hobby, professional, test pilots, retired).<br />
<br />
This applies especially to long-term contributors. Obviously, the people who contribute for a long time, get to shape the project more so than people who just happen to show up and post some ideas, features requests or bug reports.<br />
In part, this is also due to the reputation they get to enjoy among fellow contributors, so their feedback has automatically also more weight, too.<br />
<br />
That might explain why many long-term contributors seem to have a fairly similar mindset, and why some things are done the way they are.<br />
<br />
Some of these decisions are hard to understand without having a similar background, be it education, professional experience, families, real life obligations and such.<br />
<br />
== Community interactions ==<br />
What can be done in a forum? First off, speak the same as if you were standing in front of the person you are talking to. If you _really_ do get up in their face when you speak, take the gold chains off for a minute and lose the Jersey accent. Respect goes a long way. Respect also goes _both_ ways. If you get an email from someone, respond to it, even if it's saying that "no, I can't help".<br />
<br />
=== The forum ===<br />
Regarding helping others on the forum, thinking back on my early days with FG I'd have to say that what's obvious to a long-time FlightGear person isn't necessarily obvious to others. Sometimes people do search for answers first, but they may not be asking the right questions or have a deep enough knowledge of a system or community to proceed.<br />
<br />
New people might not think to look in the wiki (yes, there are links all over the place), or try and find an answer there first. Or maybe they did try and failed but didn't mention it. The wiki is a fine repository for some deep, often esoteric information, but the information is spotty and it's not the easiest place to hunt for a specific answer. And I can well remember when the information in the FG docs folder might as well have been written in Martian, given what I knew at the time. Heck, some of it is still Martian to me.<br />
<br />
It's usually obvious when people are asking questions in the forum thoughtfully, and when they are being casual, lazy, or discourteous. But sometimes it isn't so clear. There may be language barriers, or they may not know exactly how to ask, or they may simply be shy of a new environment. Like Someguy, I cringe when I see our good people tell somebody to go on an Easter-egg hunt for their answers. If it's tiresome, which is understandable, or one doesn't feel like helping, then it's wiser to simply not respond.<br />
<br />
What's at stake isn't getting person X to information Y. In 90%+ cases, it won't matter much-- person X will likely move on to some other hobby. But every now and then, that new person who asked that same tired-old question stays around and eventually becomes a Gijs, or a Heiko, or a Someguy, or a Melchior, or an Anders, or an Emmanuel, etc. The more open, friendly and patient we are, the more likely it is that we will retain these incredibly valuable sorts of people and keep moving forward.<br />
<br />
=== Coordination ===<br />
It'd be really nice to have a better feeling for what is in the works and to know about what is going to change beforehand, rather than pulling the new version to learn that suddenly nothing works and spend the next week trying to figure out just what the change has been. Been there, done it, not pleasant.<br />
<br />
Some interface to exchange that kind of information would be really helpful, because some developments depend on how others are structured. In general, more talk between core C++ developers and other developers wouldn't be a bad thing.<br />
<br />
=== User facts of life ===<br />
* Those that can't "create" an entire aircraft from a blank screen will have to wait for someone to build it. Don't post a blind "please build this" advertisement. My guess is that has never worked, and is borderline rude, asking for something without ever offering something. Accept your limitations, enjoy what we have.<br />
* Don't believe that you are the _only_ user, and therefore represent everyone when you stand on your forum soapbox. _Everyone_ may not share your emotion.<br />
* You have no power and control, and that's not a bad thing. You reap the benefits of many people that have come before you, and even those that may come after you.<br />
<br />
=== Developer facts of life ===<br />
* You have power in what you do, and you have total control. This does affect your relationship to the person that is a "Non-developer", whether you believe it or not. Choose to realize this, and be respectful.<br />
* As a "developer", you have been given power and control over something that really doesn't belong to only you. Without a board of directors to oversee your actions, realize that _do_ have a responsibility to provide your part of the "development". You have to consciously choose to do this, for power and control are strong drugs.<br />
* For the most part, there was someone before you, and their will be someone after you. Your actions will help ensure there is a place for someone after you. Remember the past. Don't be the reason that those before you chose to leave.<br />
<br />
== Conclusion ==<br />
There's simply no use in complaining that FlightGear isn't the community you'd like it to be - but there is use in working to make it the community you like it to be. It's just requires more effort <br />
<br />
May FlightGear always provide the beauty of flight to those that are bound by gravity.<br />
<br />
== To be discussed ==<br />
* don't like this conceptual division between users and developers. A user is just a developer who hasn't popped the hood on their car yet.<br />
<br />
* most of us try to read the forum and the lists regularly, and we also try to respond to thoughtful topics<br />
* I care if I can communicate with you on a professional level and if anything comes out of it in the end, or if I get the feeling I'm just wasting my time. That's all.<br />
* Fact of the matter is - you're a potential contributor until proven otherwise, and as far as I am concerned, that gets you basic politeness, some measure of attention and some measure of help from my side, just like I would do for anyone else asking in the forum. If you want more (information, help, of my time, of Hooray's time ...), you should keep in mind that at this point you want something from the community, and so *you* need to adapt to the community, understand how it works and play by its rules - not the other way around. To say it very bluntly - FlightGear will survive without you if needed (as it will survive without me if needed).<br />
* The time I am willing to spend trying to talk to you in the hope of any productive outcome is limited, it is about to be exhausted because I am feeling increasingly annoyed and see no real outcome except more talk. That may not have been your intention, but since it's brought to your attention that people start feeling annoyed, it might be a good idea to change the way you communicate. The chances that the devel community will adapt to your style of work are very slim indeed.<br />
* Your lack of understanding here is your inability to acknowledge that people are aware of the alternatives and have consciously chosen to organize the project the way it is. Speaking for myself, I simply don't want it done your way and would go away the day things become organized your way, and several other core developers have expressed similar sentiments on the devel list.<br />
* You assume that people basically have no clue and all you need to do is to point out how to make it better, but several people have considered the alternatives already and decided otherwise. This is what you need to understand.<br />
<br />
* Influence in the FlightGear community scales roughly with level of your contributions.<br />
* Obviously, long-time contributors have a more sizeable track record of contributions which in turn gives their voice more weight<br />
* Things are done the way the majority of contributors thinks they are best, not necessarily by some general consensus.<br />
* unnecessary community interactions are eating up time<br />
* people able to build FlightGear from source, who know C++, who have some spare time to contribute to FG are in very short supply<br />
* developers getting involved in lengthy discussions cannot write code at the same time<br />
<br />
* Asking people to work on some particular problem that's bugging you, is generally alright - but you need to be willing to make your case and do that in a fairly compelling fashion. We have some really long-standing issues in FG, some of which most of us (including core devs) agree are IMPORTANT. This is a rare situation, but there really are things that pretty much everybody agrees are REALLY IMPORTANT to work on. So there's some very real competition and it won't be easy to talk people into doing something for you. <br />
* Another important thing is staying focused: it isn't helpful to raise dozens of issues in a short amount of time if you cannot also solve them, regardless of how "real" and valid these issues might be.<br />
* signal/noise ratio<br />
<br />
* Frequently, people keep emphasizing that this attitude is related to their inability of fixing things themselves. Now, we are not going to suggest you learn how to build FG from source or how to program in C++. But rather, we suggest you focus on a handful of issues that truly annoy you, and where you think you could actually help and contribute solving them. That would surely help improving your signal/noise ratio, basically giving you opinions more weight here. There should be a fair share of opportunities to get involved in meaningful ways. We have a bunch of wiki resources to get people started contributing in various ways.<br />
<br />
* People asking for increased project management and more coordination may want to ask themselves how they would respond if they were exactly told what to work on, rather than just doing what they are interested in. Seriously, nobody is asking you to contribute within a particular domain at all, which is also a good thing and attracted many of the long-term contributors to the project in the first place.<br />
<br />
* When comparing FlightGear to other OSS project, it is important not to compare apples and oranges from a manpower perspective. We don't have the manpower here to establish a proper hierarchy like many of the more prominent projects (think Mozilla/Firefox). There's is TONS of management work happening behind the scenes, there's the Mozilla foundation and there are donations and so on - so Mozilla development is not only about coordinating a bunch of programmers who happen to develop a piece of software in their limited spare time, they have passed that point long ago.<br />
<br />
* If you are trying influence things: That's fine and a valid motivation. The thing is however, your ability to bring influence to the project is directly proportional to your impact and track record in the project. Actually, this isn't untypical for most OSS projects.We have people here who have been part of this project "just" voicing ideas, opinions and feature requests - some of whom have been involved for YEARS. While their feedback may be appreciated, their ability to direct things is still fairly limited - especially when compared to people who actually brought changes to FlightGear and who have a track record of doing so (sometimes even within a fairly short amount of time). You can find numerous examples actually, of people who have not been a member of this community for very long, but whose input and feedback is not just appreciated and respected but who are having a certain impact on the direction the project's heading. This is never because of "talking" or discussing things, it is because of DOING things.<br />
<br />
* FlightGear has never been in a better shape than it is in right now. In fact, admittedly FlightGear -as a software project- has actually been in a much worse shape for many years (for example: no forums, no wiki, no bug tracker, no git repository, no Gitorious merge requests, no build server, no formal release procedures etc)- still it somehow managed to stay around for over 10 years, despite all its deficiencies...<br />
<br />
=== Mods and forks (built on top of FG) ===<br />
<br />
* You're here asking for help from the FlightGear community. Help is hard to find in the first place (that's a fact, not a threat - there are calls for volunteers for many different projects that go unanswered).<br />
<br />
* You're planning to fork in a substantial way. The difference for me is - as long as what you're doing is FlightGear, I will care that my own development work (integrated weather system) runs fine on your system because I develop for FlightGear. If T4T is off to the degree that I'd have to download and compile different code, then I won't care that my weather system runs (it may or may not, dependent on what you do to the environment) - it has become your problem. Not because I am mean, but because I don't have the time and inclination to maintain compatibility to two different development branches. Whenever you develop using a different repository, you are 'them' and we are 'us'. We can be a friendly 'us' and 'them' as between FlightGear and JSBSim, we can exchange code, people can be part of both projects and maintain compatibility and work together - but the basic fact is that there is 'us' and 'them', and (probably like many others) I feel responsible for my part in 'us' but not for my part in 'them'.<br />
<br />
http://forum.flightgear.org/viewtopic.php?f=18&t=13298&p=134793&hilit=supply+developers#p134756<br />
* Do you have a clear idea what your project involves?<br />
* Do you have a clear idea what is already there?<br />
* Will it help Flightgear?<br />
* Will my voice be heard?<br />
<br />
* This community is far more likely to get involved if you involve it - and that'd mean opening your previous decisions for debate - than if you ask people to get involved with a project of your design which is no longer up to debate (speaking of resistance to change...). Again, that's your call, I'm not threatening in any way, I'm simply trying to explain how things (according to my best understanding) are and what the likely consequences of your project design are. I don't mean to imply that I or others would actively block you if you're not doing it 'the FlightGear way' and hold information back. I hope that is sufficiently clear.<br />
<br />
* We get to see new forum members posting interesting "project ideas" here every month, sometimes even several times per week. And we know from experience that "ripping FlightGear down to its core and rebuilding it" isn't going to happen that easily, it's not necessarily because of objection from the community - quite the contrary, sometimes people actually post ideas that everybody agrees would be great additions to FlightGear, ideas that would quite obviously involve tearing down some major subsystem and replacing it with something better.<br />
<br />
* Really, FlightGear is where it is now after 10+ years of ongoing development, many contributors (especially core developers) are long term contributors who have contributed to FlightGear for several years.<br />
Still, FlightGear is a complex piece of software and there is probably not a single core developer who is familiar with ALL of FlightGear (features, code etc).<br />
<br />
* all long-term FlightGear users know for a fact that there is usually a short supply of C++ developers, knowing not only how to program in C++, but also familiar with 3D graphics, OpenGL/OSG programming and many other aspects that are important when creating/developing a simulator.<br />
<br />
* So we are really standing on the shoulders of giants here, because we are now -after 10+ years- in the position to create significant new features within the constraints of the FlightGear base package, without even touching the C++ source code at all - simply because FlightGear has become so flexible and extensible. <br />
<br />
* So I guess you see where I am coming from: new people now asking to "tear down & rebuild" the whole thing, or people asking to introduce DRM-like measures into FlightGear (content protection) are of course not going to receive a very warm welcome<br />
<br />
* I consider what you want to do perfectly possible, but I advise you to rethink your strategy: your decision to build upon FlightGear to create a combat simulator illustrates an admirable degree of foresight and experience that many other people with similarly ambitious ideas lack, but announcing to "rip out parts" and rebuild the whole thing is very unlikely to happen any time soon.<br />
<br />
* And like I said before: this is not necessarily because we don't want to see this happen: you could probably talk to any core-developer and each of them could tell you that there are a number of parts that SHOULD be ripped out and replaced eventually (i.e. such as some legacy code), but more often than not, things are simply not as easy as they may appear at first glance. When you take a look at the mailing list archives or at the wiki, you'll certainly find plenty of things in the fgfs source code that everybody agrees should be replaced eventually.<br />
<br />
* And if people who have experience working with the code for a number of years refrain from making some important changes, you may want to re-consider your strategy.<br />
<br />
* After all, this is all "for fun" - it's an open source project, so it should be "fun" and enjoyable.<br />
<br />
* you'll have a better chance of getting your code upstream (if that really is your goal) by coordinating your plans with the fg core developers and asking for recommended paths to proceed. Getting your code contributed back is obviously a good idea because it will be much less of a maintenance burden for you guys if your changes become part of the mainline.<br />
<br />
* Ultimately, this being open source, you don't need the approval of anybody - as long as you obey the requirements of the GPL, but rest assured: it will be much easier to deal with the FlightGear community and to get help if you play it "nice" and this very help will be very much needed in the beginning.<br />
<br />
* Suggesting "drastic" changes is all neat and dandy, but after familiarizing yourself with FlightGear you'll probably see quickly that it doesn't really need drastic changes at all: We have witnessed this in the "Local Weather" project, you could say it now *optionally* replaces the old system, but to work properly it only needed a way to switch off the old code - which just involves setting a bunch of properties (variables) from a Nasal script. There was no need to completely remove the legacy code, it was just made optional by setting a switch at runtime. Similarly, the bombable script leverages hard-coded C++ code for instantiating AI models dynamically - but the objects are controlled from scripting space.<br />
<br />
* Today, with much infrastructure available for free or easy obtainable, forking a project has become easier than ever. You might end up in a position to fork Flightgear to support your own pet projects, perhaps your own little business based on said pet projects. The thing to keep in mind is that it is quite hard to keep up with the latest developments. Be prepared to spend lots of hours just to add all the new features being developed in the mainline. However, it can also be a very satisfying experience, especially if you base your own fork on a slightly older code version, and try as hard as you can to keep it stable. A successful fork is hard to achieve and maintain over time, but you may be in a situation where this is required. Do not hesitate to try it. Always bring your contributions to the attention of upstream. They might get merged and save you some trouble in the future.<br />
<br />
[[Category:Working together]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Forum_communication&diff=72714Forum communication2014-06-13T20:07:04Z<p>Bigstones: +nav template</p>
<hr />
<div>{{Working together}}<br />
So you have a problem with installing/starting/using FlightGear, and someone pointed you here. Please take the time to read on. This article will explain how you should ask for support, and why.<br />
<br />
== The "support team" includes you ==<br />
FlightGear doesn't rely on sales or license fees. FlightGear relies on having a base of contributors volunteering their time. This base includes the users, but in order to contribute, they need to be able to see something that bothers them not as something ''to complain about'' but as something ''to be investigated, understood and fixed.''<br />
<br />
== Why? ==<br />
FlightGear is developed by a fairly small community of volunteers, most of which enjoy understanding complex problems and fixing bugs. This community seems to be mostly comprised of "geeks", i.e. people using powerful gaming hardware, and Unix-based operating systems like Linux. This means, unfortunately, that newer features get tested on a very small variety of platforms that can't cover all of the end-users' cases (especially older Windows versions). Sometimes new features are only really tested once they're released, or once they're enabled by default.<br />
<br />
Don't expect your problem to be obvious, actually it could very well be unknown. It's very likely that only few people, if any, have already reported your issue, or even experienced it. In fact, very often such issues are highly setup/system specific and depend on the type of hardware, operating system, drivers, settings - and sometimes even other software installed/running locally. All this is further complicated by the fact that unlike MS FSX, FlightGear is cross-platform software, which means that it needs to run across all supported hardware platforms and operating systems (Windows, Mac OSX, Linux).<br />
<br />
Note that the fact that a bug is rare doesn't make it less important, but harder to solve for the lack of (good) data. In an open-source project like FlightGear without any funding, '''the developers depend on end-users to provide good feedback''' so that they can identify, troubleshoot and fix such issues. And they're grateful for everybody providing this very feedback in a constructive and helpful manner.<br />
<br />
== Troubleshooting is a hard job ==<br />
Remotely troubleshooting problems is an extremely tedious process, however that gets more tricky because of people's tendency to act in a frustrated and sometimes even disrespectful way when reporting such problems.<br />
<br />
Unlike a commercial software project, FlightGear has no funds to invest in development, [[wikipedia:Quality assurance|QA testing]] or support for end-users. Commercial software companies will typically have dedicated teams testing new features across a huge variety of hardware/OS configuration.<br />
<br />
== The quality and timeliness of feedback ==<br />
Lacking of resources, FlightGear depends on end-users providing '''good feedback''' to ensure that it keeps working for most people. And for features in development it also depend on '''timely feedback''', too - given that developers are volunteers, they need sufficient time to troubleshoot and understand a bug, but also enough time to fix it. Preferably, several months prior to a release, not just during the few weeks shortly before release. <br />
<br />
While the community have been providing a way for end-users to get involved in regularly testing FlightGear ''pre-releases'' provided via the [[FlightGear Build Server]], very few users seem interested in getting involved in this, and even fewer people are actually providing bug reports via the issue tracker, unfortunately, so far.<br />
<br />
This is why you need to be the developers' eyes and ears - they cannot see what you're seeing, and they cannot know what you have done. <br />
<br />
== When the frustration kicks in ==<br />
Misunderstandings may arise during a forum discussion. After all, most people here aren't native English speakers. But fighting on the forums is just a huge waste of time and energy. That time is better spent on what our developers enjoy: creating software and new features. They are willing to help ''if provided with enough information'' on the problem at hand. Otherwise they wouldn't hang out on the forum. And they are not getting paid.<br />
<br />
== In conclusion... ==<br />
'''Remember: you're the one having a problem with FG. You're asking for help, and you're not paying for the service.''' So,<br />
<br />
# Be nice.<br />
# Don't blame anyone.<br />
# Try hard to provide the information you are asked for.<br />
# If you are pointed to, e.g., the wiki articles, carefully read and try to understand them.<br />
# Work through any suggested steps to troubleshoot the problem further.<br />
# If you hit any roadblocks, tell exactly how far you proceeded and where you needed help.<br />
# If you are not sure how to provide good feedback, better provide as much info as possible - i.e. through screen shots or Youtube videos.<br />
# Don't expect immediate responses, sometimes it may take a few days to get back to you, especially during busy times (release preparations).<br />
# Try to be respectful, deal with others the way you want to be dealt with.<br />
<br />
You may of course disagree with someone who is most likely way more experienced with FlightGear than you are. But more often than not you'll be wrong.<br />
<br />
Keep in mind that there's really only a handful of people on the forum who regularly provide support to newcomers, those are usually also the most knowledgeable people - and unfortunately, those are also the ones who are most likely busy with other aspects of FlightGear. It isn't uncommon that really tricky issues can really only be understood by people involved in developing the original feature, but those people will have little time to respond properly (if at all), and may also not show much courtesy when dealing with your issue, because we're really just trying to understand and fix problems, not trying to provide top-notch end-user support.<br />
<br />
== Further reading ==<br />
* [[How the FlightGear project works]]<br />
* [[FlightGear and old Hardware]]<br />
* [[Troubleshooting Problems]]<br />
* [[Requesting Technical Help]]<br />
<br />
[[Category:Working together]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=FlightGear_and_old_hardware&diff=72713FlightGear and old hardware2014-06-13T20:06:31Z<p>Bigstones: +nav template</p>
<hr />
<div>{{Working together}}<br />
<!--<br />
{{WIP}}<br />
--><br />
<br />
While FlightGear keeps improving, more and more people - not just users - are starting to consider if anyone is thinking about users with old and/or low-end PCs that can't use the latest features. This concern keeps coming up on the forum and the devel list, and discussing this problem is starting to take up considerable resources, even to just moderate those threads, that tend to turn into very heated debates.<br />
<br />
A selection of responses have now been copied here to present the general consensus among contributors, so that we can hopefully avoid having the same debates over and over, and simply post a link to this wiki article. We are hoping to extend this article over time - analogous to the [[How the FlightGear project works]] article which has proven to be quite a success.<br />
<br />
== Developers have powerful hardware ==<br />
Admittedly, it is a known problem in software development that developers tend to have fairly powerful hardware (especially game/3D developers!). As developers/contributors we do not have access to each and every conceivable hardware configuration - usually, we also just happen to have a single computer, so that is what we're testing on. And quite a few of us have either purchased systems specifically for FlightGear, or machines that are intended to be used for software development - i.e. are fairly powerful by design. It happens so that algorithmic performance often suffers because things are "fast enough" for those developers.<br />
<br />
== What does supporting old computers imply? ==<br />
Making things better configurable and even optional isn't exactly "rocket science", but it's also not very popular, because it is not as gratifying as coming up with a bunch of new features that look stunning. Improving this, entails quite a bit of refactoring work that can only really be measured in terms of performance improvements, while visuals will not change drastically.<br />
<br />
Technically, most of us developers would also appreciate just having fixed hardware recommendations that are adjusted over time as necessary, i.e. for each major release cycle (once per year) - but from a usability point of view, we would regret not being able to run FG on certain hardware, including very old hardware. <br />
<br />
== The need for feedback ==<br />
The situation can only be improved if people help us and provide feedback.<br />
<br />
We'd suggest to "team up" with people who have similar hardware, restrictions and goals, and then actually test FlightGear and regularly provide feedback to the developer community. You could even create a wiki article or forum thread to report what's working and what isn't, and what is performing too slowly.<br />
<br />
Otherwise, there's simply no way for developers/contributors to really know where things are "broken" for people with old hardware unfortunately. Of course that requires involvement, but if you truly care, you'll want to get involved to improve things.<br />
<br />
== Plans for improving performance testing ==<br />
"Feature scaling" is a long-standing feature request, and it simply involves making features better configurable, which also happens to be a key ingredient for [[FlightGear Benchmark|runtime benchmarking, i.e. "in-game" profiling]], which is another thing we're interested in supporting sooner or later. <br />
<br />
Not so much to have 1:1 performance benchmarks, but rather to do regression testing in an automated fashion in some kind of [[FlightGear Headless]] mode, so that certain problems can no longer go unnoticed, without us having to do lots of manual testing.<br />
<br />
To sum it up, we are certainly on the right track here, but once this is done, it will only mean that testing will be easier, but still has to be done by the end-users.<br />
<br />
== We need user collaboration ==<br />
However, the main issue here really is manpower and involvement: we need many more people like you to help ensure that FlightGear is not crippled for users who may not have access to the latest hardware (for whatever reason).<br />
<br />
That said, this involves more than just coming to the forum/devel list and making critical posts - you need to be proactive, i.e. actually test new stuff and report back here, preferably using the devel list or the issue tracker, to ensure that developers are made aware that certain features need to become more optional, better configurable. <br />
<br />
== Posts from the forum ==<br />
=== Baseline Requirements ===<br />
Well, yes, we could point out that you need a computer, electricity, an operating system installed, harddisk space,... we just operate based on the assumption that people know that computers come with different performance, that software has different requirements and that one needs to adjust options to match performance. There's <br />
the [[Hardware Recommendations]] article that details recommended hardware specs. <br />
<br />
But even this article isn't regularly updated by our end-users unfortunately, i.e. as developers, we're getting extremely little feedback in terms of what works, and what doesn't unfortunately. Still, people are coming here and complain about FlightGear not working for them asking us to fix it. Likewise, we've had a build server that regularly provides so called "nightly snapshots" that represent the latest developments all pre-compiled into a single binary, which is another thing that would allow end-users to get involved in testing -and providing feedback- without having to be core developers.<br />
<br />
The main problem here is that as developers we cannot be expected to test/troubleshoot things that work properly for us, we literally depend on end-users getting involved, willing to troubleshoot things for us based on guidance that we provide.<br />
<br />
=== Too much talking ===<br />
Another common complaint expressed on the forum is "too much talking, too little materializing".<br />
You know what ? That's typically a phenomenon of people being unskilled. Not just that though. Unskilled and unwilling to learn new skills.<br />
<br />
So they resort to talking instead, lots of talking. Trying to talk to the few people who actually have some skills. You can witness that in the FDM discussion thread: There's a ton of postings made by many people, and very few postings made by very few people who are obviously skilled an experienced.<br />
<br />
So in simple terms what's happening there is this: Those who recognize their inability/unwillingness to learn something new, beg/nag/annoy others who already have those skills to donate their spare time according to their own priorities. Simple as that. <br />
<br />
So this is typically a sign of people who are unskilled and unwilling to learn new stuff - so they beg others to do it for them, i.e. delegating responsibility to others, instead of shouldering it themselves, and being a pain in the butt in the meantime.<br />
<br />
It's a lame excuse, i.e. talking instead of acting - because talking is so much easier than spending many hours reading something and making experiments, i.e. learning a new skill such editing XML files or working through tutorials.<br />
<br />
And then you have those few people who actually have the skills required to implement what others are requesting - but they have typically very little spare time, because they're involved in other areas of FG, or maybe even because they don't have enough time to contribute to FG at all, due to RL.<br />
<br />
You can usually tell quickly who belongs to which camp of people.<br />
<br />
Then again, you have people like Thorsten, Philosopher or Gijs who have contributed hundreds -even thousands- of hours contributing to FlightGear. And they're typically the ones being asked to provide help and support in a 1:1 mentoring setup. Despite the fact that these very people also spent many hours creating resources (such as tutorials) to enable others to learn the very same skills they've acquired, by playing with "hello world" examples, experimenting a bit and working through tutorials and code examples.<br />
<br />
It's "education", just that - education always pays off, no matter if it's a degree in real life, or if it's time spent learning a new skill, such as cooking or programming, 3D modeling or writing.<br />
<br />
Successful contributors always seem to have understood that you need to be able to walk before you try to run.<br />
Many others didn't understand that, even if they were told so. We had one guy interested in "rewriting" the bombable addon, without ever looking into the code, without talking to flug (its developer) first.<br />
Kinda uninformed and stupid isn't it ?<br />
<br />
If you want to participate in a F1 race, you need to understand the rules first - and better already know how to drive a car, right ?<br />
If you were to learn how to play golf, you'd better spend some first getting the basics straight, right ?<br />
You'd be kinda ill-advised to directly ask Tiger Woods to coach you, right ?<br />
<br />
But that's exactly what's happening once people come here with a zero track record of contributing to the project, and without any obvious willingness to do some upfront work, and then ask folks like Thorsten or Philosopher to "coach" them, because they are "Tiger Woods" in FG terms <br />
<br />
Kinda annoying if you ask me ...<br />
Honestly, instead of asking the pros to accommodate you, show some willingness to get started first of all.<br />
Especially at a stage where you still have zero clue about anything relevant apparently and zero interest in rolling up your sleeves to make some experiments first ?<br />
<br />
My whole point was that we're all in the same situation at some point - your situation isn't any different.<br />
No matter if it's due to your skill set, limited spare time or limited hardware budget. All of us were once faced with at least one of these before.<br />
And like I've shown now, others are much more constrained than you are.<br />
<br />
Yes, you can go and claim that this is about all the skills necessary - but that's simply not the point.<br />
<br />
To be perfectly honest, I am not at all interested in learning Blender (3D modeling), I once had it installed but I didn't seem to have the mental capacity (read:patience) to use it any longer than 5 seconds without becoming crazy. As you can see in the canvas forum, others (including core developers) cannot stand Inkscape at all.<br />
<br />
So when I needed help related to 3D modeling, I ask others -more experienced with it- to do this for me.<br />
In return, I volunteer my own time to accommodate them, i.e. personal networking. Likewise, I am not overly interested in FDM tuning, but I can help with other things.<br />
I am also not very interested in learning GLSL or effect development, but I am sure that I could ask Thorsten to help me here, because I helped him with other things.<br />
<br />
You will find that this is how the project works generally.<br />
We have quite a few people giving "impulses" every once in a while, without necessarily contributing directly to the corresponding effort itself.<br />
You will find that I usually try to provide something in return whenever I leave a comment suggesting/requesting something - such as an offer to help with some specific feature or implementation detail.<br />
That's kinda the "glue" that keeps things together here. And that's all there's to it, really.<br />
<br />
Of course, I also find it much easier to just make suggestions or requests than implementing something directly.<br />
<br />
But that's simply not how the project works (or life in general). Not even for people who are core developers and intimately familiar with the project.<br />
You'd be surprised at the number of good comments and suggestions made by long-time core developers, that receive little or no feedback from others in return to good, informative and well-written suggestions. Zakalawe is encountering this regularly on the devel list, and still keeps on contributing - handling many ideas on his own instead.<br />
<br />
Usually, there's a handful of people interested in exactly the same things as you're. Now, you could do yourself a favor and read what they've written and actually find a way to team up with them.<br />
<br />
Some of them may be interested in XML, 3D modeling, texturing or scripting - whenever you team up with others, only need to complement each other.<br />
<br />
It would only take 20-30 minutes of your time to get this started, i.e. send out PMs to others and find a way to make yourself useful to them.<br />
<br />
So what I have laid out here is a way to make yourself useful to others, and actually cause the changes you're looking for, without having to do all the work yourself.<br />
<br />
=== Optional Features ===<br />
People go through great pains to implement new stuff in optional ways. Replacing the default renderer by ALS would be way easier than implementing ALS in an optional way such that aircraft-defined effects work in both frameworks. Replacing Basic by Advanced Weather would be much easier than to come up with a common, 'neutral' interface to which any weather system can talk to. Writing and maintaining a single terrain shader would be much easier than write and maintain three quality levels which have different demands on the GPU.<br />
<br />
Ripping out the default rendering pipeline in favor of [[Project Rembrandt]] would have been much easier than supporting multiple rendering pipelines. <br />
<br />
Possibly a quarter of developers' time goes into implementing stuff in such a way that you can run FG with essentially the options of 1.9.1 or that you can scale back performance needs. We don't even delete the legacy 256x256 terrain textures which duplicate hires textures, so if you have low GPU memory, you can go to the global texture scheme, delete the Textures.hires folder and run with very low texture resolution on the terrain.<br />
<br />
In pretty much every discussion on the devel list, having a fallback mode whatever new feature is implemented featured prominently.<br />
<br />
The only thing that really works differently between 1.9.1 and 3.0 on a legacy system is that 1.9.1 will work right out of the box, whereas for 3.0 you will have to configure some to make it work.<br />
<br />
=== Discrimination ?? ===<br />
This is one of the more common thoughts expressed on the forum, so here's our take on it:<br />
<br />
Users are essentially getting FG for free, but though most people with lower-end hardware can run the older versions just fine and can still get scenery and aircraft for versions like 2.6, some feel discriminated against because they can't run all the newest developments on outdated hardware and don't feel up to changing the config a bit to make it at least run? Seriously?<br />
<br />
That's a slap in the face of all people in the world who really have to suffer from discrimination.<br />
<br />
There isn't any form of discrimination taking place: not even manufacturing a Ferrari or Porsche qualifies as discrimination just because I cannot afford buying a Ferrari in cash - and FlightGear is far from being a high-end product. <br />
<br />
FlightGear is very much like shopping: you get what you can afford, but you aren't discriminated against just because there's certain products like salmon or caviar that you cannot afford to have every day, you simply don't use/buy them. Just because your cable TV offers payTV doesn't imply that you have to use it, or that you are "locked out" by it. The whole discussion kinda seems like people complaining about the prize for "first class" tickets, even though they're not forced to even use certain features (like flying).<br />
<br />
Some users tend to think that just because FG is free, that all its latest features also must be freely available to everyone - then, we would need to add $3k worth of hardware to each free download to make that work.<br />
<br />
On the other hand, we do have a few users and contributors who have fairly recent hardware, for which the FlightGear default settings do not scale particularly well. They're asking us to provide more eye candy features, such as higher visibility, beyond just 30 km. <br />
<br />
Consider FlightGear like a cell phone plan: it can certainly be used to make phone calls as is (even when using 90s-era phones), but if you want it to do other things (GPS, internet access, games, mapping, iPhone/Android store etc) - you simply need to have certain hardware - FlightGear is really just the "plan/contract/service/software" offered here (AT NO COST to you), it has nothing to do with the type of hardware that you've got access to. <br />
<br />
In fact, as a piece of software, the program knows nothing about the hardware you have - so we need to make concessions and compromises to support commonly available hardware. More often than not, this process is based on what we, FlightGear contributors, have access to - i.e. it is people who actually get involved in testing and development that get to provide feedback.<br />
<br />
And while it is true that some things need changing to better support older hardware, the majority of features that people are referring to in such discussions (Rembrandt, ALS, advanced weather, osgEarth) simply cannot be run on 90s-era hardware realistically, which has nothing to do with FlightGear. FlightGear is just a collection of technologies, including things like GLSL (shaders) or osgEarth - however, if not even these components can be run with old hardware, don't expect FlightGear to do so.<br />
<br />
And as a community of volunteers contributing to the project, we typically only have access to 1-2 "devices" (computers) to test-run our code, so we depend on others to provide feedback. For instance, there are some of us who really have more than just a few computers, but testing and running FlightGear on such computers is also taking up time, and few of us actually do that regularly.<br />
<br />
Some people are basically asking for hardware with "forward compatibility", because that's the main problem here: old hardware not being able to support certain features, i.e. pre-GLSL hardware not supporting shaders isn't exactly surprising.<br />
<br />
=== Scaling Issues ===<br />
Most of us do agree that there's an increasing number of features in FlightGear that require an unprecedented degree of "customizing" things for FlightGear to still perform on "old" hardware. <br />
<br />
We are definitely facing challenging times when even people with 2gb VRAM, 12 gb system ram and quadcore CPUs end up seeing FlightGear crashing more often than not due to lack of resources. <br />
For most of us, this just means that because of our typically very powerful hardware, the problem is kinda "masked" for a while, and has been obviously for some time.<br />
<br />
But don't forget it is the samurai coder way to make everything as efficient as possible, and make it run even on the toaster. That's not the case with terrain here, there is lots of room for improvement, right now terrain rendering is very inefficient and quite last century. An upgrade would not only make it run on toasters, but also give us almost unlimited distance and other underlying facilities. But it is a hard endeavor, perhaps one of the hardest.<br />
<br />
And the problem is two-fold: startup defaults that may make certain assumptions (without fallback mechanisms), but also runtime usage of precious resources without providing a means to track CPU/RAM/VRAM usage across subsystems.<br />
<br />
Even if you were to completely ignore the rendering side of things, there are algorithmic issues involved here - i.e. certain things would even be problematic in a purely "[[FlightGear Headless|headless]]" mode - no matter if it's CPU or RAM resources that are burnt, and that's the kind of stuff that needs to be solved first.<br />
<br />
Sooner or later we will need to tackle this (and it has nothing to do with AW/ALS or anything that Thorsten is working on).<br />
<br />
Note that I am not suggesting that we should "aim lower" or settle for some unreasonable set of defaults, because that would be just as frustrating for people who actually do have the corresponding horsepower. Instead, we should explore options to make things increasingly runtime-configurable and entirely optional if necessary, so that a few lines of scripted Nasal code can dynamically query the runtime environment for certain traits (number of CPU cores, amount of RAM/VRAM, GL/GLSL support) and automatically not use certain code paths that are known to be problematic for people without such hardware.<br />
<br />
The effects framework seems to be half-way there because it supports conditions and can use different fallback mechanisms - but in other areas, this still needs quite some work. It is however valuable work that would help us in other areas, such as supporting runtime-switching of aircraft, re-initialization - or re-targeting FG.<br />
<br />
As has been said earlier, it is currently possible to run FG 3.1 on extremely old hardware - even on an Intel GMA netbook with very poor OpenGL support - but it takes quite a bit of tinkering, and may sometimes even require code changes. We've seen people on the forums who reportedly ran FG 3.x on computers as old as 8 years, and graphics cards as old as 6 years.<br />
<br />
If I had to use really old hardware, I'd still go with Linux though, I have seen 90s era server hardware being extremely well supported by even a 3.x kernel, with rock-solid performance.<br />
<br />
FlightGear-wise, I would also be inclined to use the latest & greatest and customize it heavily, and provide feedback if something doesn't work as expected.<br />
<br />
However, keep your expectations reasonable. <br />
<br />
Thorsten's work however has always been 100% optional and shouldn't affect people on older hardware, and it isn't feasible to "back-port" certain features like Rembrandt, AW, ALS or osgEarth - for the reasons mentioned above.<br />
<br />
=== Response ===<br />
So the whole discussion is really not about whether we should commit to run FG on legacy systems. The whole devel community is committed to that goal. The discussion is really about how straightforward this should be. Hooray evidently argues that all installation should default to legacy systems, the majority of the devel community has the trend to set the defaults to the assumption that you run on a present-day moderately powerful computer.<br />
<br />
And what angers me personally is that there's just zero recognition that we go through all the pains of implementing new things optionally and keeping the legacy door open. I never seem to be dealing with people who say 'Hey, it's great that this still runs on my old XYZ system, all I had to do was...' I only seem to run into people who expect it to work out of the box, complain about growing harddisk needs of the installation, don't bother to read up on some config options and then complain that FG is only for rich people, that we'd ban users and similar nonsense.<br />
<br />
So yeah, if you want to run present day software on a legacy system, what's wrong if you have to configure some yourself?<br />
<br />
The whole development would really be much simpler if we'd do it the commercial way - we define system requirements, make sure the whole results fits into these, and if we add cool features we just raise them. We could get rid of plenty of legacy code, textures and such, get a more streamlined installation process, reduce the number of user-controllable options to something way more intuitive - there'd be plenty of goodies to that. Except we're not doing it.<br />
<br />
I'm the author of a rather popular (several 100.000 downloads) introductory course to Tolkien's Elvish languages. I wrote this course initially in German, later changed to English. I made the pdf freely available for download.<br />
<br />
There are undoubtedly people interested in Elvish who don't speak English well enough to understand the course. There are undoubtedly people who don't at all own a computer and can't hence read the course. There are people without internet connection who can't download it. So I've made a course that isn't really accessible for literally everyone, but only for those who have the technical means to access it.<br />
<br />
In what way would that mean I am not fair? I made something freely available - some people can't get it only theoretically though - why does that argue I'm unfair? Where in this whole business is my duty that if I spend 1000 hours on writing something, I have to spend another 2000 hours translating into more languages / different formats to that *really* everyone can get it? Where does your sense of entitlement come from that if something is provided for free, it has to be provided in such a format that really everyone can use it, otherwise it'd be unfair?<br />
<br />
If you take a 12 year old computer and try to install Windows 8, I doubt it would work. You might barely be able to make Linux run if you get source code for legacy drivers.<br />
<br />
The answer to your question is, lots of new development happens because there's development on the hardware side. We can now do things which we couldn't do 10 years ago because graphics cards are more powerful, there's more memory, more processing power. Which means if you don't have new hardware, you won't be able to benefit from a large share of new development. <br />
<br />
It's not that you couldn't get and run FG I presume - apparently the older versions run just fine for you - so you're in fact getting the product you want for free, the only thing you're not getting are the new developments - which you couldn't use anyway because they rely on new hardware. As for not being sure whether you can download aircraft for older versions - 30 seconds entering 'flightgear 2.4 aircraft download' into google would have led you here - we care so little about legacy support that the whole list for 2.4 is still up for download...<br />
<br />
So the gist of this rant is in fact that you feel unfairly treated because FG development doesn't happen specifically for you and your requirements (I hold to my statement, and Hooray has even proven it - newer FG version do run still on old hardware if you configure some) but the defaults target other users. Well - guess what - they also complain and say 'this is so rubbish' if FG does not use all the performance modern hardware provides. So kindly stop assuming you're the center of attention of the devel community and accept that FG is developed for the average hardware a user would presumably have - if your system is much different from that average, either above or below, you need to tweak options.<br />
<br />
=== Lack of Testing ===<br />
The main problem here is lack of testing not lack of development. In fact, it is the progress in developing that is causing such issues for people like you on outdated hardware: If there wasn't any progress, things would stay as they are, and just "work". So the real problem is lack of testing, not by developers, but by end users willing to get involved in order to help us ensure that FlightGear also works on hardware that we don't have access to.<br />
<br />
you don't need to become a developer to help us with testing. Even 3.0 should probably work for you if you use the instructions detailed in the article I linked to earlier.<br />
But obviously we cannot know what doesn't work as long as people don't actually help us testing and report back. Which is not just about you - it's a general problem.<br />
<br />
That said, even regardless of outdated hardware, FlightGear would be in a much better shape with more testing applied, and with more considerations for backward compatibility - there's an increasing number of users wanting to run FG on different types of hardware, such as gaming consoles or even mobile phones - here, the current way of starting & initializing FG is extremely problematic. So there are some things that need to be teased out first.<br />
<br />
This is not about applying "low" standard to all hardware - it's just about finding a common subset of startup settings that works for most people, so that the system can really "boot up" and add new stuff incrementally - kinda like a computer is booting (POST, BIOS, boot loader, real mode, protected mode, operating system, networking, GUI, hardware acceleration etc)<br />
<br />
This is something that we don't currently do very well, but it would help us in other areas (profiling, benchmarking, even headless regression testing, runtime re-initialization (saving/switching flights & aircraft) etc), so it is a worthwhile thing to aim for, even for people who have access to the latest hardware. <br />
<br />
But it's not going to happen over night, it will take patience and lots of testing and feedback - and keep in mind that the forum is not a good place for bug reoprts, a forum is about talking/debating, the issue tracker is a better place for such reports<br />
<br />
We have various starting points and articles to help with various steps, but nothing fully dedicated to "just" testing.<br />
But the minimal startup profile should be a good starting point, and then it's primarily a matter of testing various settings and using the issue tracker to report things (or at least the wiki).<br />
Ideally, people would team up with others on similar hardware. Coming up with your own .fgfsrc startup files may also be helpful (documented on the wiki), so that "profiles" can be more easily shared & exchanged. Benchmarking-wise, people could exchange pre-recorded flights and/or flight recorder tapes to replay certain flights.<br />
<br />
And then it's obviously helpful being able to interpret results, i.e. frame rate, frame spacing/latency, system monitor, built-in profiler.<br />
And accessing the log file in [[$FG_HOME]] would another thing that I'd cover in such an article. <br />
<br />
Pretty much all of these things are separately covered on the wiki, so pointers are easy to provide, it's just a matter of adding a handful of paragraphs to link all steps together, and maybe add some screen shots.<br />
<br />
To put it very bluntly: Currently, testing is one of the least popular occupations among our end-users, but also contributors - to many, this may seem like an issue that needs to be solved, and for which the project is to blame. However, we've had other areas were resources were severely lacking, such as certain documentation, or tutorials for new contributors and developers. Meanwhile, these issues have been addressed (often by very few people), however this usually meant that they're the ones to shape were things are going to some degree - I usually refer to this as "embrace the gap", by filling it what you consider important - i.e. "being the change you want to see". This is the key difference between people who come here and "whine" all day long (for months or even years!), and others who simply roll up their sleeves and accept the challenge to fill some void with their own ideas & contributions.<br />
<br />
In the context of "testing" and community networking, this could actually mean that even just a handful of dedicated end-users could significantly affect FlightGear development, simply because there's really not a lot of testing going on otherwise - i.e. it would currently take just a few testers to basically dominate or even "own" this feedback category.<br />
<br />
And as mentioned elsewhere, it is something that will be useful for a number of related efforts, even though it may not be obvious to most non-developers.<br />
<br />
Nobody here is asking you to become a programmer or aircraft developer to help us with testing.<br />
<br />
To be honest, most of us fully agree that FG's support for older hardware has not really improved very much during the last 2-3 release cycles, and we find it a pity too.<br />
<br />
But to me, this is not about some outdated aircraft - it's a core problem, that should and could be tackled, and people like you (on old hardware) could actually help with it, e.g. by contributing to the issue tracker whenever something doesn't work as expected.<br />
<br />
IF we had more people like you contributing to the project actively, certain things would not go unnoticed.<br />
For example, I actually contributed a tiny little patch 2-3 years ago which was intended to provide better diagnostics for OpenGL/shader issues.<br />
It was trivial, but it actually broke FG for people who didn't have hardware supporting shaders, i.e. people with old hardware - like you.<br />
I never noticed anything, and neither did any core developers - because we all had sufficiently modern hardware.<br />
Then again, we cannot all have dozens of computers to test FG on, that's where folks like you come in.<br />
<br />
I would LOVE to have 20+ people here with really outdated hardware who regularly test-run FG on such hardware and provide feedback via the issue tracker.<br />
And I would volunteer my time to help ensure that things are kept working on such platforms.<br />
But so far, we have very few folks actually interested in contributing in this way to the project.<br />
<br />
[[Category:Working together]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Entitlement&diff=72712Entitlement2014-06-13T20:06:05Z<p>Bigstones: +nav template</p>
<hr />
<div>{{Working together}}<br />
'''Entitlement''' is the errorneous perception by a subgroup of users that the Flightgear development team 'owes' them certain things for no other reason than that they are using Flightgear. This basic misunderstanding makes communication between developers/contributors and users prone to fail.<br />
<br />
The reality is that Flightgear is developed by a team of volunteers who work for the project in their spare time and that users get the finished product for free (that 'free' includes costs for infrastructure like download bandwidth and file hosting), so it is difficult to see in what sense developers would owe users in addition to the service already rendered. If anything, it would be the other way round.<br />
<br />
In practice, entitlement comes in various forms, often in statements like 'users should get more of a say where the project goes', requests to make binding votes and polls or unrealistic expectations in problem reporting situations.<br />
<br />
== Votes and polls ==<br />
<br />
With some regularity, users express their ideas on where they think the project should be going and feel that the project should be more democratic and take their vote into account and are disappointed that this leads nowhere. However, Flightgear is in essence a meritocracy in which the influence on where the project goes roughly scales with how much a contributor has previously contributed, and often even how difficult/complex that work was/is.<br />
<br />
{{cquote<br />
|<nowiki>FG works the way it does for a reason - exactly because people like you (or I) don't roll up their sleeves to change it for the better, but instead prefer to just voice their criticism.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So what you can learn by reading such articles is how the project works despite all of us being "lazy volunteers", who do not like to be told what to work on, and instead work on their own little pet projects, and just resort to making comments whenever we do not agree with something that we're not interested in getting involved with.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211164#p211164<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
There are at least two basic reasons why the project does not let vote users into which direction future development should be going. First, making such decision requires insight into what the issues and alternatives are, and what they would imply. Some seemingly small changes may in fact require large changes in the basic architecture of the software. Inofficial opinion polls <i>backed up with arguments</i> are sometimes held on the developer's mailing list, but the aim is more to distill the arguments than the individual opinions. Basically, project decisions should be made by the people who have the skills and experience to make them. This has real-life analogies - in case of an emergency, an airliner crew does not give the passengers a vote what should be done, the cockpit crew decides that, as they have the skill and experience necessary, the passengers do not. People following the developers mailing list will notice that even many core developers will often just express support for certain ideas, without really offering to work on implementing them-this is why it is ultimately up to the corresponding contributor to decide how to proceed, as long as there is someone who is able to commit. <br />
<br />
{{cquote<br />
|<nowiki>people won't change a single thing just by debating - even if they should be completely right. And being ignorant about how the project works behind the scenes, will not help much either. This is not to say that we all "like" the way the project works, but the way things are working is not by conscious decision, but due to the exact same behavior that many people have been exhibiting here for the last few years: due to people caring about their own stuff, with little to zero interest for getting involved in other projects, that they consider "side kicks". Simple as that. It is the few cases where people manage to work around such issues and actually collaborate that FlightGear is shaped in major ways, and consistency improved. Nasal, Canvas, NavDisplay and MapStructure are testimony to this working extremely well - but it's tedious and not exactly "fun" to work like this - just ask TheTom, Gijs, Philosopher or myself: It is much more fun to focus on our own little projects than keeping the big picture in mind and coordinating things behind the scenes. </nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211164#p211164<br />
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Fri May 30</nowiki><br />
}}<br />
}}<br />
<br />
The second reason is tied to the volunteer nature of the project. Volunteers can not be compelled to work on something they do not like. Even if a user vote would make sense conceptually, if the people who have the ability to code a certain feature that has been voted in do not want to do it, it all stops there. It is completely unreasonable to ask people who devote their free time to coding for Flightgear to regularly do things someone else tells them to - especially if that someone else has not done any service for the project. <br />
<br />
For example, some of the more recent advances in FlightGear, such as [[Canvas]], were suggested and discussed several years prior to the current implementation by some of the most senior core developers-yet, it was never implemented by any core developer, but by a new contributor who became a core developer that way. This goes to show that people may even agree on technical terms, but may still lack the interest/skills to actually implement an idea-which is why good ideas may often have a certain shelf life.<br />
<br />
== 'Useless' development ==<br />
<br />
A related theme sometimes raised comes in the form of the question 'Why do people develop a useless feature like X when the important problem Y is not fixed?'<br />
<br />
Since developers are volunteers, they pick the issues they think need to be improved with highest priority within the limits of their expertise. That means first, that while everyone may agree that there is e.g. a problem in 3d rendering which needs to be addressed, it still makes no sense for a flight dynamics coder who has no knowledge of 3d rendering to address it and vice versa. The Flightgear development team is not a homogeneous pool of people who understand every aspect of the simulation and could potentially be reassigned to any task, rather most people have their area of expertise within which they maintain systems and address problems and it makes no sense for them to address issues outside their expertise. Much of the FlightGear code base consists of legacy code, which isn't actively owned, or even just maintained, by a developer. This also leads to situations where active core developers feel no longer qualified to maintain certain unmaintained components, such as for example the YaSim FDM or Nasal scripting engine.<br />
<br />
But within an area of expertise, developers work according to their own perception what is important and what is not. Anyone who decided to work on X rather than Y is obviously of the opinion that X is more important than Y. A user demand that a developer should not use his own judgement on what has highest priority but rather accede to the user's idea on what is important is hence just another form of the above - a wish to exercise control over the priorities of the project without investing any effort. To people familiar with the project and its code/infrastructure, such attempts get very obvious pretty soon, and they start becoming boring quickly. If you'd like to have some attention from other contributors, make sure that you're offering something in return, as per: [[Implementing new features for FlightGear]]<br />
<br />
== The FSX threat ==<br />
<br />
Sometimes users threaten to leave Flightgear for another simulation software like FSX or X-Plane if their idea is not taken into account. From a developer's perspective, this is an empty threat, as the number of people who just use the software is irrelevant for the continuation of the project. This is very different from commercial projects where the number of users largely is the number of customers who finance the project, but in the Flightgear case, things actually work the other way round in that a larger userbase creates a larger drain on the infrastructure, making it more difficult to offer it for free.<br />
<br />
Thus, approaching Flightgear with the attitude of a paying customer who is crucial for the project leads nowhere - Flightgear users are not paying customers, and users leaving for FSX will not have any impact on the project.<br />
<br />
What will have an impact is contributors leaving the project - but contributors have rendered services to the project already, and so they may receive some attention from other contributors in return.<br />
<br />
{{cquote<br />
|<nowiki>any type of company/collaboration needs to be self-sustaining, a commercial entity/company will usually be self-sustaining by charging money for its products/services and listening to those who are willing to pay for them. An open source project, which doesn't have any access to regular/stable funding, needs to be self-sustaining, too - and here it's obviously contributors that are spending their time so that the project can be improved - indeed, some may even spend money on infrastructure (hosting, shipping, advertising, bandwidth etc).</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212372#p212372<br />
|title=<nowiki>Re: Eye Candy & Performance Issues (was: Slope line patterns</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Wed Jun 11</nowiki><br />
}}<br />
}}<br />
<br />
== The silent majority ==<br />
<br />
Several users have in the past questioned whether the feedback provided via the forum and other channels is really representative and argued that they represent the position of the (much larger) silent majority of users who do not provide feedback anywhere.<br />
<br />
It is certainly true that the sample of users reporting back is skewed - but the skew goes the opposite direction, since a main driving force for users appearing in the forum is that they experience problems - in all likelihood, the silent majority is therefore silent because these users don't see problems.<br />
<br />
However, as argued above, the (non)-existence of a large number of users having one opinion or the other who do not want to get in contact with the project is irrelevant for the way the project works. Unlike paying customers, the sheer number makes no difference anywhere. So even if the silent majority could be demonstrated to be of a certain opinion, the argument would not be stronger. This also holds true with regard to making our multiplayer environment more popular, which is another common notion expressed on the forums: <br />
<br />
{{cquote<br />
|<nowiki>These things are not obvious to bystanders, but our "multilplayer network" isn't very much different from having a handful of litter boxes with people trying to use them for certain purposes (for which they were never designed!), despite not quite realizing that they can only "handle" so much, in terms of capacity/load and use. Which is exactly the reason why we don't mind being reminded that there's not hundreds or thousands of people using the system: the existing system is too lame to even think about such a thing. We would have a huge problem if we all of a sudden had hundreds of players. And some of the features discussed here would definitely make things more popular (ATC, combat, airliners, virtual airlines). Currently it's just imaginary features that are implemented by people using very few feature and lots of imagination.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
We would be in the same situation if we suddenly had thousands of former FSX/XP users here - we couldn't handle the sheer volume, and we couldn't get anything done.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207692#p207692<br />
|title=<nowiki>Re: Trouble at EDDF-Triangle</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Thu May 01</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>Also consider that the added traffic will explode the bandwidth required by the multiplayer servers, possibly breaking bandwidth limitations</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=168233#p168233<br />
|title=<nowiki>Re: Populate AI Traffic with real traffic</nowiki><br />
|author=<nowiki>Johan G</nowiki><br />
|date=<nowiki>Mon Oct 08</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>The current MP system probably isn't able to deal with this amount of "traffic" at the client-side - thus, it might make more sense to develop this as a server-side module, that can be run as part of the fgms process.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=168249#p168249<br />
|title=<nowiki>Re: Populate AI Traffic with real traffic</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Mon Oct 08</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki> think we are lucky that obviously not everybody is making use of the FlightGear multiplayer support: the current multiplayer system is simply not designed for that many players, it is not even particularly efficient at what it is doing-so, I wouldn't even want to imagine how hundreds or even thousands of clients are joining the current network of servers.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
In fact, even apart from the multiplayer server design, multiplayer support isn't yet as enjoyable as just running the simulator without it: I rarely use mp myself, I just don't like the spikes in lag its causing on the simulator.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
I wouldn't dare to suggest making mp more accessible by enabling it a default in fgrun, it would just reflect badly upon fgfs as a whole.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=28354#p28354<br />
|title=<nowiki>Re: Just out of Interest</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Sun Mar 08</nowiki><br />
}}<br />
}}<br />
<br />
{{cquote<br />
|<nowiki>it's kinda pointless currently to debate the merits of such a system, because our existing architecture is fairly inadequate to pull something like this off. Yeah, having a restricted 5-10 player shared MP environment may be possible to come up with by using some creative workarounds - but overall, our existing MP system is not really a good foundation for something like that.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
In very simple non-technical terms, our fgms server acts like a "mirror" in the conventional sense, it isn't very much state-aware and cannot be easily ab/used to share/propagate/replicate other state, beyond what is currently hard-coded - that is why people had to come up with "generic properties" and the mp_broadcast system.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
We hit some of those limitations back when we were working on extending fgms to use RL traffic to populate our world</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209362#p209362<br />
|title=<nowiki>Re: Online </nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Tue May 13</nowiki><br />
}}<br />
}}<br />
<br />
We've also been seeing similar debates about introducing VATSIM/IVAO-like feature (virtual ATC) or people debating how adding more VA related features (virtual airlines) would help make the project more popular. <br />
<br />
{{cquote<br />
|<nowiki>Nobody designed any "ATC code". For the time being, there's basically zero FG contributors who are working on ATC related stuff as part of FG, so we have more people willing to use/provide ATC than people willing to implement and maintain it. Thus, there really is no ATC environment at all. What you describe as "ATC code" is a huge workaround, much more so than any other scripted system is, including flug's bombable addon or Thorsten's weather system (those are actually designed). In the case of ATC support built into FG, it doesn't exist. Simple as that.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
What you may perceive as some form of "ATC system" is nothing more than creative use of a handful of features, namely scripting, XML, a few GUI dialogs and the conventional FlightGear chat system, built into MP.</nowiki><br/><nowiki><br />
</nowiki><br/><nowiki><br />
So, it's not that people are "pooing into the ATC sand box" - rather, ATC is taking place in a huge cat loo The only reason it's still kinda immersive for some, is that people are actually talking and behaving like ATC, and others are willing to comply with their request. But otherwise the whole feature is a fake - we have no ATC system in FlightGear, neither the fgms/MP network, nor the FG binary has any explicit support for MP-enabled ATC.</nowiki><br />
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207692#p207692<br />
|title=<nowiki>Re: Trouble at EDDF-Triangle</nowiki><br />
|author=<nowiki>Hooray</nowiki><br />
|date=<nowiki>Thu May 01</nowiki><br />
}}<br />
}}<br />
<br />
== Bug reporting ==<br />
<br />
The Flightgear project does not have the resources to pay for a user support department, so again all bug reports are handled by volunteers. Most bug reports are answered with requests for more information. The reason is that it is almost impossible to find the cause of a bug if it can't be reproduced. Some users react rather violently to this, apparently out of a notion that they have done their part by reporting the bug, so now it's the developers' duty to fix it, not to ask more questions.<br />
<br />
Needless to say, this is an unproductive attitude. Nobody likes to trace bugs, people volunteer nevertheless because they realize there is need. However, to expect that a volunteer will put up with rudeness and go out of his way to investigate many possible causes of a problem he can't see because a user doesn't provide enough information is unrealistic. Users are not paying customers, and the people trying to help with problems are not a paid support department.<br />
<br />
== Support for outdated hardware ==<br />
<br />
Also see [[FlightGear and old Hardware]]<br />
<br />
On occasion, users have accused to project of discriminating against them, as they can't run the recent versions of the program on their hardware. Note first that the premise is likely not true - Flightgear is known to run fine on very old hardware using a [[Howto:Debugging FlightGear Crashes|minimum startup profile]] and legacy support is strong driving force for decisions made in the devel community. <br />
<br />
However, leaving that aside and assuming that there are systems on which a recent Flightgear version no longer runs - in what way would that be discrimination? Especially since older versions are still available? Why would the project have an obligation to support every bit of hardware in existence? With the same logic that 'free' equals 'everyone must be able to use it' - should the project provide computers for everyone who wants to use the simulator but does not own a computer at all?<br />
<br />
Users who invest in high end graphics cards have at least just as much reason to expect that new version make use of their computers' performance. Many novel features are implemented optionally can can be switched off, the project tries hard to be backward compatible (and is probably much more so than any commercial software) but fundamentally there is no right of a user that his hardware is supported, and accusations of discrimination against users with low end hardware are just baseless.<br />
<br />
Finally, there are features that cannot be realistically run on very outdated hardware, this includes deferred rendering schemes like [[Project Rembrandt]], many shaders/effects, but also osgEarth or osgOcean support - more often than not, these features actually '''require''' fairly recent hardware. <br />
<br />
And in the case of osgEarth, or many other OSG-based features, the hardware requirements (such as e.g. shader/multi-threading support and lots of RAM/VRAM) are actually beyond the control of the FlightGear project - FlightGear merely ''uses'' existing software, that comes with certain hardware requirements. <br />
<br />
People really need to understand that FlightGear is the product of putting many ingredients together, these ingredients are so called "dependencies" (usually, libraries) - and it is only normal for such libraries to have their own hardware requirements. And once you integrate, enable and use such optional features, you cannot expect that hardware requirements will remain the same. It is for a reason that these features are usually optional: they will not work for people without certain hardware specs. But for FlightGear to make progress, we must evolve and add new features, features that also scale with the horsepower available.<br />
<br />
[[Category:Working together]]</div>Bigstoneshttps://wiki.flightgear.org/w/index.php?title=Template:Working_together&diff=72711Template:Working together2014-06-13T20:05:07Z<p>Bigstones: Created page with "{{sidebar | name = Working together | title = Working together | contentstyle= text-align: left; | content1 = The project as a whole: * How the FlightGear project works..."</p>
<hr />
<div>{{sidebar<br />
| name = Working together<br />
| title = Working together<br />
| contentstyle= text-align: left;<br />
<br />
| content1 = <br />
The project as a whole:<br />
* [[How the FlightGear project works]]<br />
* [[Howto:Understand the FlightGear development process]]<br />
Users and feature requests:<br />
* [[Implementing new features for FlightGear]]<br />
* [[Entitlement]]<br />
* [[FlightGear and old Hardware]]<br />
Communication:<br />
* [[Forum communication]]<br />
}}<br />
<noinclude>[[Category:Navigation templates]]</noinclude></div>Bigstones