FlightGear wiki talk:Instant-Refs

From FlightGear wiki
Revision as of 21:51, 14 June 2014 by Bigstones (talk | contribs) (→‎recognizing wiki images: problem found, not the fix though...)
Jump to navigation Jump to search

regex / sourceforge Done Done

You're right - I just checked out the sourceforge archives, there's just a single 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.--Hooray (talk) 16:12, 31 May 2014 (UTC)

RX suffix Done Done

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:

var CONFIG = {
"sourceforge.net": { 
        author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },
        title:  { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },
        date:   { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },
        url:    { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }
    },
};

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! 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! --Hooray (talk) 16:23, 31 May 2014 (UTC)

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.
EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D
--Bigstones (talk) 18:27, 31 May 2014 (UTC)
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.--Hooray (talk) 19:47, 31 May 2014 (UTC)

extractInfo loop Done Done

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 .--Hooray (talk) 20:22, 31 May 2014 (UTC)


more sources

at some point, we may also want to add support for other sources, such as:

that should cover all important sources. And it would allow us to also use the same script to help populate FlightGear Newsletter & changelogs, but also Release plan/Lessons learned. So this could be a real time-saver. --Hooray (talk) 14:40, 1 June 2014 (UTC)

Post-Processing

the prepend field Done Done

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. --Hooray (talk) 22:24, 31 May 2014 (UTC)

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.
--Bigstones (talk) 23:47, 31 May 2014 (UTC)

CR/LF - br handling Done Done

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 ([[FOO]]) 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 <br/>) --Hooray (talk) 15:39, 1 June 2014 (UTC)

I'll take a look at these, paragraphs are easy indeed Done Done.--Bigstones (talk) 19:53, 2 June 2014 (UTC)
For starters, just looking for CR/LF and turning it into <br/> should suffice --Hooray (talk) 21:30, 2 June 2014 (UTC)
Newlines are now <br/>, 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.
--Bigstones (talk) 20:52, 2 June 2014 (UTC)
The examples below (in essence this edit) look like there is one line break more than usual inserted. I would think that both <br/> tags and the new line between the </nowiki> and <nowiki> tags are treated as line breaks, though I am not 100% sure.
Johan G (Talk | contribs) 04:53, 3 June 2014 (UTC)
I think that's due to the fact that we "fake" paragraph separation with two newlines, instead of the proper <p></p> tag. Possibly it's not that hard... even a regex could probably do: /([^\n]+)/<p><nowiki>$1<\/nowiki><\/p>\n/s
(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?)
--Bigstones (talk) 12:30, 3 June 2014 (UTC)
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 :-) --Hooray (talk) 12:49, 3 June 2014 (UTC)

retained formatting Done Done

I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?
--Bigstones (talk) 19:53, 2 June 2014 (UTC)
I don't think we need to copy the HTML content[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 [2][3][4], e.g. <a href=""></a> - 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 <ul> <li>...</li> </ul>. 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 {{#ev:youtube|VIDEO_ID}} 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--Hooray (talk) 20:18, 2 June 2014 (UTC)
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 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.
Not much else to say. Have fun :)
EDIT: I also removed the nowiki escaping from text. Possibly that should be configurable too.
--Bigstones (talk) 17:16, 8 June 2014 (UTC)
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[5]. Thanks again for your work on this !--Hooray (talk) 17:43, 8 June 2014 (UTC)
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.
--Bigstones (talk) 22:26, 11 June 2014 (UTC)
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[6] so that scripts can auto-update --Hooray (talk) 22:51, 11 June 2014 (UTC)

selection processing Done Done

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 --Hooray (talk) 10:55, 3 June 2014 (UTC)

Two+1 observations on 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.
--Bigstones (talk) 12:51, 3 June 2014 (UTC)
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! --Hooray (talk) 13:05, 3 June 2014 (UTC)
work in progress... towards 0.8
--Bigstones (talk) 20:58, 5 June 2014 (UTC)
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).
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 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?
--Bigstones (talk) 23:25, 5 June 2014 (UTC)
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 ! --Hooray (talk) 23:51, 5 June 2014 (UTC)

