FlightGear wiki - User contributions [en]

FlightGear wiki:Village pump

2016-08-23T11:26:00Z

Tipunch: /* new portal for cockpit building (hardware) ? */

{{Archives|[[/Archive 2012|2012]]|[[/Archive 2013|2013]]|[[/Archive 2014|2014]]|[[/Archive 2015|2015]]}}
{{shortcut|FGW:VP}}
Welcome to the '''Village Pump'''. This page is used to discuss the technical issues, operations and guidelines of the [[FlightGear wiki]].

Please <span class="plainlinks">[{{fullurl:{{FULLPAGENAME}}|action=edit&section=new}} add new topics]</span> to the '''bottom''' of this page.

Old discussion should be moved to a [[FlightGear wiki:Village pump/Archive YEAR]]. These discussions can then be moved to a relevant talk page if appropriate.

== Welcome template? ==
I have been thinking about suggesting a welcome template, for example named {{obr}}welcome{{cbr}}, to place on top of (at least) new users user discussion pages.

It should welcome the (new) user

In addition, it should probably mention and/or link to pages mentioning:
* The introduction page/tutorial (Hmm, I do not think I did finish that one. See [[Help talk:Tutorial]] ([http://wiki.flightgear.org/index.php?title=Help_talk:Tutorial&oldid=70843 perm])).
* Help pages
* How to use categories (in particular not like #tags, ;-) but also that image and article categories should be separate, but link to each other)
* The portals
* The style manual
* Discussion pages and where to discuss what:
** How to use discussion pages
** The wiki in general: The village pump (this page)
** Wiki articles: Article discussion pages
** Wiki user actions: User discussion pages

Maybe it should also mention that FGAddon aircraft, effects, other features etc. (except for their articles) and their bugs should be discussed on the forum, unless developers say otherwise, and that core features should be discussed on the developer mailing list and core bugs on the bug tracker.

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 20:31, 30 January 2016 (EST)

: I think this is a great idea. A nice concise summary with links to help a new user navigate the FlightGear jungle would be a great addition. It should however remain very short with simple sentences - while being complete - as many users are not native speakers. So maybe there should be translations of the template with manually added links at the bottom for easy access to all the translations?

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 03:35, 12 February 2016 (EST)

:: Regarding an introduction article, I have come to the conclusion that a complete but long article is probably not as helpful as short but specific help pages. In essence the latter would be easier to navigate and absorb. I have therefore started to slowly split up some of the help pages and have added one more section to [[Help:Contents]].
:: I think that a welcome phrase, a link to that page and the [[FlightGear wiki:Manual of Style|style manual]] might actually suffice for a welcome template for now. It is at least better than what we currently have (i.e. more or less nothing).
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 14:47, 4 March 2016 (EST)

:: I now consider
::* A Welcome message
::* A link to this page
::* A link to the help pages
::* A link to the manual of style
::* Some final welcoming words

:: A welcome template should probably also very briefly mention a pet peeve of mine: the categories.
:: Many (if not most) image uploaders seem to treat them like tags, but if say all screenshots of aircraft (probably >2000) would end up at [[:Category:Aircraft]] (instead of under a subcategory to [[:Category:Screenshots of aircraft]]), of what use would that page be when looking for a specific one? If people would like to be able to search for an aircraft, a concise but comprehensive image description is very hard to beat.
:: How do I convey all that in a way that is, short, to the point and easy to absorb (and act by)? And where is the best place?
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 02:46, 8 March 2016 (EST)

:: An early draft is now at [[User:Johan G/Template:Welcome to the wiki]]
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 02:52, 18 April 2016 (EDT)

::: Some comments on the draft:
::: * I'm not fully sure about using a prominent box - I think it stands out a bit too much. Wikipedia {{wikipedia|Template:Welcome|uses a simple thread on the Talk page}}; as an alternative, we could use lighter colors.
::: * I've also expanded the text a bit. My proposal would be (I've put it in a box, but I'm for the "thread" solution):
<div style="background: #fff; border: 1px #585858 solid; padding: 12px; margin: 12px">
[[Image:Example.png|left]] '''Welcome to the FlightGear wiki, {{#if: {{{name|}}} | {{{name}}} | {{BASEPAGENAME}}}}'''! We hope you will enjoy your stay!

See [[Help:Contents#Reading|Reading]] to learn how wikis work. You can also [[Special:CategoryTree/Root category|browse the existing page categories]].

Should you wish to create or edit some articles, ''do so''! Here are some resources to get you started:
* [[Help:Contents#Editing|How to edit pages]]
* [[Help:Discussion pages|Discussion pages]], where we discuss and agree on potential improvements
* [[FlightGear wiki:Manual of Style|The Manual of Style]], a set of guidelines to help editors maintain a consistent style and formatting (please follow them)
* [[Help:Contents|Wiki help page]]

If you have any questions, just start a topic on the [[FlightGear wiki:Village pump|''Discuss!'' page]]. Again, welcome!
</div>
::: ...where the image on the left is an appropriately chosen icon.
::: Finally, we could use the {{mediawiki|Extension:NewUserMessage|NewUserMessage extension}} to have the wiki software automatically post the message to the new user's talk page.
::: ---- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 17:30, 1 May 2016 (EDT)

== Permanently removing spam bots ==
For permanently removing spam bots, has the [https://www.mediawiki.org/wiki/Extension:UserMerge UserMerge] Mediawiki extension been considered? I use that regularly on [http://wiki.nmr-relax.com my own wiki], though there we have also reverted to communicating to the person via email before manually granting access (probably not an option here), as all of the Mediawiki captcha methods were recently cracked.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 03:15, 12 February 2016 (EST)

: Oh, for the extension, we simply have a user called 'Spam bot' in a blocked state, and merge the spam bot accounts into this one, deleting the old account.
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 03:20, 12 February 2016 (EST)

:: I'd use the [https://www.mediawiki.org/wiki/Extension:AbuseFilter abuse filter extension] instead (much more powerful and automated) - other users have also proposed different remedies, see [http://forum.flightgear.org/viewtopic.php?f=42&t=28734 this forum thread]. Anyway, Gijs is going to upgrade MediaWiki shortly and review the current anti-spam measures.
:: -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 06:26, 13 February 2016 (EST)

::: A lot of the spam bots are using their name as advertising nowadays, so the [https://www.mediawiki.org/wiki/Extension:UserMerge UserMerge] extension is the only one I know which will allow a user and associated name to be permanently deleted.

::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 12:04, 14 February 2016 (EST)

:::: The problem now is that they're also adding the information to the page title, so that it will still show up in the deletion logs [http://wiki.flightgear.org/Special:Log/delete] in other words, there's still some SEO juice associated with deleted entries ... Another idea would be to allow admins to temporarily disable wiki registrations/article creation, e.g. if more than 2 admins agree, this could be done to protect the wiki from spam attacks.

::::: Hooray, you should sign your posts ;) The bots don't target the deletion logs, as that's a little pointless. It's a Special:* page, and the default Mediawiki robots.txt file tells all search engines to not index these pages. User pages, page histories, etc. are however normally indexed.

::::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 14:36, 19 February 2016 (EST)

:: The point was not what the bots are targeting, but what shows up in the logs - i.e. SEO-wise - Gijs' article blacklist stuff should help with that hopefully. PS: I could not find the signature button on the mobile device I am using, and I am not too good at remembering the correct number of tildes ;-) [[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:04, 19 February 2016 (EST)

== WIP vs. Under construction ==
I have been beginning to miss the under construction template[http://wiki.flightgear.org/index.php?title=Template:Under_Construction&direction=prev&oldid=46229] more and more (though I could it definitively could be improved).

I have begun to appreciate the need to differentiate between letting readers that a page is to be considered a yet to be finished construction site (though we in a way have that through the {{tl|incomplete}} template) and letting the reader (and other editors) that a page will receive a large amount of work for some hours or even days, usually the use for {{tl|WIP}}.

In summary i miss templates giving a clear distinction between conditions akin to "Under construction" and "Caution - Wet floors", rather than "being worked on" and "could need more work".

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 10:11, 17 February 2016 (EST)

== [[Fr/Pilote automatique]] ==
Bonjour,

Je viens de créer la page de traduction en français de l'article original en anglais [[Autopilot]]. Vu mes faibles compétences en matière de pilotage, vu que je n'ai pas sur ma version téléchargée d'avion avec un pilote automatique, la traduction doit souffrir quelques approximations, si ce n'est des contresens plus ennuyeux. Si quelques bonnes âmes plus qualifiées pouvaient me faire la grâce d'une relecture... merci d'avance.

Cordialement, et Hop ! --[[User:F-WTSS|F-WTSS]] ([[User talk:F-WTSS|talk]]) 15:30, 18 February 2016 (EST)

== MediaWiki updated to 1.26.2 ==
I've updated MediaWiki to the latest stable release (1.26.2) today. I've still got to update some of the extensions, so there may be regressions for now. Please report bugs if you find any. For a list of changes, see https://www.mediawiki.org/wiki/Release_notes/1.26

[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:47, 19 February 2016 (EST)

: Cheers! I was hoping that it would solve the uneditable Chinese, Russian, and other non-latin character-based pages (Polish strangely as well), but unfortunately [[FlightGear_wiki:Village_pump/Archive_2015#UTF-8_language_pages_cannot_be_edited|that issue remains]].

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 10:54, 19 February 2016 (EST)

:: Hm, looks that will require quite some attention indeed. I'm afraid that'll has to wait for now.
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 12:29, 19 February 2016 (EST)

=== Nasal Syntaxhighlighting ===
: Thanks for your efforts, btw: Nasal syntax highlighting is gone again.
: {{unsigned|17:22, 19 February 2016‎|Hooray}}

:: Unfortunately this time it isn't me forgetting to copy a file. The SyntaxHighlight extension no longer uses GeSHi, but has switched to Pygments. This means our Nasal mapping no longer works and has to be re-written. If anyone is interested, be my guest. See http://pygments.org/docs/lexerdevelopment/
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 12:29, 19 February 2016 (EST)

::: Hi Gijs,
::: I'm interested in making a Pygments Nasal lexer, but unfortunately I won't be able to work on it until the end of March at the earliest.
::: [[User:Red_Leader|<span style="color:red">'''''Red Leader'''''</span>]] ([[User_talk:Red_Leader|Talk]], [[Special:Contributions/Red_Leader|contribs]]) 16:59, 23 February 2016 (EST)

:::: Unless Gijs is facing any problems, I don't think it's necessarily needed, see my comment/suggestion in this revision: [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Village_pump&oldid=93166] [[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:20, 23 February 2016 (EST)

:::Hi Gijs,
:::Here's the code for a Nasal lexer. Be warned, it's thoroughly untested, but has the following features:
:::* Full support for all three string types (backtick, single quote, and double quote), including escapes and formatting strings (e.g., for {{func link|sprintf}}).
:::* All kinds of numbers, including numbers in scientific notation and octal and hex numbers.
:::* All global functions and variables as of FG v2016.1.1.
:::* Some of the commonly-used <code>props.Node</code> methods.
:::* All the other things that can be expected (keywords, punctuation, etc.).
:::I have also created a lexer based on the XML lexer for XML with embedded Nasal, which I thought would be useful.
:::Regards,
:::[[User:Red_Leader|<span style="color:red">'''''Red Leader'''''</span>]] ([[User_talk:Red_Leader|Talk]], [[Special:Contributions/Red_Leader|contribs]]) 16:35, 2 April 2016 (EDT)

:::http://pygments.org/docs/lexerdevelopment/#adding-and-testing-a-new-lexer
:::<syntaxhighlight lang="python" enclose="div">
# -*- coding: utf-8 -*-
"""
Lexer for Nasal.
"""

from pygments.lexer import RegexLexer, words, include, inherit, bygroups, using
from pygments.token import Text, Keyword, Name, String, Number, Operator, Punctuation, Comment
from pygments.lexers.html import XmlLexer

__all__ = ['NasalLexer', 'XMLNasalLexer']

class NasalLexer(RegexLexer):

name = 'Nasal'
aliases = ['nasal']
filenames = ['*.nas']

tokens = {
'formatters': [
(r'%[-#0 +]*(?:[0-9]+)?(?:\.[0-9]+)?[dis%couxXeEfFgG]', String.Interpol),
],
'backtick': [
(r'`', String.Backtick, '#pop'),
(r'[^`\\]+', String.Backtick),
(r'\\n|\\r|\\t|\\`|\\\\|\\x[0-9a-fA-F]{2}', String.Escape),
],
'sqstring': [
(r"'", String.Single, '#pop'),
(r"[^'\\%]+", String.Single),
(r"\\'", String.Escape),
include('formatters'),
],
'dqstring': [
(r'"', String.Double, '#pop'),
(r'[^"\\%]+', String.Double),
(r'\\n|\\r|\\t|\\"|\\\\|\\x[0-9a-fA-F]{2}', String.Escape),
include('formatters'),
],
'root': [
(r'\s+', Text),
(r'#.*?$'m, Comment.Single),
(r':|\?|[!=<>+\-*\/~&|^]=?', Operator),
(words(('or', 'and'), suffix=r'\b'), Operator.Word),
(r'[{(\[})\]\.;,]', Punctuation),
(words(('for', 'foreach', 'forindex', 'while', 'break', 'return', 'continue', 'if', 'else', 'elsif'), suffix=r'\b'), Keyword),
(words(('var', 'func'), suffix=r'\b'), Keyword.Declaration),
(words(('nil'), suffix=r'\b'), Keyword.Constant),
(words(('me', 'arg'), suffix=r'\b'), Name.Builtin.Pseudo),
(words(('new', 'del', 'getNode', 'getParent', 'getChild', 'getChildren', 'removeChild', 'removeChildren', 'removeAllChildren', 'getName', 'getIndex', 'getType', 'getAttribute', 'setAttribute', 'getValue', 'setValue', 'setIntValue', 'setBoolValue', 'setDoubleValue', 'unalias', 'alias', 'getPath', 'getBoolValue', 'remove', 'setValues', 'getValues', 'initNode'), suffix=r'\b'), Keyword.Pseudo),
(r'0o[0-7]+', Number.Oct),
(r'0x[0-9a-fA-F]+', Number.Hex),
(r'\d*(?:\.\d*)?[eE][+-]?\d+', Number.Float),
(r'\d*\.\d*', Number.Float),
(r'\b[0-9]+\b', Number.Integer),
(words(('D2R', 'R2D', 'FT2M', 'M2FT', 'IN2M', 'M2IN', 'NM2M', 'M2NM', 'KT2MPS', 'MPS2KT', 'FPS2KT', 'KT2FPS', 'LB2KG', 'KG2LB', 'GAL2L', 'L2GAL'), suffix=r'\b'), Name.Variable.Global),
(words(('abort', 'abs', 'addcommand', 'airportinfo', 'airwaysRoute', 'assert', 'carttogeod', 'cmdarg', 'courseAndDistance', 'createViaTo', 'createDiscontinuity', 'createWP', 'createWPFrom', 'defined', 'directory', 'fgcommand', 'findAirportsByICAO', 'findAirportsWithinRange', 'findFixesByID', 'findNavaidByFrequency', 'findNavaidsByFrequency', 'findNavaidsByID', 'findNavaidsWithinRange', 'finddata', 'flightplan', 'geodinfo', 'geodtocart', 'getprop', 'greatCircleMove', 'interpolate', 'isa', 'logprint', 'magvar', 'maketimer', 'md5', 'navinfo', 'parse_markdown', 'parsexml', 'print', 'printf', 'printlog', 'rand', 'registerFlightPlanDelegate', 'removecommand', 'removelistener', 'resolvepath', 'setlistener', 'setprop', 'settimer', 'srand', 'systime', 'thisfunc', 'tileIndex', 'tilePath', 'values'), suffix=r'\b'), Name.Builtin),
(words(('append', 'bind', 'call', 'caller', 'chr', 'closure', 'cmp', 'compile', 'contains', 'delete', 'die', 'find', 'ghosttype', 'id', 'int', 'keys', 'left', 'num', 'pop', 'right', 'setsize', 'size', 'sort', 'split', 'sprintf', 'streq', 'substr', 'subvec', 'typeof'), suffix=r'\b'), Name.Builtin),
(words(('_createCondition', '_fgcommand', '_interpolate', '_setlistener'), suffix=r'\b'), Keyword.Reserved),
(r'`', String.Backtick, 'backtick'),
(r"'", String.Single, 'sqstring'),
(r'"', String.Double 'dqstring'),
(r'\b_\w*?\b', Keyword.Reserved),
#(r'\b\w*?\b', Name),
]
}

class XMLNasalLexer(XmlLexer):
"""
For Nasal code embedded in XML files.
"""

name = 'XML-Nasal'
aliases = ['xml-nasal', 'xml-ns']

tokens = {
'root': [
(r'(<(?:load|unload|script)>)(<!\[CDATA\[)?(.*?)(]]>)?(</(?:load|unload|script)>)', bygroups(Name.Tag, Comment.Preproc, using(NasalLexer), Comment.Preproc, Name.Tag),
inherit,
],
}
</syntaxhighlight>

:: We can use the ECMAScript/JavaScript lexer[http://pygments.org/docs/lexers/#lexers-for-javascript-and-related-languages] for now, my suggestion would be to copy that over to a file so that we can work on a custom Nasal lexer (Syntax is almost identical, with a few different keywords, and many others being irrelevant). What is missing/different can be obtained from other lexers that are similar, e.g. [http://pygments.org/docs/lexers/#lexers-for-other-c-like-languages] [[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:45, 19 February 2016 (EST)

:: Okay, here's the better/quick&easy way: We have Nasal support for some fairly popular editors, like [http://wiki.flightgear.org/Howto:Syntax_highlighting_for_Nasal#Vim|vim](originally created by Melchior<ref>https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/scripts/syntax/nasal.vim</ref>), listed at [[Howto:Syntax_highlighting_for_Nasal]] - there are various free converters available that will read such a syntaxhighlighting file and convert it to a pygments class, e.g. see: https://github.com/honza/vim2pygments [[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:00, 19 February 2016 (EST)

==== References ====
<references />

== The repository link templates ==
=== Complete overhaul of the repository link templates ===

I have now performed a complete overhaul of the repository link templates (see {{tl|repo link/doc related}}). This was motivated by the incomplete state of these templates, the lack of standardisation, the lack of SourceForge git repository support for {{tl|repo link}}, web-interface only support, etc. I have used a lot of recursive transclusion for standardisation, so that there is a single point for updating for any FlightGear infrastructure changes. This is the master {{tl|repo link}} template. All the other templates are subtemplates which recursively transclude from this master template. I have also created a number of documentation templates for simplifying template maintenance (see {{tl|repo link/doc related‎}}, {{tl|repo link/doc specific file git‎‎}}, {{tl|repo link/doc git clone‎‎}}, and {{tl|repo link/doc commit}}). The changes were constrained to maintain backwards compatibility as much as possible. However I would like to break this to allow the following templates to be updated to transclude from the master {{tl|repo link}} template:

* {{tl|flightgear file}},
* {{tl|simgear file}},
* {{tl|fgdata file}},
* {{tl|fgaddon file}}.

If no one objects, I would like to completely break these and expand and rename the parameter set to match the other <nowiki>{{* file}}</nowiki> repository templates (e.g. {{tl|terragear file}}). My overhaul currently does not include Hooray's ideas for non command line usages, i.e. different GUIs, but it enables it to be easily added via the master template and the addition of a single parameter to any subtemplates.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 15:05, 25 February 2016 (EST)

: I don't have any objections myself, I appreciate all the work you are putting into this, and would like to thank you for helping us clean up all that mess by doing such unglamorous work ;-) I also appreciate that your changes would facilitate adding a non-CLI mode to the corresponding templates. However, I would suggest to wait for Gijs' feedback, because he's ultimately the most likely person to veto something around here ;-) [[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:31, 25 February 2016 (EST)

:: Johan seems to be the one who did a lot of the initial work on these <nowiki>{{* file}}</nowiki> templates, and Red Leader with the {{tl|repo link}} template. And they were involved in the general discussions ([[http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Village_pump&oldid=87148#Repository_link_templates perm]). But I know Gijs was also involved in the design.

:: For the non-CLI mode, that will need -a lot- more planning. For example a definitive list of all these modes would be useful. Should this use an optional Mediawiki pop up extension showing a link to a general page that describes the action for all different GUIs, CLI, etc.? Should we have a switch box so that the reader can switch in-text between CLI, and the numerous GUIs? Are we going to have a large set of screenshots for each GUI? If so, I would strongly recommend the [https://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion labelled section transclusion extension] for creating a single page for one GUI with everything for that GUI, as a tutorial. Here is [http://wiki.nmr-relax.com/Relax_4.0.1 an external example where I have used this], to fragment the base release page to create [http://wiki.nmr-relax.com/Relax_release_descriptions this meta page], as well as many other meta pages.

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 03:14, 26 February 2016 (EST)

I am also thinking of changing the name of the <nowiki>{{* file}}</nowiki> templates, as I hope to make the scope of the templates far more general. The name <nowiki>{{* source}}</nowiki> or <nowiki>{{* repo}}</nowiki> might be better. For example these will allow the repository commit, tree view, log view (and maybe rss feed), with or without a file/directory path. And I would like to generalise this to handle both the SF web-interface and non-web net protocols (git://, ssh://, svn://, etc.). It will allow for CLI instructions to be built up and embedded in <nowiki>{{#tag:source|<content>|lang=sh}}</nowiki> tags. And I will defer all infrastructure decisions in the subtemplates to the single point of {{tl|project infrastructure}}, so that if there are changes in the future, then only this single template needs to be updated to update the entire wiki.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 03:22, 26 February 2016 (EST)

: The {{tl|project infrastructure}} template as a single point provider of various project infrastructure names and URL pairs seem like a great idea. If it work out well it will really lessen the maintenance by having less places needing updates, while allowing the various repository templates to be simple to use, in essence by having comprehensible names and no boiler plate parameters for their users.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:15, 27 February 2016 (EST)

==== Repository link update ====
For those following, I have massively expanded the capabilities of the {{tl|repo link}} template:
* The SourceForge URLs are now comprehensive.
* Full support for the new query-based URLs for the Gitorious archives.
* Functional GitLab URLs.
* Generic repository support (used to create the {{tl|openscenegraph co}} template).
* Detailed documentation and extensive examples for checking the implementation (if you find any non-supported links, please add these as examples).
* Isolation of the '''cmd''' parameter from the CLI options — this is to enable future support for non-CLI instructions based on the value of '''cmd'''.

I have also completed a large set of subtemplates of {{tl|repo link}}, see the list at {{tl|repo link/doc related}}. This includes a full set of <nowiki>{{* source}}</nowiki> templates. I have left the original <nowiki>{{* file}}</nowiki> templates, rather than renaming and modifying them, so these are now redundant. All of the <nowiki>{{* source}}</nowiki>, <nowiki>{{* commit}}</nowiki>, <nowiki>{{* clone}}</nowiki>, and <nowiki>{{* co}}</nowiki> templates transclude from the master {{tl|repo link}} template to do all of the work.

One important template is {{tl|gitorious source}}. The support for the new query-based URLs for the Gitorious archives is now quite comprehensive in {{tl|repo link}}. Therefore I have converted almost every single FlightGear wiki link to https://gitorious.org to use {{tl|gitorious source}} instead. This fixes a lot of broken links and broken git instructions. I have reduced the number of hits for gitorious.org on the wiki (searching just for "gitorious") to 22 hits. This includes 2 very outdated articles ([[FlightGear Git: aircraft authors]], [[Fr/FlightGear et Git]]), 15 locked newsletters, 1 with no longer existent Gitorious merge request links, and 4 base URL links for Hangars. This way we can maintain the Gitorious web interface links and git command instructions in a functional state by simply updating the single source of {{tl|repo link}}.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 11:38, 29 February 2016 (EST)

: I just remembered [[Special:LinkSearch]], so make that 184 broken gitorious.org links remaining. Lots more work to do :)

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 14:46, 29 February 2016 (EST)

For some of these templates, e.g. {{tl|repo link/doc usage}}, I'm trying to implement some logic for automatic whitespace padding for documentation formatting, but the <code><nowiki>{{#len:string}}</nowiki></code> function is not enabled. According to {{mediawiki|Wikitext_parser/Core_parser_functions#.23len}} and {{mediawiki|Extension:StringFunctions}}, the option <code>$wgPFEnableStringFunctions = true;</code> should be set (in <code>LocalSettings.php</code>). Unless there is a reason for not using this, I was wondering if someone could enable this? Cheers!

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 09:53, 8 March 2016 (EST)

=== Archived newsletters and dead links? ===

Do we have a policy for the dead links in the FlightGear newsletters? It is obviously good to preserve the historic state. But there are many Gitorious links that could be made functional again using the {{tl|gitorious source}} template to point to the historic Gitorious archives (including the official FlightGear repositories, rather than using {{tl|fgdata source}}, for example). The https://gitorious.org links have been converted from URL/path based to query based, so absolutely all of the old links are broken. I am steadily converting all Gitorious links to use the [[Template:repo link/doc related|{{obr}}repo link{{cbr}} family of templates]], with the exception of the newsletters.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 04:52, 8 March 2016 (EST)

: I think it could be a good idea to try update old links in those newsletters. I sometimes look back at things and tend to think that I probably are not the only one doing that.
: I wonder if the rotten links should be replaced or stricken, but I think they could just as well be replaced. The key thing is that they go to the same resource or content, not weather they have been updated or not (also, the change will be visible in the revision history after all).
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 07:11, 8 March 2016 (EST)

:: I should add that I'm using [http://wiki.flightgear.org/index.php?title=Special:LinkSearch&limit=500&offset=0&target=http%3A%2F%2Fgitorious.org <nowiki>Special:LinkSearch for http://gitorious.org</nowiki>] and [http://wiki.flightgear.org/index.php?title=Special:LinkSearch&limit=500&offset=0&target=https%3A%2F%2Fgitorious.org <nowiki>Special:LinkSearch for https://gitorious.org</nowiki>]. And I am also not touching the <code>User*</code> pages, <code>*talk*</code> pages, or pages tagged as out of date or up for deletion. For the newsletters I might look at these later when the broken Gitorious links are fixed in the rest of the wiki but, as these are locked, someone else might have make the switch to {{tl|gitorious source}}, {{tl|gitorious url}}, {{tl|gitorious clone}}, and {{tl|gitorious merge request}}.

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 02:53, 9 March 2016 (EST)

::: I will temporarily add a table here for the templates in the newsletters and will slowly fix them one by one together with any other admin.
{{navbox
| title = Click "show" to show -->
| state = collapsed
| navbar = plain
| list1 =
http:...
{{{!}} class="wikitable"
! Fixed !! Newsletter !! Gitorious URL !! Notes
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter May 2010]]
{{!}} http://gitorious.org/fg
{{!}} No equivalent link for the Gitorious archive - project pages are dead. Maybe just use http://gitorious.org/?
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter May 2010]]
{{!}} http://gitorious.org/fg
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter September 2010]]
{{!}} http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51
{{!}} Functional link, equivalent to {{gitorious url|fg|flightgear|commit=5c6fe952598053fa63631fc0161d666f22a50f51}}.
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter September 2010]]
{{!}} http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter January 2011]]
{{!}} http://gitorious.org/jsbsim/jsbsim
{{!}} Functional link. Switched to {{gitorious url|jsbsim|jsbsim}} to future-protect the link.
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter January 2011]]
{{!}} http://gitorious.org/jsbsim/jsbsim
{{!}} Functional link. Switched to {{gitorious url|jsbsim|jsbsim}} to future-protect the link.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter February 2011]]
{{!}} http://gitorious.org/headtrack

http://gitorious.org/arduinocockpit
{{!}} Project pages are dead, switched to {{gitorious url|headtrack|headtrack}}

{{gitorious url|arduinocockpit|arduinocockpit}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter February 2011]]
{{!}} http://gitorious.org/arduinocockpi

http://gitorious.org/headtrack
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter March 2011]]
{{!}} http://gitorious.org/lockheed-l10-electra
{{!}} Missing project - i.e. {{gitlab source|user=emilianh|repo=Lockheed-L10-Electra|text=migrated to GitLab}}. Switched to {{gitlab source|user=emilianh|repo=Lockheed-L10-Electra}}.
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter March 2011]]
{{!}} http://gitorious.org/lockheed-l10-electra
{{!}} Switched to {{gitlab source|user=emilianh|repo=Lockheed-L10-Electra}}.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter November 2011]]
{{!}} http://gitorious.org/flightgear-aircraft
{{!}} Switched to {{gitorious source}} and rephrased text slightly to help readers find the repositories.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter October 2012]]
{{!}} http://gitorious.org/anders-hangar/mtb_20m/trees/master
{{!}} Switch to {{gitorious url|proj=anders-hangar|repo=mtb_20m}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter March 2013]]
{{!}} http://gitorious.org/fg/flightgear/blobs/next/scripts/java/FGClient/src/FGFSDemo.java
{{!}} Switched to {{gitorious url|proj=fg|repo=flightgear|path=scripts/java/FGClient/src/FGFSDemo.java}}. This points to the old Gitorious repository to protect against path changes in the future.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter September 2013]]
{{!}} http://gitorious.org/boeing/707
{{!}} Switched to {{gitorious source|proj=boeing|repo=707}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter September 2013]]
{{!}} http://gitorious.org/boeing/707
{{!}} Switched to {{gitorious source|proj=boeing|repo=707}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter November 2013]]
{{!}} http://gitorious.org/fg/fgrun
{{!}} Switch to {{gitorious url|proj=fg|repo=fgrun}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter November 2013]]
{{!}} http://gitorious.org/fg/fgrun
{{!}} Switch to {{gitorious url|proj=fg|repo=fgrun}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter July 2014]]
{{!}} http://gitorious.org/nasal-support/nasal-npp
{{!}} Switched to {{gitorious url|nasal-support|nasal-npp}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter April 2015]]
{{!}} http://gitorious.org
{{!}} Switched to {{tl|gitorious source}} without parameters for the Gitorious base URL, to future-protect it.
{{!}}}

https:...
{{{!}} class="wikitable"
! Fixed !! Newsletter !! Gitorious URL !! Notes
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter April 2011]]
{{!}} https://gitorious.org/papillon81/flightgear-custom-scenery/

https://gitorious.org/dvanmosselbeen/flightgear-custom-scenery
{{!}} Switched to {{gitorious source|dvanmosselbeen|flightgear-custom-scenery}} and {{gitorious source|papillon81|flightgear-custom-scenery}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter April 2011]]
{{!}} https://gitorious.org/dvanmosselbeen/flightgear-custom-scenery

https://gitorious.org/papillon81/flightgear-custom-scenery/
{{!}} Switched to {{gitorious source|dvanmosselbeen|flightgear-custom-scenery}} and {{gitorious source|papillon81|flightgear-custom-scenery}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter July 2011]]
{{!}} https://gitorious.org/dvanmosselbeen/flightgear-custom-scenery
{{!}} Switched to {{gitorious source|dvanmosselbeen|flightgear-custom-scenery}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter July 2011]]
{{!}} https://gitorious.org/dvanmosselbeen/flightgear-custom-scenery
{{!}} Switched to {{gitorious source|dvanmosselbeen|flightgear-custom-scenery}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter December 2011]]
{{!}} https://gitorious.org/dvanmosselbeen/flightgear-custom-scenery
{{!}} Switched to {{gitorious source|dvanmosselbeen|flightgear-custom-scenery}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Fr/Nouvelles du projet FlightGear - décembre 2011]]
{{!}} https://gitorious.org/dvanmosselbeen/flightgear-custom-scenery
{{!}} Switched to {{gitorious source|dvanmosselbeen|flightgear-custom-scenery}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter April 2012]]
{{!}} https://gitorious.org/fg/fgdata/blobs/master/Aircraft/Instruments-3d/garmin196/README

https://gitorious.org/fg/fgdata/blobs/master/Aircraft/Instruments-3d/garmin196/doc/doc-en.htm
{{!}} Switched to {{fgdata source|path=Aircraft/Instruments-3d/garmin196/README|full=1}} and {{fgdata source|path=Aircraft/Instruments-3d/garmin196/doc/doc-en.htm|full=1}} to point to the current FGData locations and removed the name "Gitorious" to make the text of the Garmin 196 GPS section still relevant
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter August 2012]]
{{!}} https://gitorious.org/mil-mi-6
{{!}} Switched to {{gitorious url|proj=mil-mi-6|repo=mi6dev}}, and changed from the non-existent project page to the main repository.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter October 2012]]
{{!}} https://gitorious.org/fgradar
{{!}} Switched from the project page to the direct repository {{gitorious url|fgradar|fgradar}}.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter March 2013]]
{{!}} https://gitorious.org/fg/flightgear/commit/913727239d6776c0508d206f395e16c265413ec3

https://gitorious.org/fg/flightgear/commit/eba03b5e469824ee8f1494723fcddbbc56155a08
{{!}} Switched to {{flightgear url|commit=913727239d6776c0508d206f395e16c265413ec3}} and {{flightgear url|commit=eba03b5e469824ee8f1494723fcddbbc56155a08}}. This deliberately points to the current repository.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter April 2013]]
{{!}} https://gitorious.org/fg-radi/osm2city

https://gitorious.org/scenery-france-850
{{!}} Switched to the new GitLab repository {{gitlab source|proj=fg-radi|repo=osm2city|full=1}}

and removed the no longer existent scenery-france-850 repository, replacing it with "<s>Scenery repository (Gitorious)</s>".
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter October 2013]]
{{!}} https://gitorious.org/fg/galvedros-fgdata
{{!}} Switch to {{gitorious url|proj=fg|repo=galvedros-fgdata}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter October 2013]]
{{!}} https://gitorious.org/fg/galvedros-fgdata
{{!}} Switch to {{gitorious url|proj=fg|repo=galvedros-fgdata}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter November 2013]]
{{!}} https://gitorious.org/ec130/
{{!}} Switched from the project page to the direct repository {{gitorious source|ec130|ec130}}.
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter November 2013]]
{{!}} https://gitorious.org/ec130/
{{!}} Switched from the project page to the direct repository {{gitorious source|ec130|ec130}}.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter February 2014]]
{{!}} https://gitorious.org/fg/philosophers-fgdata/source/022bef27f05d4837d720f63c6507b47466ff2a59:Nasal/console/repl.nas#L436

https://gitorious.org/fg/philosophers-fgdata/source/nasal-console:Nasal/console

https://gitorious.org/fg/fgdata/commit/eaaf816b772649d5b0826a1d0bdd166dbc5b968f

https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353

https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4

https://www.gitorious.org/fg/flightgear/merge_requests/26
{{!}} Switched to {{gitorious source|proj=fg|repo=philosophers-fgdata|branch=nasal-console|path=Nasal/console/repl.nas|line=708}}

{{gitorious url|proj=fg|repo=philosophers-fgdata|branch=nasal-console|path=Nasal/console|view=tree}}

{{fgdata-old url|commit=eaaf816b772649d5b0826a1d0bdd166dbc5b968f}}

{{flightgear commit|34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353}}

{{gitorious merge request|mr=54}}

{{gitorious merge request|mr=26}}
{{!-}}
{{!}} {{tick}}
{{!}} [[Es/FlightGear Newsletter February 2014]]
{{!}} https://gitorious.org/fg/philosophers-fgdata/source/022bef27f05d4837d720f63c6507b47466ff2a59:Nasal/console/repl.nas#L436

https://gitorious.org/fg/philosophers-fgdata/source/nasal-console:Nasal/console

https://gitorious.org/fg/fgdata/commit/eaaf816b772649d5b0826a1d0bdd166dbc5b968f

https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353

https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4

https://www.gitorious.org/fg/flightgear/merge_requests/26
{{!}} Changes match the English article.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter April 2014]]
{{!}} https://gitorious.org/fg/fgdata/flightgear?p=fg/fgdata:flightgear.git;a=blob;f=keyboard.xml

https://gitorious.org/fg/fgdata?p=fg:fgdata.git;a=commit;h=f8c56dcc52ffd3d6dfca1d39dc4a72b6b3478368

https://gitorious.org/fg/hoorays-flightgear?p=fg:hoorays-flightgear.git;a=shortlog;h=refs/heads/topics/cppbind-fgprotocol
{{!}} This first link was the broken {{tl|git link}} template (see the table below). The other two links are not in the article?!
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter June 2014]]
{{!}} https://gitorious.org/eddp-custom-scenery/eddp-custom-scenery/
{{!}} Switched to {{tl|gitorious clone}} to provide functional '''git clone''' instructions.
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter November 2014]]
{{!}} https://gitorious.org/fg/hoorays-fgdata/source/2857d8fc9fcfe2bb162a9eb9d3dcca4d41b3a876:Nasal/ai/aim9/aim9.fdm#L9
{{!}} Switch to {{gitorious url|proj=fg|repo=hoorays-fgdata|commit=2857d8fc9fcfe2bb162a9eb9d3dcca4d41b3a876|path=Nasal/ai/aim9/aim9.fdm|line=9}}
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter January 2015]]
{{!}} https://gitorious.org/fg/canvas-hackers-fgdata/source/f59c42134a5a77e343981dcff8278c3e2f094e87
{{!}} Switch to {{gitorious url|proj=fg|repo=canvas-hackers-fgdata|commit=f59c42134a5a77e343981dcff8278c3e2f094e87|view=summary}}
{{!}}}

Broken templates:...
{{{!}} class="wikitable"
! Fixed !! Newsletter !! Template !! Notes
{{!-}}
{{!}} {{tick}}
{{!}} [[FlightGear Newsletter April 2014]]
{{!}} {{tlx|Git link|gitorious|fg/fgdata|master|keyboard.xml|pre=$FG_ROOT/}}
{{!}} Switched to {{fgdata source|path=keyboard.xml|pre=$FG_ROOT}} to fix the Gitorious link created by the broken and depreciated {{tl|git link}} template.
{{!}}}

}}

::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 12:06, 9 March 2016 (EST)

:::: I've added a '''notes''' column to help a little.

:::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 12:30, 9 March 2016 (EST)

=== Elimination of the dead Gitorious links ===
Thanks largely to the diversity and flexibility of the [[:Category:Repository link templates|{{obr}}repo link{{cbr}} family of templates]], I have now managed to eliminate almost every last dead Gitorious link in the FlightGear wiki! The locked Newsletter articles, user pages, and talk pages are the only exceptions. The page counts from the (Main) namespace are:
* [http://wiki.flightgear.org/index.php?target=http%3A%2F%2Fgitorious.org&namespace=0&title=Special%3ALinkSearch <nowiki>Special:LinkSearch for http://gitorious.org</nowiki>] — 37. Of these, 17 are for the front page with the news of the Gitorious to SourceForge migration, and the rest are Newsletters.
* [http://wiki.flightgear.org/index.php?title=Special:LinkSearch&limit=500&offset=0&target=https%3A%2F%2Fgitorious.org&namespace=0 <nowiki>Special:LinkSearch for https://gitorious.org</nowiki>] — 166. Most of these links are valid and created by the {{obr}}gitorious *{{cbr}} subtemplates of {{tl|repo link}}. The remaining broken links are all in the locked Newsletters.
The Howto:* pages are not in the (Main) wiki namespace, but I've knocked those out too.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 13:54, 10 March 2016 (EST)

: thanks for doing all this unglamorous work - I am sorry that Gijs was apparently too busy to follow up on my suggestion to either provide you with admin access around here, or at least to help you run a Python script to do all this work in an automated, rather than manual, fashion. Hopefully, things will work out better next time. Again, thank you. Like I said, I think you should definitely be given admin access on the wiki, especially given your recent contributions - and I would gladly have my wiki status downgraded accordingly. In fact, if I was able to directly promote accounts accordingly, I would have done so months ago - however, it seems that Gijs is the only one to have those privileges, and he mentioned off-list that he's kinda busy with RL/exams etc, so it is to be expected that he's going to become a bottleneck more often - hopefully, this will be recongized as an actual issue, so that there will be more people able to promote new wiki admins. Sorry that things didn't work out better this time, and thanks so much for doing all this stuff manually. -[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:49, 10 March 2016 (EST)

:: No problems! As for automating this, that would not have been possible. If you look at the changes, you'll see that each one is different <sup>[http://wiki.flightgear.org/index.php?title=Special:RecentChanges&to=20160310210655&limit=500]</sup>. I had to check each one, and update the link as required.

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 16:08, 10 March 2016 (EST)

::: There's three of us actually (Curt, Simon and myself), no need to wait on me. See http://wiki.flightgear.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=100 (Sek is inactive nowadays) ;-)
::: Please note that forum pms are really not the best way to contact me. I very much prefer email over forum pms as it's a lot easier to filter out the huge amounts of nonsense I'm receiving from stuff requiring actual attention.
::: Anyhow I've just promoted Bugman so he can edit locked articles.
::: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 05:06, 11 March 2016 (EST)

:::: Thank you. I'll try to preserve the original intent of the Newsletters while fixing the broken links (maybe even preserving any original URLs as Mediawiki link text, while pointing to the new URL). I will use the {{obr}}gitorious *{{cbr}} templates to point to the historical sources, and will probably use this for all of the Gitorious URLs so that we have full control over any future URL breakages via the single location of {{tl|repo link}}. For example, if they change the gitorious.org domain name to a https://archive.org subdomain (i.e. gitorious.archive.org).

:::: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 06:40, 11 March 2016 (EST)

=== Regex parsing of template parameters? ===

For the {{tl|repo link}} template, I am currently trying to work out what to do for git branches and tags on the SourceForge infrastructure. The problem is that the presence of the character <code>/</code> within a branch or tag name requires the text <code>/~</code> to be appended to that name in the URL, for example:

* Tag <code>version/2016.1.1</code>: https://sourceforge.net/p/flightgear/simgear/ci/version/2016.1.1/~/tree/simgear/ephemeris/ephemeris.cxx
* Branch <code>release/2016.1</code>: https://sourceforge.net/p/flightgear/simgear/ci/release/2016.1/~/tree/simgear/ephemeris/ephemeris.cxx

I haven't found out a way to use regex to parse the <code>tag</code> or <code>branch</code> template parameters to automate this, hence I am thinking of just giving the instruction for the template user to append this text to the <code>tag</code> or <code>branch</code> parameter text themselves. However this is not ideal - a change of this behaviour on the SourceForge side requires end pages with SourceForge URLs to be updated, rather than just updating {{tl|repo link}}. I was wondering about possibility of installing the extension:

* [https://www.mediawiki.org/wiki/Extension:RegexParserFunctions Extension:RegexParserFunctions]

Though I'm not 100% sure if that will work. Or does someone else know an alternative? Cheers!

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 12:09, 22 April 2016 (EDT)

: not a solution, just a potential workaround would be checking for the most common prefix strings used in tags/branches (e.g. version, release, topic, topics) and explicitly rewrite the URL accordingly to append the /~ suffix -[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:59, 22 April 2016 (EDT)

:: That might be a solution. But I don't know how to do that without regex ;) We really only have #ifeq statements, but that has to match the whole string.

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 13:44, 22 April 2016 (EDT)

As a temporary workaround, I'll update the SourceForge {{tl|repo link}} template instructions to tell the user to append <code>/~</code> to the branch or tag name, if the <code>/</code> character is present.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 10:31, 20 May 2016 (EDT)

== Discussion about quotes on the wiki ==
{{usr|Hooray}} have started a page now at [[FlightGear wiki:Quoting Guidelines]] ([http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Quoting_Guidelines&oldid=96104 perm]) for a discussion regarding guidelines for the use of quotes on the wiki. Join the discussion.

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 18:17, 21 March 2016 (EDT)

In slight relation to this I have tried to make the wiki more consistently use the most common spelling and case, "Instant-Cquotes" and have changed the automatic categorization accordingly. All articles using the {{tl|FGCquote}} template can now be found in [[:Category:Articles containing Instant-Cquotes]] (currently some ~250 articles).

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 08:21, 23 March 2016 (EDT)

== Reorganizing the Git articles ==
I've noticed that the [[:Category:Git|Git articles]] suffer from duplication and are in part obsolete (especially with regard to the instructions for running Git on Windows). Thus, I propose the following reorganization:
* [[Development workflow]]: reorganization to explain how the patch submission process is organized from a high-level point of view (forking the repository from SourceForge, developing, pushing the commits to the personal fork, submitting a merge request/sending a patch to the mailing list);
* [[FlightGear Git]]: leave as is;
* '''Installing and configuring Git''' - new article about installing Git and configuring it (setting the username/e-mail address); merge the contents of [[FlightGear Git on Windows]] and [[Resources WRT running git on Win32]] here;
* [[FlightGear Git for laymen]] - make it follow [[FGW:MOS]], merge the contents of [[Howto:Start using git]] here;
* [[FlightGear Git: core developers]] and [[FlightGear Git: data developers]] - I'm uncertain about what I should do with them: the only piece information that would not be written in other articles is the list of alternative methods for cloning FGData;
* [[FlightGear Git: gitiquette]] and [[FlightGear Git: tips]] - make them follow [[FGW:MOS]].
Any comments? -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 06:11, 13 May 2016 (EDT)

: This is sorely needed! For [[FlightGear Git: core developers]] and [[FlightGear Git: data developers]], maybe these can be merged into something like [[FlightGear Git: working with the repositories]]? The only real difference is the URL, but that is a minor difference with the [[:Category:Repository link templates]]. This could be generalised into a set of instructions for working with all git repositories for the core infrastructure, including forking and merge requests, with a current focus on the SourceForge web and non-web interfaces.

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 08:17, 13 May 2016 (EDT)

:: Yes, I was thinking about a similar solution as well. -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 10:16, 13 May 2016 (EDT)

: For the reorganisation of the articles, it would be good to make a lot of use of the {{tl|Project infrastructure}} template. This will abstract away the SourceForge infrastructure (well some instructions will be 100% SourceForge specific, so it won't be perfect). I would like to however have [[Template talk:Project infrastructure#Slight variation of the current architecture|Johan's design]] implemented first, as it would be quite beneficial.

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 18:43, 14 May 2016 (EDT)
:: Thanks, didn't know it existed. Right now I'm fixing some last-minute bugs before the release, but I'll have a look at this. -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 09:05, 15 May 2016 (EDT)

::: And while we're at it, we also have a handful of git related templates to abstract away UI-specifics, which would allow us/me to upload screenshots for different interfaces (CLI, tortoisegit etc), so that we only need to update the templates, and not touch any of those articles. OTOH, I cannot seem to find a recent discussion of the idea, only http://wiki.flightgear.org/Talk:Development_workflow and that has not been updated in 3 years. Any opinions ? -[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:52, 15 May 2016 (EDT)
:::: I'm not fully sold on this one. I see the point of creating templates (for example, the Git commands mentioned in [[Talk:Development workflow]] can be used in aircraft pages to explain how to checkout a development version from a private repository), but, in my opinion, screenshots are a bit "heavy" to be reused in other articles (beside the Git ones). Did you plan to use them in other pages and, if yes, how? -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 14:11, 23 May 2016 (EDT)

:: It was originally intended to document different UIs and workflows - i.e. by parameterizing the templates, so that a matching set of commands, and screenshots, could be shown. The basic idea was that we have a growing number of articles detailing git workflows (clone, checkout, push, branch etc) - and it seemed to make sense to have a single article/template documenting the specifics, so that other articles could merely use that template, while specifiying the "action" and any other variable items (repository, branch etc) - and then use a template to provide the matching command line. However, don't worry - we don't need to do it that way. Originally, it was all inspired by [[Howto:Build FlightGear with NetBeans using CMake]]. -[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:23, 23 May 2016 (EDT)

== UTF-8 language pages cannot be edited ==

This is a continuation of [[FlightGear wiki:Village pump/Archive 2015#UTF-8 language pages cannot be edited]]. I can see that wiki editors are [[Zh/FlightGear Wiki|forced to create workarounds]], as the [[Main page]] in Chinese [http://wiki.flightgear.org/index.php?title=Zh/%E9%A6%96%E9%A1%B5&action=edit cannot be edited]. I think it is quite important to solve this ''"A database query error has occurred. This may indicate a bug in the software"'' issue. As the fix is quite dangerous (see {{mediawiki|Topic:S1q54kosfdkhz6w1}}), do we have a backup system? Do we have regular mysql and ftp dumps that can be backed up locally using rsync?

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 05:16, 15 May 2016 (EDT)

: This is quite urgent! We have a new contributor who would like to add Greek translations to our wiki, but he is completely blocked. Here are the steps to reproduce:
:* Go the the main page.
:* Click on the "Ελληνικά" language (Greek in Greek).
:* As the page doesn't exist, create it.
:* See the error message "A database query error has occurred. This may indicate a bug in the software".

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 17:30, 19 June 2016 (EDT)

=== Non-latin characters in the URL ===

The problem is non-latin characters in the URL. I just ran a test:

* Edit [[Zh/你好]] → ''"A database query error has occurred. This may indicate a bug in the software"''
* Edit the latin equivalent [[Zh/nihao]] → No error.

Let me repeat that fixing this huge bug should be given the highest priority, as it prevents the wiki from being translated into many, many languages.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 05:30, 28 June 2016 (EDT)

== Making wiki specific templates available via editor ? ==
We now have an increasing number of wiki specific templates that should be more widely used, so that it would make sense to integrate those with the default mediawiki editor - e.g. the URL encapsulating templates. -[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 10:12, 16 May 2016 (EDT)

== Categorizing aircraft infoboxes by hangar ==
I would like to bring the discussions from [[Template talk:Infobox aircraft#fgaddon aircraft]] into here for greater exposure. The idea discussed there was to add <code>hangar</code> and <code>aircraft</code> parameters to automate and categorise the aircraft infoboxes. This is to help readers instantly identify the source of the aircraft and to give greater exposure to 3rd party hangars or independent aircraft. To show off the potential of this automated approach, I have created an example template at [[User:Bugman/Infobox Aircraft]] (see the bottom for an example based on the [[Space Shuttle]] infobox). Each [[FlightGear hangars#Third party sites|3rd party hangar]] can add one of the following options:

* The hangar logo, with a link to the hangar. For example I have created an initial test logo for FGAddon: [[File:FGAddon logo.png|80px]]
* Development repository link. An automatically created link, if the {{param|development}} parameter is not supplied.
* Download link. An automatically created link, if the {{param|download}} parameter is not supplied.
* A hangar category. For example [[:Category:FGAddon hangar]].

Feedback would be appreciated. Cheers!

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 04:53, 25 May 2016 (EDT)

: Following from these ideas, I have made a proposal for a new template: [[Template talk:Infobox aircraft#Proposal for a new aircraft infobox template design (2016/06)]]. The more feedback on this, the better ;) Cheers!

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 10:17, 1 June 2016 (EDT)

:: Thanks for your work - looks good, the only change I would make is (as you noted in the template talk page) replacing the repository/download/livery database/forum thread icons with something more suitable and less "brilliant" icons (though I admit I don't have an alternative proposal for this right now). -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 04:40, 2 June 2016 (EDT)

::: Cheers! I used the high quality Oxygen icon set from the git repository at https://quickgit.kde.org/?p=oxygen-icons.git (this used to be at svn://anonsvn.kde.org/home/kde/trunk/kdesupport/oxygen-icons), as these are {{tl|LGPLv3}} licensed, and hence usable on this wiki. I especially liked the gender neutral icon for the forum: [[File:Meeting-attending 32x32.png]]. They are hi-colour and hence match the bright yellow status stars, but they don't match the minimalistic {{tl|ready}} icons. Anyway, we can switch to a different icon set after the template and aircraft infobox collection have been updated, and once a suitable set is found or created and, more importantly, once a FG wiki-wide colour scheme policy has been discussed ;)

::: — [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 05:21, 2 June 2016 (EDT)

=== Bermuda Triangle ===

To allow for the easy management of wiki articles in which the aircraft appears to have been lost, I have created the new [[:Category:Bermuda Triangle]] aircraft "hangar". If the {{param|hangar}} parameter for the {{tl|infobox aircraft}} is set to {{param||bermuda}}, then the result is: [[Template:Infobox aircraft#Lost aircraft]]. Feedback is more than welcome!

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 06:36, 2 August 2016 (EDT)

== Set up a robot to fix all the broken "prettytable" table classes? ==

After the last Mediawiki update, the "prettytable" class for tables is no longer defined. I believe that it has been merged into the "wikitable" class. Here is a before and after example of fixing the tables:
* http://wiki.flightgear.org/index.php?title=List_of_abbreviations&oldid=70465
* http://wiki.flightgear.org/index.php?title=List_of_abbreviations&oldid=99718
I suggest automating the conversion of "prettytable" to "wikitable", as this is an absolutely huge job.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 14:04, 10 June 2016 (EDT)

: For reference, here is what the "prettytable" class formatting was like prior to its disappearance:
:* https://web.archive.org/web/20150510160626/http://wiki.flightgear.org/List_of_abbreviations
: The tables without borders that we now see is not the original format desired by those creating the tables (prior to sometime in 2015).

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 11:05, 13 June 2016 (EDT)

:: As a workaround, I have redefined the "prettytable" class in [[Mediawiki:common.css]].

:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 06:23, 22 July 2016 (EDT)

=== A new "keytable" class ===

For an improved table formatting which sits well with the {{tl|key press}} template, I have defined the new "keytable" class in [[Mediawiki:common.css]]. This is for the elegant formatting of keyboard shortcut tables. It uses high quality typesetting rules: There is no background colour; uses generous margins and padding; only horizontal dividers at the top and bottom and between the header and main content; somewhat indented from the main text. Here is an example (which will change as the "keytable" styles are refined):

{| class="keytable"
! Key
! Function
|-
| {{key press|d}}
| Open/close crew door
|-
| {{key press|D}}
| Open/close passenger door
|}

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 07:49, 21 July 2016 (EDT)

== URL change notifications ==
Referring to controversial URL changes like <ref>http://wiki.flightgear.org/index.php?title=Airbus_A340-600HGW&diff=99775&oldid=99774</ref>, could we discuss setting up some rules, infrastructure/tools to get a notification when certain links (regex) are updated/added ? For now, I have updated http://wiki.flightgear.org/MediaWiki:Spam-blacklist accordingly.-[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:23, 12 June 2016 (EDT)

: We currently have these situations under control<ref>http://wiki.flightgear.org/index.php?title=Airbus_A340-600HGW&diff=next&oldid=99776</ref>, and I have been able to resolve them in a way that is beneficial to all. So I don't think we need such measures. Education is more productive, as the intent is good. And I believe that both monitoring the recent changes list and a simple search for that keyword are sufficient for now.

: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 11:11, 13 June 2016 (EDT)

== SVG graphics support? ==
I was wondering if we could [https://www.mediawiki.org/wiki/Manual:Image_administration#SVG enable SVG graphics support]? Currently we cannot upload svg files<ref>https://forum.flightgear.org/viewtopic.php?t=29732&p=288612#p288612</ref>. The purpose would be for high quality graphics at all resolutions for icons, logos, banners, etc., and allowing for low resolution bitmap graphics to be made into higher resolution graphics for future wiki purposes.

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 10:49, 13 June 2016 (EDT)

== Thai language support ==

Could we please have Thai (th) added to the supported langauges in LocalSettings.php? Cheers!

[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 07:21, 10 August 2016 (EDT)

== new portal for cockpit building (hardware) ? ==
We are now seeing an increasing number of articles relating to hardware/cockpit building -- [[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:57, 21 August 2016 (EDT)

* [[Howto:C172P Panel Project]]
* [[Howto:Build your own procedure trainer]]
* [[Howto:Build your own Panel or Cockpit]]
* [[Howto:Build your own Panel or Cockpit - Prototyping]]
* [[Howto:Build your own Panel or Cockpit - Software]]

See also [[:Category:Cockpit_building]]

: I've added all relevant pages (except omissions) in the category Cockpit_building, so this could be enough, but having a new portal could encourage sharing of experience. Or perhaps we just need a new sub-forum on the FlightGear site?
: [[User:Tipunch|Tipunch]] ([[User talk:Tipunch|talk]])

Howto:Build your own Panel or Cockpit - Prototyping

2016-08-20T07:09:10Z

Tipunch: Category:Cockpit building

<div style="text-align: right">[[Howto:Build your own Panel or Cockpit | Return to Build your own Panel or Cockpit]]</div>
<hr>
In order to build anything of this complexity from scratch, you need to take things a step at a time. Before you can put the parts together, you'll need to be sure the parts you are going to build will work as expected.

Here's the areas I've identified for my project for prototypes in no particular order:
== Integrated Circuit Types and Features ==
{| class="wikitable" border="1"
! Type or Feature !! Description !! Manufacturer !! Part Nos
|-
| Buffers || ||
|-
| Bus Hold || ||
|-
| Inverters || ||
|-
| Drivers || ||
|-
| Flip Flops || ||
|-
| latches|| ||
|-
| Level Shifters|| ||
|-
| Translators|| ||
|-
| || ||

|}

== Integrated Circuit Candidates ==
{| class="wikitable" border="1"
! Description !! Manufacturer !! Part No !! Package/Case !! Supply Voltage !! Supply Current or Power Dissapation- Max
|-
| 8 Digit 7 Segment LED Display Driver || Maxim || MAX7221CNG+ || PDIP-Narrow-24 || 4V to 5.5 V || 330Ma
|-
| IO Expander I2C SPI 16 Lines ||Microchip ||MCP23016-I/SP ||PDIP-Narrow-28 || 2 to 5.5V ||
|-
| ||Microchip SPI 16 Lines ||MCP23S17-E/SP || PDIP-Narrow-28|| 1.8 to 5.5V ||
|-
| ||Microchip SPI 16 Lines ||MCP23S18-E/SP || PDIP-Narrow-28|| 1.8 to 5.5V ||
|-
| Multiplexer 8 channel-1 Data Selector|| Texas Instruments ||CD4512BE || PDIP-16|| -0.5 to 20V || 500mw
|-
| Demultiplexer CMOS 3 to 8 High||Texas Instruments ||CD74HC237E ||PDIP-16 || 2 to 6V||
|-
| Demultiplexer CMOS 3 to 8 Low ||Texas Instruments ||CD74HC137E ||PDIP-16 || 2 to 6V||
|-
| Demultiplexer CMOS 4 to 16 Low ||Texas Instruments||Texas Instruments ||CD74HC4515EN ||PDIP-24 || ||
|-
| ||Atmel ||ATMEGA8535-16PU || PDIP-40 .6"|| ||
|-
| ||Atmel ||ATMEGA328-PU ||PDIP-24 || ||
|-
| ||Atmel ||ATMEGA8A-PU ||PDIP-24 || ||
|-
| || || || || ||

|}
== I2C and SPI Interfaces ==
{| class="wikitable"
! Feature !! Description !! Platform !! Library
|-
| rowspan="3" | I2C and SPI Master
| rowspan="2" | Bus Masters for I2c and SPI
| Rasberry Pi
| wiringPi

|-
| AtMega || Check the Web. There's got to be one.
|-
| Bitbanged Bus Masters
| Raspberry Pi or AtMega
| Don't know if these will be needed?
|-
| rowspan=2 | AtMega Driver
| rowspan=2 | Driver to manage communication of Raw Data for AtMega Peripherals
| Raspberry Pi || New Code
|-
| AtMega || New Code

|-
| I2C and SPI Port Expander Drivers || Exact Chip TBD || Raspberry Pi || Check the Web for code or write in C
|-
| 7 Segment Display Driver || Max7221 Driver for 24 digits displayed on radios || Raspberry Pi || Check the Web for code or write in C
|-
| SPI Select || Since several SPI devices will be needed, there needs to be a way to select the one to be active. Several Methods may apply
* Use GPIO pins directly
* Use a Decoder Chip
* Use an I2c or SPI Port Expander ||Raspberry Pi || Need to look at examples and search for code
| Raspberry Pi
|
* Need to look at examples
* Probably need to code this
|-
| I2C Select || Need to know more about how the addresing and selection of I2c Devices work || Raspberry Pi
|
* Need to look at examples
* Probably need to code this
|}

== Flightgear Properties and Hardware Interfaces ==
* Mapping of each Flightgear property to a hardware interface and one or more addresses on the interface and to a routine to translate and move data between them.
* Pi to Flightgear requires Property Path, Name and Value. Protocol is documented on Flightgear Wiki.
* Pi to Max7221 is defined by the chip
* Pi to Port Expander is defined by the chip and a driver on the Pi to use the port expander instead of a gpio pin
* Pi to AtMega and Atmega to Pi requires an id for the AtMega interface port associated with the property and the value.
* To save time on the SPI or I2c intefaces, a table will be loaded down from the Pi to the ATMega at startup. On the AtMega, it will contain the AtMega Interface Port Id, identify the port's handler routine and the hardware addressing data for the port. On the Pi, it will contain the AtMega Interface Port Id, the path and name of the Flightgear property and the id of the Pi Routine responsible for translating between the Property Value and the AtMega Hardware Value.

for details see: [[Howto:Build your own Panel or Cockpit - Software]]

== Switches ==
* Map anything that behaves like a switch as a switch
** Switch Multiplexing
** Switch De-Bouncing
** On-Off Switch
** On-Off-On Switch
** Multi Position Switch
** Multiplexing Switch Data
** Rotary Encoder
== Encoder Processing ==
** Prioritization of Rotary Encoder Switch Data Processing
** Magnetic Encoder
** Rotary Encoder vs Magnetic Encoder
** Magnetic Encoder Calibration
** Synchronizing Magnetic Encoder Data, Actual Rotation of Instrument Compass Dial and Corresponding Rotation in Flightgear Properties
== Volume or Control Axis Data ==
** Audio Volume or Linear Potentiometer
** Potentiometer vs Magnetic Encoder
== Air Coils ==
* Air Coils are used for Various Guages and Instruments with Needles
** Mounting of Air Coils for Gauges, VORs and center dial instruments
** Separate Air Coils for Three Needles at Center of Altitude Indicator
== Mechanical Linkages ==
** Rotation of Attitude Indicator
** Attitude Indicator Horizon
** Ball Part of Turn Coordinator
** Adjustment of Magnetic Compass with two adjusters
== Radios and Auto Pilot ==
* Display of alphabetic and numeric data in COM, NAV and DME Radios
* Tuning via Rotary Encoder or Magnetic Encoder (needs detent)
* Dual Rotary Encoders or Magnetic Encoders for Tuners
* Pull Switches vs Push Switches
* Combining Indicators and Numeric Displays
* Modelling the KR87 Ident Radio 8 Position Switches

== USB Serial Interface ==
** Implement using AtMega8-16PU
** Use for Flightgear data that cannot be set or sensed using Telnet
== Telnet Interface ==
* List as many properties needed for C172 as you can find
* Build a UI to display and set a number of them from the Raspberry Pi
* For the properties in the telnet or USB interfaces
== Raspberry Pi Setup ==
== Raspberry Pi Event Loop ==
* USB communication
* Telnet Communication
* I2C Master Communication
* SPI Master Communication
== ATmega Setup ==
== ATmega Event Loop ==
* I2C Slave Communication
* SPI Slave Communication
* Rotary Encoder Sense
* Other Switches Sense
* A/D Sense (rheostats)
* Air Coil Movement
* Frequency Display
* Indicator Display
* Instrument Lighting
* Logging
* Event Prioritization

[[Category:Cockpit building]]

Howto:Create WebPanel instrument

2016-08-20T07:07:32Z

Tipunch: Category:Cockpit building

This guide will show you how to create a one simple web based instrument for a WebPanel. In a picture below, a Cessna 172P WebPanel is shown in another monitor in front of a lcd tv used as a scenery visual.

[[File:C172p WebPanel with TV as visual.jpg|thumb|Cessna 172P WebPanel shown in a monitor front of a TV used as visual]]

First you should check that you can see a Cessna 172P WebPanel on a browser window. Start Flightgear with a Cessna 172P plane selected and with "--httpd=8080" additional option to start internal webserver. Then from Flightgear's C172P aircraft menu, click "Panel in a Browser" and browser window should open with a working instrument panel. When you start engine and lift off, instruments should be moving.

This HowTo uses following software:
* Ubuntu 16.04
* Flightgear 2016.2.1
* PC-9m aircraft
* Inkscape

=== WebPanel folder and instrument files for aircraft ===

Create a folder named "WebPanel" into Flightgear's aircraft folder. In Ubuntu, installed aircraft folders can be found from: /home/YOUR_USER_NAME/.fgfs/Aircraft/org.flightgear.official/Aircraft

For WebPanel to work, following files are needed:
* webpanel-properties.json (maps Flightgears internal properties for instruments)
* webpanel.html (html page what is shown in browser)

And for a single instrument, following files are needed:
* INSTRUMENT_NAME.svg (vector image shown in www-page as flight instrument)
* INSTRUMENT_NAME.json (for instrument animations)
* INSTRUMENT_NAMEInterpolation.xml (not necessary file, but used if instrument animation needs to be non-linear)

=== webpanel-properties.json ===

webpanel-properties.json file maps Flightgears internal properties to instruments. Create a file named webpanel-properties.json, save it to aircrafts WebPanel folder and insert following code into it:
<syntaxhighlight land="xml">
{
"instrumentSelector": ".instrument",
"instrumentDataKey": "fgpanel-instrument",
"updateInterval": 32,

"propertyMirror": [
["ias", "/instrumentation/airspeed-indicator/indicated-speed-kt"]

]
}
</syntaxhighlight>

This example file will take only planes indicated speed in knots and sends it to "ias". If you need multiple internal properties for one instrument or for creating other instruments, see example from {{fgdata source|path = Aircraft/c172p/WebPanel/c172p-webpanel-properties.json}} file, for how more rows for multiple properties are added.

=== WebPanel www-page file ===

Create webpanel.html file and save it in WebPanel folder with following code:

<syntaxhighlight land="html">
<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />

<meta name="apple-mobile-web-app-capable" content="yes">

<meta name="apple-touch-fullscreen" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">

<title>FlightGear - PC-9m Instrument Panel</title>
<style type="text/css" media="screen">
body,html {
width: 100%;
height: 100%;
overflow: hidden;
background-color: #000000;
border: 0;
margin: 0;
padding: 0;
}

.instrument {
border: 1px solid #131313;
padding: 8px;
background-color: #111111;
}
</style>

<script type="text/javascript" charset="utf-8"
src="/3rdparty/jquery/jquery-1.11.1.min.js"></script>


<link rel="stylesheet" href="bootstrap/bootstrap.min.css">

<script src="bootstrap/bootstrap.min.js"></script>

<script type="text/javascript" charset="utf-8" src="/lib/jquery.fganimate.js"></script>
<script type="text/javascript" charset="utf-8" src="/lib/fgfs.js"></script>

</head>
<body data-fgpanel="true" data-fgpanel-props="webpanel-properties.json">
<div class="row">
<div id="pc9m_ASI" class="instrument col-xs-2" data-fgpanel-instrument="pc9m_ASI.json"></div>
</div>
</body>
</html>
</syntaxhighlight>

This creates a file for browser to show instruments. Important is data-fgpanel-props="webpanel-properties.json"> which specifies planes properties .json file. In <div> tag id="pc9m_ASI" and data-fgpanel-instrument="pc9m_ASI.json" specifies what instrument is drawn into browser. To create a new instrument, add another <div> with new id tag and .json file. To create a new row for instruments start a new <div class="row">. See example from Cessna 172P planes folder /usr/share/games/flightgear/Aircraft/c172p/WebPanel/c172p-webpanel.html.

=== INSTRUMENT_NAME.json ===

INSTRUMENT_NAME.json file specifies how instrument behaves when Flightgears properties change. Create file named pc9m_ASI.json, save it to WebPanel folder and add following code into it:
<syntaxhighlight land="json">
{
"src": "pc9m_ASI.svg",

"animations": [
{
"element": "#Needle",
"type": "transform",
"transforms": [{
"type": "rotate",
"a": {
"property": "ias",
"interpolation": "AirspeedInterpolation.xml"
},
"x": 256,
"y": 256
}]
}

]
}
</syntaxhighlight>

Explanation for rows:
* "src": "pc9m_ASI.svg": filename of instruments .svg vector graphic file
* "element": "#Needle": instruments .svg images id what is meant to be animated
* "type": "rotate": we are rotating Needle layer of instrument image
* property "ias": Flightgears internal property that causes the movement
* "interpolation": file where interpolation is specified
* "x": 256, "y": 256: specifies origo for rotation. In our image size 512x512px, 256px is in middle of the image.

=== INSTRUMENT_NAMEInterpolation.xml ===

Create file AirspeedInterpolation.xml and save it to WebPanel folder with following code:
<syntaxhighlight land="xml">
<?xml version="1.0"?>

<PropertyList>
<entry><ind> 0</ind><dep> 0</dep></entry>
<entry><ind> 35</ind><dep> 36</dep></entry>
<entry><ind> 40</ind><dep> 50</dep></entry>
<entry><ind> 60</ind><dep> 100</dep></entry>
<entry><ind> 80</ind><dep> 152</dep></entry>
<entry><ind> 100</ind><dep> 206</dep></entry>
<entry><ind> 120</ind><dep> 249</dep></entry>
<entry><ind> 140</ind><dep> 291</dep></entry>
<entry><ind> 160</ind><dep> 333</dep></entry>
<entry><ind> 190</ind><dep> 340</dep></entry>
</PropertyList>
</syntaxhighlight>

Interpolation lists first number input property (air speed in this example) and second number is angle for needle.

=== Creating instrument graphics with Inkscape ===

If you are not familiar with Inkscape, see [https://inkscape.org/en/learn/tutorials/ Inkscape tutorials].

To create a instrument image, start creating a new 512x512 px size file with Inkscape. When drawing .svg file, following issues need to be kept in mind:
* moving objects needs to be on a different layers
* layers id needs to be renamed from Inkscapes XML editor. Layer animation will fail if id is not correct.

Draw a round face and a simple needle on top of it
*Create new layer and call it "Face". Draw a circle in it.
*create new layers called "Needle" and draw a needle in it. Needles rotating point should be in middle of the drawing area. Rename its ID from XML editor to "Needle".
*Save it with a pc9m_ASI.svg name in to PC-9m aircrafts WebPanel folder.

=== Test WebPanel ===

To test instrument in WebPanel, start Flightgear with "--httpd=8080" additional option to start Flightgears web server.

When Flightgear has started, go to http://localhost:8080/aircraft-dir/WebPanel/webpanel.html address and simple instrument with one needle and without numbers should be visible.

Start PC-9m and when speed is rising you should see needle to start moving.

[[File:PC-9m WebPanel tutorial air speed instrument.jpg|thumb|Example of WebPanel instrument showing PC-9m airspeed in browser]]

[[Category:Cockpit building]]

Howto:C172P Cockpit Project

2016-08-20T07:06:58Z

Tipunch: Category:Cockpit building

This Howto will develop into a detailed project plan for building a C172P Instrument Panel. While not a step by step guide, it will include details on the prototyping, design and building of a panel. The project includes the following major activities:
= Open Identified Tasks =
{| class="wikitable"
! Task Description !! Blocking Factors/Action Items/Progress !! Status
|-
| Bench Power Supply
|
* Blocked by Lack of suitable case
* Action: Visit Robinson's Hardware, check out aluminum sheet

* Blocked by: Lack of a Bending Brake
* Action: Make a Bending Brake

* Action: Bend Some Tin
* Action: Test what load Resistor will turn on the power supply
* Action: Drill Mounting Holes for Load Resistor
* Mount the power supply in the hand built case
* Blocked by: No way to extract power from power supply without cutting wires
* Action Taken Ordered 24 Pin Socket from E-Bay
| Proceeding in part
|-
| Flightgear Rasberry Pi Client
| Ready To Start
* Create Data Structures
** Flightgear Aircraft Property Table
** Cockpit Hardware Table
** Flightgear Connection Table
* Build Test Stubs with data for these tables
* Investigate Exporting/Importing the data from XML files
* Find out if a node server could drive or call the client
*
| Status
|-
| Task Description
| Blocking Factors/Progress
| Status
|-
| Task Description
| Blocking Factors/Progress
| Status
|}

= Description =
The work product will match an actual C172P cockpit instrument panel as closely as possible given constraints of tool availability, time and money.

Versions:
# A set of rotary encoders and switches in an overlay for a regular monitor
# Expand the project to include items in the radio stack
# Replace the monitor with individual instruments

= Design Alternatives =
* Instruments
** Monitor Overlay
** Individual Instruments
* Multi-value inputs
** using potentiometers and ADC ports
** Using magnetic encoders with:
*** AtMega driven pins
*** SPI
*** I2C
* Display of Numeric and Alphabetic data
** driven by Maxim Max7221 on an SPI interface
** driven directly by an AtMega processor
* Banks of switches and rotary encoders with a multiplexed parallel interface
* Raspberry Pi connected to one or more AtMega Processors via SPI or I2C
* Raspberry Pi connected to a 4 to 16 bit multiplexer to select SPI data
* Raspberry Pi responsible for interfacing raw data to flightgear property values
* Display of numeric and alphabetic data using 7 and 16 segment displays
** drive with AtMega chip and Transistors
** drive with Maxim Max7221CNG Integrated Circuit
* AtMega Processors with port expanders responsible for raw data
* AtMega Processors communicate with Raspberry Pi
** Using SPI
** Using I2C
* Telnet interface to Flightgear runs on Raspberry Pi
** C programming language

== Code Development Activities
=== Client to Flightgear protocol ===
=== Client to AtMega protocol
=== Pi Client ===
=== AtMega Client ===
=== Magnetic Encoders ===
* For Heading Adjusters on Instruments
* Replacement for Rotary Encoders
* Replacement for Potentiometers

= Proof of Concept and Prototyping Activities =

== Client on PI ==
=== Communication with Flightgear using Telnet ===
* Change the value of a cockpit switch
* Read the value of a Com or Nav Radio's frequency
* Change a standby frequency
* Make a standby frequency the in use frequency
* Dim and brighten the instruments
* Move the throttle
* Move one of the control surfaces
=== SPI ===
* different speeds
* Error Detection and re-transmission
* Client to ATMega
* Client to Max7221
* Client to Port Expander
=== I2C ===
* different speeds
* Error Detection and re-transmission
* Client to ATMega
* Client to Port Expander
== Client on AtMega ==
=== Communication ===
* I2c
* SPI
* Raw Data Protocol
== Data Acquisition ==
* Switch
* Rotary Encoder
* Magnetic Encoder
* Potentiometer
== Control Data ==
* Air Core
* Stepper Motor
* Lighting Level
*

= Building =

== Hardware Choices ==
* AtMega Models
* Raspberry Pi III
* for 7 and 16 segment displays
** Max7221
** or 7 Segment Driver Transistors
* 4 to 16 Multiplexer
* Magnetic Encoder
* Rotary Encoder
* Slider Potentiometer:
* Power Supply: Bench Supply based on an ATX PC power supply
* Knobs
** Heading Adjusters
** Radio Stack Volume
** Radio Stack Frequency Select
** Radio Stack Buttons
** Rotary Switches
** Rocker Switches
** Toggle Switches
** Main Switches
** Magneto Switch
** Flaps Lever: Design the Mechanism to attach to a rotary switch

[[Category:Cockpit building]]

Cessna 150

2016-08-18T06:56:07Z

Tipunch: Gallery added

{{WIP|The C150 is now (20160504) under maintenance by HJ}}

{{:{{PAGENAME}}/info}}
The '''Cessna 150''' is a two-seat tricycle gear general aviation [[aircraft]], that was designed for flight training, touring and personal use.

The Cessna 150 is the third most produced civilian plane ever, with 23,839 aircraft produced. The Cessna 150 was offered for sale in the 150 basic model, Commuter, Commuter II, Patroller and the aerobatic Aerobat models.

== Normal Operating Procedures ==

=== Airspeeds for normal flight operation ===

{| class="wikitable"
! !! Vias
|-
| '''NORMAL / OPTIMUM''' || kts|| MPH
|-
| Best angle of climb '''V'''<sub>X</sub> || 56 || 64
|-
| Best rate of climb '''V'''<sub>Y</sub> || 68 || 78
|-
| Normal rotation speed '''V'''<sub>R</sub> || 50 || 58
|-
| Normal climb speed || 65-75 || 75-85
|-
| Normal landing (no flaps) || 60-70 || 70-80
|-
| Normal landing (full flaps) || 50-60 || 57-69
|-
| Powered landing (no flaps) || 65 || 75
|-
| Powered landing (full flaps) || 55 || 63
|-
| Maximum performance approach || 52 || 60
|-
| Optimum glide speed || 60 || 69
|}

{| class="wikitable"
! !! Vias
|-
| '''LIMITS''' || kts|| MPH
|-
| Never Exceed Speed '''V'''<sub>NE</sub> <br>Do not exceed this speed in any operation || 141 || 162
|-
| Max structural speed '''V'''<sub>NO</sub> <br>Do no exceed this speed except in smooth air and<br>then only with caution || 107 || 123
|-
| Maneuvering speed '''V'''<sub>A</sub> || ||
|-
| 1,600 pounds || 67 || 111
|-
| 1,450 pounds || 93 || 107
|-
| 1,300 pounds || 88 || 101
|-
| Maximum flap extended speed '''V'''<sub>FE</sub> || 85 || 97
|-
| Stall speed V<sub>S</sub> || 47 || 54
|-
| Stall speed (10° Flaps) '''V'''<sub>S1</sub> || 45 || 52
|-
| Stall speed in landing configuration '''V'''<sub>S0</sub> || 42 || 49
|-
| Optimum glide speed || 60 || 69
|}

=== Checklist ===

==== Startup ====
# Carburetor Heat - Cold
# Mixture - Rich
# Primer - As Required
# Ignition switch - Both
# Throttle - Open 1/4 inch
# Propeller Area - Clear
# Starter - On

==== Takeoff ====
# Wing flaps - Up
# Carburetor Heat - Cold
# Throttle - Full "Open"
# Elevator Control - Lift nose wheel at 50 mph
# Climb Speed - 72 MPH until all obstacles are cleared

==== Climb ====
# Air Speed - 75 to 80 MPH
# Power - Full throttle
# Mixture - Rich (unless engine is rough)

==== Cruise ====
# Power - 2000 to 2750 RPM
# Elevator Trim - Adjust
# Mixture - Lean to maximum RPM

==== Approach ====
# Mixture - Rich
# Carburetor Heat - Apply full heat before closing throttle
# Airspeed - 65 to 75 MPH
# Wing Flaps - As desired below 100 MPH
# Airspeed - 60 to 70 MPH with flaps extended

==== Landing ====
# Touch down - Main wheels first
# Landing Roll - Lower nose wheel gently
# Braking - Minimum required

=== Keyboard reminder ===
{| class="keytable"
!Key
!Function
|-
|{{Key press|d}}/{{Key press|Shift|d}}
|Door select
|-
|{{Key press|Ctrl|d}}
|Open/close selected door
|-
|{{Key press|Shift|O}}
|Operate priming pump
|-
|{{Key press|<nowiki>=</nowiki>}}
|Open configuration dialog
|}

== Gallery ==

<gallery mode="packed">
C150-064.jpg|Taking off at Winterland (CCC2)
</gallery>

== External links ==
* [http://en.wikipedia.org/wiki/Cessna_150 Wikipedia]
* [http://www.cessna150-152club.com/ Cessna 150-152 Club]

{{Cessna}}

File:C150-064.jpg

2016-08-18T06:52:04Z

Tipunch: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Taking off at CCC2}}
|date=2016-08-18
|source={{own}}
|author=[[User:Tipunch|Tipunch]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Screenshots of aircraft]]

Changelog 2016.3

2016-08-14T07:19:49Z

Tipunch: new version of the Cessna 150

{{draft|changelog|This changelog is currently being written for the FlightGear v2016.3 release. Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.}}



== Major enhancements in this release ==
=== Core ===
* new XML Sound expression support
* Enable the Qt gui inside the sim [https://sourceforge.net/p/flightgear/fgdata/ci/654a343bbb7eb51b387060515e3415e152d12c2a/]

=== Aircraft Modeling ===

=== JSBSim ===

=== Atmospheric Light Scattering ===

=== Environment Rendering ===

=== Performance ===

=== Misc/Uncategorized ===

=== Usability ===

=== Internationalization ===

=== Scenery ===

=== Canvas System ===

=== Nasal Scripting ===
* [[Emesary]] MPI framwork and multiplayer bridge have been added [{{fgdata url|view=commit|commit=c350d79007eeafe9b602cf763c28de81bf54d2da}}]

=== Documentation ===

=== Highlighted new and improved aircraft ===
* [[Cessna 150]]

=== Other ===

=== Bug fixes ===
* See [https://sourceforge.net/p/flightgear/codetickets/search/?q=status%3AFixed+AND+created_date%3A%5B2016-05-17T09%3A03%3A11Z+TO+*%5D our bugtracker] for a list, albeit incomplete, of the bugs fixed in this release.

[[Category:FlightGear changelogs]]
[[Category:New Versioning Scheme]]

Template:Cessna

2016-08-14T07:11:17Z

Tipunch: the Cessna 150 is a 150 L

{{Navbox
| name = Cessna
| title = [[Cessna]]
| listclass = hlist

| group1 = Civilian aircraft
| list1 =
* [[Cessna 150|150L]]
* [[Cessna 172P|172P]]
* [[Cessna 172R Skyhawk|172R]]
* [[Cessna 182S|182S]]
* [[Cessna C310|310]]
* [[Cessna 337G Skymaster|337G Skymaster]]
* [[Cessna 550 Citation II|550 Citation II]]
* [[Cessna Citation Bravo|Citation Bravo]]
* [[Cessna Citation X|Citation X]]

| group2 = Military aircraft
| list2 =
* [[Cessna T-37|T-37]]
}}<includeonly>{{main other| [[Category:Cessna]] }}</includeonly><noinclude>
{{Informative template|1=
__NOTOC__
== Goal ==
This navigation template links together Cessna aircraft.

Adding this template to a page in the article namespace will automatically add [[:Category:Cessna]] to that page.

== Usage ==
Put this line before the categories and the language links at the bottom of the article.

{{obr}}'''Cessna'''{{cbr}}

}}

[[Category:Navigation templates]]
</noinclude>

Walk view

2016-08-11T18:15:59Z

Tipunch: typos

{{stub}}
== Updates ==
{{See also|Skydiving}}

Marius_A has started extending Stuart's [[Tutorials]] system to also support DFaber's Walker:

{{#ev:youtube|dU7ikBZOjgk}}

Learn more at: [[FlightGear Missions and Adventures]]...

== Easy walk ==
This is the most easy walk mode: you just walk at the same level (compared to the plane) and you will not fall if you get outside the plane.
=== walk.nas ===
<syntaxhighlight lang="nasal">
# view nodes and offsets --------------------------------------------
var zNoseNode = props.globals.getNode("sim/view/config/y-offset-m", 1);
var xViewNode = props.globals.getNode("sim/current-view/z-offset-m", 1);
var yViewNode = props.globals.getNode("sim/current-view/x-offset-m", 1);
var hViewNode = props.globals.getNode("sim/current-view/heading-offset-deg", 1);

var walk_about = func(wa_distance) {
var i = getprop("sim/current-view/view-number");
if (i == view.indexof("Pilot View") or i == view.indexof("Model View") or i == view.indexof("View 8")) {
var wa_heading_rad = hViewNode.getValue() * 0.01745329252;
var new_x_position = xViewNode.getValue() - (math.cos(wa_heading_rad) * wa_distance);
var new_y_position = yViewNode.getValue() - (math.sin(wa_heading_rad) * wa_distance);
xViewNode.setValue(new_x_position);
yViewNode.setValue(new_y_position);
}
}
</syntaxhighlight>
=== -set.xml ===
<syntaxhighlight lang="xml">
<input>
<keyboard>
<key n="119">
<name>w</name>
<desc>Walk forward toward view</desc>
<repeatable>true</repeatable>
<binding>
<command>nasal</command>
<script>walk.walk_about(0.1)</script>
</binding>
</key>
<key n="87">
<name>W</name>
<desc>Walk backward from view</desc>
<repeatable>true</repeatable>
<binding>
<command>nasal</command>
<script>walk.walk_about(-0.1)</script>
</binding>
</key>
</keyboard>
</input>
</syntaxhighlight>
== Advanced walk with jump and parachute ==
{{Out of date}}

This advanced mode is way more complicated than the easy walk (see above). With this mode you can jump out of the plane and land with a parachute.
=== walk.nas ===
''See the [[Pilatus PC-6 Porter‎]]'s <tt>PC-6/Nasal/walk.nas</tt>''

=== -set.xml ===
<syntaxhighlight lang="xml">
<walker>
<outside type="bool">false</outside>
<walking type="bool">false</walking>
<speed type="double">0.000006</speed>
<latitude-deg type="double">0.0</latitude-deg>
<longitude-deg type="double">0.0</longitude-deg>
<altitude-at-exit-ft type="double">0.0</altitude-at-exit-ft>
<altitude-ft type="double">0.0</altitude-ft>
<heading-deg type="double">0.0</heading-deg>
<pitch-deg type="double">0.0</pitch-deg>
<roll-deg type="double">0.0</roll-deg>
<internal>
<x-offset-m type="double">4.3</x-offset-m>
<y-offset-m type="double">0.0</y-offset-m>
<z-offset-m type="double">0.0</z-offset-m>
<heading-deg type="double">0.0</heading-deg>
</internal>
<keep-inside-offset-x type="double">0.0</keep-inside-offset-x>
<keep-inside-offset-y type="double">0.0</keep-inside-offset-y>
<keep-inside-offset-z type="double">0.0</keep-inside-offset-z>
<keep-pitch-offset-deg type="double">0.0</keep-pitch-offset-deg>
<key-triggers>
<forward type="double">0</forward>
<outside-toggle type="bool">0</outside-toggle>
<slide type="double">0</slide>
</key-triggers>
<parachute-opened-altitude-ft type="double">0</parachute-opened-altitude-ft>
<parachute-opened-sec type="double">0</parachute-opened-sec>
<starting-trajectory-lat type="double">0</starting-trajectory-lat>
<starting-trajectory-lon type="double">0</starting-trajectory-lon>
<time-of-exit-sec type="double">0</time-of-exit-sec>
</walker>

<input>
<keyboard>
<key n="111">
<name>o</name>
<desc>Toggle walker outside/inside</desc>
<repeatable>false</repeatable>
<binding>
<command>property-toggle</command>
<property>sim/walker/key-triggers/outside-toggle</property>
</binding>
</key>
<key n="119">
<name>w</name>
<desc>Walk forward</desc>
<repeatable>false</repeatable>
<binding n="0">
<command>property-assign</command>
<property>sim/walker/key-triggers/forward</property>
<value>1</value>
</binding>
<binding n="1">
<command>property-assign</command>
<property>sim/walker/speed</property>
<value>0.000006</value>
</binding>
<mod-up>
<binding n="0">
<command>property-assign</command>
<property>sim/walker/key-triggers/forward</property>
<value>0</value>
</binding>
<binding n="1">
<command>property-assign</command>
<property>sim/walker/speed</property>
<value>0.000006</value>
</binding>
</mod-up>
</key>
<key n="87">
<name>W</name>
<desc>Run forward</desc>
<repeatable>false</repeatable>
<binding n="0">
<command>property-assign</command>
<property>sim/walker/key-triggers/forward</property>
<value>1</value>
</binding>
<binding n="1">
<command>property-assign</command>
<property>sim/walker/speed</property>
<value>0.000018</value>
</binding>
<mod-up>
<binding n="0">
<command>property-assign</command>
<property>sim/walker/key-triggers/forward</property>
<value>0</value>
</binding>
<binding n="1">
<command>property-assign</command>
<property>sim/walker/speed</property>
<value>0.000006</value>
</binding>
</mod-up>
</key>
<key n="115">
<name>s</name>
<desc>Walk backward</desc>
<repeatable>false</repeatable>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/forward</property>
<value>-1</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/forward</property>
<value>0</value>
</binding>
</mod-up>
</key>
<key n="97">
<name>a</name>
<desc>Slide left</desc>
<repeatable>false</repeatable>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>-1</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>0</value>
</binding>
</mod-up>
</key>
<key n="65">
<name>A</name>
<desc>Slide left2, override default assignment</desc>
<repeatable>false</repeatable>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>-1</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>0</value>
</binding>
</mod-up>
</key>
<key n="100">
<name>d</name>
<desc>Slide right</desc>
<repeatable>false</repeatable>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>1</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>0</value>
</binding>
</mod-up>
</key>
<key n="68">
<name>D</name>
<desc>Slide right2</desc>
<repeatable>false</repeatable>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>1</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>sim/walker/key-triggers/slide</property>
<value>0</value>
</binding>
</mod-up>
</key>
<key n="114">
<name>r</name>
<desc>open parachute</desc>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>walk.open_chute()</script>
</binding>
</key>
</keyboard>
</input>
</syntaxhighlight>

== Adding a walker pilot or co-pilot <ref>Human [http://cms.flightgear-de.net/index.php/engoben/91-comdiffen/112-humanen]</ref> ==

To add the Walker to your Aircraft replace the <PropertyList> Entry at the top of your -set file with this:

<PropertyList include="Aircraft/Generic/Human/Include/walker-include.xml">

This includes all Properties for the Walker, Key Bindings and a Menubar Entry. The Keys "a", "A" and "s" have their normal Binding when not in Walk View or Walker Orbit View.

To have a custom Exit Point add the following Properties to the <model> section in your Aircrafts -set file:
<map>
<default_exit>
<x-offset-m type ="float">1</x-offset-m>
<y-offset-m type ="float">3</y-offset-m>
</default_exit>
</map>

This specifies where the Walker Model appears.

=== Creating a pilot/copilot ===

First, position the Walker Model (walker.xml) below the seat with it's origin (feet) on the Cockpit floor. Then start FlightGear and edit the pose in the Walker animation dialog. When this is done, export the animation and copy the file to a subfolder of the aircraft. This file is referenced in the -set files pilot Properties via "include".

Note: Once the pose is done, the walker.xml entry in the Model file has to be replaced with either pilot.xml or copilot.xml!

The following properties control the appearance of the pilot and co-pilot. They are located in the /sim/model/ section of the -set file:

<crew>
<pilot n="0">
<pose include = "Include/ju52_pilot.xml"></pose>
<gender>0</gender>
<character>0</character>
<outfit>2</outfit>
</pilot>
<pilot n="1">
<pose include = "Include/ju52_pilot.xml"></pose>
<gender>1</gender>
<character>0</character>
<outfit>0</outfit>
</pilot>
</crew>

=== Custom movements ===
Basic Head Movements can be done by including this in the nasal section:

<pilot-movment>
<file>Aircraft/Generic/Human/Nasal/pilot-movment.nas</file>
<script>
var head_x = "sim/model/crew/pilot[0]/pose/position/limb[2]/x-deg";
var head_y = "sim/model/crew/pilot[0]/pose/position/limb[2]/y-deg";
var head_z = "sim/model/crew/pilot[0]/pose/position/limb[2]/z-deg";
</script>
</pilot-movment>

<copilot-movment>
<file>Aircraft/Generic/Human/Nasal/pilot-movment.nas</file>
<script>
var head_x = "sim/model/crew/pilot[1]/pose/position/limb[2]/x-deg";
var head_y = "sim/model/crew/pilot[1]/pose/position/limb[2]/y-deg";
var head_z = "sim/model/crew/pilot[1]/pose/position/limb[2]/z-deg";
</script>
</copilot-movment>

== WalkView: Another option for internal walk views ==

Another option is to use the WalkView module available in Aircraft/Generic/WalkView/ (in FlightGear 2.2.0 or later).
The module supports aircraft internal views that can move around based on a description of the reachable spaces.

Load the WalkView module and the configuration from the -set file. The example below is from [[Nordstern]] and makes the view named "Walk View" into a walk view. See also [[Zeppelin NT]] and [[Short Empire]] for more examples.

<syntaxhighlight lang="xml">

<sim>
...
<view n="103">
<name>Walk View</name>
<internal>true</internal>
<config>

<from-model type="bool">true</from-model>
<from-model-idx type="int">0</from-model-idx>
<x-offset-m type="double"> 0.00 </x-offset-m>
<y-offset-m type="double"> -7.50 </y-offset-m>
<z-offset-m type="double"> 51.00 </z-offset-m>
<heading-offset-deg type="double"> 0.0 </heading-offset-deg>
<pitch-offset-deg type="double"> 0.0 </pitch-offset-deg>
<default-field-of-view-deg type="double"> 65 </default-field-of-view-deg>
</config>
</view>
...
</sim>


<nasal>
<walkview>
<file>Aircraft/Generic/WalkView/walkview.nas</file>
<script>
# The keel walk-way is a long narrow path running in the fore-aft direction.
# Additionally there is a path to the side engine cars.
var keelConstraint =
walkview.makeUnionConstraint(
[
walkview.makePolylinePath(
[
[ 10.0, 0.0, -6.3],
[ 15.0, 0.0, -7.2],
[ 20.0, 0.0, -7.8],
[ 25.0, 0.0, -8.2],
[ 30.0, 0.0, -8.6],
[ 35.0, 0.0, -8.8],
[ 40.0, 0.0, -9.0],
[ 50.0, 0.0, -9.1],
[ 65.0, 0.0, -9.1],
[ 70.0, 0.0, -8.8],
[ 80.0, 0.0, -8.5],
[ 90.0, 0.0, -7.9],
[ 95.0, 0.0, -7.4],
[100.0, 0.0, -6.9],
[105.0, 0.0, -6.2],
[110.0, 0.0, -5.4],
],
0.20),
walkview.makePolylinePath(
[
[ 59.75, -4.90, -7.79],
[ 59.75, -1.70, -9.05],
[ 59.75, 1.70, -9.05],
[ 59.75, 4.90, -7.79],
],
0.20)
]);
# Create the walker for the named view and the given movement restrictions.
var rigger_walker = walkview.Walker.new("Walk View",
keelConstraint);
</script>
</walkview>
...
</nasal>


<input>
<keyboard include="Aircraft/Generic/WalkView/walk-view-keys.xml">
...
</keyboard>
...
</input>
</syntaxhighlight>
[[es:Walk View]]

[[Category:Aircraft enhancement]]
[[Category:Nasal]]

Cessna 150/info

2016-08-07T11:31:25Z

Tipunch: aircraft rating

<includeonly>{{infobox aircraft
| name = Cessna 150L
| hangar = fgaddon
| aircraft = c150
| image = C150L.jpg
| image2 = C150l-cockpit.jpg
| type = Civil aircraft/Civil utility aircraft/Trainer aircraft
| config = High wing aircraft/Fixed gear aircraft/Tricycle landing gear aircraft
| propulsion = Propeller aircraft/Single-engine aircraft
| manufacturer = Cessna
| authors = Harald Johnsen
| fdm = JSBSim
| fgname = c150
| status = beta
| status-fdm = 2
| status-systems = 3
| status-cockpit = 4
| status-model = 3
| ready =
| devel-repo = {{github url|user=Harald67|repo=c150}}
| liverydbid =
| forumtid =
| note =
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Cessna 150]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Cessna 150

2016-08-02T17:23:30Z

Tipunch: Adding limits

{{WIP|The C150 is now (20160504) under maintenance by HJ}}

{{:{{PAGENAME}}/info}}
The '''Cessna 150''' is a two-seat tricycle gear general aviation [[aircraft]], that was designed for flight training, touring and personal use.

The Cessna 150 is the third most produced civilian plane ever, with 23,839 aircraft produced. The Cessna 150 was offered for sale in the 150 basic model, Commuter, Commuter II, Patroller and the aerobatic Aerobat models.

== Normal Operating Procedures ==

=== Airspeeds for normal flight operation ===

{| class="wikitable"
! !! Vias
|-
| '''NORMAL / OPTIMUM''' || kts|| MPH
|-
| Best angle of climb '''V'''<sub>X</sub> || 56 || 64
|-
| Best rate of climb '''V'''<sub>Y</sub> || 68 || 78
|-
| Normal rotation speed '''V'''<sub>R</sub> || 50 || 58
|-
| Normal climb speed || 65-75 || 75-85
|-
| Normal landing (no flaps) || 60-70 || 70-80
|-
| Normal landing (full flaps) || 50-60 || 57-69
|-
| Powered landing (no flaps) || 65 || 75
|-
| Powered landing (full flaps) || 55 || 63
|-
| Maximum performance approach || 52 || 60
|-
| Optimum glide speed || 60 || 69
|}

{| class="wikitable"
! !! Vias
|-
| '''LIMITS''' || kts|| MPH
|-
| Never Exceed Speed '''V'''<sub>NE</sub> <br>Do not exceed this speed in any operation || 141 || 162
|-
| Max structural speed '''V'''<sub>NO</sub> <br>Do no exceed this speed except in smooth air and<br>then only with caution || 107 || 123
|-
| Maneuvering speed '''V'''<sub>A</sub> || ||
|-
| 1,600 pounds || 67 || 111
|-
| 1,450 pounds || 93 || 107
|-
| 1,300 pounds || 88 || 101
|-
| Maximum flap extended speed '''V'''<sub>FE</sub> || 85 || 97
|-
| Stall speed V<sub>S</sub> || 47 || 54
|-
| Stall speed (10° Flaps) '''V'''<sub>S1</sub> || 45 || 52
|-
| Stall speed in landing configuration '''V'''<sub>S0</sub> || 42 || 49
|-
| Optimum glide speed || 60 || 69
|}

=== Checklist ===

==== Startup ====
# Carburetor Heat - Cold
# Mixture - Rich
# Primer - As Required
# Ignition switch - Both
# Throttle - Open 1/4 inch
# Propeller Area - Clear
# Starter - On

==== Takeoff ====
# Wing flaps - Up
# Carburetor Heat - Cold
# Throttle - Full "Open"
# Elevator Control - Lift nose wheel at 50 mph
# Climb Speed - 72 MPH until all obstacles are cleared

==== Climb ====
# Air Speed - 75 to 80 MPH
# Power - Full throttle
# Mixture - Rich (unless engine is rough)

==== Cruise ====
# Power - 2000 to 2750 RPM
# Elevator Trim - Adjust
# Mixture - Lean to maximum RPM

==== Approach ====
# Mixture - Rich
# Carburetor Heat - Apply full heat before closing throttle
# Airspeed - 65 to 75 MPH
# Wing Flaps - As desired below 100 MPH
# Airspeed - 60 to 70 MPH with flaps extended

==== Landing ====
# Touch down - Main wheels first
# Landing Roll - Lower nose wheel gently
# Braking - Minimum required

=== Keyboard reminder ===
{| class="keytable"
!Key
!Function
|-
|{{Key press|d}}/{{Key press|Shift|d}}
|Door select
|-
|{{Key press|Ctrl|d}}
|Open/close selected door
|-
|{{Key press|Shift|O}}
|Operate priming pump
|-
|{{Key press|<nowiki>=</nowiki>}}
|Open configuration dialog
|}

== External links ==
* [http://en.wikipedia.org/wiki/Cessna_150 Wikipedia]
* [http://www.cessna150-152club.com/ Cessna 150-152 Club]

{{Cessna}}

Troubleshooting input devices

2016-07-29T12:54:50Z

Tipunch: Category:Joysticks and Yokes

{{Troubleshooting}}
'''Troubleshooting input devices''' will try to help you with input device issues, like with joysticks, yokes and keyboards.

Other than this page, consider visiting the main page for [[input device]]s, and the forum section on hardware, with its [http://forum.flightgear.org/viewtopic.php?f=24&t=2439 FAQs on joysticks].

== Known issues ==
=== Checking the position of your controls ===
Often, when trying to find what's wrong with your controls, you'll need to be sure that the movements are correctly interpreted. For this, the [[Head-up display]] (HUD) will be very helpful, as it has indication of their position. Press {{key press|h}} to enable the HUD and see its wiki page to learn how to interpret it.

=== USB Joystick Fails to Work ===
FlightGear is designed to recognize automatically any USB joystick that it is aware of (has a configuration on file for it). Configuration for USB joysticks is located in the Inputs folder. For example:

Input/Saitek/X45.xml

The name reported by the joystick through the hardware of your system must match the name specified in the configuration file. If the stick identifies itself as

Saitek Saitek X45 Flight Control Stick

but the configuration file specifies

Saitek X45 USB Flight Stick

FlightGear will fail to recognize it.

This happens with some frequency. It has been known for the same stick in a manufacturer's line to report different identifier strings. If you encounter a problem getting your usb stick to be recognized by FlightGear, it is helpful to first check to see

* a configuration file matching the name of your stick exists
* the configuration joystick name matches the name the stick actually reports to your computer

=== USB Joystick exhibits permanent offset / requires repeated recalibration ===
USB Joystick drivers should automatically zero and calibrate the joystick on plugin. Some examples of some types of joystick can be faulty where the fault is exhibited as an offset from the zero position when this process is completed. In Kubuntu this can be fixed for the session by use of the Joystick calibration tool under "Keyboard and Mouse" of "System Settings", or equivalent tools with other distributions, but the problem will recur.

In some cases this may be caused by improper connector seating or other loose connections within the joystick. This can sometimes be remedied by unscrewing the base or other case element to access the circuit board and then reseating the connectors. Also check for faulty solder joints and discrete components bent over onto the circuit board. Before attempting any repair unplug the device and remove any batteries.

=== Configuring CH Products Under Windows Vista ===
The CH Products Yoke and Pedals are among the most popular flight sim controls.
FlightGear provides excellent configuration files for both the Yoke and Pedals manufactured by CH. Windows Vista recognizes and configures the USB versions of these products by default. However, it reports them as "Generic Controls." This creates an issue when FlightGear tries to assign the appropriate controller configuration.

To overcome this you need to edit your Joystick.xml (Filghtgear\Data\Joystick.xml) file to manually assign a configuration file for FlightGear to use.

Eg:

If you have the Yoke as MS-Windows Controller 0 and Pedals as Controller 1 then you include the following lines:
<code>
<js n="0" include="Input/Joysticks/CH/pro-yoke-usb.xml"/>
<js n="1" include="Input/Joysticks/CH/pro-pedals-usb.xml"/>
</code>

=== [Enter] does not work for rudder control ===
First of all: if [0] doesn't work, check if toggling num-lock solves the issue.

Open file ''[[$FG_ROOT]]/keyboard.xml'' with your preferred Editor. and search for those lines (it's close to the top, around line 40):
## uncomment this line to get keycode reports printed to the terminal window
#setlistener("devices/status/keyboard/event", func(n) debug.dump(n.getValues()));
Read the first one and uncomment the second one. To uncomment it remove the leading "#".<br />
Save the file and run FlightGear as usual but with the log-level set to "alarm" (no need to do anything if it wasn't used/changed before!).<br />
When FlightGear is running press [Enter] and immediately after this, without doing anyting on the keyboard, ''click'' on FlightGears log window and you'll see something like this in the last two lines of the log:
{ key: 13, modifier: { meta: 0, shift: 0, alt: 0, super: 0, ctrl: 0, hyper: 0 }, pressed: 1 }
{ key: 13, modifier: { meta: 0, shift: 0, alt: 0, super: 0, ctrl: 0, hyper: 0 }, pressed: 0 }
The first line is for pressing the [Enter]-Key, the second for releasing it. Keep the first number, named "key", in this exaple shown as "13", in mind.

Open file [[$FG_ROOT]]/keyboard.xml again and search for "enter". You should find following:
<key n="10">
<name>Enter</name>
<desc>Move rudder right</desc>
Now replace the value of ''key n='' with the one you had to keep in mind earlier. Save file and run FlightGear to test it.

If the [Enter] key doesn't work at all for some reason one solution would be to assign the key right hand next to (not the num-block-)[0], if it is not already assigned to something else. Procedure is the same as shown with the [Enter] key.

Last thing to do, in any case, disable the keycode reports by replacing the "#" which we removed earlier.

=== Controls returning to a particular position ===
Some laptops have an onboard gravity sensor, that might be detected by FlightGear as a [[joystick]]. You can set FlightGear to ignore this fake-joystick:
# Get your accelerometer's name via the in-sim ''Help > Joystick Information'' dialog.
# Add this name to your <tt>[[$FG_ROOT]]/Input/Joysticks/Accelerometers/accelerometers.xml</tt> file, enclosed by <tt><name></tt> and <tt></name></tt> tags..
# Report your device name to #flightgear at [[IRC|irc.flightgear.org]], or on the [http://forum.flightgear.org/viewforum.php?f=24 hardware support forum], so it can be included in the "official" accelerometer.xml file.

[[Category:Troubleshooting]]
[[Category:Joysticks and Yokes]]

Home made Joystick

2016-07-29T12:49:37Z

Tipunch: Category:Joysticks and Yokes

Many of you will remember [[Howto:Build a yoke in 5 minutes|the 5 minute yoke]], well here is another home made effort for those of us who still fly by mouse.

== You will need ==
* A smooth surfaced (plastic?) hollow ball with just a little larger diameter than your computer mouse's length.
* A wooden dowel about 50mm thick.
* Another dowel which fits comfortably into your hand, or any other object you want which will form the handle.
* Three Lengths of floor board. I prefer them long enough for me to be able to rest my elbow for stability.
* A material which will set hard e.g. plaster of paris, filling foam (like cavity wall insulation) or similar.
* Some superglue or wood glue.

== Method ==
[[File:Screen shot 2012-07-09 at 12.34.49.png|thumb|Lower half-sphere with mouse inside.]]
[[File:Screen shot 2012-07-09 at 12.36.54.png|thumb|Base unit.]]
[[File:Screen shot 2012-07-09 at 12.36.08.png|thumb|Joystick.]]
'''Sizes: I have deliberately not included any measurements because they will depend on the size of your mouse etc.'''

# Carefully cut the ball into 2 equal halves.
# Make sure one half-sphere fits around your mouse without touching, then drill a hole in the centre with a slightly larger diameter than your thin dowel. If the gaps between your mouse and the half-sphere are too great, you can line or pack out the inside of the half-sphere with insulation tape.
#: '''Note:''' If your mouse is wired you will need to make a hole on one edge to allow the wire through.
# In the other half-sphere, drill a hole a little larger than your thin dowel's diameter, then drill a hole exactly the same diameter as the dowel in the centre of the bottom of your large dowel/handle.
# Assemble your base, making sure there will be enough room between the upper surface of the lower half-sphere and the bottom of the uppermost flat surface of the base, to allow some movement of the smaller dowel when it is protruding from the lower surface of the upper half-sphere. The base needs to be wide enough to allow plenty of movement in all directions during use.
# Drill a hole in your base, large enough for the upper half-sphere to swivel in all directions, but not large enough for it to pass through.
# Ascertain how much the smaller dowel needs to be shortened, make allowance for both the bottom of the dowel having to connect with and move the lower half-sphere (yet still clear the top of your mouse), and the other end needing to be pushed into your handle. Cut it to the required length.
# Put some glue into the hole you drilled in the bottom of your handle, then push in the smaller dowel.
# Allow that glue to dry.
# Affix some small nails near the bottom of your handle to act as anchors inside the filler, then place your handle centrally in the upper half-sphere and fill with setting material (plaster or foam etc).
#: '''Optional:''' If you wish to tidy things up a bit, you could trim off some of the upper half-sphere to lessen the amount of filler needed, but be careful not to remove too much, because this might allow the edge to rub/catch in the hole.
# Allow time for the filler to set.

== Operation ==
After you have used your mouse to do the necessary set up for your flight (If you are fortunate enough to have a spare mouse, you can take the necessary actions with the other one provided you have a spare USB slot):

# Place lower half-sphere over your computer mouse, making sure the end of your mouse which normally faces away from you is now facing towards you.
# Place your handle so the upper half-sphere sits centrally in the hole in your base unit, making sure the lower end of the small dowel goes through the hole in the top of the lower half-sphere.
# Make sure your handle is centred, then press 5 on your numpad to centre all your aircrafts control surfaces.

Start your flight.

=== Note ===
It may be necessary to go into your computer's system preferences to slow down the speed of your mouse's actions, but that is optional. You may just get used to it without adjustment.

Have fun.

[[Category:Cockpit building|Joystick, Home made]]
[[Category:Howto|Joystick, Home made]]
[[Category:Joysticks and Yokes]]

User:Johan G/Hardware Review: CH Products controls (Combatstick, throttle and pedals)

2016-07-29T12:48:45Z

Tipunch: Category:Joysticks and Yokes

My setup when at "home",<ref>I'm working to far away from "home", and have not got around to get them to where I'm living while working. I may or may not get around to bring them with me.</ref> are all from CH Products:
* 586 Combatstick
* Pro Throttle
* Pro Pedals
I also use my own configuration file, mainly because I want trim controls to be placed as on the aircraft I fly most (Petar Jedvaj's [[Pilatus PC-9M]]). In the default configuration the top hat rocker switch is used for view control instead of the instead more usual elevator and aileron trim.

== Why I bought them specifically, and some rants ==
I usually plan to stick with my stuff for 5 to 10 years, and want to by high quality gear. In order to do so I did some research on the net comparing mainly ''CH Products'', ''Logitech'', ''Saitec'' and ''Thrustmaster''.

What I was aiming for was a joystick, throttle and pedal setup with enough buttons for a HOTAS setup,<ref name="HOTAS">Hands On Throttle And Stick, in essence you will (almost) never have to hunt for keys on the keyboard.</ref> possibly later getting a throttle quadrant and a yoke.

{{Note|Keep in mind that I had below experiences while doing my research about 1 1/2 year ago; my memory might not be all correct.}}

=== Thrustmaster ===
Thrustmaster, which I looked at first, seem to have joysticks with a good build quality, but scratching under the surface I found that their top of the line joysticks had some problems. There was some mechanical problem which the enthusiast knew about and fixed upon delivery, but there was also some firmware and/or driver bugs with the initial releases that should not have made it out. Even so, their top of the line looked promising and their support seemed great.

=== Saitec ===
Saitec yokes have appeared here far to many times with the exact same problem, a hat rocker very often is wired in a way that makes the view spin around either leftwards (or rightward, I may not remember correctly). The real downer is that they seem to have no interest in fixing the problem, which is either in hardware or software. That's pretty disappointing as their stuff otherwise seem great.

=== Logitech ===
Logitechs lower and mid end joysticks are well renowned, but their try at a high end HOTAS setup (G940?) seems to be plagued. Reading their own support forum was really disappointing. What would be known as the "reversal bug", because moving the joystick forward, then back slightly would cause the output to jump and nearly make formation flying and aiming impossible, was discovered within weeks of release, but the forum posts got unanswered for months. The problem seemed to be in the firmware and was related to the force feedback. Doing anything getting even close to a fix took many months further, and when I was looking at it (November 2010?) a bug fix beta was on the way only to a select few, and only after one compassionate employee seem to have needed to pull some strings to even get permission to do something, as research and development was focusing on another product.

=== CH Products ===
Finally, after seeing that CH Products line, apart from getting USB instead of game port connectors, seemed to not have changed since my early FS 5.1 days and most of all having seen an excellent and thorough six-page review<ref>[http://www.simhq.com/_technology2/technology_014a.html An excellent and thorough six-page review] of CH Products product line.</ref> I settled for them. Also keeping in mind that the joysticks are just a side business to they're real business, industrial joysticks, is helping a bit, as well as that they are a family owned company. They are a bit on the expensive side though, and here in Sweden surprisingly hard to find.

As a side note CH products seem to be the only one of them selling spare parts to their stuff, like cords and potentiometers.

== My experiences ==
=== Installing drivers, or maybe not ===
My biggest error was doing all the configuration work before installing the drivers or simply that I installed the drivers. The stick, throttle and pedals worked well right out of the box, so I configured them up to my liking. But when installing the drivers all button assignments shifted. *sigh* I had to do all the configuration again, but now had the experience of doing that the first time, and the help of their setup and calibration software. js-demo is not for mere mortals that think in decimal.

=== The controls ===
==== The 586 Combatstick ====
If you have small hands, this is not for you. The stick is huge. While my hands are not that small, I sometimes have to change grip while flying in order to trim the aircraft etc. When flying helicopters, which I for the record is very bad at, and I rest my palm on the base the buttons are very far up. For now the throttle wheel and smaller trim wheels on the rather large joystick base is not in use as I have a separate throttle and have mapped the aileron and rudder trim to the top hat rocker and the rudder trim to the cone hat rocker on the throttle. All the buttons and hat rockers have a distinct feel when pressed, while the are easily pressed. The only thing that I would consider worth altering is perhaps a slightly less hard centring spring.

==== The Pro Throttle ====
This is the best thing in the setup. The throttle has about 5 centimeters/ 2 inces of horizontal travel. Having very fine control over the throttle is fantastic as it makes it a lot easier to control both horizontal and vertical speed, specially when I trim up the aircraft properly. The multitude of buttons makes it more easy to set up the controls in a HOTAS<ref name="HOTAS"/> way. Like the joystick, the throttle has a rather large base and all the buttons and hat rockers are distinct, yet light to press.

==== The Pro Pedals ====
The pedal base are a bit on the heavy side, but that helps to keep it in place. The pedals move horizontally and differentially in parallel, when one of them is pushed forward the other moves backward along two "tracks". The pedals are big enough for me, but are placed a bit narrow. Somehow I find toe breaking a bit difficult even though the pedals provide a lot of toe brake travel. I might have to change the braking power in the configuration file.

=== The flying ===
Flying with a setup like this is a dream compared to flying with mouse and keyboard. You have so much greater control. Formation flying, and even just cruising gets a lot easier when you can fine tune the throttle. And crosswind landings get a lot more challenging and fun with pedals. While I neither do it often or well, flying helicopters get much easier with torque pedals and a throttle stick used as collective in addition to a joystick. Since most of the helicopters have autothrottle one will not need a specialised collective/throttle control (though I bet a joystick with twist rudder would be great for that).

==== Trimming ====
Also having realistic trim controls is rewarding. Trimming a plane up makes for almost hands-free flying for short periods, like when looking at the map (or answering the phone). When changing horizontal or vertical speed, remember PAT REA:<ref>As found in [https://www.cnatra.navy.mil/pubs/folder5/T6B/P-764_ch1.PDF P-764, T-6B Primary Contact Flight Training Instruction] (PDF) on the [https://www.cnatra.navy.mil/pubs/ppub_t6b.htm Chief of Naval Air Training (CNATRA) website].</ref>
#Adjust:
##'''P'''ower,
##'''A'''ttitude and
##'''T'''rim.
#Trim:
##'''R'''udder
##'''E'''levator and
##'''A'''ileron.

==== A few tips when flying with pedals ====
Crosswind landings and even taxing never get the same again. Consider training taxing before flying in crosswind. Remember to keep the wing on the wind side low, so the wind does not get under it lifting the wing and making steering a lot more difficult. I tended to weather-wane a lot the first days, pointing the nose towards the wind, usually ending up running off the taxi-/runway.

== Footnotes ==
<references/>

== Some posts at the forum ==
A few post I've made about my setup at the forum, though I pretty much summed them on this page:
* [http://www.flightgear.org/forums/viewtopic.php?p=113005#p113005 Rudder pedals and crosswind touch and goes]
* [http://www.flightgear.org/forums/viewtopic.php?p=113148#p113148 Re: Problem with CH products - joysticks]
* [http://www.flightgear.org/forums/viewtopic.php?p=131915#p131915 Re: Thrustmaster Hotas Warthog with Ubuntu 11.04?]

[[Category:Hardware reviews]]
[[Category:Joysticks and Yokes]]

Talk:Hardware Review: Saitek Pro Flight Cessna controls

2016-07-29T12:47:49Z

Tipunch: perhaps adding this to Category:Joysticks and Yokes

== Hardware review category ==

Please consider adding this review to the [[:Category:Hardware reviews|hardware review category]]. It would be great if all these articles could be found from the same place. ;-)

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 07:42, 30 June 2012 (EDT)

Can we add this page to Category:Joysticks and Yokes ?
[[User:Tipunch|Tipunch]] ([[User talk:Tipunch|talk]])

Bindings

2016-07-29T12:44:09Z

Tipunch: Category:Joysticks and Yokes

'''Bindings''' define what happens when a user:
* [[Howto: Make a clickable panel|Clicks an object]] in the [[scenery]] or in an [[aircraft]].
* Presses a key/button on the keyboard or [[joystick]].
* Clicks a [[menu]] item
* Interacts with a dialog (clicking a button, selecting list entries etc)

In other words, '''bindings''' are simply the term for '''actions''' that are associated with certain '''events''' in FlightGear.

There are different types of events supported by various subsystems, but the resulting action that can be triggered will typically involve either a hard-coded command (a so called fgcommand), or a block of scripted code (using [[Nasal]]). Bindings can be parameterized/customized using properties as arguments that are passed to each binding as a props.Node object.
And Nasal code can also be registered to become available as a dedicated fgcommand.

You can assign multiple bindings to one object, button or key. Bindings may contain [[conditions]] to make them conditionally executed. Each binding must specify a command node with its particular type, see below.

This article gives a small overview of frequently used bindings. Please refer to {{readme file|commands}} for additional information and refer to $FG_SRC/Main/commands.cxx for a complete list of available bindings.

All given codes are examples, found on various places in the [[FlightGear]] package.

== Commands ==
Below are a number of useful commands, some also with their equivalent Nasal call. For the complete list, see {{flightgear file|src/Main/fg_commands.cxx|l=1425}}.

To learn more about adding your own custom fgcommands to the source code, see [[Howto:Add new fgcommands to FlightGear]].

=== dialog-close ===
Closes the active dialog.
<syntaxhighlight lang="xml">
<binding>
<command>dialog-close</command>
</binding>
</syntaxhighlight>
<syntaxhighlight lang="nasal">
fgcommand("dialog-close");
</syntaxhighlight>

=== dialog-show ===
Shows a dialog, which should be present in <tt>''[[$FG_ROOT]]/gui/dialogs''</tt>. In addition, from FlightGear 2.8, dialog files located in <tt>''<aircraft directory>/gui/dialogs''</tt> are also loaded. This should be used for dialogs specific to a certain aircraft.
<syntaxhighlight lang="xml">
<binding>
<command>dialog-show</command>
<dialog-name>location-in-air</dialog-name>
</binding>
</syntaxhighlight>
<syntaxhighlight lang="nasal">
fgcommand("dialog-show", props.Node.new({"dialog-name": "location-in-air"}));
</syntaxhighlight>

; dialog-name : The name of the dialog, as designated in its XML file.

=== nasal ===
[[Nasal]] is frequently used for complicated systems, because it can execute virtually any function and allows running previously-defined Nasal functions.
<syntaxhighlight lang="xml">
<binding>
<command>nasal</command>
<script>b777.afds.input(0,1);</script>
</binding>
</syntaxhighlight>

; script : The Nasal script to execute.
: {{inote|Make sure that the script does not conflict with the {{wikipedia|List of XML and HTML character entity references#Predefined entities in XML|predefined XML entities}}. If it does, you can either put it in a {{wikipedia|CDATA|CDATA section}} or use a non-interpreted version (e.g., <code>&gt;</code> in place of <code>></code>).}}

The {{func link|cmdarg}} function is often useful in these situations to extract offset values passed to the binding. It returns the specific <tt><binding></tt> node, which contains a <tt><setting></tt> node at runtime if used in a joystick axis that represents the value of that axis.

In joysticks and keyboard keys, the script is run in a specific namespace; please see [[Howto:Understand Namespaces and Methods]] for more information on namespaces.

=== property-adjust ===
Increases or decreases a property's value with a given step. Maximum and minimum values are optional.
<syntaxhighlight lang="xml">
<binding>
<command>property-adjust</command>
<property>/autopilot/settings/heading-bug-deg</property>
<step>1</step>
<min>0</min>
<max>360</max>
<wrap>true</wrap>
</binding>
</syntaxhighlight>

; property : Property that will be changed.
; step : Amount to increase or decrease the property's value. Defaults to 0.
; offset : Offset from the property's current value. If '''step''' is not given, this is multiplied by '''factor'''.
; factor : When '''step''' is not given, '''offset''' is multiplied by this. Defaults to 1.
; min : The minimum allowed value. Defaults to "no minimum."
; max : The maximum allowed value. Defaults to "no maximum."
; wrap : If true, the value will be wrapped when it passes min or max; both min and max must be present for this to work. Defaults to false.
; mask : This argument accepts three value: "integer," "decimal" and "all" (default). "integer" means that '''step''' or '''offset * factor''' is applied to the part of the property's current value left of the decimal point first. "decimal" does the same, but applies it to the prt to the right of the decimal point. "all" simply applies it to the whole number. This parameter does not seem to affect the resulting new value of the property, and so is not needed.

=== property-assign ===
One of the most important commands. It sets a property to a predefined value.
<syntaxhighlight lang="xml">
<binding>
<command>property-assign</command>
<property>/autopilot/settings/target-speed-kt</property>
<value>0</value>
</binding>
</syntaxhighlight>

=== property-cycle ===
Cycles between a list of values and assigns one to a property. The value-list can vary in length. If the current value is "value1", it will change to "value2"; if it is "value2", it will change to "value3", and so on, wrapping around the end. If the current value is not in the list, it will jump to the first one.
<syntaxhighlight lang="xml">
<binding>
<command>property-cycle</command>
<property>/autopilot/autobrake/setting</property>
<value type="string">ARM</value>
<value type="string">DISARM</value>
<value type="string">OFF</value>
</binding>
</syntaxhighlight>
As of May 2013, the command supports additional behaviours to simplify use with the new [[Knob_/_slider_animation|knob and slider animations]]. The wrapping behaviour can be disabled by setting <wrap>0</wrap>, and the command uses the 'offset' argument to select a direction of movement. This means a property-cycle bound to a multi-position knob will function as expected for movement in both directions.

=== property-interpolate ===
Interpolates to a value with a given rate of change (per second).
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<value type="double">0</value>
<rate>0.5</rate>
</binding>
</syntaxhighlight>

Instead of using <rate>, one could use <time>, to specify the time (in seconds) it takes to go to the new value, independent of the current value.
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<value type="double">0</value>
<time>2</time>
</binding>
</syntaxhighlight>

You can also interpolate to a value given by a property.
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<property>/controls/flight/default-aileron-trim</property>
<rate>0.5</rate>
</binding>
</syntaxhighlight>

=== property-multiply ===
Multiply the value of a property by a given factor.
<syntaxhighlight>
<binding>
<command>property-multiply</command>
<property>/controls/flight/aileron</property>
<factor>0.5</factor>
<min>-1</min>
<max>1</max>
<mask>all</mask>
<wrap>true</wrap>
</binding>
</syntaxhighlight>
*'''factor:''' the amount to multiply by.
*'''min:''' minimum value.
*'''max:''' maximum value.
*'''mask:'''
** '''integer:''' mutiply only left of the decimal point.
** '''decimal:''' multiply only the right of the decimal point.
** '''all:''' multiply the entire value.
*'''wrap:''' true if the value should be wrapped if it passes min/max. It is required to set both min and max in that case.

=== property-randomize ===
Assigns a random value (between min and max) to a property.
<syntaxhighlight lang="xml">
<binding>
<command>property-randomize</command>
<property>/orientation/pitch-deg</property>
<min>0</min>
<max>360</max>
</binding>
</syntaxhighlight>

=== property-scale ===
Set the value of a property based on an axis, often used in [[joystick]] configuration files.
<syntaxhighlight lang="xml">
<binding>
<command>property-scale</command>
<property>/controls/flight/aileron</property>
<offset>0.001</offset>
<factor>-1</factor>
<power>3</power>
</binding>
</syntaxhighlight>

* '''offset:''' the offset to shift by, before applying the factor.
* '''factor:''' the factor to multiply by (use negative to reverse).
* '''squared:''' if true will square the resulting value (same as power=2).
* '''power:''' the resulting value will be taken to the power of this integer value (overrides squared).

Remember: <tt>((property+offset)*factor)^power=result</tt>

=== property-swap ===
Swaps the values of two properties, useful for radio panels.
<syntaxhighlight lang="xml">
<binding>
<command>property-swap</command>
<property>/instrumentation/comm/frequencies/selected-mhz</property>
<property>/instrumentation/comm/frequencies/standby-mhz</property>
</binding>
</syntaxhighlight>

=== property-toggle ===
Toggles the value of a property on each click, between true (1) and false (0).
<syntaxhighlight lang="xml">
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
</binding>
</syntaxhighlight>
Or - if defined - it toggles between two custom values.
<syntaxhighlight lang="xml">
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
<value>2</value>
<value>3</value>
</binding>
</syntaxhighlight>

===request-metar ===
{{cquote|
<syntaxhighlight lang="nasal">
fgcommand("request-metar", props.Node.new({"path": "/foo/mymetar", "station": "LOWI"}));
</syntaxhighlight>

If you pass an existing path, the station ID will be updated, and if you pass the same station ID as before, no additional request is made. As usual for metar-properties, there's a time-to-live and valid flags you can check, and the metar refreshes automatically every 900 seconds. You can also write to the station ID directly to change station, update the time-to-live, and wait for the valid signal.

There's also an unregister command ('clear-metar') to cancel the binding into the property tree.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38372.html|title=<nowiki>[Flightgear-devel] Requesting arbitrary metar</nowiki>|author=James Turner|date=Sun, 23 Sep 2012 08:56:48 -0700}}</ref>|James Turner}}
<references/>

== Related content ==
* {{readme file|commands}}
* [[Howto:Make a clickable panel]]
* [[Howto:Reassign keyboard bindings]]

[[Category:Development]]
[[Category:XML]]
[[Category:FlightGear keyboard]]
[[Category:Joysticks and Yokes]]

Joystick xml library

2016-07-29T12:39:09Z

Tipunch: Category:Joysticks and Yokes

This is a master page linking to pages containing joystick xml codes for various specialised functions. Note that there is an equivalent forum topic with the same aim (see Related content) as well as a dropbox page extracted from the forum. However, the wiki offers the potential to organise the codes in a hierarchical manner, and improvements can be made in a collective manner not possible as a forum topic. You are well advised to check out both.

* [[Joystick Autopilot Bindings]] Control the Bendix/KAP140 and the CENTURYIII autopilots with the joystick

NB: If you want to introduce more code, make a new wiki page and link rather than pasting code directly in this page.

== Related content ==
* [http://forum.flightgear.org/viewtopic.php?f=24&t=12363 Joystick xml codes Library project] Forum topic with a similar objective

== External link ==
* [https://dl.dropboxusercontent.com/u/11151437/STICK%20XML%20LIBRARY/INDEX.html Dropbox library] Collection of short snippets for particular tasks, complete configuration files for particular joysticks, and various general aviation related links

[[Category:Documentation]]
[[Category:Joysticks and Yokes]]

Joystick/Sony-PLAYSTATION(R)3-Controller

2016-07-29T12:38:19Z

Tipunch: Category:Joysticks and Yokes

<syntaxhighlight lang="xml">

<?xml version="1.0"?>

<PropertyList>
<name type="string">Sony PLAYSTATION(R)3 Controller</name>
<axis>
<desc type="string">Rudder</desc>
<binding>
<command type="string">property-scale</command>
<property type="string">/controls/flight/rudder</property>
<dead-band type="double">0</dead-band>
<factor type="double">1</factor>
<offset type="double">0</offset>
</binding>
</axis>
<axis n="2">
<desc type="string">Aileron</desc>
<binding>
<command type="string">property-scale</command>
<property type="string">/controls/flight/aileron</property>
<dead-band type="double">0</dead-band>
<factor type="double">1</factor>
<offset type="double">0</offset>
</binding>
</axis>
<axis n="3">
<desc type="string">Elevator</desc>
<binding>
<command type="string">property-scale</command>
<property type="string">/controls/flight/elevator</property>
<dead-band type="double">0</dead-band>
<factor type="double">-1</factor>
<offset type="double">0</offset>
</binding>
</axis>
<axis n="12">
<desc>Throttle</desc>
<direction>forward</direction>
<binding>
<command>nasal</command>
<script>controls.throttleAxis(1)</script>

</binding>
<dead-band type="double">0</dead-band>
</axis>
<button>
<desc type="string">Brakes</desc>
<repeatable type="string">false</repeatable>
<binding>
<command type="string">nasal</command>
<script type="string">controls.applyBrakes(1);</script>
</binding>
<mod-up>
<binding>
<command type="string">nasal</command>
<script type="string">controls.applyBrakes(0);</script>
</binding>
</mod-up>
</button>
<button n="2">
<desc type="string">Elevator Trim Up</desc>
<binding>
<command type="string">nasal</command>
<script type="string">controls.elevatorTrim(-1);</script>
</binding>
<repeatable type="double">1</repeatable>
</button>
<button n="4">
<desc type="string">View Up</desc>
<binding>
<command type="string">property-adjust</command>
<property type="string">/sim/current-view/goal-pitch-offset-deg</property>
<step type="string">20.0</step>
</binding>
</button>
<button n="5">
<desc type="string">View Right</desc>
<binding>
<command type="string">property-adjust</command>
<property type="string">/sim/current-view/goal-heading-offset-deg</property>
<step type="string">-30.0</step>
</binding>
</button>
<button n="6">
<desc type="string">View Down</desc>
<binding>
<command type="string">property-adjust</command>
<property type="string">/sim/current-view/goal-pitch-offset-deg</property>
<step type="string">-20.0</step>
</binding>
</button>
<button n="7">
<desc type="string">View Left</desc>
<binding>
<command type="string">property-adjust</command>
<property type="string">/sim/current-view/goal-heading-offset-deg</property>
<step type="string">30.0</step>
</binding>
</button>
<button n="9">
<desc type="string">View Increase</desc>
<binding>
<command type="string">nasal</command>
<script type="string">view.increase(0.75);</script>
</binding>
<repeatable type="double">1</repeatable>
</button>
<button n="10">
<desc type="string">FGCom PTT</desc>
<repeatable type="string">false</repeatable>
<binding>
<command type="string">nasal</command>
<script type="string">controls.ptt(1);</script>
<module type="string">__js0</module>
<offset type="double">1</offset>
</binding>
<mod-up>
<binding>
<command type="string">nasal</command>
<script type="string">controls.ptt(0);</script>
<module type="string">__js0</module>
<offset type="double">1</offset>
</binding>
</mod-up>
</button>
<button n="11">
<desc type="string">Brakes</desc>
<repeatable type="string">false</repeatable>
<binding>
<command type="string">nasal</command>
<script type="string">controls.applyBrakes(1);</script>
</binding>
<mod-up>
<binding>
<command type="string">nasal</command>
<script type="string">controls.applyBrakes(0);</script>
</binding>
</mod-up>
</button>
<button n="12">
<desc type="string">Elevator Trim Down</desc>
<binding>
<command type="string">nasal</command>
<script type="string">controls.elevatorTrim(1);</script>
</binding>
<repeatable type="double">1</repeatable>
</button>
<button n="13">
<desc type="string">View Cycle Forwards</desc>
<binding>
<command type="string">nasal</command>
<script type="string">view.stepView(1);</script>
</binding>
<repeatable type="double">0</repeatable>
</button>
<button n="14">
<desc type="string">Elevator Trim Up</desc>
<binding>
<command type="string">nasal</command>
<script type="string">controls.elevatorTrim(-1);</script>
</binding>
<repeatable type="double">1</repeatable>
</button>
<button n="15">
<desc type="string">View Cycle Backwards</desc>
<binding>
<command type="string">nasal</command>
<script type="string">view.stepView(-1);</script>
</binding>
<repeatable type="double">0</repeatable>
</button>
</PropertyList>

</syntaxhighlight>
[[Category:Joysticks and Yokes]]

Joystick/WaillyDX7s

2016-07-29T12:37:13Z

Tipunch: Category:Joysticks and Yokes

Hardware:

# PPM to USB Adapter ID 06f7:0003 Wailly Technology Ltd USB->Din 4 Adaptor
# Spektrum DX7s 7-channel RC Transmitter

<code>/usr/share/games/flightgear/Input/Joysticks/Default/joystick.xml</code>
<syntaxhighlight lang=xml>
<?xml version="1.0"?>

<PropertyList>
<axis n="1">
<desc>Aileron</desc>
<direction>right</direction>
<binding>
<command>property-scale</command>
<property>/controls/flight/aileron</property>
<offset type="double">0</offset>
<factor type="double">1</factor>
<power type="int">1</power>
</binding>
<dead-band type="double">0</dead-band>
</axis>
<axis n="2">
<desc>Elevator</desc>
<direction>down/forward</direction>
<binding>
<command>property-scale</command>
<property>/controls/flight/elevator</property>
<factor type="double">1</factor>
<power type="int">1</power>
</binding>
<dead-band type="double">0</dead-band>
</axis>
<axis n="5">
<desc>Rudder</desc>
<direction>right</direction>
<binding>
<command>property-scale</command>
<property>/controls/flight/rudder</property>
<factor type="double">1</factor>
<power type="int">1</power>
</binding>
<dead-band type="double">0</dead-band>
</axis>
<axis n="4">
<desc>Throttle</desc>
<direction>forward</direction>
<binding>
<command>nasal</command>
<script>controls.throttleAxis()</script>
<factor type="double">1</factor>
</binding>
<dead-band type="double">0</dead-band>
</axis>
<name type="string">WAILLY PPM</name>
</PropertyList>

</syntaxhighlight>

[[Category:XML]]
[[Category:Joysticks and Yokes]]

Input device

2016-07-29T12:28:14Z

Tipunch: Category:Joysticks and Yokes

Could you imagine a pilot in his or her [[:Category:Cessna|Cessna]] controlling the machine with a keyboard alone? For getting the proper feeling of flight you will need a '''joystick/yoke''' plus [[rudder]] pedals, right?

FlightGear has integrated joystick support, which automatically detects any joystick, yoke, or pedals attached. Just try it! If this does work for you, lean back and be happy! You can see what FlightGear has detected your joystick as in the Help > Joystick Configuration dialog from the [[menu]].

Unfortunately, for the above mentioned versatility, chances are your joystick does not work out of the box. This article explains you how to make FlightGear recognise your device

== Joystick or yoke? ==
{| cellpadding="4" cellspacing="0" align="right" style="clear:right; background:#fafafa; font-size: 85%; border: 1px solid #CCCCCC;"
|-
| [[File:CH Products Fighterstick USB.jpg|x199px|CH Products Fighterstick USB]]
| [[File:Saitek Pro Flight Cessna Yoke front.jpg|300px|Saitek Pro Flight Cessna Yoke]]
|-
| CH Products Fighterstick USB
| Saitek Pro Flight Cessna Yoke
|}
The two most common control devices on aircraft are the joystick (left picture) and yoke (right picture). Joysticks can be found on military fighters, helicopters and Airbus [[airliner]]s, while yokes are used on almost all other fixed wing aircraft, including Boeing airliners.

Joysticks are generally a lot cheaper, starting at $10. Yokes start at $100. When you are new to flightsimming, buying a cheap (ca. $20) joystick might be a good way to find out if it's something for you.

The following table should help you decide which one is best suited for you:
{| class="wikitable"
!
! Joystick
! Yoke
|-
! style="text-align:left;" | Price
| $10+
| $100+
|-
! style="text-align:left;" | General aviation
| {{no}}
| {{yes}}
|-
! style="text-align:left;" | Helicopter
| {{yes}}
| {{no}}
|-
! style="text-align:left;" | Fighters
| {{yes}}
| {{no}}
|-
! style="text-align:left;" | Airbus
| {{yes}}
| {{no}}
|-
! style="text-align:left;" | Boeing
| {{no}}
| {{yes}}
|}

Some reviews of flight simulation hardware can be found in [[:Category:Hardware reviews]].

== Built-in joystick support ==
In order for joystick auto-detection to work, a joystick bindings xml file must exist for each joystick. This file describes what axes and buttons are to be used to control which functions in FlightGear. The associations between functions and axes or buttons are called "bindings".

FlightGear includes a large number of such bindings files for a variety of manufacturers. Chances are high that your joystick will be recognised straight away, so let's try that first. You can confirm whether it was recognised by looking in the <tt>Help > Joystick Configuration</tt> dialog. "Used for" should contain a name/description of your joystick. It will contain "default" when FlightGear did not recognise your joystick.

Most of the time when your joystick is not recognised, it is because of a missing name definition in the respective bindings file. Because FlightGear is used on all kind of operating systems, names vary a lot. You can find the files under <tt>[[$FG_ROOT]]/Input/Joysticks/</tt> (despite the name, yokes and pedals are also found here!). For example, if you have a CH Products joystick, look in the folder <tt>[[$FG_ROOT]]/Input/Joysticks/CH</tt> for a file that might work for your joystick. When such a file exists, do the following:
# Launch FlightGear with the joystick connected.
# Look under Help > Joystick Configuration and check the name behind "Joystick #0:".
# Open your joystick's bindings file in a XML editor and add the following code to the file, below the already-present <code><name></code> tags.
# <syntaxhighlight lang="xml"><name>The EXACT name you found under step 2; including spaces, capitals etc.</name></syntaxhighlight>
# Please report this name [http://forum.flightgear.org/viewforum.php?f=24 at our forum], so it can be added to the official file (and next releases).

Please note that the latest config files are always to be found at {{fgdata file|Input/Joysticks}}. This link may contain additional binding files that were not included in the latest stable release.

If there is no file for your joystick, you will have to create such a file. We will discuss that in [[Joystick#Writing or editing joystick binding xml files|a later section]], by cutting and pasting bindings from the examples that are included with FlightGear.

=== Multiple devices on Windows ===
In case you have two USB devices (for instance a yoke plus pedals) to a Windows computer, there may be cases, where the same driver name is reported twice. In this case, you can get at least the yoke to work by assigning it number 0 (out of 0 and 1), by adding a line to <tt>[[$FG_ROOT]]/joystick.xml</tt> like:
<syntaxhighlight lang="xml"><js n="0" include="Input/Joysticks/Saitek/ST290-Pro.xml"/></syntaxhighlight>
if you also have pedals (or another joystick), just add more lines, similar to:
<syntaxhighlight lang="xml"><js n="1" include="Input/Joysticks/Saitek/Pro-Flight-Rudder-Pedals.xml"/></syntaxhighlight>

To make sure that the first input device is indeed the yoke, rotate the yoke ([[aileron]] control) and observe the Help > Joystick Configuration dialog. If the aileron value does not change, you have to make the yoke the preferred device first. For doing so, enter the Windows "Control panel", open "Game controllers" and select the "Advanced" button. Here you can select the yoke as the "Preferred" device. Afterwards you can check that assignment by restarting FlightGear. The yoke should now control the aileron.

== Adding support for your joystick ==
=== Verifying your joystick is working ===
==== Linux ====
Reboot your system and immediately enter on the [[command line]]

<syntaxhighlight lang="bash">
dmesg | grep Joystick
</syntaxhighlight>

which pipes the boot message to grep which then prints every line in the boot message that contains the string “Joystick”. When you do this with a Saitek joystick attached, you will see a line similar to this one:

<syntaxhighlight>
input0: USB HID v1.00 Joystick [SAITEK CYBORG 3D USB] on usb2:3.0
</syntaxhighlight>

This line tells us that a joystick has identified itself as SAITEK CYBORG 3D USB to the operating system. It does not tell us that the joystick driver sees your joystick. You can verify that the joystick driver sees the joystick by entering:

<syntaxhighlight>
js_demo
</syntaxhighlight>

If your joystick is not recognized by the driver, you may have to manually load the joystick device module with the command:

<syntaxhighlight>
modprobe joydev
</syntaxhighlight>

==== Windows ====
Go to <tt>Start > Control Panel > Game Controller</tt> and see whether the dialog displays (and responses) on your joystick.

=== Confirming that the driver recognizes your joystick ===
FlightGear ships with a utility called js_demo. It will report the number of joysticks attached to a system, their respective "names" and their capabilities. Under Linux, you can run js_demo from the folder /FlightGear/bin as follows:

<syntaxhighlight lang="bash">
$ cd /usr/local/FlightGear/bin
$ js_demo
</syntaxhighlight>

Under Windows, open a command shell (<tt>Start > All Programs > Accessories > Command Prompt</tt>), go to the FlightGear binary folder and start the program as follows (given FlightGear is installed under <tt>C:/Program Files/Flightgear</tt>)

<syntaxhighlight lang="dos">
C:
cd /Program Files/FlightGear/bin/win32
js_demo.exe
</syntaxhighlight>



On our system, the first few lines of output are (stop the program with C if it is quickly scrolling past your window!) as follows:

<syntaxhighlight>
Joystick test program.
Joystick 0: “CH PRODUCTS CH FLIGHT SIM YOKE USB ”
Joystick 1: “CH PRODUCTS CH PRO PEDALS USB”
Joystick 2 not detected
Joystick 3 not detected
Joystick 4 not detected
Joystick 5 not detected
Joystick 6 not detected
Joystick 7 not detected
+——————–JS.0———————-+——————–JS.1———————-+
| Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 Ax:6 | Btns Ax:0 Ax:1 Ax:2 |
+———————————————-+———————————————-+
| 0000 +0.0 +0.0 +1.0 -1.0 -1.0 +0.0 +0.0 . | 0000 -1.0 -1.0 -1.0 . . . . . |
</syntaxhighlight>

First note that js demo reports which number is assigned to each joystick recognized by the driver. Also, note that the “name” each joystick reports is also included between quotes. We will need the names for each bindings file when we begin writing the binding xml files for each joystick.

=== Identifying the numbering of axes and buttons ===
Axis and button numbers can be identified using js demo as follows. By observing the output of js demo while working your joystick axes and buttons you can determine what axis and button numbers are assigned to each joystick axis and button. It should be noted that numbering generally starts with zero.

The buttons are handled internally as a binary number in which bit 0 (the least significant bit) represents button 0, bit 1 represents button 1, etc., but this number is displayed on the screen in hexadecimal notation, so:

* 0001 ⇒ button 0 pressed
* 0002 ⇒ button 1 pressed
* 0004 ⇒ button 2 pressed
* 0008 ⇒ button 3 pressed
* 0010 ⇒ button 4 pressed
* 0020 ⇒ button 5 pressed
* 0040 ⇒ button 6 pressed
* ... etcp to ...
* 8000 ⇒ button 15 pressed
* ... and ...
* 0014 ⇒ buttons 2 and 4 pressed simultaneously
* ... etc.

For Linux users, there is another option for identifying the “name” and the numbers assigned to each axis and button. Most Linux distributions include a very handy program, “jstest”. With a CH Product Yoke plugged into the system, the following output lines are displayed by jstest:

<syntaxhighlight lang="bash">
jstest /dev/js3
Joystick (CH PRODUCTS CH FLIGHT SIM YOKE USB ) has 7 axes and 12 buttons. Driver version is 2.1.0
Testing…(interrupt to exit)
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 Buttons: 0:off 1:off 2:off 3:on 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off
</syntaxhighlight>

Note the “name” between parentheses. This is the name the system associates with your joystick.

When you move any control, the numbers change after the axis number corresponding to that moving control and when you depress any button, the “off” after the button number corresponding to the button pressed changes to “on”. In this way, you can quickly write down the axes numbers and button numbers for each function without messing with binary.

In most modern repositories, there is a graphical version of this program, called "jstest-gtk", where you are given a list of attached devices to choose from, and then get a graphical representation of all axes and buttons.

=== Calibration ===
For many/most joysticks this step might not be necessary. If either, the centre position of the joystick does not yield near-zero values for relevant axes, or if the maximum value for an axis cannot be reached, or is reached too early, you need to calibrate the joystick. (Note that some calibration problems can be fixed with the flighgear joystick configuration files, but not all, e.g. if the maximum value is reached too early)

==== Linux ====
The program "jscal" (install from repositories if not already available on your system) provides a calibration routine for joysticks. You need to know or find out the device name of your joystick (usually /dev/js0 or /dev/input/js0 - instead of 0 a different number might need to be used, look at output of js_demo to figure out which). For example to calibrate the joystick with device name /dev/input/js0, execute
<syntaxhighlight lang="bash">jscal -c /dev/input/js0
</syntaxhighlight>
and follow instructions.
The calibration is retained until the joystick is unplugged, or the computer rebooted. In order to save it for future use, execute
<syntaxhighlight lang="bash">jscal -p /dev/input/js0
</syntaxhighlight>
which will print the command that needs to be entered to restore the calibration, for example
<syntaxhighlight lang="bash">jscal -s 6,1,0,8171,8171,65936,65374,1,0,8166,8166,65928,65494,1,0,128,128,4194176,4227201,1,0,128,128,4194176,4227201,1,0,0,0,536854528,536854528,1,0,0,0,536854528,536854528 /dev/input/js0
</syntaxhighlight>
Copy the command you obtained into your startup script in order to restore calibration automatically.

Recent versions of jscal have this simplified, you can store and restore your calibration settings.
After calibration store the settings:
<syntaxhighlight lang="bash">jscal-store /dev/input/js0
</syntaxhighlight>

Then in your startup script recall the settings for the given device:
<syntaxhighlight lang="bash">jscal-restore /dev/input/js0
</syntaxhighlight>

However if you have multiple controllers connected, they might be renumbered on pluging/repluging. Best way to insure you get the correct calibration is to create a custom '''udev''' rule-set that you put into /etc/udev/rules.d/00-joystick.rules, similar to the following example:
<syntaxhighlight lang="bash">
#joystick rules to make the names persistent and reload the stored calibration profile
ACTION!="add|change", GOTO="joystick_end"
SUBSYSTEM!="input", GOTO="joystick_end"

KERNEL=="js*", ATTRS{idProduct}=="a02f", ATTRS{idVendor}=="12bd", SYMLINK+="input/joystick" RUN+="/etc/udev/scripts/joycal.sh"
KERNEL=="js*", ATTRS{name}=="Logitech Logitech Racing Wheel", SYMLINK+="input/logiwheel" RUN+="/etc/udev/scripts/wheelcal.sh"

LABEL="joystick_end"
</syntaxhighlight>

Then the scripts called would be as follows:
*/etc/udev/scripts/joycal.sh:
<syntaxhighlight lang="bash">
#!/bin/sh
jscal-restore /dev/input/joystick
</syntaxhighlight>
*/etc/udev/scripts/wheelcal.sh
<syntaxhighlight lang="bash">
#!/bin/sh
jscal-restore /dev/input/logiwheel
</syntaxhighlight>

Now each time you plug/replug your joysticks/controllers they will get the persistent device names, and will get the correct calibration profile restored.

The calibration is even more comfortable using the program "jstest-gtk", also available from most repositories. Starting this you are given a list of all attached joysticks with their device names. Pick the one you wish to inspect or calibrate and click 'Properties', then calibrate. This calibration tool offers the possibility to fine-tune the calibration by editing the numbers. The program manipulates the same internals as jscal so you can use jscal to save the calibration information for later use, as before.

=== Writing or editing joystick binding xml files ===
At this point, you have confirmed that the operating system and the joystick driver both recognize your joystick(s). You also know of several ways to identify the joystick “name” your joystick reports to the driver and operating system. You will need a written list of what control functions you wish to have assigned to which axis and button and the corresponding numbers.

Make the following table from what you learned from js demo or jstest above (pencil and paper is fine). Here we assume there are 5 axes including 2 axes associated with the hat.

{| class="prettytable"
! align="center" bgcolor="#EFEFEF" | Axis
! align="center" bgcolor="#EFEFEF" | Button
|-
|elevator = 0
|view cycle = 0
|-
|rudder = 1
|all brakes = 1
|-
|aileron = 2
|up trim = 2
|-
|throttle = 3
|down trim = 3
|-
|leftright hat = 4
|extend flaps = 4
|-
|foreaft hat = 5
|retract flaps = 5
|-
|
|decrease RPM = 6
|-
|
|increase RPM = 7
|}

We will assume that our hypothetical joystick supplies the “name” QUICK STICK 3D USB to the system and driver. With all the examples included with FlightGear, the easiest way to get a so far unsupported joystick to be auto detected, is to edit an existing binding xml file. Look at the xml files in the sub-folders of '''/FlightGear/Input/Joysticks/'''. After evaluating several of the xml binding files supplied with FlightGear, we decide to edit the file <tt>[[$FG_ROOT]]/Input/Joysticks/Saitek/Cyborg-Gold-3d-USB.xml</tt>.

This file has all the axes functions above assigned to axes and all the button functions above assigned to buttons. This makes our editing almost trivial.

Before we begin to edit, we need to choose a name for our bindings xml file, create the folder for the QS joysticks, and copy the original xml file into this directory with this name.

<syntaxhighlight lang="bash">
$ cd /usr/local/FlightGear/Input/Joysticks
$ mkdir QS
$ cd QS
$ cp /usr/local/FlightGear/Input/Joysticks/Saitek/
Cyborg-Gold-3d-USB.xml QuickStick.xml
</syntaxhighlight>

Here, we obviously have supposed a Linux/UNIX system with FlightGear being installed under '''/usr/local/FlightGear'''. For a similar procedure under Windows with FlightGear being installed under C:/Program Files/FlightGear, open a command shell and type

<syntaxhighlight lang="dos">
C:
cd /Program Files/FlightGear/Input/Joysticks
mkdir QS
cd QS
copy /Program Files/FlightGear/Input/Joysticks/Saitek/
Cyborg-Gold-3d-USB.xml QuickStick.xml
</syntaxhighlight>

Next, open QuickStick.xml with your favorite editor. Before we forget to change the joystick name, search for the line containing <name>. You should find the line

<syntaxhighlight lang="xml"><name>SAITEK CYBORG 3D USB</name></syntaxhighlight>

and change it to

<syntaxhighlight lang="xml"><name>QUICK STICK 3D USB</name></syntaxhighlight>

This line illustrates a key feature of xml statements. They begin with a <tag> and end with a </tag>.

You can now compare your table to the comment table at the top of your file copy. Note that the comments tell us that the Saitek elevator was assigned to axis 1. Search for the string

<syntaxhighlight lang="xml"><axis n="1"></syntaxhighlight>

and change this to

<syntaxhighlight lang="xml"><axis n="0"></syntaxhighlight>

Next, note that the Saitek rudder was assigned to axis 2. Search for the string

<syntaxhighlight lang="xml"><axis n="2"></syntaxhighlight>

and change this to

<syntaxhighlight lang="xml"><axis n="1"></syntaxhighlight>

Continue comparing your table with the comment table for the Saitek and changing the axis numbers and button numbers accordingly. Since QUICKSTICK USB and the Saitek have the same number of axes but different number of buttons, you must delete the buttons left over. Just remember to double check that you have a closing tag for each opening tag or you will get an error using the file.

Finally, be good to yourself (and others when you submit your new binding file to a FlightGear developers or users archive!), take the time to change the comment table in the edited file to match your changed axis and button assignments. The new comments should match the table you made from the js demo output. Save your edits.

Several users have reported that the numbers of axes and buttons assigned to functions may be different with the same joystick under Windows and Linux. The above procedure should allow one to easily change a binding xml file created for a different operating system for use by their operating system.

You can tell how FlightGear has interpretted your joystick setup by selecting <tt>Help > Joystick Configuration</tt> from the menu.

== Joystick support via .fgfsrc entries ==
Fortunately, there is a tool available now, which takes most of the burden from the average user who, maybe, is not that experienced with XML, the language which these files are written in.

For configuring your joystick using this approach, open a command shell (command prompt under windows, to be found under Start|All programs|Accessories). Change to the directory <tt>[[$FG_ROOT]]/bin</tt> via e.g. (modify to your path)

<syntaxhighlight lang="dos">cd C:/Program Files/FlightGear/bin</syntaxhighlight>

and invoke the tool fgjs via

<syntaxhighlight lang="bash">./fgjs --fg-root=$FG_ROOT</syntaxhighlight>

on a UNIX/Linux machine, or via

<syntaxhighlight lang="dos">fgjs --fg-root=$FG_ROOT</syntaxhighlight>

on a Windows machine. The program will tell you which joysticks, if any, were detected. Now follow the commands given on screen, i.eṁove the axis and press the buttons as required. Be careful, a minor touch already “counts” as a movement. Check the reports on screen. If you feel something went wrong, just re-start the program.

After you are done with all the axis and switches, the directory above will hold a file called fgfsrc.js. If the FlightGear base directory FlightGear does not already contain an options file .fgfsrc (under UNIX)/system.fgfsrc (under Windows) mentioned above, just copy

'''fgfsrc.js''' into '''.fgfsrc''' (UNIX)/'''system.fgfsrc''' (Windows)

and place it into the directory FlightGear base directory FlightGear. In case you already wrote an options file, just open it as well as fgfsrc.js with an editor and copy the entries from fgfsrc.js into .fgfsrc/system.fgfsrc. One hint: The output of fgjs is UNIX formatted. As a result, Windows Editor may not display it the proper way. I suggest getting an editor being able to handle UNIX files as well, for example [https://notepad-plus-plus.org/ Notepad++]. 

The the axis/button assignment of fgjs should, at least, get the axis assignments right, its output may need some tweaking. There may be axes moving the opposite way they should, the dead zones may be too small etc. For instance, I had to change

<syntaxhighlight>
--prop:/input/joysticks/js[1]/axis[1]/binding/factor=-1.0
</syntaxhighlight>

into

<syntaxhighlight>
--prop:/input/joysticks/js[1]/axis[1]/binding/factor=1.0
</syntaxhighlight>

(USB CH Flightsim Yoke under Windows XP). Thus, here is a short introduction into the assignments of joystick properties.

Basically, all axes settings are specified via lines having the following structure:

<syntaxhighlight>
--prop:/input/joysticks/js[n]/axis[m]/binding/command=property-scale
--prop:/input/joysticks/js[n]/axis[m]/binding/property=/controls/steering option
--prop:/input/joysticks/js[n]/axis[m]/binding/dead-band=db
--prop:/input/joysticks/js[n]/axis[m]/binding/offset=os
--prop:/input/joysticks/js[n]/axis[m]/binding/factor=fa
</syntaxhighlight>

where

{| class="prettytable"
! align="center" bgcolor="#EFEFEF" |
! align="center" bgcolor="#EFEFEF" |
|-
|n
|number of device (usually starting with 0)
|-
|m
|number of axis (usually starting with 0)
|-
|steering option
|elevator, aileron, rudder, throttle, mixture, pitch
|-
|dead-band
|range, within which signals are discarded; useful to avoid jittering for minor yoke movements
|-
|offset
|specifies, if device not centered in its neutral position
|-
|factor
|controls sensitivity of that axis; defaults to +1, with a value of -1 reversing the behavior
|}

You should be able to at least get your joystick working along these lines. Concerning all the finer points, for instance, getting the joystick buttons working, John Check has written a very useful README being included in the base package to be found under '''FlightGear/Docs/Readme/Joystick.html'''. In case of any trouble with your input device, it is highly recommended to have a look into this document.

== More about programming joystick XML files ==
=== General tips ===
* When testing a new xml file it is best to start FlightGear via a command window (rather than the GUI interface). Any error messages will then be displayed in the terminal. Error messages will give both a message and a line number, helping you pinpoint any errors.
* Errors can be detected on initial startup or at runtime. Both types of errors will be displayed in the terminal.
* One of the most common errors is including a character that makes XML choke. Such characters include<br>& < --<br>These characters will cause problems even if simply included in comments or within scripts.
* If your scripts contain any of these characters, you have to enclose the scripts in <script><![CDATA[...]]></script>. Alternatively, you can 'escape' the characters, ie "<" becomes "&lt;".
* You can reload your edited joystick file without restarting FlightGear by selecting "Debug" > "Reload Input" from the main simulator window.
* You can find many examples of different ways to program joysticks simply by examining the joystick xml files that are packaged with FlightGear. See the directory FlightGear/data/input/joysticks
* Many advanced functions can be programmed using the Nasal scripting language. These scripts are enclosed in <script></script> tags in the XML file. Helpful:
** A guide to the [[Nasal scripting language]] in FlightGear
** [[Nasal FAQ]]
** [[Howto: Write simple scripts in Nasal]]
* You can explore the internal property tree to see many variables that can be altered using joystick buttons or axes (File/Browse Internal Properties)
* You can test bits of Nasal code and do some other useful things using the Nasal Console (Debug/Nasal Console).
* All Nasal code shares a common namespace, so it's possible to set a variable in one nasal binding, and to read it in another.

=== Useful hints for scripts ===
Some particularly useful ideas for programming scripts within joystick XML files:
* getprop and setprop can be used for getting & setting properties from the internal properties tree:
<syntaxhighlight lang="nasal">
var brake = !getprop("/controls/gear/brake-parking");
setprop("/controls/gear/brake-parking", brake);
</syntaxhighlight>
* You can also make your own values on the property tree:
<syntaxhighlight lang="nasal">
setprop("/input/joysticks/js[0]/myjoystick-modifier", 1);
var mod = getprop("/input/joysticks/js[0]/myjoystick-modifier");
</syntaxhighlight>
* You can print to terminal using the print function. This is very useful for debugging.
<syntaxhighlight lang="nasal">
print("Just", " a ", "test");
</syntaxhighlight>
* You can display info in FlightGear via a popup. This is useful for giving the user feedback about changes that may not be obvious via the panel. It can also be useful for debugging. Example:

<syntaxhighlight lang="nasal">
gui.popupTip("Parking Brake ON");
</syntaxhighlight>

Arguments for gui.popupTip must be strings, so if you want to display other types of variables they should be formatted with something like sprintf:

<syntaxhighlight lang="nasal">
gui.popupTip(sprintf("Elevator trim: %d", 100 * getprop("/controls/flight/elevator-trim")));
</syntaxhighlight>

Or

<syntaxhighlight lang="nasal">
thv = getprop("/controls/engines/engine[0]/mixture");
gui.popupTip("Thrust vector " ~ int(thv * 120 - 20));
</syntaxhighlight>

* You can just start using variables, ie,
<syntaxhighlight lang="nasal">
x = 10;
</syntaxhighlight>

But [http://wiki.flightgear.org/index.php/Nasal_scripting_language#Variables for various reasons] it is generally better to declare variables with the "var" statement:
<syntaxhighlight lang="nasal">
var x = 10;
</syntaxhighlight>

Note that "var" creates variables that are local in scope, but since all bindings for a joystick share the same scope, it will be seen across each script in the joystick file.

* You can include a section of script that runs on startup to initialize variables, create functions, etc. Example:
<syntaxhighlight lang="xml">
<PropertyList>
<name type="string">My joystick name</name>
<name type="string">My joystick name #2</name>
<nasal>
<script>
#initialize variables
f1 = f2 = 0;
left_brake = right_brake = 0;
# create a function to be used with all buttons
getmod = func { getprop("/input/joysticks/js[0]/t-flight-hotas-x-modifier" ) }
</script>
</nasal>
</syntaxhighlight>

* Sample code for firing weapons with the joystick is found on the [[Gun Effects]] page.

== Related content ==
{{Forum|24|Hardware}}
* [[Head tracking]]
* [[Joystick xml library]]
* [[Force feedback]]
* [[Troubleshooting input devices]]
* [[Writing Joystick Code: Part 1]]

== External links ==
* [http://www.flightgear.org/Docs/getstart/getstartch3.html#x8-360003.6 The FlightGear Manual]
* [http://sourceforge.net/projects/hapticsforfg/ Force Feedback]

[[Category:Hardware]]
[[Category:Joysticks and Yokes]]

[[de:Joystick]]
[[es:Joystick]]

Gimbal Project

2016-07-29T12:26:44Z

Tipunch: Category:Joysticks and Yokes

Back in May 2009 I had spent some time tossing ideas back and forth with a nice gent by the name of Jentron on the #flightgear [[IRC|IRC channel]] (irc.flightgear.org). We were discussing the various methods that could be used to create a very inexpensive gimbal assembly for pitch & roll control in a home built flight simulator [[cockpit]].

This is what Jentron developed:

[[File:jentron_original.jpg|400px]]

As you can see, it's very simple and uses easily obtainable off the shelf hardware. In fact, this particular example was built entirely from the resources of his local Ace Hardware.

I've named his original gimbal design the "Mark I" to differentiate it from the design I'm using - but they're both built from essentially the same components.

Here is what I call the Jentron Gimbal, Mk II:

[[File:jentron_mk2-1.jpg|400px]]

As you can see, the design elements from the Mk I design are present here with a couple notable changes:
* The pitch axis bearings are two separate components.
* Simpler interconnect for the pitch axis centering arm - no need for a hand-fabricated pitch arm.
* Reduced part count

Jentron's design is perfectly usable in it's configuration, but I needed to modify it for use with the DIY Cockpit Project.<br>Besides, I'm a geek and no self respecting geek can resist fiddling with things. :)

Below is instructions on how you can construct this gimbal for use in your cockpit!

== Building instructions ==

Here's information on how my version of the Jentron Gimbal Mk II was built and how you can build your own.

One important thing to note - the gimbal is designed to be mounted underneath the cockpit floor. This is what it looks like from above, in the "operating" position:

[[file:jentron_mk2-3.jpg|400px]]

This article will only cover the ins and outs of the gimbal itself. The reason for this is that your application may be a bit different and you'll need to adjust other parts of the design to fit your situation.

Two "fancy" tools are going to be required to build this project.
* 1 Step Drill. This is used to enlarge the end holes in the single-gang extender box.
* 1/4" Die. This is used for threading the ends of the centering push-rods.

A cheap 1" Step Drill can be had for less than $30. In case you're not sure, a step drill looks like this:

[[file:step_drill.jpg]]

Here's a list of some other common tools you're going to need:
* Hacksaw -or- a pipe cutter. Pipe cutters work better for cutting EMT.
* Drill
* Drill Bits - 1/4" and 13/64"
* Pop-Rivet gun
* Jig Saw, Band Saw or a Scroll Saw
* Two 7/16" open end wrenches
* 3/8" open end wrench
* Philips screwdriver
* Vice Grips (2 pair if you can)
* Vice or vice-like device

Materials needed to build the gimbal box:
* 1 each single-gang electrical extension box
[[file:single-gang_box.jpg]]
* 2 each 3/4" EMT connectors
[[file:emt_connector.jpg]]
* 2 each 3" "T" Brackets
[[file:t-bracket.jpg]]
* 4 each 3/16" Pop-Rivets
[[file:pop-rivet.jpg]]

Now the first thing you're going to need to do is pop out all the knock-outs in the electrical box and then drill out the ends using the 1" Step Drill. The hole needs to be large enough to accept the threaded portion of the 3/4" EMT connector. When you're done, the box should look like this:

[[file:prepped_box.jpg]]

Next up, you're going to have to use your vice grips (2 pair if you have them!) to position the 3" "T" bracket on the side of the extension box. The best way to do this is to measure 1-1/2" in from the end of the "top" of the T brace and draw a centering line. Measure the electrical box along its long axis and mark the center of it. The centering lines ensure that you'll correctly position the "T" bracket on the side of the box.

Position the box and T-Bracket like this:

[[file:t-bracket_position.jpg]]

With the vice grip(s) holding the t-bracket in place, put the box in a vice to hold it down. You're going to use a 1/4" drill bit to drill holes in the extension box, using the bracket as a guide. Do this for both brackets. When you've got all four holes drilled, go ahead and pop-rivet them in place - please be careful to make sure that both brackets are lined up with one another. The portion of the bracket that sticks out will be the support for the stick stub. It's got to be as close perfect as you can make it. In the end, you should have something that looks like this:

[[file:both_brackets_mounted.jpg]]

You'll notice in my drawing that I'm using screws to hold the brackets in. This was done because I didn't want to take the time to draw a reasonable looking pop rivet. :)

The last step is to mount the 3/4" EMT fittings. These hold 3" sections of 3/4" EMT conduit that act as the pitch bearings for the box. It's important to get these as tight as you can. They'll take all the force of the stick moving fore and aft. I recommend using a pair of Channel-Lock pliers and a vice to make sure those fittings are as tight as you can make them.

If you're paranoid and have a welder, it couldn't hurt it to weld them in place.

With it all assembled, it should look like this:

[[file:complete_gimbal_box.jpg]]

I didn't include the nuts that go to the EMT connectors on purpose. They MUST be used. :)

Here's an exploded diagram that shows you how it all goes together:

[[file:gimbal_box_exploded.jpg]]

The last part of this assembly is the stick stub. The stick stub is made from a 7" long piece of 3/4" EMT that has had two holes and a notch cut in the bottom. A PDF file of the part drawing is available: [[media:stick_stub.pdf]]

The completed stick stub should look like this:

[[file:stick_stub.png|400px]]

The stick stub is just that - a stub. Your flight grip and lower stick or "stick box" will attach to this using another 3/4" EMT mating connector. The stick stub also provides the mechanical interconnect for the roll and pitch axes.

The next part is the roll axis actuator rod. This is just a fancy name for a 6.75" long bit of 1/4" steel rod that you've flatted on one end and threaded on the other. It looks like this:

[[file:roll_axis_acutator_rod.png|400px]]

[[medial:roll_axis_actuator_rod.pdf]]Here is a PDF file that shows the details of making the rod. The hole is sized for a #10 screw. When installed, it looks like this:

[[file:roll_actuator_installed.png|400px]]

The screw is not shown. The attachment will take bit of experimenting with to get it centered in the stick stub. You want a #10 screw that's about 1-1/4" long You'll use a "stop-nut" which is basically a regular nut with a nylon ring pressed into the top. The idea is to allow you to tighten the screw down enough to take the slop out, but not enough to bind up the mechanism. Stop-nuts allow this - the nylon ring ensures that they won't loosen over time.

[[file:roll_axis_pushrod_connection.jpg|400px]]

To center the rod in the stick stub, you'll need to get two #10 nylon washers and a few #10 zinc washers. Place the nylon washers on the "outside" of the stack. They'll be the washers that will rub on the inside of the stick stub. The nylon won't produce the noise that a metal washer would when rubbing against the inside wall of the stick stub. Take the metal washers and stack them on either side of the rod until you've got the right number on each side that gives the closest to center fit.

The clevis fork is made by taking a 1/4" extruded aluminum turnbuckle and cutting off the left-hand threaded end. You then drill a hole that's the appropriate size for the bolt you're going to use. In my case the holes were drilled for 1/4" and #10 bolts (not on the same clevis).

[[file:clevis_fork.png|400px]]

Next up, making the wooden bearing blocks for the gimbal... First, you're going to need to download the drawing for the bearing parts.

[[media:pitch%20axis%20bearing%20drawing.dxf]] pitch axis bearing drawing.dxf

- This drawing was saved in AutoCAD 2004 DXF format. You shouldn't have any problems reading it using any of the freely available CAD programs, you can download a PDF of the plan [[media:pitch%20axis%20bearing%20drawing.pdf]]. The drawing will print full size on a single 11x17 sheet. The blocks are made from 5/8" Birch plywood. However, any good quality 5/8" (or close) plywood will work.

Please take your time cutting out the bearing blocks. Here are some recommendations that should help you get a more accurate
result:

* When drilling the three mounting holes in the bearing base, it would be a good idea to drill both parts at the same time to ensure that the holes are placed identically in both parts. The bearings must be square and aligned to one another or the pitch axis bearing shaft will bind.
* When creating the parts with the bearing holes in them, it is far safer and more accurate to drill all the small holes and the two large holes<em>before </em>you cut the parts to shape. Trust me, you don't want to be boring a near 1" diameter hole in a part with nearly no material to hang on to while the drill does its job. :)
* The large bearing holes are specified at .95". The easiest way to reach that size is to use a 7/8" Forstner or Spade bit. This will get you to .875" The remainder can be sanded away with a small drum sander in a drill or a drill press. The idea is to get the size of the holes to the point where they're just a little bit loose around the 3/4" EMT conduit that makes up the pitch axis bearing. Make sure that when you're sanding the parts to shape, you do them in assembled pairs.
* If you'd rather not sand the holes to size, you can still get good results by boring a 1" diameter hole instead of a .95" hole. The fit will only be a tiny bit looser than what I've specified and it won't affect how the gimbal operates.

Here is an exploded illustration that shows you how the pitch axis bearings are assembled:

[[file:pab_exploded.jpg|400px]]

The bearing is assembled using three 1-3/4" #10 pan head screws and three #10 nylon ringed stop-nuts. It's important that you don't use any washers on this because the washers will actually rub on the bearing shaft when it's installed. The base is attached using two 1-1/2" #8 flat head wood screws. You should countersink the holes for them as shown in the model above.

Now that you've got the bearing blocks made, you're going to need to lay out the position of them on the base plate. This spacing will vary, but generally a distance of about 6-1/4" should be sufficient. When you do your bearing block layout, you'll also want to mark out the space needed to allow the gimbal box to protrude up through the cockpit floor. In my version I'm using a hole that's 5-1/2" wide and 5-1/4" high.

You'll now want to make the pitch axis bearings. They consist of two short lengths of 3/4" EMT conduit cut to a length that will allow them to fully seat in the EMT mating connectors on the gimbal box and extend at least two inches on the pitch actuator side and about 1/2" on the roll axis actuator side. Below are examples that show you roughly how it should look. Pitch axis connection end:

[[file:pitch_axis_bearing_detail.jpg|400px]]

You'll note here how the centering rod for the pitch axis is mounted to the bearing. I'm using a #8 eye bolt that has a locknut on both sides to hold it in place. I chose a #8 because the eye is perfectly sized for a 1/4" bolt. You can also just barely see the Du-Bro ball-link that I'm using to connect the pitch axis to the potentiometer that connects to the computer. The ball-links are very inexpensive and very handy to use. The ones I chose are threaded and have a long enough reach for them to be able to pass through the side of the clevis fork. You can see the nut for the ball on the inside.

Roll axis connection end:

[[file:roll_axis_pushrod_and_center_interconnect.jpg|400px]]

Here you can see why the roll axis side of the pitch axis bearing needs to be so short. When you move the stick to the far left, the back end of the clevis fork can't come in contact with the bearing tube.

You can also see the roll axis potentiometer connection. Just like on the pitch axis, I'm using a Du-Bro ball-link on the clevis end, and a Du-Bro E/Z Connector on the potentiometer end. This is a very simple and very reliable way to connect your axis pots to your stick gimbal. The last component I'm going to cover is the centering mechanism. The centering mech is very simple. It consists of a 1/4" steel rod that's been threaded on one end, a clevis fork made from a turnbuckle, a pair of springs and some locking collars.

In my design the steel rod is 10" long. Your application may and probably will vary. Here's a picture of the assembly:

[[file:roll_axis_centering_and_pot.jpg|400px]]

As you can see, the whole thing is very simple. A 1x1 L bracket is bolted in place and has a 5/16" hole to allow the rod to pass through it.

A collar on either end holds the spring in place. The springs are compressed against the center bracket just slightly. This provides good centering force for the gimbal.

One option you may want to consider is using two spring pairs. If you stack a lighter spring atop a heavier spring, your gimbal will have light force around the center and it will increase as you move the controls. This happens because small movements around the center only compress the light spring, while movements toward the travel ranges compresses both the light and heavy springs.

That's really all there is to it! Below you'll find various pictures of the assembly that will help out in building your own.

[[file:roll_axis_pushrod_and_center_interconnect-2.jpg|400px]] [[file:pitch_axis_pushrod_and_pot.jpg|400px]]

[[file:pitch_axis_pushrod_and_pot-2.jpg|400px]] [[file:pitch_axis_bearing_detail.jpg|400px]]

[[file:pitch_axis_bearing_detail-2.jpg|400px]] [[file:gimbal_box_detail.jpg|400px]]

[[file:roll_axis_pushrod_connection-2.jpg|400px]]

[[Category:Hardware|Gimbal Build a simple pitch & roll gimbal]]
[[Category:Howto|Gimbal Build a simple pitch & roll gimbal]]
[[Category:Joysticks and Yokes]]

Force feedback

2016-07-29T12:25:08Z

Tipunch: Category:Joysticks and Yokes

Development of '''force feedback''' (also called haptic) support for [[FlightGear]] started in December 2011.

==Repository==
The development is currently happening at {{gitorious source|proj=fg-haptic|repo=fg-haptic|text=FG-Haptic on Gitorious}}. It is tested on Linux only, as the author (Zan) has no build environment on Windows. Testers wanted!

No built modules yet available. Only source code and nasal/xml scripts. Requires SDL 2.0 to function (might also work with 1.3 or later, but is tested with 2.0).

==Installation and how to use==
===Building===
# You need to have SDL 2.0 development libraries installed
# Edit Makefile for the library paths if necessary
# Type '''make''' and it should build
# Done

===Installation===
# Copy '''ff-protocol.xml''' to '''Protocols/''' in FG data directory.
# Copy '''force-feedback.nas''' to '''Nasal/''' in FG data directory.
# Copy '''force-feedback.xml''' to '''gui/dialogs/''' in FG data directory.

===Using===
# Run '''fg-haptic''' or '''fg-haptic.exe'''
# Launch flightgear with following command line: '''fgfs --telnet=5401 --generic=socket,out,20,localhost,5402,tcp,ff-protocol'''
# If menu bar is not visible, press '''F10'''
# In flightgear's '''Help->Force feedback options''' you can configure force settings
# Enjoy

==Features==
[[File:Fgfs-haptic-settings.png|thumb|270px|The options dialog.]]
===General features===
* In-sim options dialog
* Support for multiple devices simultaneously
* Devices do not need to be the same ones that are used as inputs
* Devices can have different effects applied on them
* Add-on, can be installed on older FlightGear versions too

===Effects===
* Stick shaker when about to stall
* Stick pusher
* Control surface forces ([[JSBSim]] support, no [[YASim]] or others yet, but to be done)
* Pilot G forces

==Technical details==
===System description===
Fg-haptic uses two communication methods with FG; telnet and general protocol. Telnet is used to send force-feedback device info to FG during intialisation, and later on it is used to fetch device configuration. General protocol is used to send force details from FG (one way communication). Telnet is quite slow, update of device configuration may take up to 10 seconds, while general protocol sends data currently 20 times per second.

All properties used by fg-haptic currently reside under '''/haptic/'''. All effects are directly under that (like '''stick-force/''') and each device is below '''/haptic/device[X]/''', showing device info and configuration.

Generic protocol, '''ff-protocol''', uses following format:
<nowiki>reconfigure_request|aileron|elevator|rudder|pilot_x|pilot_y|pilot_z|stick_shaker_trigger|ground_rumble_period</nowiki>

===Force calculations===
Stick forces are based on the following equation, which represents force caused by air flowing towards a surface:<br />
'''F=0.5*airspeed^2*density*area*Cd''', where Cd is drag coefficient and area is perpendicular to airflow.

Since the surfaces can turn, the effective area is:<br />
'''effective_area=area*sin(angle)''', where angle is the deflection angle, and it should take angle of attack into account:<br />
'''angle=deflection_angle-AoA''', since that is the real direction of air flow with relation to the surface. For rudder, we use slip angle instead of AoA.

Also slip may be taken into account, if the air flows from side, it has less effect on the surface, thus giving:<br />
'''effective_area_2=effective_area*(1-sin(slip_angle))'''.

Another thing we take into account is stall and deep stall. If AoA is over the stall limit, or over deep stall limit, forces acting on elevator and aileron are quickly ramped to zero, representing separated airflow.

In this implementation, multiplication by 0.5, Cd and area are combined to a single coefficient for aileron, elevator and rudder, that are aircraft specific. Coefficients should be set so that the force does not exceed 1.0 (maximum value) in normal operation, and they can also be set to 0 or other value to represent fly-by-wire systems. Also slip coefficients can be defined to fine tune the stick feeling. A good starting value to try for each coefficient is:<br />
'''coeff=1.0/((Vne^2)*sin(max_deflection)*0.00257)''', where Vne is the maximum (never exceed) speed in knots, max deflection is the maximum deflection of the control surface and 0.00257 is standard air density (slugs/ft3). This value can then be fine tuned.

===Force feedback===
TBD

== External links ==
* {{gitorious source|proj=fg-haptic|repo=fg-haptic|text=Official FG-Haptic repository}} (Gitorious)
* [http://sourceforge.net/projects/hapticsforfg/ hapticsforfg] (SourceForge)

[[Category:Hardware]]
[[Category:Joysticks and Yokes]]

Changing repeat rate of joystick buttons

2016-07-29T12:24:22Z

Tipunch: Category:Joysticks and Yokes

If you are new to writing Nasal functions for joysticks, read [[Using a Nasal file with a joystick]] first.

== Background ==

Sometimes the repeat rate of joystick buttons is too high. The value changes so fast that you can't set it accurately. In your joystick xml file you could use
<syntaxhighlight lang="xml">
<desc>whatever</desc>
<interval-sec>x.xx</interval-sec>
</syntaxhighlight>

where x.xx is the time between button action repeats. This has the problem that the delay is implemented at the start of the button press, as well as between repeats. It is also not as versatile as using this method.

== Changes (additions) to the Nasal file ==

You must have set up everything according to [[Using a Nasal file with a joystick]] so that your joystick button calls a routine in a Nasal file, as per the next paragraph.

Assume that the button in question is labelled "C". The property we want to change with the button is '''/mythical/telescope-colour'''. Our nas file is called mynasfile.nas. We will use a flag called busyTelescope to control the repeat rate.

Start off by adding the function for the button
<syntaxhighlight lang="nasal">
var buttonC = func {
if (getprop("/busyTelescope")) return;

setprop("/busyTelescope", 1);

# ... Your code to adjust telescope property goes here ..

}
</syntaxhighlight>

Now when the button is pressed the busy flag will be set, the code will be called. As soon as FG repeats the button, the set state of the busy flag will make the routine return. So far so good.

We still need to create the busy flag, set the repeat rate we want, and clear the busy flag between (our) repeats.

At the top of the nas file add
<syntaxhighlight lang="nasal">
var buttonRate = 0.1;
</syntaxhighlight>
This is the number of seconds we want ''between'' repeats. In this case it is 100 milliseconds.

Then we need to create the busy flag. This must be done in an init routine. Add to the init routine
<syntaxhighlight lang="nasal">
props.globals.getNode("/busyTelescope", 1);
setprop("/busyTelescope", 0);
</syntaxhighlight>
We now have the flag, and it is cleared.

We still need to clear it at our required repeat rate. Add to the init routine
<syntaxhighlight lang="nasal">
setlistener("/busyTelescopy", func
{
if (getprop("/mythical/busyTelescope"))
settimer(busyTelescopeClear, buttonRate, 1);
} #end of anonymous function
); #end of setlistener

</syntaxhighlight>

and add this function
<syntaxhighlight lang="nasal">
var busyTelescopeClear = func {
setprop("/busyTelescope", 0);
}
</syntaxhighlight>

Now, whenever the button is pressed, the flag gets set. The listener detects this and starts a timer, with delay buttonRate. When the delay elapses, busyTelescopeClear is called, which clears the flag, and the button will repeat.

We now can control the repeat rate of the button.

== Making the code safe ==
To avoid the busy flag possibly getting stuck in the true state, make the mod-up of your joystick call ''mynasfile.buttonCUp()''.

Then add this to the nas file
<syntaxhighlight lang="nasal">
var buttonCUp = func {
busyTelescopeClear();
}
</syntaxhighlight>

== Other uses ==
It is of course possible to use this technique for adding a delay in any nasal code, with appropriate changes.

[[Category:Howto]]
[[Category:Hardware]]
[[Category:Joysticks and Yokes]]

Using a Nasal file with a joystick

2016-07-29T12:23:08Z

Tipunch: Category:Joysticks and Yokes

Sometimes the code for a button is quite complicated. Not only does it make your xml file larger and more difficult to go through, but writing the code in a dedicated Nasal file cane be a lot easier. There are things which are just easier that way. You may also have come across an example in the forums which you want to use, and you don't know how to do it.

Whatever your reason for using a Nasal file, this is how to implement the Nasal file approach. Part 2, expands the idea and shows you just why it is easier.

== Getting Started ==

You are going to put your Nasal file in the same folder as your joystick's xml file. You need to choose a suitable name for the file. If your joystick is a KungFu ABC123 you could safely name the file abc123.nas. If, however, you have a Saitek yoke, you don't want to name the file yoke.nas, because in the Saitek folder is a Pro Flight Yoke and a Cessna Yoke, so you want to be more specific. Call the file cessnayoke.nas or proflightyoke.nas'

The name you choose is visible ''everywhere'' in FG, so make sure you choose something unique.

Notice that there are no capital letters.

So open up your favourite text-editor, create a new file, and save it in your joystick's folder with the chosen filename. Don't forget that the extension must be .nas, and make sure your editor doesn't make it .nas.txt.

== Changes to your joystick's xml file ==

'''Save a copy of your xml file in a safe place, one that you will remember.'''

For the sake of this exercise we will assume that you have a KungFu ABC123 joystick. So your nasal file is abc123.nas.

Open the xml file.

At the top, just after all the <name> entries, add this:
<syntaxhighlight lang="xml">
<nasal>
<script>
## begin of custom section
var modulename = "abc123"; # customize this according to the namespace used
var module_path = "/Input/Joysticks/KungFu/abc123.nas"; # customize this according to the file name/path
## end of custom section

var is_loaded = func (name) contains(globals,name);

if (!is_loaded(modulename)) {
io.load_nasal(getprop("/sim/fg-root") ~ module_path);
}

abc123.initABC123(); # customize init routine
</script>
</nasal>
</syntaxhighlight>

The ''if (!contains...'' bit (if not contains) makes sure that the nas file is loaded only once.

The ''abc123.initABC123'' cals an initialise routine in the nas file. We haven't created it yet. Notice the ''abc123''. This tells FG which nas file to use. The ''initABC123'' is which routine in that nas file to call. The ''()'' is because it is a function.

Save your xml file and open the nas file.

== Adding routines to the nas file ==

We have just told the xml file to call initABC123, so we better add it to the nas file.

At the top of the file add
<syntaxhighlight lang="nasal">
var initABC123 = func() {
}
</syntaxhighlight>

Every new thing in Nasal starts with '''var'''. That is followed by its name (initABC123). Then we must assign it to something. In this case it is a function, so we write '''= func()'''. If you want to pass a value to the function (we aren't here), you give a name to the value between the brackets, and place the value to pass between the brackets in the xml file. The '''{''' and '''}''' mark the start and end of the function (what it does.) It doesn't currently do anything, so there is nothing between them.

Now we need to make at least one button call a function in the nas file. Let's assume you have a button labelled D on your joystick. So we will have a function called buttonD. If it is the only red button, you could call the function redButton.

So we add
<syntaxhighlight lang="nasal">
var buttonD = func() {
}
</syntaxhighlight>

Once again, it doesn't do anything yet.

Save the nas file and open the xml file. Go to where the D button is handled.

Between the <binding> and </binding> we add our call to the nas file. We get
<syntaxhighlight lang="xml">
<binding>
<command>nasal</command>
<script>abc123.buttonD()</script>
</binding>
</syntaxhighlight>

Now, when button D is pressed, it will call the function '''buttonD''' in abc123.nas. You just need to put the correct code in the function.

To make your nas file a bit more use-friendly, open it and at right at the top add
<syntaxhighlight lang="nasal">
print("Loading abc123.nas");
</syntaxhighlight>

Now, when you run FG, along with all the other info in the "black window" you will see ''Loading abc123.nas'' when the joystick xml file loads. This not only confirms that it has loaded, but if you have a parse error in your nas file it will be reported, and you can fix it.

== Notes ==

This article does not supply any coding for actions, it is just to get you started. A sort of template. See Part 2 for more details.

When naming Nasal functions, the convention is to use camel coding. That is, the first word in the name starts with a lower-case letter, all subsequent words star with an upper-case letter. The can be no spaces in the name. If you want to separate words use an underscore (_).

So valid names would be startDividingByThree, start_Dividing_By_Three, adjRadioFrequency.

[[Category:Howto]]
[[Category:Hardware]]
[[Category:Joysticks and Yokes]]

Using Saitek AV8R second throttle as view pan speed control

2016-07-29T12:21:59Z

Tipunch: Category:Joysticks and Yokes

These changes to your <code>aviator.xml</code> file will enable you to use the second throttle of the Saitek AV8R joystick as a view panning speed control. The panning speed can be controlled smoothly from no movement at all to very fast.

== Caveats ==
You will lose the second throttles other functionality. The most important being mixture, which means you will have to use the keyboard for this - {{key press|Shift|M}} for leaner and {{key press|M}} for richer. This is not a significant problem as the mixture does not have to be adjusted often.

Also, this article assumes that you have not done any modifications to your <code>aviator.xml</code> file. If you have, you will have to work out the changes yourself, or ask on the Support->Hardware forum.

== Usage ==
This is the same as standard - use the hat-switch as is to get the predefined views. Press the modifier (trigger) while using the hat-switch to pan left/right and up/down. The difference is that, while using the trigger/hat-switch, Throttle 2 will control the speed of view-change.

There are two methods you can use:

; Method 1
: Moving the hat-switch left/right (up/down) will pan left/right (up/down) with Throttle 2 controlling the speed of movement - throttle closed is dead-still and throttle fully open is very fast movement. This means that the hat-switch can only be used for left/right and up/down.

; Method 2
: With this method you assign 4 different controls to the 4 directions of the hat-switch. With each one, Throttle 2 in the center means no movement, fully open is fast in one direction and throttle closed means fast in the ''other'' direction.

So you could use hat-switch left for pan left/right and hat-switch up for pan up/down. This leaves hat-switch right and hat-switch down for other functions, such as move eye-position (more on this later.)

== Changes to aviator.xml ==
You need a text-editor to modify this file:
.../FlightGear/data/Input/Saitek/Aviator.xml

Step 1 is to make a copy of this file in a safe place, in case things go wrong.

Step 2 is to open the file, and find this:

<syntaxhighlight lang="xml">

<axis>
<name>Right throttle</name>
<number>
<unix>4</unix>
<mac>4</mac>
<windows>4</windows>
</number>
<desc>TM0: mixture, TM1: throttle/propeller 2, TM2: throttle/propeller 4</desc>
<binding>
<command>nasal</command>
<script>
if (engine_select_mode == 0) {
controls.mixtureAxis();
} else {
controls.perEngineSelectedAxisHandler(engine_axis_mode)
((engine_select_mode == 1) ? engine[1] : engine[3]);
}
</script>
</binding>
</axis>
</syntaxhighlight>

and change it to this:

<syntaxhighlight lang="xml">

<axis>
<name>Right throttle</name>
<number>
<unix>4</unix>
<mac>4</mac>
<windows>4</windows>
</number>
<desc>TM0: mixture, TM1: throttle/propeller 2, TM2: throttle/propeller 4</desc>
<binding>
</binding>
</axis>
</syntaxhighlight>

Now Throttle 2 does nothing. No cutting out the engine because you changed the Mixture while panning around.
If you really want to keep your Mixture control, then you can change the above to:

<syntaxhighlight lang="xml">

<axis>
<name>Right throttle</name>
<number>
<unix>4</unix>
<mac>4</mac>
<windows>4</windows>
</number>
<desc>TM0: mixture, TM1: throttle/propeller 2, TM2: throttle/propeller 4</desc>
<binding>
<command>nasal</command>
<script>
if (!modifier) {
if (engine_select_mode == 0) {
controls.mixtureAxis();
} else {
controls.perEngineSelectedAxisHandler(engine_axis_mode)
((engine_select_mode == 1) ? engine[1] : engine[3]);
}
}
</script>
</binding>
</axis>
</syntaxhighlight>

This will keep the Throttle 2 functionality, but you need to return it to its original position before you release the modifier button.

Next is to look for this:

<syntaxhighlight lang="xml">

<axis>
<name>Hat left/right</name>
<number>
<unix>5</unix>
<mac>5</mac>
<windows>5</windows>
</number>
<desc>quick view left/right, +mod: horizontal view pan</desc>
.....
</syntaxhighlight>

Scroll down until you see:

<syntaxhighlight lang="xml">
<script>
<![CDATA[
trace("Axis 5, Hat: low!");
if (modifier) {
view.panViewDir(0.5);
} else {
quick_view(1);
}
]]>
</script>
</syntaxhighlight>

You will need to change this line:

<syntaxhighlight lang="xml">
view.panViewDir(0.5);
</syntaxhighlight>

If you are using Method 1, change it to

<syntaxhighlight lang="xml">
view.panViewDir(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting"));
</syntaxhighlight>

If you are using Method 2, change it to

<syntaxhighlight lang="xml">
view.panViewDir(getprop("input/joysticks/js[0]/axis[4]/binding/setting") * 2);
</syntaxhighlight>

You only need do this step for Method 1. Scroll a bit further down until you see

<syntaxhighlight lang="xml">
<script>
<![CDATA[
trace("Axis 5, Hat: high!");
if (modifier) {
view.panViewDir(-0.5);
} else {
quick_view(2);
}
]]>
</script>
</syntaxhighlight>

The line to change is

<syntaxhighlight lang="xml">
view.panViewDir(-0.5);
</syntaxhighlight>

Change it to

<syntaxhighlight lang="xml">
view.panViewDir(-(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting")));
</syntaxhighlight>

Having made these changes, you can do the following:

; Method 1: Pressing modifier (trigger) and moving the hat-switch left means you can use Throttle 2 to control the speed of pan to the left. Pressing modifier (trigger) and moving the hat-switch right means you can use Throttle 2 to control the speed of pan to the right.

; Method 2: Pressing modifier (trigger) and moving the hat-switch left means that you can use Throttle 2 to control the speed of pan to left and right, with throttle in the middle doing no movement.

Now to make the changes to manage pan up and down (pitch).

Scroll down to

<syntaxhighlight lang="xml">

<axis>
<name>Hat up/down</name>
<number>
<unix>6</unix>
<mac>6</mac>
<windows>6</windows>
</number>
<desc>view reset/quick view front, +mod: vertical view pan</desc>
</syntaxhighlight>

Scroll a bit further down. The line to change is

<syntaxhighlight lang="xml">
view.panViewPitch(0.5);
</syntaxhighlight>

For Method 1, change it to

<syntaxhighlight lang="xml">
view.panViewPitch(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting"));
</syntaxhighlight>

For Method 2, change it to

<syntaxhighlight lang="xml">
view.panViewPitch(getprop("input/joysticks/js[0]/axis[4]/binding/setting") * 2);
</syntaxhighlight>

For Method 1, scroll a bit further down and replace

<syntaxhighlight lang="xml">
view.panViewPitch(0.5);
</syntaxhighlight>

with this

<syntaxhighlight lang="xml">
view.panViewPitch(-(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting")));
</syntaxhighlight>

Now you can do look up/down exactly the same as left/right.

== Alternatives ==
You could of course use this exact same method to move your eye-point around, instead of looking around.

If using Method 1, replace

<syntaxhighlight lang="xml">
view.panViewDir(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting"));
</syntaxhighlight>

with

<syntaxhighlight lang="xml">
controls.slewProp("/sim/current-view/x-offset-m", (1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting")) * 10);
</syntaxhighlight>

and

<syntaxhighlight lang="xml">
view.panViewDir(-(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting")));
</syntaxhighlight>

with

<syntaxhighlight lang="xml">
controls.slewProp("/sim/current-view/x-offset-m", (1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting"))* -10);
</syntaxhighlight>

If using Method 2. change

<syntaxhighlight lang="xml">
view.panViewDir(getprop("input/joysticks/js[0]/axis[4]/binding/setting") * 2);
</syntaxhighlight>

to

<syntaxhighlight lang="xml">
controls.slewProp("/sim/current-view/x-offset-m", getprop("input/joysticks/js[0]/axis[4]/binding/setting") * 20);
</syntaxhighlight>

This will move you horizontally.
To move up and down, replace x-offset with y-offset. To move backwards and forwards, change it to z-offset.

You can also use this method for zooming in and out. Unfortunately we need to implement limits for zoom, so the code is more complicated.
If using Method 1, replace

<syntaxhighlight lang="xml">
view.panViewDir(-(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting")));
</syntaxhighlight>

with

<syntaxhighlight lang="xml">
<![CDATA[
controls.slewProp("/sim/current-view/field-of-view",
(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting")) * -20);
if (getprop("/sim/current-view/field-of-view") >= 120)
setprop("/sim/current-view/field-of-view", 120);
if (getprop("/sim/current-view/field-of-view") <= 1)
setprop("/sim/current-view/field-of-view", 1);
]]>
</syntaxhighlight>

and

<syntaxhighlight lang="xml">
view.panViewDir(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting"));
</syntaxhighlight>

with

<syntaxhighlight lang="xml">
<![CDATA[
controls.slewProp("/sim/current-view/field-of-view",
-(1 - getprop("input/joysticks/js[0]/axis[4]/binding/setting")) * -20);
if (getprop("/sim/current-view/field-of-view") >= 120)
setprop("/sim/current-view/field-of-view", 120);
if (getprop("/sim/current-view/field-of-view") <= 1)
setprop("/sim/current-view/field-of-view", 1);
]]>
</syntaxhighlight>

If using Method 2. change

<syntaxhighlight lang="xml">
view.panViewDir(getprop("input/joysticks/js[0]/axis[4]/binding/setting") * -2);
</syntaxhighlight>

to

<syntaxhighlight lang="xml">
<![CDATA[
controls.slewProp("/sim/current-view/field-of-view",
getprop("input/joysticks/j[0]/axis[4]/binding/setting") * 40);
if (getprop("/sim/current-view/field-of-view") >= 120)
setprop("/sim/current-view/field-of-view", 120);
if (getprop("/sim/current-view/field-of-view") <= 1)
setprop("/sim/current-view/field-of-view", 1);
]]>
</syntaxhighlight>

== Summing up ==
It seems a bit daunting, but if you look carefully, the steps are all the same, there are just a few places where the changes need to be made.

== Related content ==
* [[Input device]]

[[Category:Hardware]]
[[Category:Joysticks and Yokes]]

Improving the Joystick GUI

2016-07-29T12:21:18Z

Tipunch: Category:Joysticks and Yokes

{{Template:Mentored Volunteer Effort
|mentors= macnab, Philosopher, Hooray, Stuart (review/commit), Zakalawe (C++ hooks [http://forum.flightgear.org/viewtopic.php?f=18&t=18530#p172461])
|skills=[[PropertyList XML File]], [[Property Tree]], [[Nasal|Nasal scripting]], fgcommands, [[Howto:Making HTTP Requests from Nasal|Nasal/Web scripting]]}}

== Background ==
We once talked about integrating the various Nasal capabilities added by Macnab and Philosopher right into Stuart's new JS config dialog - back then, Stuart & Zakalawe actually seemed supportive of the idea. And it would indeed not require many customizations to allow bindings to become fully runtime-configurable, including Nasal bindings and a standard library of general-purpose Nasal/JS APIs. UI-wise, we could simply reuse/integrate the existing Nasal console, so that bindings can be dynamically added and edited. At the end of the day, it's all XML, Nasal and the property tree, and some fgcommands to reinit stuff - so if people still think, that'd be useful, please speak-up and share your feature requests / ideas here.

Also see [[User:Philosopher/Advanced Input Programming]].

== Status 07/2013 ==
Stuart being the developer and maintainer of the latest Joystick GUI, here's his feedback:

'''Stuart''':
Adding the ability to write Nasal for a given button was something I considered, but didn't implement. Partly this was due to time constraints, but it was also because I didn't think there was a use-case for it. The joystick configuration dialog is really targeted at new users who don't have any XML or Nasal experience. IMO anyone who knows enough to write Nasal joystick bindings will have enough knowledge to edit the joystick XML files directly and use the Nasal Console.

On a different note, I'm interested to see what bindings people are using on joysticks, to check that the set of button bindings that are supported in the configuration dialog are sufficient.

At present the dialog supports trim settings, but sets the button to be repeatable. Is there are a particular reason for not using the repeatable flag, or is it purely for people who have mode-switches and might have another (non-repeatable) function assigned to the button?

I'm very happy if someone wants to expand the Joystick GUI to include advanced features such as modifier keys, and support for arbritary Nasal snippets. I also very much like the idea of re-implementing it in Canvas, as I had to make some design decisions purely on the basis of what was possible through the XML GUI code.

If someone is working on this, it would be good to add support to allow setting of the joystick deadband - this is something that I simply haven't had the time to add.

Finally, one point that I'm sure you will bear in mind: It's critical that it remains easy to use for new users. In particular, I spent some time determining the minimum set of bindings that were really required so that someone programming their joystick for the first time wouldn't be overloaded by a massive list of possible key bindings. It might be worth having an "Advanced bindings" option that enables modifier keys and the more esoteric bindings. For example, my yoke has a slider switch that I use to control the sensitivity of the view movement control. That's really useful for my yoke in particular, but probably doesn't generalize.

Finally, I'm very happy to review any code that people want to submit, though I apologize in advance if it takes me a little time.

== Roadmap ==

=== Misc ===
* To me the first step would be to have the UI include at least one "Modifier" button and/or keyboard modifiers. Then the UI can have the option of switching views between modified/not modified. This will give more available actions.

=== repeatable flag ===
* Between us we can come up with the "actions" and code. If we can get "on the fly" switching between repeatable/non-repeatable that would make a great addition/change for Version 3.
** To make this work we definitely need to get around the repeatable/non-repeatable limitation first.
** making the repeatable flag runtime configurable should be pretty straightforward for anybody familiar with the JS code and property tree listeners (SGPropertyChangeListener).
** Without on-the-fly switching between repeatable/non-repeatable switching to modified view would have to limit the available actions to repeatable/non-repeatable based on the unmodified action.
** It will need FGCommands to do it. Then the specific joystick code can set/clear it according to needs. If no FGCommand is sent it must stay the way it is for compatibility with existing joystick xml files.
** there are obviously several ways to skin this cat - no matter if it's fgcommands or listeners - I just believe listeners to be more "direct", i.e. by simply replicating the whole config file through the property tree and just waiting for events that change things, and automatically reparsing/re-initializing things - that's after all, how the AP, AI system or the canvas work, without necessarily requiring fgcommands. On the other hand, Stuart -as the author of the JS dialog- seems to prefer fgcommands over listeners (see his clouds API). So at the end of the day it all boils down to who gets around to implementing it. It doesn't really matter if it's through listeners or fgcommands (or even something else).
** Note that the upcoming FG releases (beyond 2.12+) will include a new Nasal API for registering invididual Nasal functions as fgcommands, so that you can have very compact joystick bindings by making up new, joystick-specific, fgcommands
** it's basically the same, except obviously more universal (C++ code can use it too). It also looks better (to me) as it just used the <command> tag instead of a function call with all those tags around it (<command>nasal</command><script>call_function()</script>), and it of course requires "arguments" to be in the property tree (they can be retrieved using cmdarg() or the first argument passed to the callback function). For example, I could register a "Cyborg-X-axis" fgcommand
** this is probably going to be what bindings will look like in the future, simply because we can easily maintain a generic standard Nasal library for joystick code, without individual bindings having to be aware of implementation details - so this is pretty much the "frontend", and what things will look like to end-users, or the joystick GUI, while the backend would be based on generic and unified Nasal snippets dealing with Joystick/Yokes, Pedals etc - that would allow us provide a "stable frontend API" through Nasal-based fgcommands, whereas the back-end could evolve as needed - and the front-end would be easily editable through a corresponding GUI dialog. It would then even be possible to merge the Nasal console into everything, so that backend snippets become also customizable at runtime. Basically, more flexibility, with less coding required for people who do not want to look into scripting - also, no need for cdata or XML escaping

* Being able to edit the generated code would be nice for those who are capable of tweaking it. (Such as a personal preference for slew-rate.) Dynamic re-inits would also be good.

=== GUI ===
Before creating new [[Canvas GUI]] widgets please have a look at Tom's fgdata branch: {{gitorious url|fg|toms-fgdata|branch=canvas-gui-demo}}.
Tom is currently working on creating a standard widget and layout system (similar to eg. Qt). At the moment there only exists a button widget (but already with focus, and hover/press effects) [http://forum.flightgear.org/viewtopic.php?f=24&p=186563#p186563]. Specifically, see {{gitorious source|fg|toms-fgdata|branch=canvas-gui-demo|path=Nasal/canvas/gui|view=tree|pre=$FG_ROOT}}.

* The UI can be worded carefully so that less-experienced users can understand the concept of doubling-up on button actions.
* And for doing it in Canvas. And for all buttons to be implemented in a nas file, not the xml file. (Standard axes can stay in the xml file.)
* For the axes, along with deadband, power as well. (With a slider in the GUI?)
* Maybe the start page with only the basic bindings, and 3 buttons: Basic, Medium and Advanced that change the view?

=== Updating ===
* Something that occurs to me is that once the system is out there people will make requests for bindings that don't exist yet. If these are implemented, unless the people use Git, they will have to wait for a new release to see them. So maybe a system where they can download just the necessary files, which be the GUI and the new glorified version of controls.nas.
** You could provide custom bindings as self-contained PropertyList-encoded XML files with embedded Nasal sections - FlightGear already supports loading PropertyList XML files via network, which is how the multiplayer list is loaded dynamically. In other words, you could take these building blocks and load/share arbitrary stuff via network, including custom joystick bindings. For details, see: Howto:Making HTTP Requests from Nasal. The tutorial also demonstrates how to use a simple web server (in fact, a single line in python) to serve a FG GUI XML file that shows a FG GUI dialog with a custom message ("Hello World").
** the tutorial uses the official fgdata repository to dynamically download the latest XML/Nasal stuff - and we've been talking about using such a method for automatically updating the Nasal APIs of the Canvas system. Also, Zakalawe is planning to provide a feature to allow aircraft to be downloaded at runtime using WebDAV (see the wiki)
** we could simply use $FG_HOME for persistence/caching - either by using the "userarchive" attribute on all JS-related snippets, so that they become persistent between sessions (see $FG_HOME/autosave.xml) or by using a custom PropertyList-XML file that stores downloaded snippets and uses a hash to check if they were already downloaded and/or need to be updated. Thus, you would only need to be online when downloading things - later on, everything would be persistent/cached.
** also, by convention, fgdata has usually been considered (and installed) as read-only - especially on "true" multi-user systems, so this should be kept in mind - it simply makes sense to have user-specific stuff in $FG_HOME, i.e. a user-specific directory for application settings. Just look at how TerraSync solves the same problem basically - because it also cannot modify $FG_ROOT, but still needs to download and store tons of data.
** The library and GUI will have to be put in a read/write folder. It does mean making FG look for it in the correct place - non-standard.
** There are a bunch of Nasal wrappers available in io.nas for loading Nasal code from different places, and there are helpers in gui.nas to load GUI dialogs from non-standard places. Keep in mind how we have a bunch of Nasal code and custom GUI dialogs in most aircraft folders, which are also "non-standard" - so that's a no-brainer.

== Team ==
Please feel free to add your name to this list if you are willing and able to help.

=== Mentors ===
* Hooray

=== Joystick GUI ===
* Philosopher

=== Nasal Joystick Routines ===
* macnab. I already have a large collection of of what would be classified as Advanced (or even Esoteric) functions written in Nasal.

=== C++ Code ===
* Zakalawe

=== Review/Commit ===
* Stuart

== Ideas/Suggestions ==
Please add any ideas or suggestions you may have which are not listed above.

== Related ==
* http://forum.flightgear.org/viewtopic.php?f=24&t=20324
* http://forum.flightgear.org/viewtopic.php?f=18&t=18530
* http://forum.flightgear.org/viewtopic.php?f=24&t=17892

[[Category:Core development projects]]
[[Category:Joysticks and Yokes]]

Using Saitek Pro Flight Yoke Mode Switch

2016-07-29T12:17:57Z

Tipunch: Category:Joysticks and Yokes

== Before you start ==

To use the Mode Switch you need to install the Smart Technology software that came on the CD with your yoke. Install it ''after'' installing the drivers.

== Running the Profile Editor ==
If the Profile Editor does not run after installation, you can run it from the Start Menu - Start - All Programs - Smart Technology (folder) - Profile Editor.
If you have the rudder pedals as well as the yoke you will have to select the yoke in the first dialog box that appears.
At the top right is ''Product Programming Support''. Click on 'Programming'. Here is the top left corner of the page that appears:

[[File:Saitek Yoke - Top Left Blank.jpg | 550px]]

== Creating a blank safety profile ==
The first thing to do is create a profile that does nothing, i.e. does not interfere in any way with the current working of the yoke. This is your "safety" backup. Click on (Create) Profile. This generates the file that will be saved and opens the Save as dialog. Give the profile a suitable name (such as Blank) and save it.

== What the software does ==
It simulates keystrokes. You can assign different keystrokes to specific yoke buttons for each mode. Then, when you select a mode and press a button, that/those keystroke(s) are sent to Flightgear. Just as if you had typed them at the keyboard.
But this does have the limitation of only being able to use commands that exist on keyboard.xml and multikey.xml. And that also means no 'repeatable' actions, such as 'Trim' Elevator'. So we will not discuss it.

== Mod-Key style of use ==
What we are going to do is make the Mode Switch act as if we are pressing the Shift, Ctrl or Alt keys while pressing a yoke button - emulating <mod-shift>, <mod-ctrl> and <mod-alt>. Mode 1 is none of the above pressed. Choose which 2 of the 3 mod conditions you want to use. In this article we will use Shift in Mode 2 and Ctrl in Mode 3. It really doesn't matter unless you already have your yoke programmed with mods.
To make Mode 2 emulate pressing the Shift key, hold your mouse pointer in the large blank rectangle under Mode 2, and then click on the little arrow that appears.

[[File:Saitek Yoke - To make little arrow appear.jpg | 400px]]

A popup menu appears. Click on "New Key Presses...". You now see this:

[[File:Saitek Yoke - New Key Presses clicked.jpg | 400px]]

Ignore where the cursor is (this is just for a name) and click in the bigger rectangle. Then give the Shift key a tap. An icon of the Shift key will appear in the rectangle. Click on the little green tick mark. (If you got it wrong, click on the little red cross and try again.
You will have this, if you got it right:

[[File:Saitek Yoke - Shift key done..jpg | 400px]]

If it doesn't look like that, click on one of the incorrect key icons. You will be taken back to the point before you clicked the green tick. You can then right-click on any incorrect keys and select Cut. And redo tapping the Shift key if needed.

Now go to the column for Mode 3, and repeat all the ablove actions, except using the Ctrl key, instead of Shift.
Now you need to create the profile. Click on (Create) Profile. The profile will be created and the Save As dialog will open. Choose a suitable name for the profile and save it.
You will now need to edit your joysticks's xml file. There is plenty of information on that. You will of course need to program <mod-shift> and <mod-ctrl> sections for the buttons.

== Very Important ==
* If you assign Shift to Mode 2, and the yoke switch is in Mode 2, then ''everything'' you do will be treated as if the shift key is pressed while you do it. This includes the mouse. To use a modded button, flick the switch to Mode 2 or Mode 3, do what you have to do, and then flick straight back to Mode 1.

* The profile you have defined is not automatically assigned at system boot-up. You have to go to the system area, right-click on the yoke-icon and select your profile. The icon will then have a green box around it to show that it has been assigned a profile.

[[Category:Hardware]]
[[Category:Howto]]
[[Category:Joysticks and Yokes]]

Using a Nasal file with a joystick Part 2

2016-07-29T12:17:19Z

Tipunch: Category:Joysticks and Yokes

In [[Using a Nasal file with a joystick]] you saw how to get started.
This article goes into it in more depth.

== First Steps ==
Backup your xml file.
Print it, you need to know which button does what.
If you have a Nasal file, back it up too.
If you haven't read the first part, read it and do the basic implementation now.

== Modifying your xml file ==
This seems like a lot of work, but it is worth it in the end.
You need to use the labels of the buttons on your joystick.
You will use these labels for the name of the Nasal function to call in your nasal file.
For each button in your xml file, change your code. Here, the button is labelled "1".
And remember, we are talking about the label printed on the joystick, not the button number

assigned by the operating system.
<syntaxhighlight lang="xml">
<button n="xxx">

<desc>Whatever it does</desc>
<binding>
<command>nasal</command>
<script>nasfilename.button1()</script>
</binding>
</button>
</syntaxhighlight>
Of course, nasfilename is the name of your Nasal file.

If you have a modifier button, named ''mymod'', then do this
<syntaxhighlight lang="xml">
<button n="xxx">

<desc>Whatever it does</desc>
<binding>
<command>nasal</command>
<script>nasfilename.button1(mymod)</script>
</binding>
</button>
</syntaxhighlight>

If you use the keyboard Shift, Ctrl or Alt buttons as a modifier, you do this
<syntaxhighlight lang="xml">
<button n="xxx">

<desc>Whatever it does</desc>
<binding>
<command>nasal</command>
<script>nasfilename.button1(1)</script>
</binding>
<mod-shift>
<binding>
<command>nasal</command>
<script>nasfilename.button1(2)</script>
</binding>
</mod-shift>
</button>
</syntaxhighlight>

If you use 2 keyboard buttons then you would need another <mod-...> section, and pass the value 3.
To help you remember, add a comment at the top of your Nasal file to remind you what the values mean.

If your button needs a mod-up, then do this
<syntaxhighlight lang="xml">
<button n="xxx">

<desc>Whatever it does</desc>
<binding>
<command>nasal</command>
<script>nasfilename.button1()</script>
</binding>
<mod-up>
<binding>
<command>nasal</command>
<script>nasfilename.button1Up()</script>
</binding>
</mod-up>
</button>
</syntaxhighlight>
but this is very seldom needed. Of course, if you use modifiers you need to pass the number of the modifier in the brackets.

You could use 2 modifiers simultaneously. The Saitek Pro Flight Yoke has a Mode Switch, which needs special methods to access it - see [[Using Saitek Pro Flight Yoke Mode Switch]], then could have a case where you have these modes (which simulate using the keyboard Shift, Ctrl and Alt keys) as well as a modifier button on the joystick.

In such a case do this
<syntaxhighlight lang="xml">
<button n="6">

<desc>Whatever</desc>
<repeatable>true</repeatable>
<binding>
<command>nasal</command>
<script>saitekyoke.buttonC1(saitekAlter, 1)</script>
</binding>
<mod-shift>
<binding>
<command>nasal</command>
<script>saitekyoke.buttonC2(saitekAlter, 2)</script>
</binding>
</mod-shift>
<mod-ctrl>
<binding>
<command>nasal</command>
<script>saitekyoke.buttonC1(saitekAlter, 3)</script>
</binding>
</mod-ctrl>
</button>
</syntaxhighlight>
Here, saitekAlter is the value (0 or 1) of the modifier button, and the 1, 2 and 3 represent the position of the Mode Switch.

Now do this for all the buttons.

== Contents of the Nasal file ==

=== The blank file ===
For each button you need a function defined. In our simplest example above you need
<syntaxhighlight lang ="php">
var button1 = func {
... code goes here ...
}
</syntaxhighlight>

If you pass the value of a modifier button then it is slightly different.

Assuming that your modifier button is 0 for not pressed and 1 for pressed, we can make use of the fact that in Nasal 0 represents false, and any other value represents true.
<syntaxhighlight lang ="php">
var button1 = func(mod) {
if (mod) {
... code for modifier button pressed goes here ...
} else {
... code for modifier not pressed goes here ...
}
}
</syntaxhighlight>

When have values other than just 0 and 1 then you need specific if clauses
<syntaxhighlight lang ="php">
var button1 = func(mod) {
if (mod == 1) {
... code for modifier value 1 goes here ...
}
if (mod == 2) {
... code for modifier value 2 goes here ...
}
}
</syntaxhighlight>

If you have 2 modifiers, as in the case of the Saitek Yoke with modes and a modifier button, then you need to nest the if clauses.
<syntaxhighlight lang ="php">
var button1 = func(alter, mode) {
if (mode == 1) {
if (alter) {
... Mode 1, mod button pressed ...
} else {
... Mode 1, mod button not pressed ...
}
}
if (mode == 2) {
if (alter) {
... Mode 2, mod button pressed ...
} else {
... Mode 2, mod button not pressed ...
}
}
}
if (mode == 3) {
if (alter) {
... Mode 3, mod button pressed ...
} else {
... Mode 3, mod button not pressed ...
}
}
}
</syntaxhighlight>

=== Populating the Nasal file ===

Now you need to put in all the code.
Have the printout of the xml file handy, it is easier than switching between files.
The equivalent code for most actions is available in numerous places, but some equivalents will be supplied below. And you can always ask on the Hardware forum for the Nasal equivalents of xml code.

Enter all the code.

=== Testing your code ===

If you use an editor such as gedit (multi-platform, free) which has line-numbers, it makes the task soooo much easier.

Run FG, keeping an eye on the "black window." If you don't see Loading myfilename.nas, then there is a mistake in the xml file.
If you get a parse error when starting FG, then you have a basic mistake in your Nasal file. The first entry after parse error is the line number to look for.
If you get a parse when pressing a button, then the error is in the code for that button.

== Nasal equivalents to xml code ==

If your xml code has
<syntaxhighlight lang="xml">
<command>nasal</command>
<script>blah blah</script>
</syntaxhighlight>
then you can use the bit between <script> and </script> as is.

Elevator Trim
<syntaxhighlight lang="xml">
<command>property-scale</command>
<property>/controls/flight/elevator</property>
<factor type="double">1.0</factor>
<squared type="bool">true</squared>
</syntaxhighlight>
becomes
<syntaxhighlight lang="nasal">
controls.elevatorTrim(1);
</syntaxhighlight>
The 1 becomes -1 for the other direction. Just substitute ''ruder'' and ''aileron'' for the others.

View Direction
<syntaxhighlight lang="xml">
<command>property-adjust</command>
<property>/sim/current-view/goal-heading-offset-deg</property>
<step type="double">1.0</step>
</syntaxhighlight>
becomes
<syntaxhighlight lang="nasal">
controls.slewProp("/sim/current-view/goal-heading-offset-deg", 15);
</syntaxhighlight>
You can fiddle with the 15 to make it slower or faster. Make it -15 for the other direction. Change ''goal-heading'' to ''goal-pitch'' for up and down.

Zoom
<syntaxhighlight lang="xml">
<command>property-adjust</command>
<property>/sim/current-view/field-of-view</property>
<step type="double">0.5</step>
</syntaxhighlight>
becomes
<syntaxhighlight lang="nasal">
view.increase(0.5);
</syntaxhighlight>
Use view.decrease to zoom out.

[[Category:Howto]]
[[Category:Hardware]]
[[Category:Joysticks and Yokes]]

Joystick/SimpedGameport

2016-07-29T12:16:00Z

Tipunch: Category:Joysticks and Yokes

How to setup the "analog" (non-USB) Simped rudder pedals in ubuntu Linux.
Hardware needed:
* 2nd hand Simped pedals
* a PCI Soundblaster Soundcard with DB15 gameport connector

~/.fgfs/Input/Joysticks/simped4.xml
<syntaxhighlight lang="xml">

<PropertyList>

<name>Analog 4-axis 4-button joystick</name>

<axis n="1">
<desc>Rudder</desc>
<binding>
<command>property-scale</command>
<property>/controls/flight/rudder</property>
<factor type="double">1.0</factor>
<squared type="bool">true</squared>
</binding>
</axis>

</PropertyList>

</syntaxhighlight>

/etc/modules
<syntaxhighlight>
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

lp
rtc

# Generated by sensors-detect on Sun Mar 10 01:48:26 2013
# Chip drivers
coretemp

#gameport joystick & Pedal
analog

</syntaxhighlight>

/etc/modprobe.d/alsa-base.conf
<syntaxhighlight>
.
.
.
.
options snd-ens1371 joystick_port=1
</syntaxhighlight>

[[Category:Hardware]]
[[Category:Joysticks and Yokes]]

Category:Joysticks and Yokes

2016-07-29T12:15:23Z

Tipunch: new category

Content related to joysticks, yokes and pedals.

[[Category:FlightGear]]

Joystick autopilot bindings

2016-07-29T12:12:42Z

Tipunch: Category:Joysticks and Yokes

This page describes joystick bindings, which can be used to control the (simulated) autopilot with a set of joystick buttons.

== Prerequisites ==
Before you start, read [[Input device]] and probably [[Writing Joystick Code: Part 1]].

== Introduction ==
Autopilots are often very useful devices, but unfortunately the standard key bindings of Flightgear control the `magic autopilot' rather than the simulated real ones, and the only way to control popular GA autopilots is by clicking the corresponding buttons in the 3D-cockpit. This is awkward if there is a need to change mode or turn off the autopilot quickly (at final stage of ILS landing, or if the autopilot does something silly).

Every type of autopilot is operated quite differently, such that these keys only work for specific models. Here, key bindings are provided for the [[Bendix/King KAP140 Autopilot]] (in the [[Cessna 172]]) and the [http://www.centuryflight.com/manuals/CENTIII.pdf CENTURY III Autopilot POH] ([[Seneca II]]).
Those were prioritised, as the more complex autopilots in jets usually have a dedicated GUI and therefore maybe less in need of joystick binding. However, it is planned to provide bindings for at least basic functions like AUTOPILOT OFF for other autopilot types in the future.

== Implementation ==
The example code provides a setup for six buttons arranged like this:

4 5 6<br />
9 8 7

(this happens to be suitable for the Thrustmaster T16000M but it can be adapted trivially to other button numbers by simply changing the button numbers in the snippets below).
In the following snippets for each functionality are provided - usually one with the actual binding and some corresponding initialisation code (placed between nasal tags at the beginning of the script). You need to copy/paste both into your joystick bindings xml file. In the summary the code of all snippets is provided in one code box for convenience but you learn more if you consider each snippet in turn. Generally, it was attempted to have largely consistent bindings for the different autopilot types, but because they are operated quite differently, this was not entirely possible, and it was attempted to stay close to the mode of operation of the actual instruments.

=== Generic initialisation code ===
On startup, we need to figure out whether we are dealing with a Bendix KAP 140 or CENTURY III autopilot.
<syntaxhighlight lang="nasal" >
<nasal>

<script><![CDATA[
var autopilottype=0;
var horizontalmode=0;
if (getprop("sim/aircraft")=="c172p") {
print("JOYSTICK INIT: Found KAP140 autopilot");
autopilottype=1;
} elsif (getprop("autopilot/CENTURYIII/power")>-1) {
print("JOYSTICK INIT: Found CENTURYIII autopilot");
autopilottype=2;
}
....
]]></script>
</nasal>

</syntaxhighlight>
As you can see it assumes only the Cessna 172 has the KAP-140. If there is another plane with this autopilot the condition should be adjusted.

=== Major mode selection ===
Button 4 turns the autopilot on or off (toggle switch).
With modifiers:<br />
(SHIFT) HDG mode toggle (the details of this mode are controlled by button 4)<br />
(CTRL) PITCH mode toggle (CENTURYIII only!)<br />
(ALT) ALT mode toggle (KAP140: switches between VS and ALT vertical modes. CENTURYIII: turns on and off ALT mode)

Button settings:
<syntaxhighlight lang="xml">
<button n="4">
<repeatable type="bool">false</repeatable>
<desc>Autopilot Toggle / HDG mode toggle / PITCH mode / ALT mode </desc>
<binding>
<condition><property>/autopilot/CENTURYIII/controls/roll/button-state</property></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/disconnect</property>
<value>1</value>
</binding>
<binding>
<condition><not><property>/autopilot/CENTURYIII/controls/roll/button-state</property></not></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/roll/button-on</property>
<value>1</value>
</binding>
<binding>
<command>nasal</command>
<script>
if ( autopilottype == 1 ) {
kap140.apButton();
if ( getprop("autopilot/KAP140/locks/roll-mode") == 0 ) {
gui.popupTip("AP off");
} else {
gui.popupTip("AP on");
}
}
</script>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/disconnect</property>
<value>0</value>
</binding>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/roll/button-on</property>
<value>0</value>
</binding>
<binding>
<command>nasal</command><script>
if ( autopilottype == 2 ) {

if ( getprop("autopilot/CENTURYIII/controls/roll/button-state") ) {
gui.popupTip("AP ROLL on");
} else {
gui.popupTip("AP ROLL off");
}
}
</script>
</binding>
</mod-up>
<mod-shift>
<binding>
<condition><property>/autopilot/CENTURYIII/controls/hdg/button-state</property></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/hdg/button-off</property>
<value>1</value>
</binding>
<binding>
<condition><not><property>/autopilot/CENTURYIII/controls/hdg/button-state</property></not></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/hdg/button-on</property>
<value>1</value>
</binding>
<binding>
<command>nasal</command>
<script>
if ( autopilottype == 1 ) {
kap140.hdgButton();
if ( getprop("autopilot/KAP140/locks/roll-mode") == 2 ) {
gui.popupTip("AP HDG");
} elsif ( getprop("autopilot/KAP140/locks/roll-mode") == 1 ) {
gui.popupTip("AP ROL");
}
}
</script>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/hdg/button-off</property>
<value>0</value>
</binding>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/hdg/button-on</property>
<value>0</value>
</binding>
<binding>
<command>nasal</command><script>
if ( autopilottype == 2 ) {

if ( getprop("autopilot/CENTURYIII/controls/hdg/button-state") ) {
gui.popupTip("AP HDG on");
} else {
gui.popupTip("AP HDG off");
}
}
</script>
</binding>
</mod-up>
</mod-shift>
<mod-ctrl>
<binding>
<condition><property>/autopilot/CENTURYIII/controls/pitch/button-state</property></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/pitch/button-off</property>
<value>1</value>
</binding>
<binding>
<condition><not><property>/autopilot/CENTURYIII/controls/pitch/button-state</property></not></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/pitch/button-on</property>
<value>1</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/pitch/button-off</property>
<value>0</value>
</binding>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/pitch/button-on</property>
<value>0</value>
</binding>
<binding>
<command>nasal</command><script>
if ( autopilottype == 2 ) {

if ( getprop("autopilot/CENTURYIII/controls/pitch/button-state") ) {
gui.popupTip("AP PITCH on");
} else {
gui.popupTip("AP PITCH off");
}
}
</script>
</binding>
</mod-up>
</mod-ctrl>
<mod-alt>
<binding>
<command>nasal</command>
<script>if (autopilottype==1 ) {
kap140.altButton();
if ( getprop("autopilot/KAP140/locks/pitch-mode") == 2 ) {
gui.popupTip("AP ALT");
} elsif ( getprop("autopilot/KAP140/locks/pitch-mode") == 1 ) {
gui.popupTip("AP VS");
}
}
</script>
</binding>
<binding>
<condition><property>/autopilot/CENTURYIII/controls/alt/button-state</property></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/alt/button-off</property>
<value>true</value>
</binding>
<binding>
<condition><not><property>/autopilot/CENTURYIII/controls/alt/button-state</property></not></condition>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/alt/button-on</property>
<value>true</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/alt/button-off</property>
<value>false</value>
</binding>
<binding>
<command>property-assign</command>
<property>autopilot/CENTURYIII/controls/alt/button-on</property>
<value>false</value>
</binding>
<binding>
<command>nasal</command>
<script>
if(autopilottype==2) {
if ( getprop("autopilot/CENTURYIII/controls/alt/button-state")) {
gui.popupTip("AP ALT on");
} else {
gui.popupTip("AP ALT off");
}
}
</script>
</binding>
</mod-up>
</mod-alt>
</button>
</syntaxhighlight>

=== Horizontal mode selection ===
Button 5 controls the source of course selection in HDG mode (for the LOC and APR modes, the vertical mode is also affected, of course). It works quite differently in the two autopilots:
* KAP140: (no modifier) NAV mode: track radial of VOR1 beacon. Press again to go back to follow set heading<br />
(SHIFT) APR mode: track ILS beacon (set radial to runway orientation). If glideslope is approached from below in ALT mode, lock on to localiser <br />
(CTRL) REV mode: track reverse ILS direction<br />
* CENTURYIII: Move mode selector button to the right (clockwise) <br />
(SHIFT) Move mode selector button to the left (anti-clockwise) <br />
Both directions are wrapped, i.e. you can keep pressing the button until you arrive at the selected mode. In turn, the modes selected are: NAV, OMNI, HDG, LOC NORM, LOC REV. Please refer to the CENTURYIII manual for further explanation.

Initialisation:
<syntaxhighlight lang="nasal">
var showhorizontalmode=func() {
if ( autopilottype == 1 ) {
if ( getprop("autopilot/KAP140/locks/roll-arm") == 1 ) {
gui.popupTip("AP NAV");
} elsif ( getprop("autopilot/KAP140/locks/roll-arm") == 2 ) {
gui.popupTip("AP APR");
} elsif ( getprop("autopilot/KAP140/locks/roll-arm") == 3 ) {
gui.popupTip("AP REV");
}
}
if (autopilottype == 2) {
horizontalmode=getprop("autopilot/CENTURYIII/controls/mode");
if ( horizontalmode==0) {
gui.popupTip("APmode NAV");
} elsif ( horizontalmode==1) {
gui.popupTip("APmode OMNI");
} elsif ( horizontalmode==2) {
gui.popupTip("APmode HDG");
} elsif ( horizontalmode==3) {
gui.popupTip("APmode LOC");
} elsif ( horizontalmode==4) {
gui.popupTip("APmode REV");
}
}
}
</syntaxhighlight>

Button settings:
<syntaxhighlight lang="nasal">
<button n="5">
<repeatable type="bool">false</repeatable>
<desc>KAP140: NAV / APR / REV ; CENTURYIII:
Move Hdg select button to the right (wrap)</desc>
<binding>
<command>property-adjust</command>
<property>autopilot/CENTURYIII/controls/mode</property>
<step type="double">1</step>
<min>0</min>
<max>5</max>
<wrap>true</wrap>
</binding>
<binding>
<command>nasal</command>
<script>
if (autopilottype==1) {
kap140.navButton(); }
showhorizontalmode();
</script>
</binding>
<mod-shift>
<binding>
<command>property-adjust</command>
<property>autopilot/CENTURYIII/controls/mode</property>
<step type="double">-1</step>
<min>0</min>
<max>5</max>
<wrap>true</wrap>
</binding>
<binding>
<command>nasal</command>
<script>
if (autopilottype==1) { kap140.aprButton();}
showhorizontalmode();
</script>
</binding>
</mod-shift>
<mod-ctrl>
<binding>
<command>nasal</command>
<script> if (autopilottype==1) { kap140.revButton();}
showhorizontalmode();
</script>
</binding>
</mod-ctrl>
</button>
</syntaxhighlight>

=== Vertical mode pitch or vertical speed selector ===
Control the vertical mode.

* KAP140: Button 6 increases target VS by 100 ft/min, button 7 decreases target VS by 100 ft/min
* CENTURYIII: Button 6 smoothly lowers pitch (nose down), button 7 increases pitch (nose up)

The opposite way these buttons work for the two types of autopilot arises from the arrangement in the cockpit. For the CENTURYIII, the pitch is controlled by a wheel, which needs to be moved up to lower the nose (similar to elevator trim wheels), whereas for the KAP140 two buttons are arranged such that the top button increases target VS.

Initialisation:
<syntaxhighlight lang="nasal">
var showvertical=func() {if ( autopilottype==1 ) {
if ( getprop("autopilot/KAP140/locks/pitch-mode") == 1 ) {
gui.popupTip(sprintf("AP VS
%d",getprop("autopilot/KAP140/settings/target-pressure-rate")*(-58000)));
}
} elsif ( autopilottype==2 ) {
gui.popupTip(sprintf("AP Pitch:%4.1f",getprop("autopilot/CENTURYIII/settings/pitch-wheel-deg")));
}}
</syntaxhighlight>
Button settings:
<syntaxhighlight lang="nasal">
<button n="6">
<repeatable type="bool">false</repeatable>
<desc>AP-VS (KAP140:increase VS, CENTURYII: pitch down</desc>

<binding>
<command>nasal</command>
<script>if (autopilottype==1) {
kap140.upButton();
}
showvertical();
</script>
</binding>

<binding>
<command>property-interpolate</command>
<property>/autopilot/CENTURYIII/settings/pitch-wheel-deg</property>
<value type="double">-10</value>
<rate>4</rate>
</binding>
<mod-up>
<binding>
<command>property-interpolate</command>
<property>/autopilot/CENTURYIII/settings/pitch-wheel-deg</property>
<property>/autopilot/CENTURYIII/settings/pitch-wheel-deg</property>
<rate>1</rate>
</binding>
<binding>
<command>nasal</command>
<script>
if(autopilottype==2) { showvertical(); }
</script>
</binding>
</mod-up>
</button>

#7: Autopilot VS down
<button n="7">
<repeatable type="bool">false</repeatable>
<desc>AP-dn</desc>

<binding>
<command>nasal</command>
<script>if (autopilottype==1) {
kap140.downButton();
}
showvertical();
</script>
</binding>

<binding>
<command>property-interpolate</command>
<property>/autopilot/CENTURYIII/settings/pitch-wheel-deg</property>
<value type="double">10</value>
<rate>4</rate>
</binding>
<mod-up>
<binding>
<command>property-interpolate</command>
<property>/autopilot/CENTURYIII/settings/pitch-wheel-deg</property>
<property>/autopilot/CENTURYIII/settings/pitch-wheel-deg</property>
<rate>1</rate>
</binding>
<binding>
<command>nasal</command>
<script>
if(autopilottype==2) { showvertical(); }
</script>
</binding>
</mod-up>
</button></syntaxhighlight>
=== Horizontal mode direction selector ===
Adjust heading bug (button 8 clockwise and button 9 anti-clockwise).

With modifiers:<br />
(SHIFT) coarse heading bug adjustment<br />
(CTRL) adjust bank angle (CENTURY III only!)<br />
(ALT) adjust radial of NAV1 (can also be used without autopilot)<br />

Initialisation:
<syntaxhighlight lang="nasal" >
var showhdgbug=func() {if ( autopilottype==1 ) {
gui.popupTip(sprintf("Heading Bug:%3d",getprop("autopilot/settings/heading-bug-deg")));
} elsif ( autopilottype==2 ) {
gui.popupTip(sprintf("Hdg Bug:%3d",getprop("instrumentation/kcs55/ki525/selected-heading-deg")));
}}
var showroll=func() { if ( autopilottype==2 ) {
gui.popupTip(sprintf("AP Roll:%2d",getprop("autopilot/CENTURYIII/settings/roll-knob-deg")));}}
var showcourseselect=func() {
if ( autopilottype==1 ) {
gui.popupTip(sprintf("Course select:%2d",getprop("instrumentation/nav/radials/selected-deg")));
} elsif ( autopilottype==2 ) {
gui.popupTip(sprintf("Course select:%2d",getprop("instrumentation/kcs55/ki525/selected-course-deg")));}}
</syntaxhighlight>

Button definition:
<syntaxhighlight lang="xml" >
<button n="8">
<desc>Heading bug CW / Heading bug CW large steps /
(CENTURYIII:)Roll knob turn right / Course select CW</desc>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/autopilot/settings/heading-bug-deg</property>
<step type="double">0.25</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>property-adjust</command>
<property>instrumentation/kcs55/ki525/selected-heading-deg</property>
<step type="double">0.25</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>nasal</command>
<script>
showhdgbug();
</script>
</binding>
<mod-shift>
<binding>
<command>nasal</command>
<script>
showhdgbug();
</script>
</binding>
<binding>
<command>property-adjust</command>
<property>/autopilot/settings/heading-bug-deg</property>
<step type="double">2.5</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>property-adjust</command>
<property>instrumentation/kcs55/ki525/selected-heading-deg</property>
<step type="double">2.5</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>nasal</command>
<script>
showhdgbug();
</script>
</binding>
</mod-shift>
<mod-ctrl>
<binding>
<command>property-adjust</command>
<property>/autopilot/CENTURYIII/settings/roll-knob-deg</property>
<step type="double">0.5</step>
<max>30</max>
</binding>
<binding>
<command>nasal</command>
<script>
showroll();
</script>
</binding>
</mod-ctrl>
<mod-alt>
<binding>
<command>property-adjust</command>
<property>instrumentation/nav/radials/selected-deg</property>
<step type="double">0.25</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>property-adjust</command>
<property>instrumentation/kcs55/ki525/selected-course-deg</property>
<step type="double">0.25</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>nasal</command>
<script>
showcourseselect();
</script>
</binding>
</mod-alt>
</button>

<button n="9">
<desc>Heading bug CCW / Heading bug CCW large steps</desc>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/autopilot/settings/heading-bug-deg</property>
<step type="double">-0.25</step>
</binding>
<binding>
<command>property-adjust</command>
<property>instrumentation/kcs55/ki525/selected-heading-deg</property>
<step type="double">-0.25</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>nasal</command>
<script>
showhdgbug();
</script>
</binding>
<mod-shift>
<binding>
<command>property-adjust</command>
<property>/autopilot/settings/heading-bug-deg</property>
<step type="double">-2.5</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>property-adjust</command>
<property>instrumentation/kcs55/ki525/selected-heading-deg</property>
<step type="double">-2.5</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>nasal</command>
<script>
showhdgbug();
</script>
</binding>
</mod-shift>
<mod-ctrl>
<binding>
<command>property-adjust</command>
<property>/autopilot/CENTURYIII/settings/roll-knob-deg</property>
<step type="double">-0.5</step>
<min>-30</min>
</binding>
<binding>
<command>nasal</command>
<script>
showroll();
</script>
</binding>
</mod-ctrl>
<mod-alt>
<binding>
<command>property-adjust</command>
<property>instrumentation/nav/radials/selected-deg</property>
<step type="double">-0.25</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>property-adjust</command>
<property>instrumentation/kcs55/ki525/selected-course-deg</property>
<step type="double">-0.25</step>
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
<binding>
<command>nasal</command>
<script>
showcourseselect();
</script>
</binding>
</mod-alt>
</syntaxhighlight>

== Summary ==
For convenience all of the above bindings are summarised into one file accessible at [http://pastebin.com/2HM9S1df pastebin] (at the time of writing identical to the combination of the snippets above but of course the pastebin might not always keep up with the Wiki - beware)

[[Category:Documentation]]
[[Category:Joysticks and Yokes]]

Key commands compared to other simulators

2016-07-28T12:05:38Z

Tipunch: Category:FlightGear keyboard

{{stub}}

When coming from an other simulator, [[FlightGear]]'s key commands might be confusing at first. To help you get started, some of the essential commands are listed on this page with the respective keys from various simulators.

=== Simulator commands ===
{| class="keytable"
|-
! Action
! FlightGear
! MSFS X
! X-Plane
|-
| Pause
| {{key press|p}}
| {{key press|p}}, {{key press|Break}}
| {{key press|p}}
|-
| Menus display/hide
| {{key press|F10}}, appears when the mouse pointer is at the top of the window
| Appears when the mouse pointer is at the top of the window
| {{key press|Alt}}
|-
| Exit Flight Simulator
| {{key press|Esc}}
| {{key press|Ctrl|c}}
|
|-
| Capture Screenshot
| {{key press|F3}}
| {{key press|Shift|V}}
| {{key press|Ctrl|.}}
|}

=== Control surface commands ===
{| class="keytable"
|-
! Action
! FlightGear
! MSFS X
! X-Plane
|-
|Ailerons (bank left)
| {{key press|NumPad 4}}, Left arrow key
| {{key press|NumPad 4}}
|
|-
| Ailerons (bank right)
| {{key press|NumPad 6}}, Right arrow key
| {{key press|NumPad 6}}
|
|-
| Rudder (yaw left)
| {{key press|NumPad 0}}
| {{key press|NumPad 0}}
|
|-
| Rudder (yaw right)
| {{key press|NumPad Enter}}
| {{key press|NumPad Enter}}
|
|-
| Center Ailerons and Rudder
| {{key press|NumPad 5}}
| {{key press|NumPad 5}}
| {{key press|9}} (ailerons) and {{key press|6}} (rudder)
|-
| Pitch Down (elevator)
| {{key press|NumPad 8}}, Up arrow key
| {{key press|NumPad 8}}
|
|-
| Pitch Up (elevator)
| {{key press|NumPad 2}}, Down arrow key
| {{key press|NumPad 2}}
|
|-
| Elevator Trim Down
| {{key press|NumPad 7}}
| {{key press|NumPad 7}}
| {{key press|]}}
|-
| Elevator Trim Up
| {{key press|NumPad 1}}
| {{key press|NumPad 1}}
| {{key press|[}}
|-
| Flaps (retract incrementally)
| {{key press|[}}
| {{key press|F6}}
| {{key press|1}}
|-
| Flaps (extend incrementally)
| {{key press|]}}
| {{key press|F7}}
| {{key press|2}}
|}

=== Engine commands ===
{| class="keytable"
|-
! Action
! FlightGear
! MSFS X
! X-Plane
|-
| Reverse Thrust (turboprops/jets)
| {{key press|Delete}} (on/off)
| {{key press|F2}} (press and hold)
| {{key press|.}} (on/off)
|-
| Throttle (decrease)
| {{key press|PgDn}}
| {{key press|F2}} or {{key press|NumPad 3}}
| {{key press|F1}}
|-
| Throttle (increase)
| {{key press|PgUp}}
| {{key press|F3}} or {{key press|NumPad 9}}
| {{key press|F2}}
|}

=== General aircraft commands ===
{| class="keytable"
|-
! Action
! FlightGear
! MSFS X
! X-Plane
|-
| Brakes (apply left brake)
| {{key press|,}}
| {{key press|Numpad +}}
|
|-
| Brakes (apply right brake)
| {{key press|.}}
| {{key press|Numpad -}}
|
|-
|Landing Gear (extend/retract)
| {{key press|g}}/{{key press|Shift|g}}
| {{key press|Shift|g}}
| {{key press|Shift|g}}
|}

=== View commands ===
{| class="keytable"
|-
! Action
! FlightGear
! MSFS X
! X-Plane
|-
| View (default zoom)
| {{key press|Ctrl|X}}
| {{key press|Backspace}}
|
|-
|Zoom In
| {{key press|x}}
| {{key press|<nowiki>=</nowiki>}}
| {{key press|<nowiki>=</nowiki>}} (normal), {{key press|Shift|<nowiki>=</nowiki>}} (fast)
|-
|Zoom Out
| {{key press|Shift|X}}
| {{key press|<nowiki>-</nowiki>}}
| {{key press|<nowiki>-</nowiki>}} (normal), {{key press|Shift|<nowiki>-</nowiki>}} (fast)
|}

{{Appendix|all|
* {{cite web |url=http://www.x-plane.com/files/MSFS_XP_keys.pdf.zip |title=Help for MSFS users |date=2 February 2009 |publisher=X-Plane |accessdate=27 February 2012 }}
}}
[[Category:FlightGear keyboard]]

Keyboard shortcuts

2016-07-28T12:03:54Z

Tipunch: Category:FlightGear keyboard

{{stub}}
Cheat sheet for using the most common keyboard shortcuts. Many planes have their own specific shortcuts, so not all of these shortcuts will apply. They're worth a shot though if your aircraft just isn't quite behaving as you would like it.
{| class="vatop"
|width="500" |
=== General ===
{| class="wikitable sortable" border="0" cellspacing="0"
|-
! style="background:#efefef" | Key combination
! style="background:#efefef" | Action
|-
|/
|Show [[property browser]]
|-
|?
|Show current aircraft specific help
|-
|:
|vi-like [[multikey commands]]
|-
|,
|Apply left brakes
|-
|.
|Apply right brakes
|-
|M
|Show map
|-
|Ctrl-C
|Toggle [[Howto: Make a clickable panel|clickable panel hotspots]]
|-
|Esc
|Quit FlightGear
|-
|h
|Cycle through [[HUD]] styles
|-
|H
|Cycle through [[HUD]] brightnesses
|-
|F3
|Print screen
|-
|F10
|Toggle [[menu]]bar visibility
|-
|F11
|Open [[autopilot]] dialog
|-
|F12
|Open radio settings dialog
|-
|p
|Pause/continue sim
|-
|P
|Toggle [[2D panel]]
|-
|Shift-Esc
|Reset FlightGear
|-
|Shift-F1
|Load flight
|-
|Shift-F2
|Save flight
|-
|Shift-F5
|Scroll 2D panel down
|-
|Shift-F6
|Scroll 2D panel up
|-
|Shift-F7
|Scroll 2D panel left
|-
|Shift-F8
|Scroll 2D panel right
|-
|Shift-F10
|Cycle through GUI styles
|}

=== View ===
{| class="wikitable sortable" border="0" cellspacing="0"
|-
! style="background:#efefef" | Key combination
! style="background:#efefef" | Action
|-
|Ctrl-X
|Reset zoom to default
|-
|v
|Next view
|-
|V
|Previous view
|-
|x
|Zoom in
|-
|X
|Zoom out
|-
|z
|Increase visibility
|-
|Z
|Decrease visibility
|-
|Ctrl-R
|Instant replay
|}
|width="500"|
=== Flying ===
{| class="wikitable sortable" border="0" cellspacing="0"
|-
! style="background:#efefef" | Key combination
! style="background:#efefef" | Action
|-
|}}} s
|Start a propeller engine ("}" x3 to set magneto, then hold "s" to start)
|-
|/
|Show [[property browser]]
|-
|b
|Apply all brakes
|-
|B
|Toggle parking brake(s)
|-
|g
|Gear up
|-
|G
|Gear down
|-
|j
|Spoilers/air brake down
|-
|k
|Spoilers/air brake up
|-
|[
|Flaps up
|-
|]
|Flaps down
|}

=== Autopilot ===
{| class="wikitable sortable" border="0" cellspacing="0"
|-
! style="background:#efefef" | Key combination
! style="background:#efefef" | Action
|-
|Ctrl-A
|Altitude lock
|-
|Ctrl-H
|Heading lock
|-
|Ctrl-G
|Glideslope lock
|-
|Ctrl-N
|NAV1 lock
|-
|Ctrl-P
|Pitch hold
|-
|Ctrl-S
|Autothrottle
|-
|Ctrl-T
|Terrain lock
|-
|Ctrl-W
|Wing level
|-
|F6
|Heading lock
|}
|}
[[Category:FlightGear keyboard]]

Keyboard function priority list

2016-07-28T12:03:19Z

Tipunch: Category:FlightGear keyboard

{{Template:RFC Navigation}}

{{cquote|My point of view is that the current keybindings file is a mess, with many historical bindings, and also it binds in the ASCII space, as opposed to the scan code space, so we can't distinguish keypad vs normal number keys, and various other combinations, even though osgViewer supports that.

My *personal* feeling is that unless it's something the > 50% of users use *each flight*, it shouldn't be a keybinding. So flaps, trim, CDI/HSI heading,
fine, but things to change view distance or FoV seem unnecessary to me.

The other issue is the keybindings are effectively 'full' (we can't easily add more), because they've been added and added over the years, but rarely removed, so at this point every key 'does something', but often something quite obscure.

What I'd like to see is the entire 'Ctrl' (Command on Mac) space reserved for GUI functions, like a normal application - Ctrl-Q for quit, Ctrl-M for map dialog, Ctrl-A for autopilot dialog, Ctrl-R for replay dialog (or radios dialog :) - then have a complete discussion about which key-bindings make sense on
the main keyboard. This is basically a usability discussion, so everyone will have strong opinions :)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39648.html |title= Keyboard bindings|author=James Turner |date= Sun, 03 Mar 2013}}</ref>|James Turner}}

{{cquote|<nowiki>A separate step, much harder to make happen, would be to explicitly reserve the
Ctrl (Command on Mac) keybinding space for menu/non-aircraft keyboard
shortcuts. I would really like to do this so we can have user-friendly
key-bindings for dialogs and standard items, such as Ctrl-Q to quit, Ctrl-A for
autopilot dialog, Ctrl-P for pause, Ctrl-R for reply, etc. [And the entire
normal key / key + shift / key+alt ranges available FOR aircraft functions, of
course) The problem is right now we have aircraft using Ctrl- shortcuts for
many things (usually because they're the only choice), and I can't decide a
sane way to migrate to this split without lots of breakage and frustration. Any
ideas welcome.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40838.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}

{{cquote|<nowiki>the problem is the OSs have already decreed that Ctrl (Command on Mac) is
the standard shortcut key, so lots of Ctrl-something have standard meanings
which FlightGear deviates from. Though we escape the worst of it since we don't
support file or edit operations.

Keep in mind if the GUI things such as dialogs were moved to Ctrl-blah, that
frees up lots of normal keys for use, which are currently taken up by simulator
things. While I agree Ctrl is probably the easiest modifier to access (except
maybe shift, since there's two, so it's more friendly for left-handed people),
I think by this logic a shortcut with *no* modifiers is even easier to access,
and that's an argument in *favour* of such change :)</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40853.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}

{{cquote|<nowiki>this actually shows a larger problem. Obviously it isn't too
uncommon for aircraft to disable or override specific menu items -
mainly affects menu items for the radio stack and autopilot.
Unfortunately all of this is done using fixed menu item positions -
e.g. 5th menu, 3rd item... So any change of the menu item ordering
currently breaks lots of planes. And obviously the recent menubar
overhaul has done just that.
We'll need to adapt all the aircraft using such hacks to the changed
menu structure. And might need to think about a better solution to
avoid future problems of this kind.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30166.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}

{{cquote|<nowiki>IMO the menu reordering represents a significant usability improvement and is
something we want to encourage. Furthermore backing it out will also require
changes to the manual, so isn't quite as straightforward as it might seem at
first.

I think the number of affected theses aircraft is sufficiently small that they
can be updated to fix this. Aircraft maintainers have always had to keep up
with changes in the core code (e.g. The ambient material change) and this is no
different except that it has only been noticed fairly late in the release
cycle.

Aircraft outside of the shears repository are not restricted to our release
cycle and can be updated after the release as and when their maintainers notice
this issue. I suspect that a number are waiting for the release to test their
aircraft anyway.

Adding symbolic names along with some helper functions for disabling them in
Nasal/gui.nas is pretty easy. I'm happy to take on writing the code etc.
Probably not today though!</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30178.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}

{{cquote|<nowiki>It turns out that Nasal/gui.nas already had a menuEnable function for
enabling or disabling entire menus or individual menu items using
unique names rather than the labels. Names already exist for the
autopilot menu and the Fuel & Payload dialog. So, the fix is for the
aircraft to make use of this e.g.

gui.menuEnable("fuel-and-payload", false);

We can add new names for any other menus that we might want to disable
on a per-aircraft basis, but from a quick skim through the menus I
couldn't see any other candidates.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30188.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}

{{cquote|<nowiki>Going through the aircraft highlighted a number of functions that
aren't covered by the existing enable/disable function in gui.nas
1) Replacing the autopilot dialog with another.
2) Adding pushback. Most aircraft add this to the Equipment menu

I'll need to think about how to handle these cases.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30194.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}

{{cquote|<nowiki>The following aircraft override the radio dialog, which has moved since v2.0.0.

777-200ER
b1900d
Citation-Bravo

I've just pushed an enhancement to gui.nas that allows the aircraft developer to
change the binding for a symbolically named dialog, in the same way
that they can
enable/disable dialogs and menus using the existing gui.menuEnable() function.

So, you can now put the following code in your aircraft-specific Nasal files:

gui.menuBind("radio", "dialogs.Radio.open()");

This replaces the binding for the "radio" menu item with a command to open the
dialogs.Radio dialog box (that you've defined elsewhere).

Note that this searches the menu for the symbolic names (name tag) defined in
menubar.xml, (e.g. radio, autopilot-settings, gps, map) rather than
the label tag,
which may change over time, so should be a robust long-term solution.
</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30208.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}

<references/>

As a first step in the keyboard refactoring, we need to come up with a prioritized list of functions that (a) are general enough to apply to most (or at least many) aircraft, and (b) are important enough to justify a keyboard shortcut rather than just a menu/dialog or a model hotspot.

Feel free to add to the list, but please don't delete anything — just move it to the bottom if you don't think it's important.

As we'll probably not want to change too many existing key-bindings, The current CVS key-binding is also listed in brackets.

* Program
** Pause {{Key press|P}}
** Exit {{Key press|Esc}}
** Show/Hide menu {{Key press|F10}}
* Primary flight controls
** ailerons {{Key press|Left}} / {{Key press|Right}}, {{Key press|4}} / {{Key press|6}}
** elevator {{Key press|Up}} / {{Key press|Down}}, {{Key press|8}} / {{Key press|2}}
** rudder {{Key press|0}} / {{Key press|Enter}}, {{Key press|Insert}}
** centre controls {{Key press|5}}
* Primary powerplant
** throttle — ''for helicopters, should the same key control the collective?'' {{Key press|3}} / {{Key press|9}}, {{Key press|Page up}} / {{Key press|Page down}}
** Winch / Aerotow (begin winching, open hitch etc)
* View controls
** view reset {{Key press|Ctrl|V}}
** look left/right {{Key press|Shift|4}} / {{Key press|Shift|6}}
** look up/down
** look forward/backwad {{Key press|Shift|8}} / {{Key press|Shift|2}}
** zoom in/out {{Key press|X}} / {{Key press|Shift|X}}
** change view type — ''e.g. cockpit, chase plane, tower, etc.'' {{Key press|V}} / {{Key press|Shift|V}}
* Secondary flight controls
** flaps extend/retract {{Key press|<nowiki>[</nowiki>}} / {{Key press|<nowiki>]</nowiki>}}
** landing gear raise/retract {{Key press|G}} / {{Key press|Shift|G}}
** elevator trim up/down {{Key press|1}} / {{Key press|7}}, {{Key press|Home}} / {{Key press|End}}
** speed brakes extend/retract {{Key press|Ctrl|B}}
** spoilers extend/retract {{Key press|J}} / {{Key press|K}}
** slats extend/retract
** toggle tailwheel lock {{Key press|1}}
** differential toe brakes left/right {{Key press|,}} / {{Key press|.}}
** parking brake {{Key press|Shift|B}}
** drag chute deploy/jettison
** aileron trim left/right
** rudder trim left/right
* Secondary powerplant
** mixture — ''piston aircraft only'' {{Key press|Shit|M}} / {{Key press|M}}
** propeller — ''some piston aircraft only'' {{Key press|Shift|N}} / {{Key press|N}}
** carburettor heat — ''some piston aircraft only''
** magneto/ignition selection {{Key press|<nowiki>{</nowiki>}} / {{Key press|<nowiki>}</nowiki>}}
** Select engines {{Key press|~}} / {{Key press|@}} / {{Key press|!}} / {{Key press|#}} / {{Key press|$}} <small>(Note: These keys are problematic on some keyboard layouts, e.g. Swedish where IIRC '~', '@' and'$' are at inconvenient locations. Is there a way to capture number key + shift instead of whatever "strange" symbol the English keyboard layout maps to that key?)</small>
* Autopilot
** engage/disengage
** toggle heading mode {{Key press|Ctrl|H}}
** toggle altitude mode {{Key press|Ctrl|A}}
** toggle wing leveller {{Key press|Ctrl|W}}
** toggle speed mode (auto-throttle) {{Key press|Ctrl|S}}
** autotrim engage/disengage
* Comms
** open/close text based chat console
** PTT switch {{Key press|Space}}
** active/standby com/nav channel swap
* Weapons
** fire primary weapon
** fire secondary weapon
** select secondary weapon
** jettison store
* Miscellaneous
** hoist deploy (helicopters)
** hoist up/down
** hoist jettison
** water/cargo release
** carrier launch bar engage
** carrier catapult release
** hook up/down (compatible A/C ''all modern jet fighters have a hook'')
** canopy toggle
** seat up/down/default

Things that don't require key bindings:
* throw turkey out of window (Les Nessman only)
* change viewing styles (dynamic view and g-force based view where supported)

[[Category:RFC]]
[[Category:FlightGear keyboard]]

Howto:Reassign keyboard bindings

2016-07-28T12:01:53Z

Tipunch: Category:FlightGear keyboard

{{WIP}}

A common request is how to change keys to do different commands. FlightGear makes this as easy as editing an XML file, and possibly adding a parameter to point FG to the new XML file.

In general, the list of keyboard commands is stored in the property tree and is loaded at startup or when the menu option "Debug -> Reload input" is selected. The main list of commands is available in {{fgdata source|path=keyboard.xml|pre=$FG_ROOT}}, but each aircraft can add/change its own bindings through its -set.xml file, and additional [[config file]]s can do the same.

== Adding or modifying key bindings ==
Keyboard bindings are usually fairly simple. They consist of a <tt><key></tt> node (with a corresponding index), optional <tt><name></tt> and <tt><desc></tt> nodes, and one or more <tt><binding></tt>s. A very simple example is the default for {{key press|Ctrl|V}}:

<syntaxhighlight lang="xml">
<key n="22">
<name>Ctrl-V</name>
<desc>Select initial view (view 0)</desc>
<binding>
<command>property-assign</command>
<property>/sim/current-view/view-number</property>
<value>0</value>
</binding>
</key>
</syntaxhighlight>

The initial tag (<tt><key n="22"></tt>) is used to identify the keycode; see the next section for how to find it for other keys. If this is not specified, FG won't have an accurate view of which key it is supposed to represent. The next two tags, <tt><name></tt> and <tt><desc></tt>, simply are there to describe the key and its function, respectively. They are not required but might be used for showing keyboard help information or other user-display uses. The <tt><binding></tt> tag is the functional aspect that gets executed when the key is pressed. The above example would be equivalent to this Nasal code:
<syntaxhighlight lang="nasal">setprop("/sim/current-view/view-number", 0)</syntaxhighlight>
For more on bindings and their different commands see the article about them: [[bindings]].

Here's a more complex binding, also from keyboard.xml, for {{key press|/}}:

<syntaxhighlight lang="xml">
<key n="47">
<name>/</name>
<desc>Open property browser</desc>
<binding>
<condition>
<not>
<property>/sim/input/property-key-handler</property>
</not>
</condition>
<command>nasal</command>
<script>gui.property_browser()</script>
</binding>
<binding>
<condition>
<property>/sim/input/property-key-handler</property>
</condition>
<command>nasal</command>
<script>prop_key_handler.start()</script>
</binding>
</key>
</syntaxhighlight>

This now has two bindings that execute based on a <tt><condition></tt> (see: [[conditions]]). The first executes if the property key handler development extension is ''not'' enabled, the second if it ''is'' enabled. Both execute a Nasal command: one to open the property browser, the other to start capturing keys (which will also open a browser if the user enters and path and hits {{key press|:}}).

Another common element is the <tt><mod-up></tt> event, which happens when the button is released. For example, the {{key press|S}} key fires the starter only as long as it is held down, via complementary commands on press and release:
<syntaxhighlight lang="xml">
<key n="115">
<name>s</name>
<desc>Fire Starter on Selected Engine(s)</desc>
<binding>
<command>nasal</command>
<script>controls.startEngine(1)</script>
</binding>
<mod-up>
<binding>
<command>nasal</command>
<script>controls.startEngine(0)</script>
</binding>
</mod-up>
</key>
</syntaxhighlight>

Other similar modifiers are the following:
* mod-up: release the key
* mod-shift: if {{key press|Shift}} is held down during event
* mod-ctrl: if {{key press|Ctrl}} is held down during event
* mod-alt: if {{key press|Alt}} is held down (rare)
* mod-meta: if {{key press|Meta}} is held down (rare)
* mod-super: if {{key press|Super}} is held down (very rare)
* mod-hyper: if {{key press|Hyper}} is held down (very rare)

(FIXME: describe more, esp. interaction with the key code...)

== Finding keycodes ==
As mentioned in keyboard.xml, "regular keycodes go up to 255; special keys start at 256, and can be calculated by adding 256 to the GLUT key value in glut.h."

For printable/ASCII keys (e.g. any letter of the alphabet, number, or symbol found on a keyboard), this is simply the ASCII value of the key.

=== Using the property browser ===
{{tip|You may want to press {{key press|p}} to pause the simulation first in order to not mess up something.}}

One of the easier ways to find out the key codes is to open up the [[property browser]] by pressing {{key press|/}} or {{key press|Shift|7}} and go to

* <code>/devices/status/keyboard/event/</code>
** <code>key= <nowiki>'A'</nowiki> (int)</code> – The key code of the currently or last pressed key
** <code>modifier/</code> – Key modifiers of the currently or last pressed key
*** <code>alt= <nowiki>'false'</nowiki> (bool)</code>
*** <code>ctrl= <nowiki>'false'</nowiki> (bool)</code>
*** <code>hyper= <nowiki>'false'</nowiki> (bool)</code>
*** <code>meta= <nowiki>'false'</nowiki> (bool)</code>
*** <code>shift= <nowiki>'true'</nowiki> (bool)</code>
*** <code>super= <nowiki>'false'</nowiki> (bool)</code>
** <code>pressed= <nowiki>'true'</nowiki> (bool)</code> – True if the key is currently pressed down

The above will be the values if you hold down {{key press|Shift|A}}.

=== Using a nasal script ===
An alternative would be to use Nasal (in the [[Nasal Console]] or [[Interactive Nasal REPL|REPL]]), with a simple script like this that will "pop up" the result:

<syntaxhighlight lang="nasal">
gui.popupTip(`a`); # replace with the key you want to test
</syntaxhighlight>

No matter what method you use, for "a" (lowercase), you should get 97; "A" (uppercase) is 67; "0" would be 48.

=== By looking in keyboard.xml ===
For non-printable characters, the simplest option is to look for the specific key (or control key) in keyboard.xml. For example, {{key press|Ctrl|N}} is found on line 154 in keyboard.xml, which reads:

<syntaxhighlight lang="xml">
<key n="14">
<name>Ctrl-N</name>
...
</key>
</syntaxhighlight>

Thus the key code is 14 (as well as the index of the key binding).

=== By enabling special debugging output ===
If the key isn't listed in keyboard.xml, the last option is to enable some helpful output to see what the correct keycode is. Uncomment {{fgdata source|path=keyboard.xml|line=39}} and run with the <tt>--console</tt> option, if on windows, and look at the console to see each keycode for each key. Make sure you can see the output as you press keys, or you won't know which is which! When I press and release {{key press|a}}, I get this output:

<syntaxhighlight lang="nasal">
{ key: 97, modifier: { meta: 0, shift: 0, alt: 0, super: 0, ctrl: 0, hyper: 0 }, pressed: 1 }
{ key: 97, modifier: { meta: 0, shift: 0, alt: 0, super: 0, ctrl: 0, hyper: 0 }, pressed: 0 }
</syntaxhighlight>

This shows that key 97 was pressed (without any modifiers) and then released. This view can also help with combining modifiers, like mod-meta above.

== Adding custom bindings ==
The "easiest" option for many is to edit keyboard.xml in place, because it just works. If you do this, make sure to keep a backup of it, in case you need to revert back to the default setup, or simply download it from {{fgdata-old source|view=raw|branch=release/3.0.0|path=keyboard.xml|text=fgdata-old (v3.0)}} or {{fgdata source|path=keyboard.xml|text=fgdata cutting edge}}.

Another option, that ends up cleaner, is using a config file. These are specified on the commandline with '''<tt>--config</tt>''', like this:
<syntaxhighlight lang="bash">fgfs --config=/Users/philosopher/Documents/FlightGear/keyboard-config.xml</syntaxhighlight>
These can be formatted in the same way as keyboard.xml, with the exception of requiring input and keyboard tags, so it looks like this:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<input><keyboard>
<key n="....">...</key>

</keyboard></input>
</PropertyList>
</syntaxhighlight>
This makes sure it writes to the correct place in the tree, viz. /input/keyboard/.

This allows you to more easily keep several different files for different types of setups, without having to rename them before starting FG, you only need to change the filename passed in the <tt>--config=</tt> option.

== Related content ==
=== Wiki articles ===
* [[Bindings]]
* [[Howto:Add multi-key commands to an aircraft]]
* [[Howto:Make a clickable panel]]

=== Forum topics with layouts ===
Several users have modified the default keyboard bindings and shared the results.

==== Complete layouts ====
* [http://forum.flightgear.org/viewtopic.php?f=6&t=10902 New mice.xml and keyboard.xml for mouse and keyboard users]

==== Individual bindings ====
* [http://forum.flightgear.org/viewtopic.php?f=24&t=20531#p188008 Taxi/Landing Lights]
* [http://forum.flightgear.org/viewtopic.php?f=25&t=19873#p182779 Reset all trim to neutral]
* [http://forum.flightgear.org/viewtopic.php?f=24&t=17836#p168079 New rascal bindings] (control rudder/aileron/elevator as "all or nothing")
* [http://forum.flightgear.org/viewtopic.php?f=17&t=17312#p164775 Autopilot adjustment]
* [http://forum.flightgear.org/viewtopic.php?f=25&t=20504#p187879 Concorde rudder keyboard] (rudder on the normal left/right brake keys)
* [http://forum.flightgear.org/viewtopic.php?f=25&t=14494#p143807 Keyboard "sensitivity"]
* [http://forum.flightgear.org/viewtopic.php?f=24&t=17862#p168250 Idea for Elevator- and Aileron-trim] (show value of trim in a popupTip)

[[Category:Howto]]
[[Category:FlightGear]]
[[Category:FlightGear keyboard]]

Bindings

2016-07-28T12:01:16Z

Tipunch: Category:FlightGear keyboard

Howto:Add multi-key commands to an aircraft

2016-07-28T12:00:22Z

Tipunch: Category:FlightGear keyboard

[[File:FlightGear vi-like commands on-screen help.png|thumb|The on-screen help for the multi-key commands.]]
This tutorial will guide you through '''how to add multi-key commands to an aircraft''' and how they work.

The [[multi-key commands]] are vi-like key sequences that begin with {{key press|:}} and is followed by other keys.

== Define the multi-key commands ==
* Begin the aircraft-specific sequences with {{key press|:}}{{key press|A}}.

* If for example an instrument have many bindings, begin its sequences with {{key press|:}}{{key press|A}} and a uppercase letter specific for that instrument followed by the rest of the sequence.

=== The multikey.xml file ===
The multi-key commands are defined in a [[PropertyList XML files|property-list xml file]], named for example <code>aircraft-multikey.xml</code>.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>



<PropertyList>

<key n="65"> 
<name>A</name>
<desc>Aircraft</desc> 



</key>

</PropertyList>
</syntaxhighlight>

=== Syntax ===
The syntax builds up like a tree where the leaf nodes have bindings.

==== Non-leaf nodes ====
<syntaxhighlight lang="xml">
<key n="n"> 
<name><name> 
<desc></desc> 

<key n="n"> 

</key>

<key n="n"> 

</key>



</key>
</syntaxhighlight>

==== Leaf nodes ====
<syntaxhighlight lang="xml">
<key n="n"> 
<name><name> 
<desc></desc> 
<exit/> 
<binding> 

</binding>
<binding> 

</binding>
</key>
</syntaxhighlight>

==== Key codes ====
:''See [[Howto:Reassign keyboard keys#Finding keycodes]].''

==== Name and description ====
It is a very good idea to use the key name and a short but meaningful description as those are used by the multi-key command on-screen help dialog (when it is toggled on with {{key press|:}}{{key press|Tab}}).

==== Bindings ====
The bindings uses the same syntax as described in [[Bindings]] and [[Howto:Reassign keyboard keys#Adding or modifying key assignments]].

== Include the commands into the aircraft-set.xml file ==
Add this line to the <code>[[aircraft-set.xml]]</code> file:

<syntaxhighlight lang="xml">


<input>
<keyboard n="0">
<multikey include="aircraft-multikey.xml"/> 


</keyboard>
<input>


</syntaxhighlight>

== Technical details ==
{{stub|section=1}}
Among the nasal files in <code>$FGDATA/Nasal</code> that are loaded when FlightGear starts is <code>multikey.nas</code> that will load a number of Nasal functions. The keyboard configuration file <code>$FGDATA/keyboard.xml</code> will call <code>multikey.start()</code> when the {{key press|:}} key is used.

== Related content ==
=== Wiki articles ===
* [[Aircraft-set.xml]]
* [[Bindings]]
* [[Multi-key commands]]
* [[Howto:Reassign keyboard keys]]

=== Source code ===
==== fgdata files ====
* {{fgdata source|path=keyboard.xml|line=634|pre=$FG_ROOT}} Lines 634-641 of the keyboard configuration file delegates handling to multikey.start()
* {{fgdata source|path=Nasal/multikey.nas|pre=$FG_ROOT}} The global Nasal multi-key handler.

==== F-14B files ====
These are a good example of how one can do.
* {{fgaddon source|path=Aircraft/f-14b/f-14-common.xml|line=1367|pre=$FG_AIRCRAFT}} Line 1367 delegates the handling to Systems/instruments-multikey.xml.
* {{fgaddon source|path=Aircraft/f-14b/Systems/instruments-multikey.xml|pre=$FG_AIRCRAFT}}

[[Category:Aircraft enhancement]]
[[Category:Howto]]
[[Category:FlightGear keyboard]]

Category:FlightGear keyboard

2016-07-28T11:59:40Z

Tipunch: new category Category:FlightGear keyboard

Related content about keyboard mapping in Flightgear.

Multi-key commands

2016-07-28T11:58:19Z

Tipunch: Category:FlightGear keyboard

[[File:FlightGear vi-like commands on-screen help.png|thumb|The on-screen help for the multi-key commands.]]

FlightGear have a set of useful vi-like '''multi-key commands''' that can be used to change some settings quicker than if going through the menus.

== Basic keys ==
All multi-key sequence starts with {{Key press|:}}

{{Key press|:}}{{Key press|Tab}} toggles on-screen command help

{{Key press|enter}} sends the command

{{Key press|esc}} cancels the command

== Some useful commands ==
{| class="wikitable sortable" border="0" cellspacing="0"
! Sequence !! Use
|-
| :Da || Autopilot settings dialog
|-
| :Df || Fuel & weight dialog
|-
| :Dm || Multiplayer pilot list dialog
|-
| :Dpa || Position aircraft in air dialog
|-
| :Dr || Radio settings dialog
|-
| :Ds || Sound settings dialog
|-
| :Dt || Time settings dialog
|-
| :Ewsf || Set fair weather
|-
| :Ewsm || Set METAR (live) weather
|-
| :Etc || Timeofday: clock time
|-
| :Etn || Timeofday: noon
|-
| :Pg ''ICAO'' || Position aircraft at airport + optional runway number
|-
| :Yf/ || Fog off
|-
| :fat0 || Flight controls: aileron trim 0
|-
| :fet0 || Flight controls: elevator trim 0
|-
| :fia || Flight controls: reset all 3 trims
|-
| :rn1f110.50 || Radio: set nav1 radio to 110.50MHz
|}

== Related content ==
=== Wiki articles ===
* [[Howto:Add multi-key commands to an aircraft]]

=== Source code ===
* {{fgdata source|path=Input/Keyboard/multikey.xml|pre=$FG_ROOT}}
* {{fgdata source|path=Nasal/multikey.nas|pre=$FG_ROOT}}

[[Category:FlightGear]]
[[Category:FlightGear keyboard]]

Cessna 150/info

2016-07-25T22:03:00Z

Tipunch: added a cockpit image

<includeonly>{{infobox aircraft
| name = Cessna 150L
| hangar = fgaddon
| aircraft = c150
| image = C150L.jpg
| image2 = C150l-cockpit.jpg
| type = Civil aircraft/Civil utility aircraft
| config = High wing aircraft/Fixed gear aircraft
| propulsion = Propeller aircraft/Single-engine aircraft
| manufacturer = Cessna
| authors = Harald Johnsen
| fdm = JSBSim
| fgname = c150
| status = alpha
| status-fdm = 1
| status-systems = 1
| status-cockpit = 1
| status-model = 1
| ready =
| devel-repo = {{github url|user=Harald67|repo=c150}}
| liverydbid =
| forumtid =
| note =
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Cessna 150]].
[[Category:Aircraft infobox documentation]]
</noinclude>

File:C150l-cockpit.jpg

2016-07-25T22:01:10Z

Tipunch: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Updated cockpit of the Cessna 150 L}}
|date=2016-07-26
|source={{own}}
|author=[[User:Tipunch|Harald JOHNSEN]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

Standard aircraft structure

2016-07-24T14:57:38Z

Tipunch: dialog-show can only find the dialogs in 'gui/dialogs', not in 'Dialogs'

{{Out of date}}

To help provide a more consistent experience for end users, please use [[Release:Aircraft Selection Criteria]] as a guide to prepare aircraft for inclusion in the base package, especially if you are hoping for your aircraft to become part of the default distribution, such as the c172p for example.

== Standard Aircraft Folder Structure ==
The majority of cleanly structured [[aircraft]] share (more or less) a pretty similar folder layout.

While the suggested structure may seem overly verbose, using this or a similar structure for your own work ensures that your aircraft is pretty intuitively organized and that key components are kept in distinct places (and can be easily identified), so that future maintenance is simplified because of the self-documenting nature of the underlying file hierarchy.

'''Please note''': While the following folder layout has merely advisory character, it can be considered a product of "convention by evolution": As aircraft emulations in [[FlightGear]] are getting more and more complex, it is also
getting more complicated to maintain an overview of aircraft components and their implementation files, including their mutual relationships and purposes.

Furthermore, having aircraft authors organize their aircraft this way, also ensures that future contributors can more easily find, borrow and understand certain code snippets from existing work, so that they don't have to waste time trying to understand the purpose of the various files included.

=== Multiplayer Notes ===
Only few aircraft have a specific multiplayer model, so the feature only helps with some aircraft.
There is one thing I'd like to see added to the top-level directory tree for each aircraft. That is an MPModel directory, which would contain a simplified version of the model for AI/MP use. I think the MP version should be made by the original model builder, and it should be included in the original model package.

The reason I'd like to see this is I usually remove all models from my Aircraft directory except the ones I'm working on. This is to prevent periodic freezing of my sim session on MP when someone logs in with a heavy model. I'd like to see their airplane though, but not in its full form, and not replaced with a blue glider (or some other one-off substitue). I used to keep my own stable of MP versions of many models, but it became too unwieldy to maintain. It would be easier if I could set an XML element in preferences.xml to use the MP version of a model rather than the full version, or get a blue glider if no MP version exists.

Note that I don't consider turning some features off on a full model to be sufficient for making an MP model. The really lagging thing is the loading of textures, so I modified the livery exchange for the model (which is needed to send the correct livery over MP) to use a low-res version of the texture. So it's not the full blown 2048x2048 texture but a light weight 512x512 texture.

Many (or most/all?) AI models ignore liveries. They could still support it though - it really depends on what is coded in the AI model's animation code. An AI aircraft could support all the very same features as the real model. But obviously they only make really sense, when they are omitting a few features compared to the full-blown original. But it's up to the author to decide what to omit/simplify for the lightweight version.

An additional AI Model for AI Scenario use is helpful too, especially tail-draggers need some additional animations to work properly (e.g. lift the tail while accelerating).

If you use some low detail impostor for some objects at a distance, make sure you use the same texture as the "original" high poly version. Loading textures is the most expensive operation currently in FG (you need to unpack the png, generate the mipmaps on the fly then upload the uncompressed texture+mipmaps to the gpu.). This texture loading is the cause of the freezes everyone notices when some "detailed" aircraft joins MP.

I think the Model complexity needs to be reduced via the Model itself. E.g put all 3d Cockpit models into a seperate XML File and have a range animation (suggested by Anders) to load it only if sitting in the cockpit. Usable for gears too.
Livery select over Multiplayer can reduce lag too, by loading a low res texture instead of the hi res default one (see the F4U for an example).

== Structure ==

* '''MPModel''' - for multiplayer models [http://forum.flightgear.org/viewtopic.php?f=4&p=183059#p183057] [http://forum.flightgear.org/viewtopic.php?f=18&t=14814#p146655] [http://forum.flightgear.org/viewtopic.php?f=4&t=15292]
* <strike>'''Dialogs''' - for aircraft-specific dialog resources</strike> (if you load your dialogs manually)
** '''gui/dialogs''' - for aircraft-specific dialog resources (if you use dialog-show for opening your dialogs)
* '''Docs''' - for aircraft-specific documentation
* '''Engines''' - for various different engines supported by the FDMs (possibly beneath FDM folder?)
* '''Huds''' - for aircraft-specific [[HUD]]s
* '''Models''' - for 3D models
** '''Instruments''' - for aircraft-specific 3D instruments
** '''Liveries''' - for aircraft-specific livery textures
* '''Nasal''' - for aircraft-specific [[Nasal]] scripts
* '''Panels''' - for 2D cockpit panels
** '''Instruments''' - for aircraft specific 2D instruments
* '''Sounds''' - for aircraft-specific sounds
* '''Splashs''' - for aircraft-specific splash screens
* '''Systems''' - for aircraft-specific system modelling files (such as the electrical system and [[autopilot]])
* '''Tutorials''' - aircraft-specific tutorials (i.e. cold startup, approach etc.)

* '''Resources''' - for all sorts of aircraft specific development resources that may be required by other developers to continue development of an aircraft (i.e. data, images, artwork etc) but that isn't officially included in any of the other folders because it isn't yet used. That is, such "resource" folders could/should be automatically excluded from the script that is currently used to create the default base package for distribution.

== Recommended set of Standard Files to be provided ==
Additionally, all aircraft are recommended to have files such as the following included (possibly in a directory named "'''contrib'''"?):

* limits.xml - XML file configuring aircraft specific flight regime limits, i.e. to provide crash detection parameters
* AUTHORS.txt - list original authors and contributors, including their work
* CHANGELOG.txt - list recent changes to the aircraft
* README.txt - general information about aircraft
* HELP.txt - Help-related information
* FEATURES.txt - summary of supported features in plaintext
* TODO.txt - things that yet need to be done
* FILES.txt - a description of all relevant files and their purposes
* LICENSE.txt - detailing licensing and distribution
* LAYOUT.txt - file detailing layout of folder (i.e. contents of this paragraph)
* thumbnail.jpg - thumbnail image of aircraft for use by GUI/web frontends ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14562.html standard size 171x128 for fgfs thumbnails ])
* thumbnail.txt - [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14653.html optional file containing description being displayed on the web as the thumbnail's caption]

Also, providing such a set of standard files describing your work in detail, makes it possible for arbitrary web and gui frontends to optionally provide very detailed information about the progress of your work, so that automated scripts could be used to compile comprehensive summaries for all base package aircraft providing such files.

== Related content ==
* [[Release:Aircraft Selection Criteria]]
* [[Aircraft-set.xml]]
* [[FlightGear Roadmap]]

[[Category:Aircraft enhancement]]

Fr/Cessna 172P

2016-07-24T14:03:22Z

Tipunch: translation from the c172p detailed 4/4

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
Le '''Cessna 172 Skyhawk''' est un [[Fr/Avions|avion]] quadriplace, monomoteur à aile haute. Il effectua son premier vol en 1955 et est toujours en production, plus de Cessna 172 ont été construits que tout autres avions.

Le C 172 est l'avion par défaut dans [[FlightGear]] depuis 2000, il a remplacé le [[Navion]]. Il a eu un long développement et il inclut une grande variété de fonctionnalités pour FlightGear. En 2015, il a été complètement rénové ; cela comprend de nouvelles options de moteur, de taille de pneus ou de flotteurs, ainsi qu'une refonte complète du cockpit. Cette nouvelle version détaillée de l'avion est devenu l'avion inclus en standard depuis [[Changelog_3.6|FlightGear 3.6]].

== Contenu et variantes ==

Le nouveau C172p a un bien meilleur modèle 3D et est maintenant complètement texturé (y compris à l'intérieur). Tous les
interrupteurs du cockpit sont cliquables. Il a aussi un meilleur FDM, des procédures plus complexes et des checklist réalistes, de nouveaux effets sonores et une modélisation des dégâts. L'avion peut être endommagé s'il n'est pas utilisé correctement (par example le train d’atterrissage se brise si l’atterrissage est trop brutal).

[[File:C172p-bodensee-panorama.jpg|center|800px]]

L'avion dispose actuellement de cinq variantes qui sont accessibles depuis le menu de l'avion :
* roues standards
* roues 26 pouces pour le bush
* roues 31 pouces pour le bush
* flotteurs
* amphibie
* skis pour la neige

De plus depuis ce même menu l'utilisateur peut choisir entre deux moteurs :
* 160 HP
* 180 HP (recommandé si on utilise les variantes flotteurs, amphibie ou skis)

L'avion peut désormais être endommagé suite à des collisions, crash, atterrissage difficiles ou surcharges et la modélisation inclus la destruction des roues ou des ailes, etc. Les dégâts peuvent être désactivés dans le menu, il y a aussi une option pour réparer l'avion.

Les fenêtres peuvent recevoir de la buée ou du givre en fonction de la combinaison des températures intérieures et extérieures. Le pilote doit utiliser les commandes d'arrivée d'air ou de chauffage de la cabine (à droite de la commande de volet). Ou alors il est possible de désactiver cet effet dans les options de l'avion dans le menu "Cessna 172P".
Ces effets graphiques nécessitent les nouveaux effets ALS de FG 3.5 ou plus récent et risquent de produire des fenêtres grises sur les version antérieures.

Le FDM a aussi été amélioré. L'avion peut entamer une vrille dans une situation de décrochage asymétrique (une situation particulièrement dangereuse lorsqu'on tourne pour la manœuvre finale et que l'avion vole à une vitesse et une altitude faibles). Le FDM a aussi été ajusté pour inclure les effet hydrodynamiques lorsqu'il décolle ou atterrit sur l'eau. Il sait aussi gérer le moteur de 180 chevaux.

Il y a plusieurs livrées disponibles, certaines ont une meilleure résolution que d'autres et sont marquées avec 'HD' dans le menu des livrées.
There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

L'avion fournit une simulation du [[Bendix/King KAP140 Autopilot]].

Si l'utilisateur a activé [[ALS]] (Atmospheric light scattering) dans la boite de dialogue des options de rendu, alors il est possible d'activer la lampe de poche à partir du menu "Cessna 172P" et en choisissant "Flashlight".
Activer le une fois pour la lumière blanche, une deuxième fois pour la lumière rouge et une troisième fois pour l'éteindre.

Vous pouvez désormais effectuer la procédure d'avant-vol : cale pour les roues, attaches au sol et protection du pitot peuvent être mis ou enlevé, il est aussi possible de vérifier l'état de l'huile et la contamination du carburant par l'eau (ces fonctionnalités sont désactivées par défaut mais sont disponible dans le menu de l'avion).
[[File:c172p-ALS-flashlight2.jpg|500px|center|Lampe de poche du Cessna 172P dans le cockpit]]

== Aide de l'avion ==

=== Inspection avant le vol ===
[[File:C172p-secured-Aosta.jpg|270px||thumb|Cessna 172P sécurisé à l'aéroport d'Aosta]]
Il est préférable d'utiliser une vue de l’extérieur ou d'utiliser le marcheur (walker) pour ces procédures.
* Niveau de carburant : cliquer que le bouchon de réservoir de chaque aile pour en ajouter
* Aile droite : enlever l'attache
* Aile droite : vérifier la contamination en cliquant sous l'aile pour extraire un échantillon de carburant. Si l’échantillon est bleu pâle alors le carburant n'est pas contaminé et peut être remis dans le réservoir. Si l’échantillon est transparent ou semi-transparent alors vous devez vous en débarrasser et reprendre des échantillons jusqu'à ce que l’échantillon soit complètement bleu pâle.
* Nez : vérifier la quantité en cliquant sur la trappe d'huile. Le niveau critique d'huile pour les moteurs est de 5.0 quarts.
* Nez : enlever la cale.
* Aile gauche : enlever l'attache
* Aile gauche : enlever la protection du tube de Pitot
* Aile gauche : vérifier la contamination du carburant

=== Mise en route (démarrage simple ou complexe) ===
* Priming: pompez le moteur au moins 3 fois
* Mixture: Riche (manette rouge poussée à fond)
* Gaz: 1/8" (1/2 cm)
* Frein de parking: Serré ({{Key press|Shift|B}})
* Zone autour de l'hélice: Dégagée
* Magnétos: les deux ({{Key press|<nowiki>}</nowiki>}} trois fois)
* Démarreur ({{Key press|S}})

=== Démarrage moteur (automatique avec l'Autostart) ===
* Dans le menu "Cessna C172P", choisissez "Autostart" puis garder la touche {{Key press|S}} appuyée pour démarrer l'avion.

=== Décollage ===
[[File:c172p-cockpit.jpg|270px||thumb|Cessna 172P prêt au décollage]]
* Volets rentrés
* Plein gaz
* Rotation à 55 KIAS

=== Montée ===
* Volets rentrés
* Plein gaz
* 75 KIAS

=== Croisière ===
* gaz: 65%
* mixture: "rich of peak"

=== Atterrissage ===
[[File:c172p-landing2.jpg|270px||thumb|Cessna 172P sur le point d'atterrir]]
* Volets: tout sorti
* 60 KIAS

=== Vitesses limites ===

: ''Voir aussi [[Aircraft speed#V speeds]]''

Les informations de cette section sont fondées sur des sources externes.
<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

{| class="wikitable"
! Vitesse (Airspeed) !! Vitesse calibrée (CAS)
|-
| Vitesse de décrochage, configuration pour l’atterrissage, V<sub>S<sub>0</sub></sub> || 33 kt
|-
| Vitesse de décrochage, V<sub>S<sub>1</sub></sub> || 44 kt
|-
| Vitesse de rotation, V<sub>R</sub> || 55 kt
|-
| Vitesse avec le meilleur angle of montée, V<sub>X</sub> || 59 kt
|-
| Vitesse avec la montée la plus rapide, V<sub>Y</sub> || 76 kt
|-
| Vitesse maximale avec les volets sortis, V<sub>FE</sub> || 85 kt
|-
| rowspan="2" valign="top" | Vitesse de manœuvre, V<sub>A</sub> || 96 kt (flotteurs)
|-
| 99 kt (roues)
|-
| Vitesse maximale de croisière pour l’intégrité structurelle, V<sub>NO</sub> || 127 kt
|-
| Vitesse à ne jamais dépasser, V<sub>NE</sub> || 158 kt
|}

== FAQ ==

Voici quelques questions fréquentes sur cet appareil :

'''Q:''' Les fenêtres sont grises...que se passe t'il ?

'''R:''' Si les fenêtres sont grises vous n'avez pas la bonne version de FlightGear. Cet appareil nécessite la version 3.5 ou ultérieure.

'''Q:''' Pourquoi est-ce que l'avion tourne vers la gauche ?

'''R:''' Cela est normal, voir [[understanding Propeller Torque and P-Factor]]. Si vous utilisez la variante amphibie sur une piste en dur le contrôle se fait par freinage différentiel (la gouverne sera plus efficace à mesure que l'avion gagne de la vitesse).

'''Q:''' Pourquoi le moteur ne démarre t'il pas ?

'''R:''' Vous pouvez démarrer le moteur automatiquement via le menu "Cessna C172P" puis le choix "Autostart" ; ensuite il suffit de garder la touche {{Key press|S}} appuyée. Pour un démarrage manuel veuillez suivre les indications de la checklist accessible depuis le menu "Aide" puis "Aircraft Checklists". Comme vu précédemment, le carburant doit être pompé manuellement avant de lancer le moteur. Si la gestion de l'huile est active alors vous devez avoir un niveau suffisant d'huile (5.0 quarts). Si la contamination du carburant est activée alors le carburant doit être de couleur bleue pâle pour que le moteur fonctionne correctement.

'''Q:''' Pourquoi le moteur s’arrête t'il immédiatement après le démarrage ?

'''R:''' Probablement parce que la manette des gaz est poussée trop fortement après le démarrage du moteur ; celui-ci a besoin de quelques secondes pour se stabiliser.

'''Q:''' Pourquoi ne puis-je pas démarrer la simulation avec le moteur qui tourne ?

'''R:''' Vous pouvez ! Allez dans le menu "Cessna C172P" puis dans "Aircraft Options" et cocher la case "Start with engine running" (Commencer avec le moteur qui tourne).

'''Q:''' Pourquoi est-ce que l'avion de bouge pas ?

'''R:''' L'avion ne bougera pas si vous avez activé les freins de parking ou si les ailes sont attachées avec des liens ou si des cales sont en place (vérifier si l'option "allow securing aircraft" est activée dans les options de l'appareil).

'''Q:''' Pourquoi l'indicateur de vitesse ne fonctionne t'il pas ?

'''R:''' Si l'option de sécurisation de l'appareil est activée, alors il y a de grandes chances que vous avez oublié d'enlever la protection du pitot.

'''Q:''' Comment changer de roues / skis / flotteurs ?

'''R:''' Dans le menu "Cessna 172P", choisissez "Aircraft Options" puis choisissez un type de train d'atterrissage.

'''Q:''' Comment puis-je passer au moteur de 180 chevaux ?

'''R:''' Cela se fait aussi depuis le menu "Cessna 172P", puis "Aircraft Options", puis en choisissant la puissance de moteur voulue.

'''Q:''' Pourquoi ne puis-je pas décoller depuis un plan d'eau sans crasher l'avion ?

'''R:''' Décoller ou atterrir sur l'eau peut être un peu délicat. Essayer de tirer un peu le manche en accélérant jusqu'à 55 KIAS. Il est aussi recommandé d'utiliser le moteur de 180 chevaux à la place du moteur de 160 chevaux parce que le poids supplémentaire des flotteurs rend très difficile le décollage avec le moteur de base.

'''Q:''' Pourquoi le simulateur rame t'il autant ?

'''R:''' Comme avec tout modèle 3D complexe, cette nouvelle version du c172p demande plus de ressource à l'ordinateur que l'ancien modèle. Si vous avez des problèmes de performance essayer de ne pas utiliser les livrée en haute définition ; il y a aussi d'autres choses qui peuvent améliorer les performance (réduire les options graphique, réduire la résolution du programme, etc.).

Une astuce qui peut aider à augmenter les images/seconde est de fermer toutes les boites de dialogue, y compris la barre de menu et le compteur de fps orange au bas de l'écran. Vous pouvez afficher un autre compteur de fps depuis le menu "Debug" puis en choisissant "Cycle On-Screen Statistics". Veillez à cacher le menu avec {{Key press|F10}} pour voir le compteur fps.

Une autre astuce consiste à désactiver le rendu des nuages si vous n'en avez pas besoin. Démarrer FlightGear avec l'option
<code>"--prop:/sim/rendering/draw-mask/clouds=0"</code>

Si vous remarquez de gros ralentissements lorsque vous volez au dessus de certain endroits et que vous voyez Flightgear générer beaucoup d'anomalies "Warning:: Picked up error in TriangleIntersect" dans la console ou le fichier de log, vous pouvez désactiver ces message avec le paramètre <code> "--prop:/sim/rendering/osg-notify-level=fatal" </code>.

'''Q:''' Pourquoi les fenêtres sont elles givrées ou embuées ?

'''R:''' Si la température du point de rosée de l'air de la cabine est plus grand que la température du pare-brise, les vitres deviendront givrées ou embuées. Utilisez les commandes de température ou d'arrivée d'air de la cabine (à la droite de la commande de volets). Le point de rosée augmente avec la température de la cabine et il augmente plus vite que la température du pare-brise, résultant dans une buée temporaire. Si l'air est très humide alors le point de rosée sera très proche de la température de la cabin, ce qui le rendra très probablement plus élevé que la température du pare-brise.
Des passagers en plus génèrent plus d'humidité dans la cabine. Essayer d'augmenter le flux d'air an utilisant la commande d'arrivée d'air ou la ventilation au niveau des ailes pour réduire l'humidité ou la température.
Une autre possibilité est de désactiver l'effet dans le menu "Cessna 172P", puis "Aircraft Options" puis "Enable frost and fog".

'''Q:''' Comment augmenter la température de la cabine ?

'''R:''' Pour augmenter la température de la cabine il faut utiliser la commande de chauffage de la cabine.
Pour avoir réellement un air chaud il faut une température de gaz d’échappement moyenne ou haute (EGT -- l'instrument entre le manche et l'ADF), et un flux d'air suffisant.

'''Q:''' Comment cliquer sur un interrupteur qui est caché par le manche ?

'''R:''' Vous pouvez cacher les manches à partir du menu "Cessna 172P", puis "Hide/Show Yokes".

== Etat du development/Problèmes/A faire ==

Cet avion est en développement constant, vous pouvez suivre les avancées sur [https://github.com/Juanvvc/c172p-detailed le repository], il y a aussi une [https://github.com/Juanvvc/c172p-detailed/issues liste des problèmes et améliorations futures].

== Gallérie ==

<gallery mode="packed">
c172p-plane5.jpg|Cessna 172P au dessus de Chapada Diamantina au Brésil
c172p-plane4.jpg|Décollage à Compiegne Margny (LFAD)
c172p-cockpit2.jpg|Sur le point d'atterrir, demonstration du nouvel effet d'ombre ALS dans le cockpit
c172p-floats.jpg|Variante avec flotteurs à San Francisco
c172p-plane3.jpg|Cessna 172P volant à haute altitude au dessus de Lago di Garda en Italie
c172p-landing.jpg|On final at Aosta Airport (LIMW)
c172p-cockpit3.jpg|L'intèrieur texturé du nouveau c172p
c172p-night.jpg|Un vol de nuit, montrant l'illumination des instruments
c172p-particles.jpg|Décollage sur l'eau, montrant le système de particules
c172p-plane1.jpg|Au dessus de Serra do Mar au Brésil
c172p-plane2.jpg|Coucher de soleil
c172p-winter.jpg|L'hiver en Europe
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|Avec les conditions adéquates du givre ou du brouillard apparaissent sur les vitres
c172p-taubate.jpg|Vol au dessus de Taubate, Brésil

</gallery>

=== Liens externes ===
* [http://en.wikipedia.org/wiki/Cessna_172 Wikipedia article]
* [http://www.atlasaviation.com/checklists/cessna-172/cessna_172_checklist.htm Cessna 172 checklists at AtlasAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[zh:Cessna 172P]]

Fr/Cessna 172P

2016-07-24T10:28:05Z

Tipunch: translation from the c172p detailed 3/4

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
Le '''Cessna 172 Skyhawk''' est un [[Fr/Avions|avion]] quadriplace, monomoteur à aile haute. Il effectua son premier vol en 1955 et est toujours en production, plus de Cessna 172 ont été construits que tout autres avions.

Le C 172 est l'avion par défaut dans [[FlightGear]] depuis 2000, il a remplacé le [[Navion]]. Il a eu un long développement et il inclut une grande variété de fonctionnalités pour FlightGear. En 2015, il a été complètement rénové ; cela comprend de nouvelles options de moteur, de taille de pneus ou de flotteurs, ainsi qu'une refonte complète du cockpit. Cette nouvelle version détaillée de l'avion est devenu l'avion inclus en standard depuis [[Changelog_3.6|FlightGear 3.6]].

== Contenu et variantes ==

Le nouveau C172p a un bien meilleur modèle 3D et est maintenant complètement texturé (y compris à l'intérieur). Tous les
interrupteurs du cockpit sont cliquables. Il a aussi un meilleur FDM, des procédures plus complexes et des checklist réalistes, de nouveaux effets sonores et une modélisation des dégâts. L'avion peut être endommagé s'il n'est pas utilisé correctement (par example le train d’atterrissage se brise si l’atterrissage est trop brutal).

[[File:C172p-bodensee-panorama.jpg|center|800px]]

L'avion dispose actuellement de cinq variantes qui sont accessibles depuis le menu de l'avion :
* roues standards
* roues 26 pouces pour le bush
* roues 31 pouces pour le bush
* flotteurs
* amphibie
* skis pour la neige

De plus depuis ce même menu l'utilisateur peut choisir entre deux moteurs :
* 160 HP
* 180 HP (recommandé si on utilise les variantes flotteurs, amphibie ou skis)

L'avion peut désormais être endommagé suite à des collisions, crash, atterrissage difficiles ou surcharges et la modélisation inclus la destruction des roues ou des ailes, etc. Les dégâts peuvent être désactivés dans le menu, il y a aussi une option pour réparer l'avion.

Les fenêtres peuvent recevoir de la buée ou du givre en fonction de la combinaison des températures intérieures et extérieures. Le pilote doit utiliser les commandes d'arrivée d'air ou de chauffage de la cabine (à droite de la commande de volet). Ou alors il est possible de désactiver cet effet dans les options de l'avion dans le menu "Cessna 172P".
Ces effets graphiques nécessitent les nouveaux effets ALS de FG 3.5 ou plus récent et risquent de produire des fenêtres grises sur les version antérieures.

Le FDM a aussi été amélioré. L'avion peut entamer une vrille dans une situation de décrochage asymétrique (une situation particulièrement dangereuse lorsqu'on tourne pour la manœuvre finale et que l'avion vole à une vitesse et une altitude faibles). Le FDM a aussi été ajusté pour inclure les effet hydrodynamiques lorsqu'il décolle ou atterrit sur l'eau. Il sait aussi gérer le moteur de 180 chevaux.

Il y a plusieurs livrées disponibles, certaines ont une meilleure résolution que d'autres et sont marquées avec 'HD' dans le menu des livrées.
There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

L'avion fournit une simulation du [[Bendix/King KAP140 Autopilot]].

Si l'utilisateur a activé [[ALS]] (Atmospheric light scattering) dans la boite de dialogue des options de rendu, alors il est possible d'activer la lampe de poche à partir du menu "Cessna 172P" et en choisissant "Flashlight".
Activer le une fois pour la lumière blanche, une deuxième fois pour la lumière rouge et une troisième fois pour l'éteindre.

Vous pouvez désormais effectuer la procédure d'avant-vol : cale pour les roues, attaches au sol et protection du pitot peuvent être mis ou enlevé, il est aussi possible de vérifier l'état de l'huile et la contamination du carburant par l'eau (ces fonctionnalités sont désactivées par défaut mais sont disponible dans le menu de l'avion).
[[File:c172p-ALS-flashlight2.jpg|500px|center|Lampe de poche du Cessna 172P dans le cockpit]]

== Aide de l'avion ==

=== Inspection avant le vol ===
[[File:C172p-secured-Aosta.jpg|270px||thumb|Cessna 172P sécurisé à l'aéroport d'Aosta]]
Il est préférable d'utiliser une vue de l’extérieur ou d'utiliser le marcheur (walker) pour ces procédures.
* Niveau de carburant : cliquer que le bouchon de réservoir de chaque aile pour en ajouter
* Aile droite : enlever l'attache
* Aile droite : vérifier la contamination en cliquant sous l'aile pour extraire un échantillon de carburant. Si l’échantillon est bleu pâle alors le carburant n'est pas contaminé et peut être remis dans le réservoir. Si l’échantillon est transparent ou semi-transparent alors vous devez vous en débarrasser et reprendre des échantillons jusqu'à ce que l’échantillon soit complètement bleu pâle.
* Nez : vérifier la quantité en cliquant sur la trappe d'huile. Le niveau critique d'huile pour les moteurs est de 5.0 quarts.
* Nez : enlever la cale.
* Aile gauche : enlever l'attache
* Aile gauche : enlever la protection du pitot
* Aile gauche : vérifier la contamination du carburant

=== Mise en route (démarrage simple ou complexe) ===
* Priming: pompez le moteur au moins 3 fois
* Mixture: Riche (manette rouge poussée à fond)
* Gaz: 1/8" (1/2 cm)
* Frein de parking: Serré ({{Key press|Shift|B}})
* Zone autour de l'hélice: Dégagée
* Magnétos: Both ({{Key press|<nowiki>}</nowiki>}} trois fois)
* Démarreur ({{Key press|S}})

=== Démarrage moteur (automatique avec l'Autostart) ===
* Dans le menu "Cessna C172P", choisissez "Autostart" puis garder la touche {{Key press|S}} appuyée pour démarrer l'avion.

=== Décollage ===
[[File:c172p-cockpit.jpg|270px||thumb|Cessna 172P prêt au décollage]]
* Volets rentrés
* Plein gaz
* Rotation à 55 KIAS

=== Montée ===
* Volets rentrés
* Plein gaz
* 75 KIAS

=== Croisière ===
* gaz: 65%
* mixture: "rich of peak"

=== Atterrissage ===
[[File:c172p-landing2.jpg|270px||thumb|Cessna 172P sur le point d'atterrir]]
* Volets: tout sorti
* 60 KIAS

=== Vitesses limites ===

: ''Voir aussi [[Aircraft speed#V speeds]]''

Les informations de cette section sont fondées sur des sources externes.
<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

{| class="wikitable"
! Vitesse (Airspeed) !! Vitesse calibrée (CAS)
|-
| Vitesse de décrochage, configuration pour l’atterrissage, V<sub>S<sub>0</sub></sub> || 33 kt
|-
| Vitesse de décrochage, V<sub>S<sub>1</sub></sub> || 44 kt
|-
| Vitesse de rotation, V<sub>R</sub> || 55 kt
|-
| Vitesse avec le meilleur angle of montée, V<sub>X</sub> || 59 kt
|-
| Vitesse avec la montée la plus rapide, V<sub>Y</sub> || 76 kt
|-
| Vitesse maximale avec les volets sortis, V<sub>FE</sub> || 85 kt
|-
| rowspan="2" valign="top" | Vitesse de manœuvre, V<sub>A</sub> || 96 kt (flotteurs)
|-
| 99 kt (roues)
|-
| Vitesse maximale de croisière pour l’intégrité structurelle, V<sub>NO</sub> || 127 kt
|-
| Vitesse à ne jamais dépasser, V<sub>NE</sub> || 158 kt
|}

== FAQ ==

Voici quelques questions fréquentes sur cet appareil :

'''Q:''' Les fenêtres sont grises...que se passe t'il ?

'''R:''' Si les fenêtres sont grises vous n'avez pas la bonne version de FlightGear. Cet appareil nécessite la version 3.5 ou ultérieure.

'''Q:''' Pourquoi est-ce que l'avion tourne vers la gauche ?

'''R:''' Cela est normal, voir [[understanding Propeller Torque and P-Factor]]. Si vous utilisez la variante amphibie sur une piste en dur le contrôle se fait par freinage différentiel (la gouverne sera plus efficace à mesure que l'avion gagne de la vitesse).

'''Q:''' Pourquoi le moteur ne démarre t'il pas ?

'''R:''' Vous pouvez démarrer le moteur automatiquement via le menu "Cessna C172P" puis le choix "Autostart" ; ensuite il suffit de garder la touche {{Key press|S}} appuyée. Pour un démarrage manuel veuillez suivre les indications de la checklist accessible depuis le menu "Aide" puis "Aircraft Checklists". Comme vu précédemment, le carburant doit être pompé manuellement avant de lancer le moteur. Si la gestion de l'huile est active alors vous devez avoir un niveau suffisant d'huile (5.0 quarts). Si la contamination du carburant est activée alors le carburant doit être de couleur bleue pâle pour que le moteur fonctionne correctement.

'''Q:''' Pourquoi le moteur s’arrête t'il immédiatement après le démarrage ?

'''R:''' Probablement parce que la manette des gaz est poussée trop fortement après le démarrage du moteur ; celui-ci a besoin de quelques secondes pour se stabiliser.

'''Q:''' Pourquoi ne puis-je pas démarrer la simulation avec le moteur qui tourne ?

'''R:''' Vous pouvez ! Allez dans le menu "Cessna C172P" puis dans "Aircraft Options" et cocher la case "Start with engine running" (Commencer avec le moteur qui tourne).

'''Q:''' Pourquoi est-ce que l'avion de bouge pas ?

'''R:''' L'avion ne bougera pas si vous avez activé les freins de parking ou si les ailes sont attachées avec des liens ou si des cales sont en place (vérifier si l'option "allow securing aircraft" est activée dans les options de l'appareil).

'''Q:''' Pourquoi l'indicateur de vitesse ne fonctionne t'il pas ?

'''R:''' Si l'option de sécurisation de l'appareil est activée, alors il y a de grandes chances que vous avez oublié d'enlever la protection du pitot.

'''Q:''' Comment changer de roues / skis / flotteurs ?

'''R:''' Dans le menu "Cessna 172P", choisissez "Aircraft Options" puis choisissez un type de train d'atterrissage.

'''Q:''' Comment puis-je passer au moteur de 180 chevaux ?

'''R:''' Cela se fait aussi depuis le menu "Cessna 172P", puis "Aircraft Options", puis en choisissant la puissance de moteur voulue.

'''Q:''' Pourquoi ne puis-je pas décoller depuis un plan d'eau sans crasher l'avion ?

'''R:''' Décoller ou atterrir sur l'eau peut être un peu délicat. Essayer de tirer un peu le manche en accélérant jusqu'à 55 KIAS. Il est aussi recommandé d'utiliser le moteur de 180 chevaux à la place du moteur de 160 chevaux parce que le poids supplémentaire des flotteurs rend très difficile le décollage avec le moteur de base.

'''Q:''' Pourquoi le simulateur rame t'il autant ?

'''R:''' Comme avec tout modèle 3D complexe, cette nouvelle version du c172p demande plus de ressource à l'ordinateur que l'ancien modèle. Si vous avez des problèmes de performance essayer de ne pas utiliser les livrée en haute définition ; il y a aussi d'autres choses qui peuvent améliorer les performance (réduire les options graphique, réduire la résolution du programme, etc.).

Une astuce qui peut aider à augmenter les images/seconde est de fermer toutes les boites de dialogue, y compris la barre de menu et le compteur de fps orange au bas de l'écran. Vous pouvez afficher un autre compteur de fps depuis le menu "Debug" puis en choisissant "Cycle On-Screen Statistics". Veillez à cacher le menu avec {{Key press|F10}} pour voir le compteur fps.

Une autre astuce consiste à désactiver le rendu des nuages si vous n'en avez pas besoin. Démarrer FlightGear avec l'option
<code>"--prop:/sim/rendering/draw-mask/clouds=0"</code>

If you notice heavy slowdowns when flying over certain scenery and you see FlightGear generating many "Warning:: Picked up error in TriangleIntersect" messages in the terminal or log file, you can disable this by starting FlightGear with "--prop:/sim/rendering/osg-notify-level=fatal".

'''Q:''' Why are the windows getting foggy/frosty?

'''R:''' If the dew point of the cabin air temperature is higher than the surface temperature of the windshield, the windows will get either foggy or frosty. Use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. The dew point rises with the temperature in the cabin, and it rises faster than the windshield temperature can adjust, resulting in temporary fog. If the air is very humid, the dew point is going to be very close to the cabin temperature, which makes it likely that it will be higher than the windshield temperature. Extra passengers will create a more humid atmosphere in the cabin. Try to increase air flow using the Cabin Air lever or overhead air vents in order to decrease the humidity or temperature. Alternatively, disable the effect by going to the menu "Cessna 172P", selecting "Aircraft Options" and disable the option "Enable frost and fog".

'''Q:''' How do I increase the cabin air temperature?

'''R:''' Increase the cabin air temperature by opening the Cabin Heat lever. In order to actually get a heated air flow, you need a medium or high EGT (Exhaust Gas Temperature -- the instrument between the yoke and the ADF instrument), and airspeed and/or sufficient propeller RPM.

'''Q:''' How can I click on a switch which is being covered by the yoke?

'''R:''' You can hide the yokes by clicking on them or by going to the menu "Cessna 172P", selecting "Hide/Show Yokes".

== Etat du development/Problèmes/A faire ==

Cet avion est en développement constant, vous pouvez suivre les avancées sur [https://github.com/Juanvvc/c172p-detailed le repository], il y a aussi une [https://github.com/Juanvvc/c172p-detailed/issues liste des problèmes et améliorations futures].

== Gallérie ==

<gallery mode="packed">
c172p-plane5.jpg|Cessna 172P au dessus de Chapada Diamantina au Brésil
c172p-plane4.jpg|Décollage à Compiegne Margny (LFAD)
c172p-cockpit2.jpg|Sur le point d'attérir, demonstration du nouvel effet d'ombre ALS dans le cockpit
c172p-floats.jpg|Variante avec flotteurs à San Francisco
c172p-plane3.jpg|Cessna 172P volant à haute altitude au dessus de Lago di Garda en Italie
c172p-landing.jpg|On final at Aosta Airport (LIMW)
c172p-cockpit3.jpg|L'interrieur texturé du nouveau c172p
c172p-night.jpg|Un vol de nuit, montrant l'illumination des instruments
c172p-particles.jpg|Décollage sur l'eau, montrant le système de particules
c172p-plane1.jpg|Au dessus de Serra do Mar au Brésil
c172p-plane2.jpg|Coucher de soleil
c172p-winter.jpg|L'hiver en Europe
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|Avec les conditions adéquates du givre ou du brouillard apparaissent sur les vitres
c172p-taubate.jpg|Vol au dessus de Taubate, Brésil

</gallery>

=== Liens externes ===
* [http://en.wikipedia.org/wiki/Cessna_172 Wikipedia article]
* [http://www.atlasaviation.com/checklists/cessna-172/cessna_172_checklist.htm Cessna 172 checklists at AtlasAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[zh:Cessna 172P]]

Fr/Cessna 172P

2016-07-23T10:35:32Z

Tipunch: translation from the c172p detailed 2/3

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
Le '''Cessna 172 Skyhawk''' est un [[Fr/Avions|avion]] quadriplace, monomoteur à aile haute. Il effectua son premier vol en 1955 et est toujours en production, plus de Cessna 172 ont été construits que tout autres avions.

Le C 172 est l'avion par défaut dans [[FlightGear]] depuis 2000, il a remplacé le [[Navion]]. Il a eu un long développement et il inclut une grande variété de fonctionnalités pour FlightGear. En 2015, il a été complètement rénové ; cela comprend de nouvelles options de moteur, de taille de pneus ou de flotteurs, ainsi qu'une refonte complète du cockpit. Cette nouvelle version détaillée de l'avion est devenu l'avion inclus en standard depuis [[Changelog_3.6|FlightGear 3.6]].

== Contenu et variantes ==

Le nouveau C172p a un bien meilleur modèle 3D et est maintenant complètement texturé (y compris à l'intérieur). Tous les
interrupteurs du cockpit sont cliquables. Il a aussi un meilleur FDM, des procédures plus complexes et des checklist réalistes, de nouveaux effets sonores et une modélisation des dégâts. L'avion peut être endommagé s'il n'est pas utilisé correctement (par example le train d’atterrissage se brise si l’atterrissage est trop brutal).

[[File:C172p-bodensee-panorama.jpg|center|800px]]

L'avion dispose actuellement de cinq variantes qui sont accessibles depuis le menu de l'avion :
* roues standards
* roues 26 pouces pour le bush
* roues 31 pouces pour le bush
* flotteurs
* amphibie
* skis pour la neige

De plus depuis ce même menu l'utilisateur peut choisir entre deux moteurs :
* 160 HP
* 180 HP (recommandé si on utilise les variantes flotteurs, amphibie ou skis)

L'avion peut désormais être endommagé suite à des collisions, crash, atterrissage difficiles ou surcharges et la modélisation inclus la destruction des roues ou des ailes, etc. Les dégâts peuvent être désactivés dans le menu, il y a aussi une option pour réparer l'avion.

Les fenêtres peuvent recevoir de la buée ou du givre en fonction de la combinaison des températures intérieures et extérieures. Le pilote doit utiliser les commandes d'arrivée d'air ou de chauffage de la cabine (à droite de la commande de volet). Ou alors il est possible de désactiver cet effet dans les options de l'avion dans le menu "Cessna 172P".
Ces effets graphiques nécessitent les nouveaux effets ALS de FG 3.5 ou plus récent et risquent de produire des fenêtres grises sur les version antérieures.

Le FDM a aussi été amélioré. L'avion peut entamer une vrille dans une situation de décrochage asymétrique (une situation particulièrement dangereuse lorsqu'on tourne pour la manœuvre finale et que l'avion vole à une vitesse et une altitude faibles). Le FDM a aussi été ajusté pour inclure les effet hydrodynamiques lorsqu'il décolle ou atterrit sur l'eau. Il sait aussi gérer le moteur de 180 chevaux.

Il y a plusieurs livrées disponibles, certaines ont une meilleure résolution que d'autres et sont marquées avec 'HD' dans le menu des livrées.
There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

L'avion fournit une simulation du [[Bendix/King KAP140 Autopilot]].

Si l'utilisateur a activé [[ALS]] (Atmospheric light scattering) dans la boite de dialogue des options de rendu, alors il est possible d'activer la lampe de poche à partir du menu "Cessna 172P" et en choisissant "Flashlight".
Activer le une fois pour la lumière blanche, une deuxième fois pour la lumière rouge et une troisième fois pour l'éteindre.

Vous pouvez désormais effectuer la procédure d'avant-vol : cale pour les roues, attaches au sol et protection du pitot peuvent être mis ou enlevé, il est aussi possible de vérifier l'état de l'huile et la contamination du carburant par l'eau (ces fonctionnalités sont désactivées par défaut mais sont disponible dans le menu de l'avion).
[[File:c172p-ALS-flashlight2.jpg|500px|center|Lampe de poche du Cessna 172P dans le cockpit]]

== Aide de l'avion ==

=== Inspection avant le vol ===
[[File:C172p-secured-Aosta.jpg|270px||thumb|Cessna 172P sécurisé à l'aéroport d'Aosta]]
Il est préférable d'utiliser une vue de l’extérieur ou d'utiliser le marcheur (walker) pour ces procédures.
* Niveau de carburant : cliquer que le bouchon de réservoir de chaque aile pour en ajouter
* Aile droite : enlever l'attache
* Aile droite : vérifier la contamination en cliquant sous l'aile pour extraire un échantillon de carburant. Si l’échantillon est bleu pâle alors le carburant n'est pas contaminé et peut être remis dans le réservoir. Si l’échantillon est transparent ou semi-transparent alors vous devez vous en débarrasser et reprendre des échantillons jusqu'à ce que l’échantillon soit complètement bleu pâle.
* Nez : vérifier la quantité en cliquant sur la trappe d'huile. Le niveau critique d'huile pour les moteurs est de 5.0 quarts.
* Nez : enlever la cale.
* Aile gauche : enlever l'attache
* Aile gauche : enlever la protection du pitot
* Aile gauche : vérifier la contamination du carburant

=== Mise en route (démarrage simple ou complexe) ===
* Priming: pompez le moteur au moins 3 fois
* Mixture: Riche (manette rouge poussée à fond)
* Gaz: 1/8" (1/2 cm)
* Frein de parking: Serré ({{Key press|Shift|B}})
* Zone autour de l'hélice: Dégagée
* Magnétos: Both ({{Key press|<nowiki>}</nowiki>}} trois fois)
* Démarreur ({{Key press|S}})

=== Démarrage moteur (automatique avec l'Autostart) ===
* Dans le menu "Cessna C172P", choisissez "Autostart" puis garder la touche {{Key press|S}} appuyée pour démarrer l'avion.

=== Décollage ===
[[File:c172p-cockpit.jpg|270px||thumb|Cessna 172P prêt au décollage]]
* Volets rentrés
* Plein gaz
* Rotation à 55 KIAS

=== Montée ===
* Volets rentrés
* Plein gaz
* 75 KIAS

=== Croisière ===
* gaz: 65%
* mixture: "rich of peak"

=== Atterrissage ===
[[File:c172p-landing2.jpg|270px||thumb|Cessna 172P sur le point d'atterrir]]
* Volets: tout sorti
* 60 KIAS

=== Vitesses limites ===

: ''Voir aussi [[Aircraft speed#V speeds]]''

Les informations de cette section sont fondées sur des sources externes.
<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

{| class="wikitable"
! Vitesse (Airspeed) !! Vitesse calibrée (CAS)
|-
| Vitesse de décrochage, configuration pour l’atterrissage, V<sub>S<sub>0</sub></sub> || 33 kt
|-
| Vitesse de décrochage, V<sub>S<sub>1</sub></sub> || 44 kt
|-
| Vitesse de rotation, V<sub>R</sub> || 55 kt
|-
| Vitesse avec le meilleur angle of montée, V<sub>X</sub> || 59 kt
|-
| Vitesse avec la montée la plus rapide, V<sub>Y</sub> || 76 kt
|-
| Vitesse maximale avec les volets sortis, V<sub>FE</sub> || 85 kt
|-
| rowspan="2" valign="top" | Vitesse de manœuvre, V<sub>A</sub> || 96 kt (flotteurs)
|-
| 99 kt (roues)
|-
| Vitesse maximale de croisière pour l’intégrité structurelle, V<sub>NO</sub> || 127 kt
|-
| Vitesse à ne jamais dépasser, V<sub>NE</sub> || 158 kt
|}

== FAQ ==

Here are some of the frequently asked questions about this aircraft:

'''Q:''' I am experiencing grey windows, what is happening?

'''A:''' If you experience grey windows, you do not have the correct FlightGear version. This aircraft requires 3.5 or above.

'''Q:''' Why does the aircraft keep turning left?

'''A:''' Please see [[understanding Propeller Torque and P-Factor]]. If using the amphibian model on a solid runway, note that at the taxiing is done by differential braking (the rudder becomes more and more effective as the plane gains speed).

'''Q:''' Why will the engine not start?

'''A:''' You can start the engine automatically by clicking on the menu "Cessna C172P", selecting "Autostart" and then simply holding the key {{Key press|S}}. For a manual start, please follow the checklists available by clicking on the menu "Help" followed by "Aircraft Checklists". As seen above, the engine must by "primed" before starting. If oil management is activated, you must have enough oil for the engine to work (more than 5.0 quarts). If fuel contamination is activated, the fuel must be light blue in order for the engine to properly work.

'''Q:''' Why does the engine die immediately after startup?

'''A:''' Probably because the throttle is being incremented too fast after startup as the engine needs a few seconds to stabilize itself.

'''Q:''' Why can't I start the sim with the engine running?

'''A:''' You can! Go to the menu "Cessna C172P", select "Aircraft Options" and tick the option "Start with engine running".

'''Q:''' Why the aircraft doesn't move?

'''A:''' The aircraft won't move if you have the parking brakes set, or if either of the wing tie-downs, the tail tie-down or wheel chocks are in place (if the option "allow securing aircraft" is enabled in the aircraft menu).

'''Q:''' Why the airspeed indicator doesn't work?

'''A:''' If the option "allow securing aircraft" is enabled in the aircraft menu, then very likely you forgot to remove the pitot tube cover.

'''Q:''' How can I switch to the bush tires/pontoons/amphibian?

'''A:''' By clicking in menu "Cessna 172P", selecting "Aircraft Options" and then selecting the other landing gear options.

'''Q:''' How can I switch to the 180 HP engine?

'''A:''' This is also done by clicking in menu "Cessna 172P", selecting "Aircraft Options" and then selecting the engine power option.

'''Q:''' Why can't I take off from the water without crashing the plane?

'''A:''' Taking off and landing on water can be quite tricky. Try applying a little bit of back pressure on the yoke while accelerating to 55 KIAS. It's also recommended to use the 180 HP engine instead of the default 160 HP, as the extra weight of the pontoons make it really hard to climb with the default engine.

'''Q:''' Why is the simulator lagging so much?

'''A:''' As with any complex 3D model, this new version of the c172p is a bit more demanding on the computers than the older one. If you are having troubles with performance, try using non-HD liveries which use textures with lower resolutions, as well as other solutions that can improve performance (disabling certain graphical options in the Rendering Options, lowering the resolution of FlightGear, etc.).

Some tricks that help to increase fps is by disabling all GUI windows, including the menu bar and the orange fps counters at the bottom of the screen. You can display an alternative fps counter in the top left corner via the "Debug" menu and then selecting "Cycle On-Screen Statistics". Make sure to hide the menu bar by pressing F10 to see the counter.

A second trick is to simply disable the rendering of all clouds if you don't mind. Start FlightGear with "--prop:/sim/rendering/draw-mask/clouds=0".

If you notice heavy slowdowns when flying over certain scenery and you see FlightGear generating many "Warning:: Picked up error in TriangleIntersect" messages in the terminal or log file, you can disable this by starting FlightGear with "--prop:/sim/rendering/osg-notify-level=fatal".

'''Q:''' Why are the windows getting foggy/frosty?

'''A:''' If the dew point of the cabin air temperature is higher than the surface temperature of the windshield, the windows will get either foggy or frosty. Use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. The dew point rises with the temperature in the cabin, and it rises faster than the windshield temperature can adjust, resulting in temporary fog. If the air is very humid, the dew point is going to be very close to the cabin temperature, which makes it likely that it will be higher than the windshield temperature. Extra passengers will create a more humid atmosphere in the cabin. Try to increase air flow using the Cabin Air lever or overhead air vents in order to decrease the humidity or temperature. Alternatively, disable the effect by going to the menu "Cessna 172P", selecting "Aircraft Options" and disable the option "Enable frost and fog".

'''Q:''' How do I increase the cabin air temperature?

'''A:''' Increase the cabin air temperature by opening the Cabin Heat lever. In order to actually get a heated air flow, you need a medium or high EGT (Exhaust Gas Temperature -- the instrument between the yoke and the ADF instrument), and airspeed and/or sufficient propeller RPM.

'''Q:''' How can I click on a switch which is being covered by the yoke?

'''A:''' You can hide the yokes by clicking on them or by going to the menu "Cessna 172P", selecting "Hide/Show Yokes".

== Etat du development/Problèmes/A faire ==

Cet avion est en développement constant, vous pouvez suivre les avancées sur [https://github.com/Juanvvc/c172p-detailed le repository], il y a aussi une [https://github.com/Juanvvc/c172p-detailed/issues liste des problèmes et améliorations futures].

== Gallérie ==

<gallery mode="packed">
c172p-plane5.jpg|Cessna 172P au dessus de Chapada Diamantina au Brésil
c172p-plane4.jpg|Décollage à Compiegne Margny (LFAD)
c172p-cockpit2.jpg|Sur le point d'attérir, demonstration du nouvel effet d'ombre ALS dans le cockpit
c172p-floats.jpg|Variante avec flotteurs à San Francisco
c172p-plane3.jpg|Cessna 172P volant à haute altitude au dessus de Lago di Garda en Italie
c172p-landing.jpg|On final at Aosta Airport (LIMW)
c172p-cockpit3.jpg|L'interrieur texturé du nouveau c172p
c172p-night.jpg|Un vol de nuit, montrant l'illumination des instruments
c172p-particles.jpg|Décollage sur l'eau, montrant le système de particules
c172p-plane1.jpg|Au dessus de Serra do Mar au Brésil
c172p-plane2.jpg|Coucher de soleil
c172p-winter.jpg|L'hiver en Europe
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|If the conditions are just right, frost or fog will appear in the windows
c172p-taubate.jpg|Vol au dessus de Taubate, Brésil

</gallery>

=== Liens externes ===
* [http://en.wikipedia.org/wiki/Cessna_172 Wikipedia article]
* [http://www.atlasaviation.com/checklists/cessna-172/cessna_172_checklist.htm Cessna 172 checklists at AtlasAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[zh:Cessna 172P]]

Fr/Cessna 172P

2016-07-23T08:57:55Z

Tipunch: translation from the c172p detailed 1/2

{{BeingTranslated}}

{{:{{#titleparts:{{PAGENAME}}||2}}/info}}
Le '''Cessna 172 Skyhawk''' est un [[Fr/Avions|avion]] quadriplace, monomoteur à aile haute. Il effectua son premier vol en 1955 et est toujours en production, plus de Cessna 172 ont été construits que tout autres avions.

Le C 172 est l'avion par défaut dans [[FlightGear]] depuis 2000, il a remplacé le [[Navion]]. Il a eu un long développement et il inclut une grande variété de fonctionnalités pour FlightGear. En 2015, il a été complètement rénové ; cela comprend de nouvelles options de moteur, de taille de pneus ou de flotteurs, ainsi qu'une refonte complète du cockpit. Cette nouvelle version détaillée de l'avion est devenu l'avion inclus en standard depuis [[Changelog_3.6|FlightGear 3.6]].

== Contenu et variantes ==

The new C172p has a much better 3D model and is now fully textured (including the interior). All the switches in the cockpit are clickable. It also has an improved FDM, more complex procedures and new realistic checklists, new sound effects, and damage modelling. The aircraft can get damaged if mishandled (e.g. gear collapse after a hard landing).

[[File:C172p-bodensee-panorama.jpg|center|800px]]

The aircraft currently has five variants, all available from the aircraft menu:
* regular wheels
* 26" bush tires
* 31" bush tires
* pontoons
* amphibian
* snow skis

Also, from the same menu, the user can select two different engines:
* 160 HP
* 180 HP (recommended when using pontoons, amphibian and skis variants)

The aircraft now can get damaged from collisions, crashes, hard landings or overload while in-flight, and the modelling includes wheel collapse, wings breaking, etc. The damage can be turned off in the aircraft menu, which also contains an option for repairing the aircraft.

The windows now can get foggy or frosty, depending on the combination of interior and exterior temperatures. The pilot must then use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. Alternatively, it's possible to disable the effect in the "Aircraft Options" in the "Cessna 172P" menu. This effect depends on the new ALS effects found in 3.5 and above, and will also have the side effect of producing grey windows in versions prior to 3.5.

The FDM has also been modified. The aircraft may enter into a spin in case of an asymmetric stall (a particularly dangerous situation when turning to final, in which case the aircraft is at low speed and low height). The FDM has also been tweaked to include hydrodynamics effects while taking off or landing on water, as well as adding a new 180 HP engine.

There are several liveries available, some of which have higher resolution than others, which are marked as HD in the liveries menu. Each of the HD liveries also has unique cockpit and interior textures.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]].

Also, if the user has enabled ALS (Atmospheric light scattering) in the Rendering Options, then it's possible to activate the flashlight by clicking on the "Cessna 172P" menu and selecting "Flashlight". Select it once for the white flashlight, select it again for a red one and select it one more time to turn it off.

The aircraft can now go through a pre-flight: wheel chocks, tie-downs and the pitot tube cover can now be added or removed, oil management and fuel contamination by water have been implemented (both of which are not activated by default, but are available in the aircraft menu).
[[File:c172p-ALS-flashlight2.jpg|500px|center|Lampe de poche du Cessna 172P's dans le cockpit]]

== Aide de l'avion ==

=== Inspection avant le vol ===
[[File:C172p-secured-Aosta.jpg|270px||thumb|Cessna 172P sécurisé à l'aéroport d'Aosta]]
It's recommended to use any exterior view or activate the walker for these procedures.
* Fuel quantity: add by clicking on the fuel tank caps above each wing
* Right wing: remove tie-downs
* Right wing: check for fuel contamination by clicking under the wing and take a fuel sample. If the sample is light blue, the fuel is not contaminated and can be returned to the tank. If the sample is transparent or partially transparent, you must discard it and take new samples until they are completely light blue
* Nose: check for oil quantity by clicking on the oil door in the nose. Critical oil level for either engine is 5.0 quarts.
* Nose: remove wheel chocks
* Left wing: remove tie-downs
* Left wing: remove pitot tube cover
* Left wing: check for fuel contamination

=== Mise en route (démarrage simple ou complexe) ===
* Priming: pompez le moteur au moins 3 fois
* Mixture: Riche (manette rouge poussée à fond)
* Gaz: 1/8" (1/2 cm)
* Frein de parking: Serré ({{Key press|Shift|B}})
* Zone autour de l'hélice: Dégagée
* Magnétos: Both ({{Key press|<nowiki>}</nowiki>}} trois fois)
* Démarreur ({{Key press|S}})

=== Démarrage moteur (automatique avec l'Autostart) ===
* Dans le menu "Cessna C172P", choisissez "Autostart" puis garder la touche {{Key press|S}} appuyée pour démarrer l'avion.

=== Décollage ===
[[File:c172p-cockpit.jpg|270px||thumb|Cessna 172P prêt au décollage]]
* Volets rentrés
* Plein gaz
* Rotation à 55 KIAS

=== Montée ===
* Volets rentrés
* Plein gaz
* 75 KIAS

=== Croisière ===
* gaz: 65%
* mixture: "rich of peak"

=== Atterrissage ===
[[File:c172p-landing2.jpg|270px||thumb|Cessna 172P sur le point d'atterrir]]
* Volets: tout sorti
* 60 KIAS

=== Vitesses limites ===

: ''Voir aussi [[Aircraft speed#V speeds]]''

The information in this section is based on external resources.<ref>[http://www.triangleaviation.com/1982_172r.html Triangle Aviation]{{dead link|2015-10}}</ref><ref>[http://www.otisair.com/c172info.html OtisAir's Airborne Observations]{{dead link|2015-10}}</ref><ref>{{cite web |url=http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/724e90061c5bf3b1862576260063e599/$FILE/3A12.pdf |title=Type Certificate No. 3A12, Revision 79 |date=27 August 2009 |work= |publisher=FAA |format=pdf |accessdate=9 October 2015}}</ref>

{| class="wikitable"
! Vitesse(Airspeed) !! Vitesse calibrée (CAS)
|-
| Vitesse de décrochage, configuration pour l’atterrissage, V<sub>S<sub>0</sub></sub> || 33 kt
|-
| Vitesse de décrochage, V<sub>S<sub>1</sub></sub> || 44 kt
|-
| Vitesse de rotation, V<sub>R</sub> || 55 kt
|-
| Vitesse avec le meilleur angle of montée, V<sub>X</sub> || 59 kt
|-
| Vitesse avec la montée la plus rapide, V<sub>Y</sub> || 76 kt
|-
| Vitesse maximale avec les volets sortis, V<sub>FE</sub> || 85 kt
|-
| rowspan="2" valign="top" | Vitesse de manœuvre, V<sub>A</sub> || 96 kt (flotteurs)
|-
| 99 kt (roues)
|-
| Vitesse maximale de croisière pour l’intégrité structurelle, V<sub>NO</sub> || 127 kt
|-
| Vitesse à ne jamais dépasser, V<sub>NE</sub> || 158 kt
|}

== FAQ ==

Here are some of the frequently asked questions about this aircraft:

'''Q:''' I am experiencing grey windows, what is happening?

'''A:''' If you experience grey windows, you do not have the correct FlightGear version. This aircraft requires 3.5 or above.

'''Q:''' Why does the aircraft keep turning left?

'''A:''' Please see [[understanding Propeller Torque and P-Factor]]. If using the amphibian model on a solid runway, note that at the taxiing is done by differential braking (the rudder becomes more and more effective as the plane gains speed).

'''Q:''' Why will the engine not start?

'''A:''' You can start the engine automatically by clicking on the menu "Cessna C172P", selecting "Autostart" and then simply holding the key {{Key press|S}}. For a manual start, please follow the checklists available by clicking on the menu "Help" followed by "Aircraft Checklists". As seen above, the engine must by "primed" before starting. If oil management is activated, you must have enough oil for the engine to work (more than 5.0 quarts). If fuel contamination is activated, the fuel must be light blue in order for the engine to properly work.

'''Q:''' Why does the engine die immediately after startup?

'''A:''' Probably because the throttle is being incremented too fast after startup as the engine needs a few seconds to stabilize itself.

'''Q:''' Why can't I start the sim with the engine running?

'''A:''' You can! Go to the menu "Cessna C172P", select "Aircraft Options" and tick the option "Start with engine running".

'''Q:''' Why the aircraft doesn't move?

'''A:''' The aircraft won't move if you have the parking brakes set, or if either of the wing tie-downs, the tail tie-down or wheel chocks are in place (if the option "allow securing aircraft" is enabled in the aircraft menu).

'''Q:''' Why the airspeed indicator doesn't work?

'''A:''' If the option "allow securing aircraft" is enabled in the aircraft menu, then very likely you forgot to remove the pitot tube cover.

'''Q:''' How can I switch to the bush tires/pontoons/amphibian?

'''A:''' By clicking in menu "Cessna 172P", selecting "Aircraft Options" and then selecting the other landing gear options.

'''Q:''' How can I switch to the 180 HP engine?

'''A:''' This is also done by clicking in menu "Cessna 172P", selecting "Aircraft Options" and then selecting the engine power option.

'''Q:''' Why can't I take off from the water without crashing the plane?

'''A:''' Taking off and landing on water can be quite tricky. Try applying a little bit of back pressure on the yoke while accelerating to 55 KIAS. It's also recommended to use the 180 HP engine instead of the default 160 HP, as the extra weight of the pontoons make it really hard to climb with the default engine.

'''Q:''' Why is the simulator lagging so much?

'''A:''' As with any complex 3D model, this new version of the c172p is a bit more demanding on the computers than the older one. If you are having troubles with performance, try using non-HD liveries which use textures with lower resolutions, as well as other solutions that can improve performance (disabling certain graphical options in the Rendering Options, lowering the resolution of FlightGear, etc.).

Some tricks that help to increase fps is by disabling all GUI windows, including the menu bar and the orange fps counters at the bottom of the screen. You can display an alternative fps counter in the top left corner via the "Debug" menu and then selecting "Cycle On-Screen Statistics". Make sure to hide the menu bar by pressing F10 to see the counter.

A second trick is to simply disable the rendering of all clouds if you don't mind. Start FlightGear with "--prop:/sim/rendering/draw-mask/clouds=0".

If you notice heavy slowdowns when flying over certain scenery and you see FlightGear generating many "Warning:: Picked up error in TriangleIntersect" messages in the terminal or log file, you can disable this by starting FlightGear with "--prop:/sim/rendering/osg-notify-level=fatal".

'''Q:''' Why are the windows getting foggy/frosty?

'''A:''' If the dew point of the cabin air temperature is higher than the surface temperature of the windshield, the windows will get either foggy or frosty. Use the Cabin Heat and Cabin Air levers (on the right of the flaps) to control it. The dew point rises with the temperature in the cabin, and it rises faster than the windshield temperature can adjust, resulting in temporary fog. If the air is very humid, the dew point is going to be very close to the cabin temperature, which makes it likely that it will be higher than the windshield temperature. Extra passengers will create a more humid atmosphere in the cabin. Try to increase air flow using the Cabin Air lever or overhead air vents in order to decrease the humidity or temperature. Alternatively, disable the effect by going to the menu "Cessna 172P", selecting "Aircraft Options" and disable the option "Enable frost and fog".

'''Q:''' How do I increase the cabin air temperature?

'''A:''' Increase the cabin air temperature by opening the Cabin Heat lever. In order to actually get a heated air flow, you need a medium or high EGT (Exhaust Gas Temperature -- the instrument between the yoke and the ADF instrument), and airspeed and/or sufficient propeller RPM.

'''Q:''' How can I click on a switch which is being covered by the yoke?

'''A:''' You can hide the yokes by clicking on them or by going to the menu "Cessna 172P", selecting "Hide/Show Yokes".

== Development status/Issues/TODO ==

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/Juanvvc/c172p-detailed repository], where a [https://github.com/Juanvvc/c172p-detailed/issues list of issues and future enhancements] can also be found.

== Gallery ==

<gallery mode="packed">
c172p-plane5.jpg|Cessna 172P au dessus de Chapada Diamantina au Brésil
c172p-plane4.jpg|Décollage à Compiegne Margny (LFAD)
c172p-cockpit2.jpg|Sur le point d'attérir, demonstration du nouvel effet d'ombre ALS dans le cockpit
c172p-floats.jpg|Variante avec flotteurs à San Francisco
c172p-plane3.jpg|Cessna 172P at high altitude flying over Lago di Garda in Italy
c172p-landing.jpg|On final at Aosta Airport (LIMW)
c172p-cockpit3.jpg|The fully textured interiors of the new c172p
c172p-night.jpg|A night flight, showing the instrument illumination
c172p-particles.jpg|Taking off on water, showing the particle system
c172p-plane1.jpg|Above Serra do Mar in Brazil
c172p-plane2.jpg|Flying at sunset
c172p-winter.jpg|European winter
c172p-damage.jpg|Gear collapse due to heavy landing
c172p-frost.jpg|If the conditions are just right, frost or fog will appear in the windows
c172p-taubate.jpg|Flying above Taubate, Brazil

</gallery>

=== Liens externes ===
* [http://en.wikipedia.org/wiki/Cessna_172 Wikipedia article]
* [http://www.atlasaviation.com/checklists/cessna-172/cessna_172_checklist.htm Cessna 172 checklists at AtlasAviation.com]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]

[[de:Cessna 172P]]
[[en:Cessna 172P]]
[[es:Cessna 172P]]
[[zh:Cessna 172P]]

Fr/Portal:Utilisateur

2016-07-23T07:45:19Z

Tipunch: added help section

{{Main page/Header
|title=Bienvenue sur le portail des utilisateurs
|subtitle=''Volez librement!''
|introduction= Si vous ne trouvez pas ce que vous recherchez, vous pouvez visiter le [http://forum.flightgear.org forum anglophone] ou [http://fr.flightgear.tuxfamily.org/forum/index.php le forum francophone]
|rightbox=

|rightcolumn1= </div>
<span style="font-size:105%; font-weight:bold">Vous débutez?</span><br />
<span style="font-style:italic;">
[[Fr/Nouveau_sur_flightgear|Nouveau sur Flightgear]] · [[Fr/FlightGear_Manual|Manuel de Flightgear]]<br/>
[[Fr/Foire_aux_questions|Foire Aux Questions]]<br/>
[[Fr/Volontaires|Participer]]<br/>
[[Fr/Glossaire|Glossaire]]</span>
|rightcolumn2= [[File:Portal helpcenter.png|40px]] </div>
<span style="font-size:105%; font-weight:bold">[[Troubleshooting_problems|Problème / amélioration]]</span><br />
<span style="font-style:italic;">
[[Fr/Howto: Débarrassez-vous des erreurs les plus fréquentes|Erreurs fréquentes]]<br/>
[[Troubleshooting performance issues|Augmenter le nombre d'images par seconde]]<br/>
[[Fr/Anti-aliasing|Anti-aliasing]]</span>
|rightcolumn3= [[File:Portal aircraft.png|40px]] </div>
<span style="font-size:105%; font-weight:bold">Voler</span><br />
<span style="font-style:italic;">
[[Fr/Avions|Les avions]] · [[Fr/Helicoptere|Les hélicoptères]] · [[Fr/Vehicules|Les véhicules]]<br/><br/>
[[Fr/Piloter_les_warbirds|Piloter les warbirds]] · [[Fr/Piloter l'hélicoptère|Piloter des hélicoptères]]<br/>
[[Fr/Ravitaillement_en_vol|Ravitaillement en vol]] · [[Howto: Carrier|Appontage sur porte-avion]]<br/>
[[Soaring|Vol à voile]] · [[Howto: Be a controller|Devenir contrôleur aérien]]<br/>
[[Fr/Howto:_Multijoueur|Mode multijoueur]]· [[Dual control|Multi-équipage]]· [[Weather|Météo]]<br/><br/>
[[Avionics and instruments|Avionique et instruments]] · [[Aircraft lighting|éclairages de l'avion]]<br/>
[[Fr/Altitude|Altitude]] · [[Fr/Vitesse de l'avion|Vitesse]] · [[Understanding Propeller Torque and P-Factor|Comprendre l'effet de couple et le Facteur P]]<br/>
[[Understanding Navigation|Navigation]] · [[Howto:Create a flightplan|Créer un plan de vol]]<br/>
[[List of abbreviations|Liste des abréviations]]</span>
|rightcolumn4= [[File:Portal hardware.png|40px]] </div>
<span style="font-size:105%; font-weight:bold">Matériel</span><br />
<span style="font-style:italic;">
[[Joystick|Joystick, manche et palonnier]] · [[Howto: Configure camera view windows|Affichage multiple]]<br/>
[[Fr/Hardware_Recommendations|Matériel prérequis]]</span>
|rightcolumn5= [[File:Portal star.png|40px]] </div>
<span style="font-size:105%; font-weight:bold">Articles conseillés</span><br />
<span style="font-style:italic;">
[[Suggested Aircraft|Avions suggérés]] · [[Suggested Airports/Scenery| Aéroports et scenes suggérés]]<br/>
[[Suggested Flights|Vols suggérés]] · [[Challenging Airports|Aéroports difficiles]]<br/>
[[Suggested Software|Logiciels]] </span>
|rightcolumn6= [[File:Portal tools.png|40px]] </div>
<span style="font-size:105%; font-weight:bold">Outils supplémentaires</span><br />
<span style="font-style:italic;">
[[FGo!]] · [[Fr/FlightGear_Launch_Control|FGRun]] · [[KFreeFlight]]<br/>
[[FGCOM]] · [[OpenRadar]] · [[ATC-pie]]<br/>
[[Fr/TerraSync|TerraSync]] · [[TerraMaster]]<br/>
[[Fr/Atlas|Atlas]] · [[Airport Diagram Generator]]</span>
|rightcolumn7= [[File:Portal promotion.png|40px]] </div>
<span style="font-size:105%; font-weight:bold">Promotion</span><br />
<span style="font-style:italic;">
[[Unique Features|Fonctionnalités uniques]] · [[FlightGear Reviews|Avis]]<br/>
[[FlightGear Videos|Vidéos]] · [[FlightGear logos|Logos]] · [[Howto:Make nice screenshots|Faire de belles captures d'écran]]<br/>
[[Presentation Recipe|Presentation recipe]] · [[FlightGear Expo Checklist|Expo checklist]]</span>


|sections=
{{Main page/Leftbox|title=Installation
|logo=Nuvola apps download manager.png
|contents=
{{{!}}
{{!}} valign="top" {{!}}
* [[Fr/Howto_Installer_un_avion|Ajouter des avions]]
* [[Fr/Installer_une_scène|Ajouter des scènes (aéroports,etc..)]]
{{!}} valign="top" {{!}}
* [[FlightGear hangars|Les hangars de Flightgear]]
{{!}}}
}}
{{Main page/Leftbox|title=Obtenir de l'aide
|contents=
* Chercher et demander de l'aide :
# Vous obtiendrez plus d'aide si vous vous êtes informé au préalable et que vous posez une question pertinente, donc :
#* Parcourez les liens sur cette page.
#* [[Special:Search|Chercher dans le wiki]].
#* [http://forum.flightgear.org/search.php Chercher dans le forum]. Si vous ne trouvez pas grand chose essayer la recherche Google ci-dessous.
#* [http://google.com Chercher avec Google] Plus utile qu'on ne le pense si vous ajouter le site Flightgear à la fin de la recherche "site:forum.flightgear.org".
# [http://forum.flightgear.org/viewforum.php?f=17 Demandez sur le forum de support] ou de préférence dans un des sous-forum en donnant le maximum d'information.

* Pour des problèmes simples, essayer le 'chat' dans le simulateur si d'autres pilotes sont à proximité, ou sur le canal IRC de FlightGear irc://#flightgear@irc.flightgear.org''
}}

{{Main page/Leftbox|title=Liens externe
|contents=
* [http://freechecklists.net/ Checklists]
* [http://www.faa.gov/library/manuals/ FAA Handbooks & Manuals]
* [http://fr.flightgear.tuxfamily.org/forum/index.php Forum FlightGear France]
* [http://www.gcmap.com/ Great Circle Mapper]
* [http://www.smartcockpit.com SmartCockpit.com]
* [http://www.worldaerodata.com/ World Aeronautical Database]

}}
}}

[[Category:Portals]]

[[de:Portal:Benutzer]]
[[es:Portal:User]]
[[en:Portal:User]]
[[it:Portal:Utente]]
[[pl:Portal:Dla użytkowników]]
[[zh:Portal:用户]]

Canary Islands Custom Scenery

2016-07-23T07:05:20Z

Tipunch: Category:Scenery enhancement projects

[[File:Las-Palmas-Apron.png|thumb|The fully modeled Las Palmas de Gran Canaria airport at dusk]]
The Canary Islands Custom Scenery project is an ambitious project of pilots, developers and supporters of the Canary Islands region. Its aim is to provide the region in a scenery quality as high and as detailed as possible. Other branches of this project take care about a more realistic local AI traffic, multiplayer events and local airlines.

The project is currently under development, with an increasing number of contributors and steady updated contents.

== History ==
The whole project started in June 2016, when passionate developers and former residents of the archipelago started several threads in the FlightGear-Forum. Scenery and model developers started to work on the textures, as well as on the terrain, the objects, the sea traffic and obviously on the airports. Within hours and days, a whole re-texturing of all seven major islands took place. Soon after that, the first 3D models for local urban areas were published and shared, and airports had been developed. Developers who had worked on one or two islands before, now shared their experiences and work with others. By now, the development is going on, already having several islands and airports modeled, but there is still a lot of work to do...

== Area description ==
The Canary Islands are an archipelago in the east Atlantic, off the coast of Morocco. While geographically belonging to Africa, their political status is that of an autonomous region of Spain.

Being called the "Islands of eternal spring", their climate is mostly warm, with an average temperature of 25°C. This makes all seven Islands perfect for tourism, so that this is the region's main income. Because of this very high tourist level, there are airports on all islands. Except for the airport of El Hierro (GCHI), every island has an international airport.
The weather is excellent for flying nearly all the time, some winds could make it a challenge, especially in smaller planes.
Aside from general air traffic, there are many touristic flights from central Europe, mostly from the Uk and Germany. Connections to the spanish mainland are provided by Vueling and Iberia.

Very interesting is the regional carrier sector, operated by the Canarian regional airline Binter Canarias.

== Why fly to the Canary Islands? ==
Having eight regional and international airports in such a small region is a very big advantage. This makes it very easy for pilots to improve their skills, especially takeoffs, approaches and landings.

The nicely-modeled scenery is worth a special look, so you really can enjoy your flight. A whole lot of people had visited the Islands for their holiday, so now you are able to really get that holiday feeling, when touching down at one of the nicely modeled airports.
The airports themselves are very different in style, conception, use and their level of difficulty. From the international airport of Las Palmas de Gran Canaria, where you can easily perform a landing with a 747 or A380 to the small one of El Hierro, where it can be difficult to have a touch down even with small regional turboprops, or the notorious Tenerife Norte - Los Rodeos, there are sites for every kind of aviator.

== Development ==
This custom scenery is currently under development. We are still working on the project, making it better and more realistic. It's not planned to publish it via [[TerraSync]] by now, maybe we are going to do that later. Actual and updated versions are accessible via {{github url|user=D-ECHO|repo=Canarys}}

== Status of the Project ==
The whole region is re-textured according to the actual vegetation and look.

You can see the airport development in the list below:

{| class="wikitable"
|-
! Airport !! Airport layout !! Airport buildings and furniture
|-
| GCRR || YES || NOT YET
|-
| CGFV || YES || NOT YET
|-
| GCLP || YES || YES
|-
| GCTS || YES || NOT YET
|-
| GCXO || YES || YES
|-
| GCGM || YES || YES
|-
| GCLA || YES || YES
|-
| GCHI || YES || YES
|}

== Things to contribute to ==
The following things need to be added or improved. Your help is appreciated! If you want to take care of one of the listed topics below, please leave a comment in the forum: https://forum.flightgear.org/viewtopic.php?f=5&t=29773

This avoids double processing, and gives us a notice what we can expect in the near term.

* Airport buildings and furniture for GCFV (Fuerteventura)
* Airport buildings and furniture for GCRR (Lanzarote)
* Airport buildings and furniture for GCTS (Tenerife Sur)
* regional AI Traffic (Binter Canarias Airline)
* Contributors to multiplayer events

[[Category:Scenery enhancement projects]]

OpenRadar

2016-07-23T06:57:27Z

Tipunch: Category:ATC clients

{{Infobox Software
| title = OpenRadar
| logo =
| image = OpenRadar Prototype.png
| alt = Frankfurt Airport (EDDF)
| developedby = Wolfram Wagner (Ralf Gerlich)
| initialrelease = Nov, 18th 2012
| latestrelease = May, 10th 2015
| writtenin = Java
| os = Linux, Windows, Mac
| platform = Java
| developmentstatus = active
| type =
| license =
| website = https://sourceforge.net/projects/openradar/
}}
[[File:OpenRadar_KSFO_large.png|thumb|270px|San Francisco bay area(historical)]]
[[File:OpenRadar_KSFO_closeup.png|thumb|270px|[[San Francisco International Airport]](historical)]]

'''OpenRadar''' is a standalone radar screen which connects to the [[FlightGear]] [[Howto: Multiplayer|multiplayer]] servers. Coastlines, lakes, airfield layouts and airspaces (at least the 2D part) are being read from shapefiles.
It supports Multiplayer Chat and multiple FGCom frequencies.

Please read the [[OpenRadarGuide| Guide to OpenRadar]]!

== Main Features ==
* ''Radar:''
:* Display of radar contacts
:* Highlighting of the selected contact, controlled and interesting contacts
:* Contacts can be neglected
:* Display of radar contact base data on screen
:* Airports including runway numbers, alignment lines, extended center lines, vectoring help and baselines
:* Navaids (FIX, NDB, VOR) toggle
:* Navaid search
:* Possibility to convert/define STARs and SIDs
:* Distance circles around airport
:* Ground net including parking positions
:* Free definable zoom levels (Ground, Tower, App, Sector), mouse wheel works additional (zoom level and centers is saved)
:* Zoom depending detail visibility (runway numbers close to ground, airways visible from further away)
* ''Multiplayer Chat''
:* Filter on selection and visibility
:* ''Automated multilanguage text handling like ATC-ML'' (The same texts are available, Live data is included into messages): Click on flight strip, choose message, add details and send the message in English and in one additional language, defined on per contact base
* ''FGCom'' Integration (multiple radios in parallel), PTT Button, FGCom started by OpenRadar in background
* ''Weather'' (Metar) Download and display (wind, air pressure, visibility)
* ''Runway display'' is using Metar information (magn. heading,length, width, cross wind stength, ILS frequency)
* Compensation of wind and magnetic declination
* Radar contacts displayed on ''Flight Strips''
:* Flight Strips can be ordered manual in sequence and arranged in list (3 columns)
:* Automatic ordering available
:* Comment editor to make notes on Flight Strips
* ''Transponder/Squawking''
:* Compatible to FGFS Git implementation (generic transponder in radio dialog)
:* Optional usable
:* Define a squawk code range
:* Assign a squawk code to a contact
:* Revoke a squawk code from a contact to release the contact out of control
* ''SetupDialog''
:* Search airports
:* Download new airport shape files from scenery database
:* Edit settings
:* Main switches to tweak OR (available inside OR via map menu

== Current state ==
[[OpenRadarDownload| Latest binary release download]]

== System requirements ==
OpenRadar is no application for a small, a weak computer without graphic acceleration. We need to handle a lot of data, perform permanent Geo to Map projections and display them on the screen, while you
are shifting the map.
And believe me, a small screen is bad for the eyes and your neck muscles :-)

* a screen wide enough to display everything (22'' can show about 20 radar contacts, with two radios and two runways active, if you control a small airport with less runways, 18'' should be minimum)
* a Java Runtime Environment 1.7.0 e.g. OpenJDK
* [[FGCom]] really recommended
* a rather good network connection (FGCom is a VoIP application and FG transmits data as UDP packages, they can get lost over a weak connection)

== Related content ==
* [[OpenRadarGuide|A guide to OpenRadar]]
* [[OpenRadar: Chat aliases|Chat Aliases]] Use aliases instead of the chat menu...
* [[OpenRadar: Transponder|Transponder support]] How to use squawk codes (requires contacts with a recent fgfs)
* [[OpenRadar: Editing routes|Editing STAR/SID routes]]
* [[OpenRadar_FGFS_ORCAM|ORCAM: Your window to the the airport]]

* [[OpenRadarDownload|'''Download'''! I want to try it!]], [[OpenRadar Change Log|Change Log]]
* [[OpenRadarKnownIssues|'''FAQ''' / Known Issues]]
* Please add your feature proposals to [[OpenRadarFeatureWishlist|this page]]!

[[Category:OpenRadar| ]]
[[Category:ATC clients]]

Howto:Build your own Panel or Cockpit - Communicating with the Simulator

2016-07-23T06:53:43Z

Tipunch: Category:Cockpit building

The panel consists of a number of physical switches, rotary encoders, meter movements, numeric and alphanumeric displays, led indicators, rotation sensors. Even a small plane such as the C172P contains over 100 distinct items that must communicate with the simulator.

A way is needed to communicate changes for each of these elements to the appropriate item in the property tree in the running simulator.

From the hardware perspective this communication involves

# Physical cockpit hardware: switches, encoders, instrument movements etc.
# Low level interfaces to gather or distribute raw data for the cockpit hardware
# A Master Client to
## interpret between raw and simulator data
## handle communication between the cockpit and the simulator software

For the complete C172p there are:

* 12 volume controls
* 9 multi position switches
* 17 meter movements
* 50 spst switches
* 9 spdt switches
* 17 rotary encoders
* 7 instruments with rotational movement
* 12 3 to 6 digit numbers
* 4 3 letter Alpha displays
* 23 on/off indications on radios and instruments

The simplest implementation would about 300 gpio pins to drive every hardware element. We can reduce this number greatly by thinking carefully about how to

Some low level interfaces can use an ATMega processor of some type, probably an ATMEGA8535 or ATMEGA8515. Each of these can handle inputs and outputs for specific controls, switches, instruments and radios. Because the number of pins on the microprocessors is limited, there will be several of them. Other interfaces such as the display of 7 and 16 segment Numbers and letters can be handled using a driver chip such as the Max7221. Another approach is to use I2c or SPI to aggregate data from multiple cockpit elements into a single message.

From a software perspective, we'll need programming for:

# a telnet client handling communicating between a raspberry pi and Flightgear
# managing communication between the raspberry pi and lower level interfaces
# interpreting various types of simulator properties
# handling raw data for
## single and multi position switch data
## data from rotary encoders
## data going to numeric displays
## rotation and rotational position sensing for certain instruments

[[Category:Cockpit building]]