HTML handling and Escaping Done Done

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.--Hooray (talk) 17:11, 12 June 2014 (UTC)

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.)
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.
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.
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.
--Bigstones (talk) 17:49, 12 June 2014 (UTC)
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 # character or URL-encoding could be contributing to this --Hooray (talk) 17:56, 12 June 2014 (UTC)
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 [7] and [8] --Hooray (talk) 18:01, 12 June 2014 (UTC)
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.)
--Bigstones (talk) 19:55, 12 June 2014 (UTC)
Working on this... will commit something before going to bed. --Bigstones (talk) 20:55, 13 June 2014 (UTC)
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. --Bigstones (talk) 22:02, 13 June 2014 (UTC)

example

Cquote1.png 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.

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.

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.

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.
Cquote2.png
Cquote1.png 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.

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.
Cquote2.png
Cquote1.png 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..
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.
— henrysean84 (Mon Aug 05). ILS-Problem on Airbus A330-223.
Cquote2.png

testing CR/LF conversion

Cquote1.png 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.

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.

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.

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.
— hvengel (Thu May 29). Re: Aircraft Rating System.
Cquote2.png
Cquote1.png Could you perhaps give a few examples - I don't really have much FG time at the moment to look into this...

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.

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.

— Renk Thorsten (2014-06-01). Re: [Flightgear-devel] Unused textures?.
Cquote2.png
Cquote1.png What a muddle...

There's a whole bunch of different cases in there.

1) Duplicate 'winter'-textures:

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.

2) dds-converted unused textures:

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.

3) Unused unique png textures:

As argued previously, these we should store, possibly in 'unused'.

4) Unique dds textures:

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.
— Renk Thorsten (2014-06-02). Re: [Flightgear-devel] Unused textures?.
Cquote2.png

Automatic update of script and old quotes

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[9] so that scripts can auto-update --Hooray (talk) 22:51, 11 June 2014 (UTC)

selection/clipboard buffer or alert() limits ?

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. --Hooray (talk) 14:11, 12 June 2014 (UTC)

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 security issue.
--Bigstones (talk) 22:02, 13 June 2014 (UTC)
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.--Hooray (talk) 23:16, 13 June 2014 (UTC)

Testing 0.9

Cquote1.png 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/tutori ... -range.htm
Cquote2.png

Testing 0.10

Cquote1.png 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.

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.

For more info, I suggest to check out:

http://wiki.flightgear.org/MapStructure ... map_dialog
MapStructureDialog.png

You can basically create arbitrary layers, even for custom objects/positions:
Map-canvas-chain-home-editor.png

The same method can be used for creating a "live" radar display:
http://wiki.flightgear.org/Canvas_Radar
MapStructure-TFC-Troubleshooting.png

But maps and layers can be fairly sophisticated, too - all 100% scripted:
http://wiki.flightgear.org/FlightGear_N ... Map_dialog
Map-canvas-dialog-storms-overlay.png

As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments

Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure article.
— Hooray (Sat Jun 14). Re: Get objects to show up on Map/Radar.
(powered by Instant-Cquotes)
Cquote2.png

Issues

phpBB code snippets not displayed using syntaxhighlight

Cquote1.png What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:
<periodic>
     <min>-180</min>
     <max>180</max>
</periodic>

will transform a value of -190 to +170 for example. But that's probably not what you asked for.


Cquote2.png

recognizing wiki images

I just tested the script using one of my recent forum postings:

Cquote1.png
RevHardt wrote in http://wiki.flightgear.org/MapStructure ... map_dialog
(see the linked image)

You can basically create arbitrary layers, even for custom objects/positions:
(see the linked image)

The same method can be used for creating a "live" radar display:
http://wiki.flightgear.org/Canvas_Radar
(see the linked image)

But maps and layers can be fairly sophisticated, too - all 100% scripted:
http://wiki.flightgear.org/FlightGear_N ... Map_dialog
(see the linked image)

As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments

Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure
— Hooray (Sat Jun 14). Re: Get objects to show up on Map/Radar.
Cquote2.png

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 --Hooray (talk) 16:45, 14 June 2014 (UTC)

Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <cite>RevHardt... part.)
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.
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.
(Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)
--Bigstones (talk) 17:37, 14 June 2014 (UTC)
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.
--Bigstones (talk) 21:35, 14 June 2014 (UTC)
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...
--Bigstones (talk) 21:51, 14 June 2014 (UTC)